------=_Part_84_25132963.1366728942216
Content-Type: text/plain; charset=ISO-8859-1

While the proposed make_unique() is very welcome, I feel the choice of name
is a mistake, based on a misconception. It is parallel to make_shared, but
it overlooks the fact that the "unique" in unique_ptr doesn't refer to the
same thing as the "shared" in shared_ptr. In shared_ptr the object is
shared; in unique_ptr it is the pointer which is unique. So while
make_shared<T> reads clearly as the creation of a shared T, make_unique<T>
is meaningless, because the object created isn't unique at all.

I see the function as a replacement for new (as described in the paper),
but using unique_ptr as a safer, no-overhead replacement for a raw pointer.
It should therefore simply be called make<T>(). That it returns a
unique_ptr is an important safety feature, but the use of the function is
to make an object.

Yechezkel Mett


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_84_25132963.1366728942216
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

While the proposed make_unique() is very welcome, I feel the choice of name=
 is a mistake, based on a misconception. It is parallel to make_shared, but=
 it overlooks the fact that the "unique" in unique_ptr doesn't refer to the=
 same thing as the "shared" in shared_ptr. In shared_ptr the object is shar=
ed; in unique_ptr it is the pointer which is unique. So while make_shared&l=
t;T&gt; reads clearly as the creation of a shared T, make_unique&lt;T&gt; i=
s meaningless, because the object created isn't unique at all.<div><br></di=
v><div>I see the function as a replacement for new (as described in the pap=
er), but using unique_ptr as a safer, no-overhead replacement for a raw poi=
nter. It should therefore simply be called make&lt;T&gt;(). That it returns=
 a unique_ptr is an important safety feature, but the use of the function i=
s to make an object.</div><div><br></div><div>Yechezkel Mett</div><div><br>=
</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_84_25132963.1366728942216--

.

------=_Part_3346_17734331.1366730012728
Content-Type: text/plain; charset=ISO-8859-1

I completely disagree. The purpose of make_pair is to make a pair,
make_tuple makes a tuple, make_shared makes a shared_ptr and make_unique
makes a unique_ptr. Also, the T itself is not shared at all, it is the
ownership of T which is shared, and the unique in unique_ptr refers to the
uniqueness of ownership of T, so they are completely the same.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3346_17734331.1366730012728
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I completely disagree. The purpose of make_pair is to make a pair, make_tup=
le makes a tuple, make_shared makes a shared_ptr and make_unique makes a un=
ique_ptr. Also, the T itself is not shared at all, it is the ownership of T=
 which is shared, and the unique in unique_ptr refers to the uniqueness of =
ownership of T, so they are completely the same.

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3346_17734331.1366730012728--

.

------=_Part_2083_5104699.1366734007915
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, April 23, 2013 4:13:32 PM UTC+1, DeadMG wrote:
>
> I completely disagree. The purpose of make_pair is to make a pair,
> make_tuple makes a tuple, make_shared makes a shared_ptr and make_unique
> makes a unique_ptr.


And make_exception_ptr makes an exception_ptr, so we *do* have precedence
for make_xxx_ptr.

A key difference is that make_pair, make_tuple and make_exception_ptr
deduce a type from their argument(s) and return a pair/tuple/exception_ptr
which contains the deduced type(s), so make_pair(1,2) means "make a pair
_containing_ 1 and 2"

make_unique and make_shared cannot deduce the type, so the call
make_shared<T>(args) can be read "make a shared T _from_ args" as opposed
to "make a shared_ptr _containing_ args". Considered that way make_unique
is exactly the same:  "make a T that will have unique ownership" vs "make a
T that will have shared ownership".



> Also, the T itself is not shared at all, it is the ownership of T which is
> shared, and the unique in unique_ptr refers to the uniqueness of ownership
> of T, so they are completely the same.


I completely agree.

We discussed this in Bristol and the overwhelming consensus was that
make_unique and make_shared are entirely analogous and that any name except
make_unique would be a bad idea.


