On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari wrote:
> On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote:
>
>> But, shouldn't we just name these std::move and std::forward and use these
>> implementations only when we're using STLPort? I know we're not supposed
>> to
>> add stuff to the std:: na
On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote:
> On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith
> wrote:
>
> > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey
> > wrote:
> >
> > > Note that STL is another story. We're not using libstdc++ that
> > > comes with the compiler on android a
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote:
> On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey wrote:
>
> > Note that STL is another story. We're not using libstdc++ that comes
> > with the compiler on android and b2g. We use STLport instead, and STLport
> > has, afaik, no support for C++11
On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey wrote:
> Note that STL is another story. We're not using libstdc++ that comes
> with the compiler on android and b2g. We use STLport instead, and STLport
> has, afaik, no support for C++11 STL types. So, while we can now fix
> nsAutoPtr to use move sem
On 7/22/2013 6:05 PM, Rob Arnold wrote:
Ah, you're right. Bad example. 'UseFoo(new T)' compiles but leaks,
'nsRefPtr foo() { nsRefPtr bar(...); ...; return bar; }' is a
use-after-tree in cases like 'T* p = foo();' and there are probably a
number of other cases that the compiler allows and/or wri
On Mon, Jul 22, 2013 at 10:01 PM, Rob Arnold wrote:
> That idiom seems dangerous by itself; the assumption it makes is that the
> reference will outlive the callee but that isn't actually enforced anywhere
> (you could write UseFoo(nsRefPtr(new T)) and Bad Things would happen;
> there are less obv
On Mon, Jul 22, 2013 at 12:46 PM, Benjamin Smedberg
wrote:
> On 7/22/2013 3:01 PM, Rob Arnold wrote:
>
>>
>> Wouldn't disallowing this implicit conversion break code which does
>>
>>void UseFoo(nsIFoo* foo);
>>
>>nsCOMPtr foo;
>>UseFoo(foo);
>>
>> ? That is an extremely common idiom i
On 7/22/2013 3:01 PM, Rob Arnold wrote:
Wouldn't disallowing this implicit conversion break code which does
void UseFoo(nsIFoo* foo);
nsCOMPtr foo;
UseFoo(foo);
? That is an extremely common idiom in our code.
That idiom seems dangerous by itself; the assumption it makes is that th
On 7/22/2013 1:59 AM, Justin Lebar wrote:
It seems really dangerous that there is an implicit conversion from a strong
ref ptr to a weak pointer. With C++11, you can thankfully require this
conversion to be explicit which should alleviate your concern.
Wouldn't disallowing this implicit conversi
On 13-07-22 10:30 AM, Ehsan Akhgari wrote:
> That's not possible in C++11. Thinking about this more, the reason that
> this works fine for std::shared_ptr is the fact that it does _not_ have
> a T* implicit conversion operator. Therefore, we can't switch to rvalue
> references to replace already_
On Sun, Jul 21, 2013 at 11:59 PM, Justin Lebar wrote:
> > It seems really dangerous that there is an implicit conversion from a
> strong
> > ref ptr to a weak pointer. With C++11, you can thankfully require this
> > conversion to be explicit which should alleviate your concern.
>
> Wouldn't disall
On 2013-07-22 2:59 AM, Justin Lebar wrote:
It seems really dangerous that there is an implicit conversion from a strong
ref ptr to a weak pointer. With C++11, you can thankfully require this
conversion to be explicit which should alleviate your concern.
Wouldn't disallowing this implicit conver
On 7/22/2013 4:40 AM, Neil wrote:
Robert O'Callahan wrote:
On Mon, Jul 22, 2013 at 3:58 PM, L. David Baron
wrote:
Is the idea here that nsRefPtr/nsCOMPtr/etc. would have move
constructors, and we'd just return them, and the move constructors
plus return value optimizations would take care
Robert O'Callahan wrote:
On Mon, Jul 22, 2013 at 3:58 PM, L. David Baron wrote:
Is the idea here that nsRefPtr/nsCOMPtr/etc. would have move constructors, and
we'd just return them, and the move constructors plus return value
optimizations would take care of avoiding excess reference counti
> It seems really dangerous that there is an implicit conversion from a strong
> ref ptr to a weak pointer. With C++11, you can thankfully require this
> conversion to be explicit which should alleviate your concern.
Wouldn't disallowing this implicit conversion break code which does
void UseFo
On Sun, Jul 21, 2013 at 10:39 PM, Justin Lebar wrote:
> AIUI the new constructor would be something like
>
> nsRefPtr(nsRefPtr&& aOther)
>
> where "&&" means "r-value", which means "temporary", so "moveable".
>
Yes, this is why you want to be careful when returning them. The rules
should be mor
On Mon, Jul 22, 2013 at 5:39 PM, Justin Lebar wrote:
> But if we return nsRefPtr, then if I have
>
> nsRefPtr GetFoo();
> Foo* = GetFoo();
>
> that compiles fine (I think?) because nsRefPtr has an implicit
> conversion to T*.
>
It doesn't leak, though. OTOH you probably get a use-after-free,
AIUI the new constructor would be something like
nsRefPtr(nsRefPtr&& aOther)
where "&&" means "r-value", which means "temporary", so "moveable".
But I'm not totally sure about being able to return nsRefPtr.
Right now, if I do
already_AddRefed GetFoo();
Foo* foo = GetFoo();
that's a comp
On Mon, Jul 22, 2013 at 3:58 PM, L. David Baron wrote:
> Is the idea here that nsRefPtr/nsCOMPtr/etc. would have move
> constructors, and we'd just return them, and the move constructors
> plus return value optimizations would take care of avoiding excess
> reference counting?
>
That, plus forge
On Friday 2013-07-19 12:15 +1200, Robert O'Callahan wrote:
> On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari wrote:
>
> > On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
> >
> > r-value references 4.3@10.0! Yes
> >>
> >
> > This is very useful. I believe the JS engine alre
On 07/21/2013 11:44 AM, Justin Lebar wrote:
> That's a fair point. Maybe we should call ours mozilla::Move and
> mozilla::Forward instead. That way we can still easily change them to
> std::move and std::forward, but there's no possibility of a collision.
This is pretty much always what we've do
>> Maybe we should call ours mozilla::move and mozilla::forward so that we
>> can change to std::move and std::forward with minimal pain?
>>
> Won't that cause confusion if someone accidentally has both using namespace
> mozilla; and using namespace std; at the same time?
That's a fair point. May
On 21/07/2013 17:56, Neil wrote:
Won't that cause confusion if someone accidentally has both using
namespace mozilla; and using namespace std; at the same time?
Possibly but our coding guidelines suggest that we avoid using ...;
statements preferring to wrap code into namespace ... { ... };
c
Justin Lebar wrote:
Maybe we should call ours mozilla::move and mozilla::forward so that we can
change to std::move and std::forward with minimal pain?
Won't that cause confusion if someone accidentally has both using
namespace mozilla; and using namespace std; at the same time?
--
Warning:
Maybe we should call ours mozilla::move and mozilla::forward so that we can
change to std::move and std::forward with minimal pain?
On Jul 19, 2013 4:36 PM, "Ehsan Akhgari" wrote:
> On 2013-07-19 7:04 PM, Mike Hommey wrote:
>
>> On Fri, Jul 19, 2013 at 03:45:13PM -0400, Ehsan Akhgari wrote:
>>
>>
On 2013-07-19 7:04 PM, Mike Hommey wrote:
On Fri, Jul 19, 2013 at 03:45:13PM -0400, Ehsan Akhgari wrote:
On 2013-07-19 3:26 PM, Ehsan Akhgari wrote:
On 2013-07-18 10:46 PM, Mike Hommey wrote:
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
On 7/18/2013 7:15 PM, Robert O'Call
On Fri, Jul 19, 2013 at 03:45:13PM -0400, Ehsan Akhgari wrote:
> On 2013-07-19 3:26 PM, Ehsan Akhgari wrote:
> >On 2013-07-18 10:46 PM, Mike Hommey wrote:
> >>On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
> >>>On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
> On Fri, Jul 19,
On 2013-07-19 3:26 PM, Ehsan Akhgari wrote:
On 2013-07-18 10:46 PM, Mike Hommey wrote:
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari
wrote:
On 2013-07-18 5:48 AM, mscl...@googlem
On 2013-07-18 10:46 PM, Mike Hommey wrote:
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari
wrote:
On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
r-value references
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
> On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
> >On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari
> >wrote:
> >
> >>On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
> >>
> >> r-value references 4.3@10.0! Yes
On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari wrote:
On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
r-value references 4.3@10.0! Yes
This is very useful. I believe the JS engine already rolls their own
tricks to implem
On Thu, Jul 18, 2013 at 11:34:53AM -0400, Ehsan Akhgari wrote:
> On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
> > From that table, using the gcc and msvc versions, that gives:
> >
> > gcc msvcclang auto 4.4 10.0*
> > Yes
>
>
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari wrote:
> On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
>
> r-value references 4.3@10.0! Yes
>>
>
> This is very useful. I believe the JS engine already rolls their own
> tricks to implement this semantics.
>
With this we c
On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
From that table, using the gcc and msvc versions, that gives:
gcc msvcclang
auto4.4 10.0* Yes
Yes, please!
decltype4.3@10.0@ 2.9
Yes
On 2013-07-18 10:49 AM, Joshua Cranmer 🐧 wrote:
On 7/18/2013 9:44 AM, Ehsan Akhgari wrote:
On 2013-07-18 5:32 AM, Mike Hommey wrote:
A good resource is http://wiki.apache.org/stdcxx/C++0xCompilerSupport
Our base versions are 4.4 for gcc, and 10.0 for MSVC. I'm not sure what
our lowest supported
On 7/18/2013 9:44 AM, Ehsan Akhgari wrote:
On 2013-07-18 5:32 AM, Mike Hommey wrote:
A good resource is http://wiki.apache.org/stdcxx/C++0xCompilerSupport
Our base versions are 4.4 for gcc, and 10.0 for MSVC. I'm not sure what
our lowest supported version of clang is.
As of bug 870173, it's 3.
On 2013-07-18 5:32 AM, Mike Hommey wrote:
On Wed, Jul 17, 2013 at 05:09:22PM +0900, Mike Hommey wrote:
On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote:
On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
We've dropped support for versions of MSVC prior to 2010, and
we're req
On 7/18/2013 4:32 AM, Mike Hommey wrote:
And it's now done. Thanks to Ted Mielczarek and Ben Hearsum for the
quick reviews, and Aki Sasaki for the buildbot reconfig.
Now we can start discussing what specific features we want to start
using. Bug 895322 has already been filed to use static_assert
On Thursday, 18 July 2013 10:32:35 UTC+1, Mike Hommey wrote:
> On Wed, Jul 17, 2013 at 05:09:22PM +0900, Mike Hommey wrote:
>
> > On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote:
>
> > > On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
>
> > > > We've dropped support for v
On Wed, Jul 17, 2013 at 05:09:22PM +0900, Mike Hommey wrote:
> On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote:
> > On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
> > > We've dropped support for versions of MSVC prior to 2010, and
> > > we're requiring at least GCC 4.4. Acc
On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote:
> On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
> > We've dropped support for versions of MSVC prior to 2010, and we're
> > requiring at least GCC 4.4. According to [0] that means we should
> > be able to use *auto*. Anybod
On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
> We've dropped support for versions of MSVC prior to 2010, and we're
> requiring at least GCC 4.4. According to [0] that means we should be
> able to use *auto*. Anybody know any reasons why we can't start using
> it?
Filed bug 894242.
On Sun, Jul 14, 2013 at 10:50:55PM -0700, Justin Lebar wrote:
> > We can't require any c++11 feature until we drop support for gcc
> > 4.4. [...] there are problems in the gcc 4.4 system headers that
> > make using c++11 mode impossible (except on b2g/android).
>
> Is there any reason to support
On 7/14/13 10:50 PM, Justin Lebar wrote:
>We can't require any c++11 feature until we drop support for gcc 4.4.
>[...] there are problems in the gcc 4.4 system headers that make using c++11
mode impossible (except on b2g/android).
Is there any reason to support gcc 4.4 outside of B2G/Android?
On 7/13/2013 3:15 PM, Kyle Huey wrote:
We've dropped support for versions of MSVC prior to 2010, and we're
requiring at least GCC 4.4. According to [0] that means we should be
able to use /auto/. Anybody know any reasons why we can't start using it?
We don't yet require C++11 mode when build
> We can't require any c++11 feature until we drop support for gcc 4.4.
> [...] there are problems in the gcc 4.4 system headers that make using c++11
> mode impossible (except on b2g/android).
Is there any reason to support gcc 4.4 outside of B2G/Android?
If we dropped support for gcc 4.4 on de
On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
> We've dropped support for versions of MSVC prior to 2010, and we're
> requiring at least GCC 4.4. According to [0] that means we should be able
> to use *auto*. Anybody know any reasons why we can't start using it?
We can't require any
47 matches
Mail list logo
