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 jo...@sicking.cc 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
), I've pretty much always tried to use |auto|. MakeUnique, and
std::make_unique if STLport ever dies the final death, should IMO be
considered idiomatic. If you read them, you *know* that what's returned is
a uniquely owned pointer. And by the very nature of these types, only one
owner ever exists
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
Jonas Sicking writes:
On Sun, Aug 2, 2015 at 3:47 AM, Xidorn Quan quanxunz...@gmail.com 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()
On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson mozn...@karlt.net wrote:
but I don't see much advantage of public constructors over
something like
static already_AddRefedFoo Foo::Create()
or
static nsRefPtrFoo Foo::Make()
Fair enough. Though it is somewhat more boilerplate in the class
On Mon, Aug 3, 2015 at 6:03 PM, Mike Hommey m...@glandium.org 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 mozn...@karlt.net wrote:
but I don't see much advantage of public constructors over
something like
static
On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking jo...@sicking.cc 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 Sun, Aug 2, 2015 at 8:37 PM, Joshua Cranmer pidgeo...@gmail.com 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
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
, consider again when about to use auto. It usually doesn't
make the code easier to read,
and it occasionally just leads to errors. In this case it clearly made
the code harder to read so that
whoever reviewed that patch didn't catch the issue.
Shouldn't we, instead, ensure that SomeRefCountedFoo
= 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 leads to errors. In this case it clearly made
the code harder to read so
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 what type
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 code
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
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,
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 leads to errors. In this case it clearly made
the code harder to read so that
whoever reviewed that patch didn't catch
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 leads to errors. In this case it clearly made
the code harder to read so that
whoever reviewed that patch didn't catch the issue.
Shouldn't we
this
and never using a raw pointer... We're currently much closer to the
never use auto in this situation world than to the other, of course.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
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, it forces
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
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
On 06/03/2015 12:12 AM, Seth Fowler wrote:
On Jun 2, 2015, at 1:59 PM, L. David Baron dba...@dbaron.org 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
On Wed, Jun 3, 2015 at 12:14 AM, Joshua Cranmer pidgeo...@gmail.com 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
On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey m...@kylehuey.com 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
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 a
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
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
On Tue, Jun 2, 2015 at 1:23 PM, L. David Baron dba...@dbaron.org 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
On Tuesday 2015-06-02 13:43 -0700, Martin Thomson wrote:
On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey m...@kylehuey.com 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
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 using it are:
- It makes the code
On Tue, Jun 2, 2015 at 1:59 PM, L. David Baron dba...@dbaron.org 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
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 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 for
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
On Jun 2, 2015, at 1:59 PM, L. David Baron dba...@dbaron.org 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
36 matches
Mail list logo