(Somewhat confusingly, unique_ptr is described as owning an object while
shared_ptr is described as owning a pointer, but I think the meaning is
clear enough.)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2083_5104699.1366734007915
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 23, 2013 4:13:32 PM UTC+1, DeadMG wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">I completely disagree. The purpose of m=
ake_pair is to make a pair, make_tuple makes a tuple, make_shared makes a s=
hared_ptr and make_unique makes a unique_ptr. </blockquote><div><br>And mak=
e_exception_ptr makes an exception_ptr, so we *do* have precedence for make=
_xxx_ptr.<br><br>A key difference is that make_pair, make_tuple and make_ex=
ception_ptr deduce a type from their argument(s) and return a pair/tuple/ex=
ception_ptr which contains the deduced type(s), so make_pair(1,2) means "ma=
ke a pair _containing_ 1 and 2"<br><br>make_unique and make_shared cannot d=
educe the type, so the call make_shared&lt;T&gt;(args) can be read "make a =
shared T _from_ args" as opposed to "make a shared_ptr _containing_ args". =
Considered that way make_unique is exactly the same:&nbsp; "make a T  that =
will have unique ownership" vs "make a T that will have shared ownership".<=
br><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Also, the T=
 itself is not shared at all, it is the ownership of T which is shared, and=
 the unique in unique_ptr refers to the uniqueness of ownership of T, so th=
ey are completely the same.</blockquote><div><br>I completely agree.<br><br=
>We discussed this in Bristol and the overwhelming consensus was that=20
make_unique and make_shared are entirely analogous and that any name=20
except make_unique would be a bad idea.<br><br><br>(Somewhat confusingly, u=
nique_ptr is described as owning an object while shared_ptr is described as=
 owning a pointer, but I think the meaning is clear enough.)<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2083_5104699.1366734007915--

.

On 4/23/2013 16:55, ymett.on.usenet@gmail.com wrote:
> While the proposed make_unique() is very welcome, I feel the choice of
> name is a mistake, based on a misconception. It is parallel to
> make_shared, but it overlooks the fact that the "unique" in unique_ptr
> doesn't refer to the same thing as the "shared" in shared_ptr. In
> shared_ptr the object is shared; in unique_ptr it is the pointer which
> is unique. So while make_shared<T> reads clearly as the creation of a
> shared T, make_unique<T> is meaningless, because the object created
> isn't unique at all.
>
> I see the function as a replacement for new (as described in the
> paper), but using unique_ptr as a safer, no-overhead replacement for a
> raw pointer. It should therefore simply be called make<T>(). That it
> returns a unique_ptr is an important safety feature, but the use of
> the function is to make an object.
I have a related question, although on somewhat different grounds
(usability and genericity).
Wouldn't make<std::shared_ptr> and make<std::unique_ptr> be a more
generic choice?
In a generic code, this would allow to delay the ownership semantics
decision to a policy (supplied as a template parameter) stage.

This is mostly on the usability grounds -- to give another example, I
find the design of boost::lexical_cast

http://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/synopsis.html

more usable and generic compared to the family of

http://en.cppreference.com/w/cpp/string/basic_string/stol
http://en.cppreference.com/w/cpp/string/basic_string/stoul
http://en.cppreference.com/w/cpp/string/basic_string/stof

where type is expressed in the name.

Isn't this dangerously close to Systems Hungarian notation, which a
statically typed language like C++ doesn't really need (and where it
doesn't really belong)?

Best,

Matt
>
> Yechezkel Mett
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_2388_30544386.1366743640473
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, April 23, 2013 7:37:12 PM UTC+1, Matt D. wrote:
>
>
> I have a related question, although on somewhat different grounds
> (usability and genericity).
> Wouldn't make<std::shared_ptr> and make<std::unique_ptr> be a more
> generic choice?
> In a generic code, this would allow to delay the ownership semantics
> decision to a policy (supplied as a template parameter) stage.
>

But why would that be useful?

One of them is copyable, one is not, how much could you realistically do in
generic code without knowing whether you're dealing with a unique_ptr or a
shared_ptr?

If you need to copy it within your generic code then you have no choice,
only a shared_ptr is possible.

If you don't need to copy it and it's possible to only move it, then use
unique_ptr.  It can always be turned into a shared_ptr later by the caller
of your generic component if that's what they want.

