> On Jul 8, 2015, at 8:34 AM, Michael Layzell wrote:
>
> We're already working on a static analysis in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1180993 which will prevent code
> like that from passing try.
>
> Hopefully that will help with your concerns.
Yes, that will solve the proble
We're already working on a static analysis in
https://bugzilla.mozilla.org/show_bug.cgi?id=1180993 which will prevent
code like that from passing try.
Hopefully that will help with your concerns.
On 2015-07-07 12:59 PM, Seth Fowler wrote:
I brought this up on IRC, but I think this is worth ta
On Tue, Jul 7, 2015 at 9:59 AM, Seth Fowler wrote:
> I brought this up on IRC, but I think this is worth taking to the list:
>
> Replacing TemporaryRef with already_AddRefed has already caused at least
> one leak because already_AddRefed does not call Release() on the pointer it
> holds if nothin
I brought this up on IRC, but I think this is worth taking to the list:
Replacing TemporaryRef with already_AddRefed has already caused at least one
leak because already_AddRefed does not call Release() on the pointer it holds
if nothing takes ownership of that pointer before its destructor runs
On Tue, Jul 7, 2015 at 6:10 PM, Michael Layzell wrote:
> No, I never checked if it happens on an optimized build, but as C++ follows
> an "as-if" principal, which means that code has to execute as if those
> temporaries had been created. Unfortunately, AddRef and Release are virtual,
> which, I'm
On 2015-07-07 6:37 AM, Aryeh Gregor wrote:
Did you check whether this actually occurs in an optimized build? C++
allows temporaries to be optimized away under some circumstances,
e.g., when returning a local variable. It would make a lot of sense
to me if it allowed the temporary created by a t
On Fri, Jul 3, 2015 at 6:22 PM, Michael Layzell wrote:
> So the ternary actually causes an unnecessary AddRef/Release pair, neat.
Did you check whether this actually occurs in an optimized build? C++
allows temporaries to be optimized away under some circumstances,
e.g., when returning a local v
On Fri, Jul 3, 2015 at 3:56 PM, Neil wrote:
> Aryeh Gregor wrote:
>
>> we still want a new type for function parameters that accepts implicit
>> conversions from nsRefPtr/nsCOMPtr, to use instead of raw pointers.
>>
> Sure, but that won't stop someone from writing Arg foo = ReturnFoo2();
> will it
On Fri, Jul 3, 2015 at 8:56 AM, Neil wrote:
> Sure, but that won't stop someone from writing Arg foo =
> ReturnFoo2(); will it?
>
> Something like that is fairly trivial for a static analysis system like
our clang plugin to catch, if we want to create a type like that.
Restricting certain types t
Aryeh Gregor wrote:
we still want a new type for function parameters that accepts implicit
conversions from nsRefPtr/nsCOMPtr, to use instead of raw pointers.
Sure, but that won't stop someone from writing Arg foo =
ReturnFoo2(); will it?
--
Warning: May contain traces of nuts.
Nathan Froyd wrote:
I guess we could fix this in current m-c to be smarter about the parameter passing, perhaps by declaring that
ParameterStorage> is StoreCopyPassByConstLRef>? (Similarly
for nsRefPtr.)
So what's StorensRefPtrPassByPtr for?
--
Warning: May contain traces of nuts.
On Thu, Jul 2, 2015 at 3:50 PM, Neil wrote:
> Would you mind reminding me what the failure case this avoids is?
already_AddRefed
ReturnFoo1()
{
nsRefPtr foo = new Foo();
return foo.forget();
}
nsRefPtr
ReturnFoo2()
{
return new Foo();
}
// This doesn't compile
Foo* foo = ReturnFoo1();
//
On Thu, Jul 2, 2015 at 9:21 AM, Neil wrote:
> Nathan Froyd wrote:
>
>> I tried this, fixed a few compilation errors, then decided this wasn't
>> worth it just yet and threw my work into a bug. Comments appreciated:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1179451
>>
>>
> 1. It's beca
Nathan Froyd wrote:
I tried this, fixed a few compilation errors, then decided this wasn't worth it
just yet and threw my work into a bug. Comments appreciated:
https://bugzilla.mozilla.org/show_bug.cgi?id=1179451
1. It's because QueryInterface has to addref, so we can't directly
p
Jeff Muizelaar wrote:
I believe this is predicated on removing the implicit conversion from
nsRefPtr to T*
Would you mind reminding me what the failure case this avoids is?
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-p
On Wed, Jul 1, 2015 at 7:39 AM, Aryeh Gregor wrote:
> On Wed, Jul 1, 2015 at 6:24 AM, Joshua Cranmer 🐧
> wrote:
> > You'd get the same benefit, I think, by making operator T*() && =
> delete;, syntax which is accepted on gcc 4.8.1+, clang, and MSVC 2015 IIRC.
>
> I once tried this and found it h
On Wed, Jul 1, 2015 at 6:24 AM, Joshua Cranmer 🐧 wrote:
>
> You'd get the same benefit, I think, by making operator T*() && = delete;,
> syntax which is accepted on gcc 4.8.1+, clang, and MSVC 2015 IIRC.
I once tried this and found it had problematic side effects that made
deploying it difficult
On 6/30/2015 4:35 PM, Jeff Muizelaar wrote:
I believe this is predicated on removing the implicit conversion from
nsRefPtr to T*
You'd get the same benefit, I think, by making operator T*() && =
delete;, syntax which is accepted on gcc 4.8.1+, clang, and MSVC 2015 IIRC.
--
Joshua Cranmer
Thu
I believe this is predicated on removing the implicit conversion from
nsRefPtr to T*
-Jeff
On Tue, Jun 30, 2015 at 5:28 PM, Robert O'Callahan wrote:
> Will it ever be possible to eliminate TemporaryRef and use moves instead?
>
> Rob
> --
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oi
Will it ever be possible to eliminate TemporaryRef and use moves instead?
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
20 matches
Mail list logo
