On 2015-08-02 11:21 AM, Boris Zbarsky wrote:
On 8/2/15 7:34 AM, Hubert Figuière wrote:
This is also part of why I'd suggest having an construction method that
will return a smart pointer - preventing the use of raw pointers.
Returning an already_AddRefed would prevent the use of raw pointers,
On 2015-08-03 10:22 PM, Martin Thomson wrote:
On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking wrote:
How would you make a factory function like the above fail?
Don't allow for the possibility. If Foo::Create() is directly
analogous to new Foo(), then it can't fail. Leave the failing for
late
On Tue, Aug 4, 2015 at 8:55 PM, Jeff Walden wrote:
> On 08/02/2015 07:17 AM, smaug wrote:
> > MakeAndAddRef would have the same problem as MakeUnique. Doesn't really
> tell what type is returned.
>
> For the MakeUnique uses I've added (doubtless many more have popped up
> since), I've pretty much
On 08/02/2015 07:17 AM, smaug wrote:
> MakeAndAddRef would have the same problem as MakeUnique. Doesn't really tell
> what type is returned.
For the MakeUnique uses I've added (doubtless many more have popped up since),
I've pretty much always tried to use |auto|. MakeUnique, and std::make_uniq
We could also do something like C++14's `make_unique`, which invokes
the constructor for you. Maybe `mkRefPtr(Arguments, To,
Some, Object, Constructor)`? (That way we wouldn't need the overhead on
each declaration - we could use static analysis to prevent direct
construction if we wanted).
Th
On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking wrote:
> How would you make a factory function like the above fail?
Don't allow for the possibility. If Foo::Create() is directly
analogous to new Foo(), then it can't fail. Leave the failing for
later method calls.
On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking wrote:
How would you make a factory function like the above fail? Returning
> an nsresult will make it not much better than NS_NewFoo() pattern.
> Returning null won't let you indicate a useful error code (though
> maybe there's no such thing as usefu
On Mon, Aug 3, 2015 at 6:03 PM, Mike Hommey wrote:
> On Mon, Aug 03, 2015 at 05:55:01PM -0700, Jonas Sicking wrote:
>> On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson wrote:
>> > but I don't see much advantage of public constructors over
>> > something like
>> >
>> > static already_AddRefed Foo:
On Mon, Aug 03, 2015 at 05:55:01PM -0700, Jonas Sicking wrote:
> On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson wrote:
> > but I don't see much advantage of public constructors over
> > something like
> >
> > static already_AddRefed Foo::Create()
> >
> > or
> >
> > static nsRefPtr Foo::Make()
On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson wrote:
> but I don't see much advantage of public constructors over
> something like
>
> static already_AddRefed Foo::Create()
>
> or
>
> static nsRefPtr Foo::Make()
Fair enough. Though it is somewhat more boilerplate in the class
itself. But may
FWIW Webkit has long had the convention of using Foo::create() as the sole
creation point for refcounted objects. I like the idea. Apart from
enforcing the invariant that every new object is addrefed, it can slightly
optimize object creation by initializing the refcount to 1.
Rob
--
lbir ye,ea ye
Jonas Sicking writes:
> On Sun, Aug 2, 2015 at 3:47 AM, Xidorn Quan wrote:
>> Probably we should generally avoid using constructor directly for
>> those cases. Instead, use helper functions like MakeUnique() or
>> MakeAndAddRef(), which is much safer.
>
> We used to have NS_NewFoo() objects all o
On Sun, Aug 2, 2015 at 8:37 PM, Joshua Cranmer 🐧 wrote:
> I've discussed this several times, but with we added operator T*() && =
> delete;, that would prevent the scenario you're talking about here.
And FWIW, I have patches that I'm going to shortly submit to bug
1179451 that do this for nsRefPt
On Sun, Aug 2, 2015 at 3:47 AM, Xidorn Quan wrote:
> On Sun, Aug 2, 2015 at 7:57 PM, Kyle Huey wrote:
>> On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
>>> On 02/08/15 04:55 AM, smaug wrote:
A new type of error 'auto' seems to cause, now seen on m-i, is
auto foo = new SomeRefCo
On 8/2/2015 10:21 AM, Boris Zbarsky wrote:
On 8/2/15 7:34 AM, Hubert Figuière wrote:
This is also part of why I'd suggest having an construction method that
will return a smart pointer - preventing the use of raw pointers.
Returning an already_AddRefed would prevent the use of raw pointers,
b
On 8/2/15 7:34 AM, Hubert Figuière wrote:
This is also part of why I'd suggest having an construction method that
will return a smart pointer - preventing the use of raw pointers.
Returning an already_AddRefed would prevent the use of raw pointers, but
would leak if the caller used "auto", rig
On 08/02/2015 02:34 PM, Hubert Figuière wrote:
On 02/08/15 07:17 AM, smaug wrote:
Probably we should generally avoid using constructor directly for
those cases. Instead, use helper functions like MakeUnique() or
MakeAndAddRef(), which is much safer.
MakeAndAddRef would have the same problem as
On 02/08/15 07:17 AM, smaug wrote:
>> Probably we should generally avoid using constructor directly for
>> those cases. Instead, use helper functions like MakeUnique() or
>> MakeAndAddRef(), which is much safer.
>
> MakeAndAddRef would have the same problem as MakeUnique. Doesn't really
> tell wha
On 02/08/15 05:57 AM, Kyle Huey wrote:
> On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
>> On 02/08/15 04:55 AM, smaug wrote:
>>> A new type of error 'auto' seems to cause, now seen on m-i, is
>>> auto foo = new SomeRefCountedFoo();
>>>
>>> That hides that foo is a raw pointer but we shoul
On 08/02/2015 01:47 PM, Xidorn Quan wrote:
On Sun, Aug 2, 2015 at 7:57 PM, Kyle Huey wrote:
On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
On 02/08/15 04:55 AM, smaug wrote:
A new type of error 'auto' seems to cause, now seen on m-i, is
auto foo = new SomeRefCountedFoo();
That hides
On Sun, Aug 2, 2015 at 7:57 PM, Kyle Huey wrote:
> On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
>> On 02/08/15 04:55 AM, smaug wrote:
>>> A new type of error 'auto' seems to cause, now seen on m-i, is
>>> auto foo = new SomeRefCountedFoo();
>>>
>>> That hides that foo is a raw pointer b
On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière wrote:
> On 02/08/15 04:55 AM, smaug wrote:
>> A new type of error 'auto' seems to cause, now seen on m-i, is
>> auto foo = new SomeRefCountedFoo();
>>
>> That hides that foo is a raw pointer but we should be using nsRefPtr.
>>
>> So please, consider
On 02/08/15 04:55 AM, smaug wrote:
> A new type of error 'auto' seems to cause, now seen on m-i, is
> auto foo = new SomeRefCountedFoo();
>
> That hides that foo is a raw pointer but we should be using nsRefPtr.
>
> So please, consider again when about to use auto. It usually doesn't
> make the c
A new type of error 'auto' seems to cause, now seen on m-i, is
auto foo = new SomeRefCountedFoo();
That hides that foo is a raw pointer but we should be using nsRefPtr.
So please, consider again when about to use auto. It usually doesn't make the
code easier to read,
and it occasionally just le
On 18-06-15 11:31, smaug wrote:
>> One common "auto" usage I've seen is for storing the result of a
>> static_cast<>. In this scenario, it lets you avoid repeating yourself
>> and makes for more concise code.
>
> It still hurts readability.
> Whenever a variable is declared using auto as type, i
On 06/02/2015 11:56 PM, Daniel Holbert wrote:
On 06/02/2015 12:58 PM, smaug wrote:
So, I'd like to understand why people think 'auto' is a good thing to use.
(bz mentioned it having some use inside bindings' codegenerator, and
sure, I can see that being rather
valid case.)
One common "auto" us
On 06/02/2015 11:56 PM, Daniel Holbert wrote:
On 06/02/2015 12:58 PM, smaug wrote:
So, I'd like to understand why people think 'auto' is a good thing to use.
(bz mentioned it having some use inside bindings' codegenerator, and
sure, I can see that being rather
valid case.)
One common "auto" us
On 6/2/15 6:28 PM, Boris Zbarsky wrote:
On 6/2/15 6:12 PM, Seth Fowler wrote:
If you write this:
auto val = Bar();
Foo(val);
I think to preserve the semantics of Foo(Bar()) you need:
auto& val = Bar();
Foo(val);
but apart from that nit, I totally agree.
This. Allow auto or lift the
On Wed, Jun 3, 2015 at 12:14 AM, Joshua Cranmer 🐧 wrote:
> The case which I am personally very much on the fence is integral types. On
> the one hand, sometimes the type just doesn't matter and you want to make
> sure that you have the same type. On the other hand, I have been very burned
> before
On 06/03/2015 12:12 AM, Seth Fowler wrote:
On Jun 2, 2015, at 1:59 PM, L. David Baron wrote:
Remember that if 'auto' is forbidden, people might get around it by
not using a variable at all (and instead repeating the expression)
rather than by writing the type explicitly on the variable... and
On 6/2/15 6:12 PM, Seth Fowler wrote:
If you write this:
auto val = Bar();
Foo(val);
I think to preserve the semantics of Foo(Bar()) you need:
auto& val = Bar();
Foo(val);
but apart from that nit, I totally agree.
-Boris
___
dev-platform mail
> On Jun 2, 2015, at 1:59 PM, L. David Baron wrote:
>
> Remember that if 'auto' is forbidden, people might get around it by
> not using a variable at all (and instead repeating the expression)
> rather than by writing the type explicitly on the variable... and
> this doesn't provide type informa
On 6/2/2015 2:58 PM, smaug wrote:
Hi all,
there was some discussion in #developers about use of 'auto' earlier
today.
Some people seem to like it, and some, like I, don't.
The reasons why I try to avoid using it and usually ask to replace it
with the actual type when I'm
reviewing a patch
On Tue, Jun 2, 2015 at 1:59 PM, L. David Baron wrote:
>
> My assumption was that this would be for cases where neither the
> reader nor writer is likely to care about which integral type it is,
> and also cases that are near the threshold for whether to repeat (in
> source code or perhaps only in
On Tuesday 2015-06-02 13:43 -0700, Martin Thomson wrote:
> On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey wrote:
> >> auto len = aArray.Length();
> >> auto display = GetStyleDisplay()->mDisplay;
> >>
> >> It can save having to look up whether aArray.Length() returns size_t
> >> (I sure hope it does
Yeah, I like to ask myself whether I am losing any information by using
auto. If it ends up eliminating redundancy within a line of code, I like
to use it. OTOH if it eliminates useful human-friendly type information
from the code then I don't.
On 6/2/2015 2:43 PM, Martin Thomson wrote:
On Tu
On 06/02/2015 12:58 PM, smaug wrote:
> So, I'd like to understand why people think 'auto' is a good thing to use.
> (bz mentioned it having some use inside bindings' codegenerator, and
> sure, I can see that being rather
> valid case.)
One common "auto" usage I've seen is for storing the result of
On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey wrote:
>> auto len = aArray.Length();
>> auto display = GetStyleDisplay()->mDisplay;
>>
>> It can save having to look up whether aArray.Length() returns size_t
>> (I sure hope it does, though) or whether mDisplay is uint8_t or
>> uint16_t.
I have no s
On Tue, Jun 2, 2015 at 1:23 PM, L. David Baron wrote:
> On Tuesday 2015-06-02 22:58 +0300, smaug wrote:
> > So, I'd like to understand why people think 'auto' is a good thing to
> use.
> > (bz mentioned it having some use inside bindings' codegenerator, and
> sure, I can see that being rather
> >
On 02/06/15 21:58, smaug wrote:
> Perhaps my mind is too much on reviewer's side, and less on the code
> writer's.
I'd say it's the right place to put your mind. I always assume that code
I review (and hopefully code I write) will be read by countless
generations of contributors with much less exp
On Tuesday 2015-06-02 22:58 +0300, smaug wrote:
> So, I'd like to understand why people think 'auto' is a good thing to use.
> (bz mentioned it having some use inside bindings' codegenerator, and sure, I
> can see that being rather
> valid case.)
One context where I think it often makes sense is
41 matches
Mail list logo