If you really want to be generic, wouldn't it be better to take a functor
that creates the object, and let the caller provide something like
make_shared / make_unique / something_else ?

make_unique does what it says on the tin, don't overcomplicate it.



>
> This is mostly on the usability grounds


I think your suggestion fails on those grounds for many users' definition
of usability.



> -- to give another example, I
> find the design of boost::lexical_cast
>
>
> http://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/synopsis.html
>
> more usable and generic compared to the family of
>
> http://en.cppreference.com/w/cpp/string/basic_string/stol
> http://en.cppreference.com/w/cpp/string/basic_string/stoul
> http://en.cppreference.com/w/cpp/string/basic_string/stof
>
> where type is expressed in the name.
>


The new std::stoX functions should be as fast as the old C strtoX functions
in all cases (do you have any idea how long it took for lexical_cast to be
properly optimized for the simple and common cases?) and are less typing.

If you need the full genericity of lexical_cast<> to convert between any
two arbitrary types that support operator<< and operator>> then you still
have it.  In most codebases I've seen the majority of uses of lexical_cast
were for conversions between strings and arithmetic types, so the std::stoX
functions do that with less code and are more readable.



>
> Isn't this dangerously close to Systems Hungarian notation, which a
> statically typed language like C++ doesn't really need (and where it
> doesn't really belong)?
>

I'm not sure I understand what you're saying, but I don't think so.  Very
often I know I'm working with a string and I know I want to convert it to a
double, I don't really need a generic component for that.  What's
"dangerous" about that?


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2388_30544386.1366743640473
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 23, 2013 7:37:12 PM UTC+1, Matt D. wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><br>I have a related question, althoug=
h on somewhat different grounds=20
<br>(usability and genericity).
<br>Wouldn't make&lt;std::shared_ptr&gt; and make&lt;std::unique_ptr&gt; be=
 a more=20
<br>generic choice?
<br>In a generic code, this would allow to delay the ownership semantics=20
<br>decision to a policy (supplied as a template parameter) stage.
<br></blockquote><div><br>But why would that be useful?<br><br>One of them =
is copyable, one is not, how much could you realistically do in generic cod=
e without knowing whether you're dealing with a unique_ptr or a shared_ptr?=
<br><br>If you need to copy it within your generic code then you have no ch=
oice, only a shared_ptr is possible.<br><br>If you don't need to copy it an=
d it's possible to only move it, then use unique_ptr.&nbsp; It can always b=
e turned into a shared_ptr later by the caller of your generic component if=
 that's what they want.<br><br>If you really want to be generic, wouldn't i=
t be better to take a functor that creates the object, and let the caller p=
rovide something like make_shared / make_unique / something_else ?<br><br>m=
ake_unique does what it says on the tin, don't overcomplicate it.<br><br>&n=
bsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>This is mostly on the usability grounds</blockquote><div><br>I think yo=
ur suggestion fails on those grounds for many users' definition of usabilit=
y.<br><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> -- to g=
ive another example, I=20
<br>find the design of boost::lexical_cast
<br>
<br><a href=3D"http://www.boost.org/doc/libs/release/doc/html/boost_lexical=
_cast/synopsis.html" target=3D"_blank">http://www.boost.org/doc/libs/<wbr>r=
elease/doc/html/boost_<wbr>lexical_cast/synopsis.html</a>
<br>
<br>more usable and generic compared to the family of
<br>
<br><a href=3D"http://en.cppreference.com/w/cpp/string/basic_string/stol" t=
arget=3D"_blank">http://en.cppreference.com/w/<wbr>cpp/string/basic_string/=
stol</a>
<br><a href=3D"http://en.cppreference.com/w/cpp/string/basic_string/stoul" =
target=3D"_blank">http://en.cppreference.com/w/<wbr>cpp/string/basic_string=
/stoul</a>
<br><a href=3D"http://en.cppreference.com/w/cpp/string/basic_string/stof" t=
arget=3D"_blank">http://en.cppreference.com/w/<wbr>cpp/string/basic_string/=
stof</a>
<br>
<br>where type is expressed in the name.
<br></blockquote><div><br><br>The new std::stoX functions should be as fast=
 as the old C=20
strtoX functions in all cases (do you have any idea how long it took for
 lexical_cast to be properly optimized for the simple and common cases?) an=
d=20
are less typing.<br><br>If you need the full genericity of=20
lexical_cast&lt;&gt; to convert between any two arbitrary types that=20
support operator&lt;&lt; and operator&gt;&gt; then you still have it.&nbsp;=
 In most codebases I've seen the majority of uses of lexical_cast were=20
for conversions between strings and arithmetic types, so the std::stoX=20
functions do that with less code and are more readable.<br><br>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
<br>Isn't this dangerously close to Systems Hungarian notation, which a=20
<br>statically typed language like C++ doesn't really need (and where it=20
<br>doesn't really belong)?
<br></blockquote><div>&nbsp;</div><div>I'm not sure I understand what you'r=
e saying, but I don't think so.&nbsp; Very often I know I'm working with a =
string and I know I want to convert it to a double, I don't really need a g=
eneric component for that.&nbsp; What's "dangerous" about that?<br><br><br>=
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2388_30544386.1366743640473--

.

--001a11c2ab987a0cc704db0be17a
Content-Type: text/plain; charset=ISO-8859-1

On 23 April 2013 22:00, Jonathan Wakely <cxx@kayari.org> wrote:

>
>
> On Tuesday, April 23, 2013 7:37:12 PM UTC+1, Matt D. wrote:
>>
>> Wouldn't make<std::shared_ptr> and make<std::unique_ptr> be a more
>> generic choice?
>> In a generic code, this would allow to delay the ownership semantics
>> decision to a policy (supplied as a template parameter) stage.
>>
>
> But why would that be useful?
>
>
It can be, in compile-time factories and such, but I don't think that's a
use case common
enough to standardize it, nor do I think it's the way
make_shared/make_unique should
be done by default. It's not trivial to get make<T> right (when you're
invoking the generic
make for a dependent type), and it often causes more trouble than benefit.

I agree with Jonathan, such a solution would be overcomplicating a simple
facility.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c2ab987a0cc704db0be17a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 23 April 2013 22:00, Jonathan Wakely <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br><br>On Tuesday, April =
23, 2013 7:37:12 PM UTC+1, Matt D. wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">
Wouldn&#39;t make&lt;std::shared_ptr&gt; and make&lt;std::unique_ptr&gt; be=
 a more=20
<br>generic choice?
<br>In a generic code, this would allow to delay the ownership semantics=20
<br>decision to a policy (supplied as a template parameter) stage.
<br></blockquote></div><div><br>But why would that be useful?<br><br></div>=
</blockquote><div><br></div><div>It can be, in compile-time factories and s=
uch, but I don&#39;t think that&#39;s a use case common<br>enough to standa=
rdize it, nor do I think it&#39;s the way make_shared/make_unique should<br=
>
be done by default. It&#39;s not trivial to get make&lt;T&gt; right (when y=
ou&#39;re invoking the generic<br>make for a dependent type), and it often =
causes more trouble than benefit.=A0 <br><br></div><div>I agree with Jonath=
an, such a solution would be overcomplicating a simple facility.<br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2ab987a0cc704db0be17a--

.

This is a multi-part message in MIME format.
--------------070709090802050806080702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 4/23/2013 21:00, Jonathan Wakely wrote:
>
>
> On Tuesday, April 23, 2013 7:37:12 PM UTC+1, Matt D. wrote:
>
>
>     I have a related question, although on somewhat different grounds
>     (usability and genericity).
>     Wouldn't make<std::shared_ptr> and make<std::unique_ptr> be a more
>     generic choice?
>     In a generic code, this would allow to delay the ownership semantics
>     decision to a policy (supplied as a template parameter) stage.
>
>
> But why would that be useful?
>
> One of them is copyable, one is not, how much could you realistically
> do in generic code without knowing whether you're dealing with a
> unique_ptr or a shared_ptr?
>
> If you need to copy it within your generic code then you have no
> choice, only a shared_ptr is possible.
>
> If you don't need to copy it and it's possible to only move it, then
> use unique_ptr.  It can always be turned into a shared_ptr later by
> the caller of your generic component if that's what they want.
>
> If you really want to be generic, wouldn't it be better to take a
> functor that creates the object, and let the caller provide something
> like make_shared / make_unique / something_else ?
>
> make_unique does what it says on the tin, don't overcomplicate it.
Thanks for the reply -- and I can already see these (and Ville's,
thanks!) good points that make me more convinced here (that's what I
love about the discussions on std-proposals) :-)
// Disclaimer: while by default I presume that chances are that when
something is standardized as X, it is standardized as X for good
reasons, I'm genuinely curious about some of these reasons at times; so,
I find this helpful.

>
>
>
>     This is mostly on the usability grounds
>
>
> I think your suggestion fails on those grounds for many users'
> definition of usability.
>
>     -- to give another example, I
>     find the design of boost::lexical_cast
>
>     http://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/synopsis.html
>     <http://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/synopsis.html>
>
>
>     more usable and generic compared to the family of
>
>     http://en.cppreference.com/w/cpp/string/basic_string/stol
>     <http://en.cppreference.com/w/cpp/string/basic_string/stol>
>     http://en.cppreference.com/w/cpp/string/basic_string/stoul
>     <http://en.cppreference.com/w/cpp/string/basic_string/stoul>
>     http://en.cppreference.com/w/cpp/string/basic_string/stof
>     <http://en.cppreference.com/w/cpp/string/basic_string/stof>
>
>     where type is expressed in the name.
>
>
>
> The new std::stoX functions should be as fast as the old C strtoX
> functions in all cases (do you have any idea how long it took for
> lexical_cast to be properly optimized for the simple and common
> cases?) and are less typing.
>
> If you need the full genericity of lexical_cast<> to convert between
> any two arbitrary types that support operator<< and operator>> then
> you still have it. In most codebases I've seen the majority of uses of
> lexical_cast were for conversions between strings and arithmetic
> types, so the std::stoX functions do that with less code and are more
> readable.
Interesting!

Just so I can see if I can understand this correctly; we're considering
three families:
- std::stoi, std::stol, std::stoll
- std::stoul, std::stoull
- std::stof, std::stod, std::stold

Could a solution using, say, "from_string<T>" function template
introduce any performance penalty?
I'm essentially wondering about the inconsistency compared to
http://en.cppreference.com/w/cpp/string/basic_string/to_string (you're
right, lexical_cast is much broader)

Admittedly, these are overloads, but we can't deduce the return-type
anyway -- so I take it that we're always going to have to express the
type somehow, either as

long long stoll( const std::string& str, size_t *pos = 0, int base = 10 );

or, say,

template <typename T>
T from_string( const std::string& str, size_t *pos = 0, int base = 10 );

To my understanding, the branch on T will always occur at compile-time;
hence, there should be no performance penalty.
Am I missing something?

Regarding the length of the name -- good argument, I haven't thought of
that (again, thanks for pointing this out!).
I'm wondering, though, wouldn't it be a good idea to balance it against
the remaining factors?
For instance, as of this point, to my understanding there's no standard
(C++11) replacement for lexical_cast here:
http://www.bnikolic.co.uk/boostqf/tokenizer.html -- that's what I meant
by usability in this case (it goes hand in hand with genericity, since
it's genericity that makes lexical_case more useful for this particular
application).

In the end, even taking both the short-to-type-name and the genericity
as desirable goals, there might still be a way out using explicit
specialization, akin to:
http://ideone.com/PlXV1V
A related question -- if I use this as a workaround personally, and I'm
facing any downsides?

>
>
>     Isn't this dangerously close to Systems Hungarian notation, which a
>     statically typed language like C++ doesn't really need (and where it
>     doesn't really belong)?
>
> I'm not sure I understand what you're saying, but I don't think so.
> Very often I know I'm working with a string and I know I want to
> convert it to a double, I don't really need a generic component for
> that.  What's "dangerous" about that?
Admittedly this is in the eye of the beholder, however, an example could
be coding mistakes not caught by the compiler "thanks" to implicit
conversions / usual arithmetic conversions. For instance, using
std::stol("0") in place where std::stoi("0") was intended (on a side
note -- while I agree that readability is important, I'm still wondering
whether short names always help in achieving it -- in this particular
case "strol" v. "stroi" is not necessarily an easy distinction to spot).

On a side note -- I also think that consistency is a helpful and
desirable quality -- given that we already have std::to_string, a
from_string seems to be the closest analogue that comes to mind.
Comparing C++11
long      stol( const std::string& str, size_t *pos = 0, int base = 10 );

with the old pre-C++11 functions, the closest analogues / precedents
that come to mind are:

long      strtol( const char *str, char **str_end, int base );
long      atol( const char *str )

given that they have different interfaces and thus rather different
semantics (i.e., "str_end" has a *very* different meaning from "pos"),
isn't name-by-analogy-to-C here somewhat akin to "false friends" in
linguistics (similar name, different meaning)? In other words, is
creating analogy between std::stoX and strtoX really desirable (perhaps
I'm simply reading too much into it when I'm worrying about the users of
strtoX expecting to be able to textually replace all instances with
std::stoX)?

Best regards,

Matt
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--------------070709090802050806080702
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/23/2013 21:00, Jonathan Wakely
      wrote:<br>
    </div>
    <blockquote
      cite="mid:5b145152-a1b9-4e70-bcaa-8e92caf3e566@isocpp.org"
      type="cite"><br>
      <br>
      On Tuesday, April 23, 2013 7:37:12 PM UTC+1, Matt D. wrote:
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
        I have a related question, although on somewhat different
        grounds <br>
        (usability and genericity).
        <br>
        Wouldn't make&lt;std::shared_ptr&gt; and
        make&lt;std::unique_ptr&gt; be a more <br>
        generic choice?
        <br>
        In a generic code, this would allow to delay the ownership
        semantics <br>
        decision to a policy (supplied as a template parameter) stage.
        <br>
      </blockquote>
      <div><br>
        But why would that be useful?<br>
        <br>
        One of them is copyable, one is not, how much could you
        realistically do in generic code without knowing whether you're
        dealing with a unique_ptr or a shared_ptr?<br>
        <br>
        If you need to copy it within your generic code then you have no
        choice, only a shared_ptr is possible.<br>
        <br>
        If you don't need to copy it and it's possible to only move it,
        then use unique_ptr.&nbsp; It can always be turned into a shared_ptr
        later by the caller of your generic component if that's what
        they want.<br>
        <br>
        If you really want to be generic, wouldn't it be better to take
        a functor that creates the object, and let the caller provide
        something like make_shared / make_unique / something_else ?<br>
        <br>
        make_unique does what it says on the tin, don't overcomplicate
        it.<br>
      </div>
    </blockquote>
    Thanks for the reply -- and I can already see these (and Ville's,
    thanks!) good points that make me more convinced here (that's what I
    love about the discussions on std-proposals) :-)<br>
    // Disclaimer: while by default I presume that chances are that when
    something is standardized as X, it is standardized as X for good
    reasons, I'm genuinely curious about some of these reasons at times;
    so, I find this helpful.<br>
    <br>
    <blockquote
      cite="mid:5b145152-a1b9-4e70-bcaa-8e92caf3e566@isocpp.org"
      type="cite">
      <div><br>
        &nbsp;<br>
      </div>
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <br>
        This is mostly on the usability grounds</blockquote>
      <div><br>
        I think your suggestion fails on those grounds for many users'
        definition of usability.<br>
        <br>
        &nbsp;</div>
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> -- to
        give another example, I <br>
        find the design of boost::lexical_cast
        <br>
        <br>
        <a moz-do-not-send="true"
href="http://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/synopsis.html"
          target="_blank">http://www.boost.org/doc/libs/<wbr>release/doc/html/boost_<wbr>lexical_cast/synopsis.html</a>
        <br>
        <br>
        more usable and generic compared to the family of
        <br>
        <br>
        <a moz-do-not-send="true"
          href="http://en.cppreference.com/w/cpp/string/basic_string/stol"
          target="_blank">http://en.cppreference.com/w/<wbr>cpp/string/basic_string/stol</a>
        <br>
        <a moz-do-not-send="true"
          href="http://en.cppreference.com/w/cpp/string/basic_string/stoul"
          target="_blank">http://en.cppreference.com/w/<wbr>cpp/string/basic_string/stoul</a>
        <br>
        <a moz-do-not-send="true"
          href="http://en.cppreference.com/w/cpp/string/basic_string/stof"
          target="_blank">http://en.cppreference.com/w/<wbr>cpp/string/basic_string/stof</a>
        <br>
        <br>
        where type is expressed in the name.
        <br>
      </blockquote>
      <div><br>
        <br>
        The new std::stoX functions should be as fast as the old C
        strtoX functions in all cases (do you have any idea how long it
        took for lexical_cast to be properly optimized for the simple
        and common cases?) and are less typing.<br>
        <br>
        If you need the full genericity of lexical_cast&lt;&gt; to
        convert between any two arbitrary types that support
        operator&lt;&lt; and operator&gt;&gt; then you still have it.&nbsp;
        In most codebases I've seen the majority of uses of lexical_cast
        were for conversions between strings and arithmetic types, so
        the std::stoX functions do that with less code and are more
        readable.<br>
      </div>
    </blockquote>
    Interesting!<br>
    <br>
    Just so I can see if I can understand this correctly; we're
    considering three families:<br>
    - std::stoi, std::stol, std::stoll<br>
    - std::stoul, std::stoull<br>
    - std::stof, std::stod, std::stold<br>
    <br>
    Could a solution using, say, "from_string&lt;T&gt;" function
    template introduce any performance penalty?<br>
    I'm essentially wondering about the inconsistency compared to <br>
    <a class="moz-txt-link-freetext" href="http://en.cppreference.com/w/cpp/string/basic_string/to_string">http://en.cppreference.com/w/cpp/string/basic_string/to_string</a>
    (you're right, lexical_cast is much broader)<br>
    <br>
    Admittedly, these are overloads, but we can't deduce the return-type
    anyway -- so I take it that we're always going to have to express
    the type somehow, either as<br>
    <br>
    long long stoll( const std::string&amp; str, size_t *pos = 0, int
    base = 10 );<br>
    <br>
    or, say,<br>
    <br>
    template &lt;typename T&gt;<br>
    T from_string( const std::string&amp; str, size_t *pos = 0, int base
    = 10 );<br>
    <br>
    To my understanding, the branch on T will always occur at
    compile-time; hence, there should be no performance penalty.<br>
    Am I missing something?<br>
    <br>
    Regarding the length of the name -- good argument, I haven't thought
    of that (again, thanks for pointing this out!).<br>
    I'm wondering, though, wouldn't it be a good idea to balance it
    against the remaining factors?<br>
    For instance, as of this point, to my understanding there's no
    standard (C++11) replacement for lexical_cast here:
    <a class="moz-txt-link-freetext" href="http://www.bnikolic.co.uk/boostqf/tokenizer.html">http://www.bnikolic.co.uk/boostqf/tokenizer.html</a> -- that's what I
    meant by usability in this case (it goes hand in hand with
    genericity, since it's genericity that makes lexical_case more
    useful for this particular application).<br>
    <br>
    In the end, even taking both the short-to-type-name and the
    genericity as desirable goals, there might still be a way out using
    explicit specialization, akin to:<br>
    <a class="moz-txt-link-freetext" href="http://ideone.com/PlXV1V">http://ideone.com/PlXV1V</a><br>
    A related question -- if I use this as a workaround personally, and
    I'm facing any downsides?<br>
    <br>
    <blockquote
      cite="mid:5b145152-a1b9-4e70-bcaa-8e92caf3e566@isocpp.org"
      type="cite">
      <div><br>
        &nbsp;</div>
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <br>
        Isn't this dangerously close to Systems Hungarian notation,
        which a <br>
        statically typed language like C++ doesn't really need (and
        where it <br>
        doesn't really belong)?
        <br>
      </blockquote>
      <div>&nbsp;</div>
      <div>I'm not sure I understand what you're saying, but I don't
        think so.&nbsp; Very often I know I'm working with a string and I
        know I want to convert it to a double, I don't really need a
        generic component for that.&nbsp; What's "dangerous" about that?<br>
      </div>
    </blockquote>
    Admittedly this is in the eye of the beholder, however, an example
    could be coding mistakes not caught by the compiler "thanks" to
    implicit conversions / usual arithmetic conversions. For instance,
    using std::stol("0") in place where std::stoi("0") was intended (on
    a side note -- while I agree that readability is important, I'm
    still wondering whether short names always help in achieving it --
    in this particular case "strol" v. "stroi" is not necessarily an
    easy distinction to spot).<br>
    <br>
    On a side note -- I also think that consistency is a helpful and
    desirable quality -- given that we already have std::to_string, a
    from_string seems to be the closest analogue that comes to mind.
    Comparing C++11<br>
    long&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stol( const std::string&amp; str, size_t *pos = 0, int
    base = 10 );<br>
    <br>
    with the old pre-C++11 functions, the closest analogues / precedents
    that come to mind are:<br>
    <br>
    long&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; strtol( const char *str, char **str_end, int base );<br>
    long&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; atol( const char *str )<br>
    <br>
    given that they have different interfaces and thus rather different
    semantics (i.e., "str_end" has a *very* different meaning from
    "pos"), isn't name-by-analogy-to-C here somewhat akin to "false
    friends" in linguistics (similar name, different meaning)? In other
    words, is creating analogy between std::stoX and strtoX really
    desirable (perhaps I'm simply reading too much into it when I'm
    worrying about the users of strtoX expecting to be able to textually
    replace all instances with std::stoX)?<br>
    <br>
    Best regards,<br>
    <br>
    Matt<br>
    <blockquote
      cite="mid:5b145152-a1b9-4e70-bcaa-8e92caf3e566@isocpp.org"
      type="cite">
      <div><br>
        <br>
      </div>
      -- <br>
      &nbsp;<br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
      Visit this group at <a moz-do-not-send="true"
        href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br>
      &nbsp;<br>
      &nbsp;<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--------------070709090802050806080702--

.

This is a multi-part message in MIME format.
--------------020102050701020808060509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 4/23/2013 22:29, Matt D. wrote:
> http://ideone.com/PlXV1V
Talking about coding mistakes ;-), the above should be:
http://ideone.com/pvtnIC

Best,

Matt

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--------------020102050701020808060509
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/23/2013 22:29, Matt D. wrote:<br>
    </div>
    <blockquote cite="mid:5176EF32.5030102@gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://ideone.com/PlXV1V">http://ideone.com/PlXV1V</a><br>
    </blockquote>
    Talking about coding mistakes ;-), the above should be:
    <a class="moz-txt-link-freetext" href="http://ideone.com/pvtnIC">http://ideone.com/pvtnIC</a><br>
    <br>
    Best,<br>
    <br>
    Matt<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--------------020102050701020808060509--

.

------=_Part_3753_6160975.1366785143660
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, April 23, 2013 6:13:32 PM UTC+3, DeadMG wrote:
>
> I completely disagree. The purpose of make_pair is to make a pair,
> make_tuple makes a tuple, make_shared makes a shared_ptr and make_unique
> makes a unique_ptr.


If make_shared and make_unique were parallel to make_pair and make_tuple
they should take a raw pointer as the parameter. Instead they take the
constructor parameters and create an object, which is considerably more
than simply creating a shared_ptr or unique_ptr.

Also, the T itself is not shared at all, it is the ownership of T which is
> shared, and the unique in unique_ptr refers to the uniqueness of ownership
> of T, so they are completely the same.


Ok.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3753_6160975.1366785143660
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 23, 2013 6:13:32 PM UTC+3, DeadMG wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">I completely disagree. The purpose of m=
ake_pair is to make a pair, make_tuple makes a tuple, make_shared makes a s=
hared_ptr and make_unique makes a unique_ptr.</blockquote><div><br></div><d=
iv>If make_shared and make_unique were parallel to make_pair and make_tuple=
 they should take a raw pointer as the parameter. Instead they take the con=
structor parameters and create an object, which is considerably more than s=
imply creating a shared_ptr or unique_ptr.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"> Also, the T itself is not shared at all, =
it is the ownership of T which is shared, and the unique in unique_ptr refe=
rs to the uniqueness of ownership of T, so they are completely the same.</b=
lockquote><div><br></div><div>Ok.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3753_6160975.1366785143660--

.