------=_Part_2624_1438383083.1425465646966
Content-Type: multipart/alternative;
 boundary="----=_Part_2625_681061702.1425465646966"

------=_Part_2625_681061702.1425465646966
Content-Type: text/plain; charset=UTF-8

Hi Everyone,
I can see that the Committee considers providing a second incarnation of
the STL, in order to facilitate Concepts Lite and the new range interface
in a backwards-incompatible manner.

If this path is ever chosen, I see it as an opportunity to fix other things
in the STL also. Below I present one thing that I personally consider a
flaw. I would like to hear your opinion.

I mean this constructor of std::vector and its kin that takes one argument
of type size_type:

explicit vector(size_type n, const Allocator& = Allocator());

It is the source of two confusions:

*Problem 1:*
vector<int> v(2);
vector<int> w{2};

The above two declarations trigger different constructors and render a
different value. This is an unnecessary point of confusion and a source of
problems. For a more detailed discussion see here
<https://akrzemi1.wordpress.com/2013/06/05/intuitive-interface-part-i/>.

*Problem 2:*
In declaration:
vector<T> v(100);
People happen to mistakenly think that that this reserves the capacity of
100 rather than setting the size. This confusion is enforced by the fact
that similar libraries in other languages mean capacity in this case, e.g.,
java.util.ArrayList<E>
<http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList.html>. Also,
in my personal experience, initial capacity is something that I require
more often that initial size.

What I propose is to remove the said constructor (and similar one taking
default T), add replace them with constructors taking tags that enforce the
user to explicitly state their intent:

constexpr class with_size_t{} with_size{};
constexpr class with_capacity_t{} with_capacity{};

explicit vector(*with_size_t*, size_type n, const Allocator& = Allocator());
explicit vector(*with_size_t*, size_type n, const T& value, const
Allocator& = Allocator());
explicit vector(*with_capacity_t*, size_type c, const Allocator& =
Allocator());
explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type n,
const Allocator& = Allocator());
explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type n,
const T& value, const Allocator& = Allocator());

This is a lot of overloads, but what it gives instead is zero ambiguity.
What do you think?

Regards,
&rzej

--

---
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/.

------=_Part_2625_681061702.1425465646966
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Everyone,<br>I can see that the Committee considers pro=
viding a second incarnation of the STL, in order to facilitate Concepts Lit=
e and the new range interface in a backwards-incompatible manner.<br><br>If=
 this path is ever chosen, I see it as an opportunity to fix other things i=
n the STL also. Below I present one thing that I personally consider a flaw=
.. I would like to hear your opinion.<br><br>I mean this constructor of std:=
:vector and its kin that takes one argument of type size_type:<br><br>expli=
cit vector(size_type n, const Allocator&amp; =3D Allocator());<br><br>It is=
 the source of two confusions:<br><br><b>Problem 1:</b><br>vector&lt;int&gt=
; v(2);<br>vector&lt;int&gt; w{2}; <br><br>The above two declarations trigg=
er different constructors and render a different value. This is an unnecess=
ary point of confusion and a source of problems. For a more detailed discus=
sion <a href=3D"https://akrzemi1.wordpress.com/2013/06/05/intuitive-interfa=
ce-part-i/">see here</a>.<br><br><b>Problem 2:</b><br>In declaration:<br>ve=
ctor&lt;T&gt; v(100);<br>People happen to mistakenly think that that this r=
eserves the capacity of 100 rather than setting the size. This confusion is=
 enforced by the fact that similar libraries in other languages mean capaci=
ty in this case, e.g., <a href=3D"http://docs.oracle.com/javase/6/docs/api/=
java/util/ArrayList.html">java.util.ArrayList&lt;E&gt;</a>. Also, in my per=
sonal experience, initial capacity is something that I require more often t=
hat initial size.<br><br>What I propose is to remove the said constructor (=
and similar one taking default T), add replace them with constructors takin=
g tags that enforce the user to explicitly state their intent:<br><br>const=
expr class with_size_t{} with_size{};<br>constexpr class with_capacity_t{} =
with_capacity{};<br><br>explicit vector(<b>with_size_t</b>, size_type n, co=
nst Allocator&amp; =3D Allocator());<br>explicit vector(<b>with_size_t</b>,=
 size_type n, const T&amp; value, const Allocator&amp; =3D Allocator());<br=
>explicit vector(<b>with_capacity_t</b>, size_type c, const Allocator&amp; =
=3D Allocator());<br>explicit vector(<b><b>with_capacity_t</b>, </b>size_ty=
pe c,<b> with_size_t</b>, size_type n, const Allocator&amp; =3D Allocator()=
);<br>explicit vector(<b><b>with_capacity_t</b>, </b>size_type c,<b> with_s=
ize_t</b>, size_type n, const T&amp; value, const Allocator&amp; =3D Alloca=
tor());<br><br>This is a lot of overloads, but what it gives instead is zer=
o ambiguity.<br>What do you think?<br><br>Regards,<br>&amp;rzej<br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2625_681061702.1425465646966--
------=_Part_2624_1438383083.1425465646966--

.

coudln't it be better if we had a special type based around size_t named
capacity_t that can simply be used in the overload ?

explicit vector( size_t )
explicit vector( capacity_t )
explicit vector( capacity_t, size_t )

and let the reguar overload mechanism do its bidding ?

I found type tag like this to be cluttering the code too much.

On 04/03/2015 11:40, Andrzej Krzemie=C5=84ski wrote:

> explicit vector(*with_size_t*, size_type n, const Allocator& =3D Allocato=
r());
> explicit vector(*with_size_t*, size_type n, const T& value, const
> Allocator& =3D Allocator());
> explicit vector(*with_capacity_t*, size_type c, const Allocator& =3D
> Allocator());
> explicit vector(**with_capacity_t*, *size_type c,*with_size_t*,
> size_type n, const Allocator& =3D Allocator());
> explicit vector(**with_capacity_t*, *size_type c,*with_size_t*,
> size_type n, const T& value, const Allocator& =3D Allocator());

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

------=_Part_1613_1377324600.1425466314667
Content-Type: multipart/alternative;
 boundary="----=_Part_1614_968321187.1425466314667"

------=_Part_1614_968321187.1425466314667
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 4 marca 2015 11:46:52 UTC+1 u=C5=BCytkownik Joel Falcou =
napisa=C5=82:
>
> coudln't it be better if we had a special type based around size_t named=
=20
> capacity_t that can simply be used in the overload ?=20
>

If we had, we would run into problems what to do for vector<capacity_t> and=
=20
similar.
=20

>
> explicit vector( size_t )=20
> explicit vector( capacity_t )=20
> explicit vector( capacity_t, size_t )=20
>
> and let the reguar overload mechanism do its bidding ?=20
>
> I found type tag like this to be cluttering the code too much.


Agreed, but any alternative I can think of either cause ambiguities, or=20
require severe language changes.

Regards,
&rzej


>
> On 04/03/2015 11:40, Andrzej Krzemie=C5=84ski wrote:=20
>
> > explicit vector(*with_size_t*, size_type n, const Allocator& =3D=20
> Allocator());=20
> > explicit vector(*with_size_t*, size_type n, const T& value, const=20
> > Allocator& =3D Allocator());=20
> > explicit vector(*with_capacity_t*, size_type c, const Allocator& =3D=20
> > Allocator());=20
> > explicit vector(**with_capacity_t*, *size_type c,*with_size_t*,=20
> > size_type n, const Allocator& =3D Allocator());=20
> > explicit vector(**with_capacity_t*, *size_type c,*with_size_t*,=20
> > size_type n, const T& value, const Allocator& =3D Allocator());=20
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_1614_968321187.1425466314667
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 4 marca 2015 11:46:52 UTC+1 u=
=C5=BCytkownik Joel Falcou napisa=C5=82:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">coudln't it be better if we had a special type based around size_=
t named
<br>capacity_t that can simply be used in the overload ?
<br></blockquote><div><br>If we had, we would run into problems what to do =
for vector&lt;capacity_t&gt; and similar.<br>&nbsp;<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
<br>explicit vector( size_t )
<br>explicit vector( capacity_t )
<br>explicit vector( capacity_t, size_t )
<br>
<br>and let the reguar overload mechanism do its bidding ?
<br>
<br>I found type tag like this to be cluttering the code too much.</blockqu=
ote><div><br>Agreed, but any alternative I can think of either cause ambigu=
ities, or require severe language changes.<br><br>Regards,<br>&amp;rzej<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
<br>On 04/03/2015 11:40, Andrzej Krzemie=C5=84ski wrote:
<br>
<br>&gt; explicit vector(*with_size_t*, size_type n, const Allocator&amp; =
=3D Allocator());
<br>&gt; explicit vector(*with_size_t*, size_type n, const T&amp; value, co=
nst
<br>&gt; Allocator&amp; =3D Allocator());
<br>&gt; explicit vector(*with_capacity_t*, size_type c, const Allocator&am=
p; =3D
<br>&gt; Allocator());
<br>&gt; explicit vector(**with_capacity_t*, *size_type c,*with_size_t*,
<br>&gt; size_type n, const Allocator&amp; =3D Allocator());
<br>&gt; explicit vector(**with_capacity_t*, *size_type c,*with_size_t*,
<br>&gt; size_type n, const T&amp; value, const Allocator&amp; =3D Allocato=
r());
<br></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1614_968321187.1425466314667--
------=_Part_1613_1377324600.1425466314667--

.

I have been bitten by that design a few times as well, so I agree that
we could need some improvement. I also agree that you more often need
an initial cpacity rather than an initial size.
But as Joel said, a solution that requires less change would be to
introduce a new type:

struct capacity
{
size_t c;
capacity(size_t initial_capacity): c(initial_capacity) {}
} ;

and then in vector have:
explicit vector::vector(capacity c) {...}

/Peter

On Wed, Mar 4, 2015 at 11:40 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> Hi Everyone,
> I can see that the Committee considers providing a second incarnation of =
the
> STL, in order to facilitate Concepts Lite and the new range interface in =
a
> backwards-incompatible manner.
>
> If this path is ever chosen, I see it as an opportunity to fix other thin=
gs
> in the STL also. Below I present one thing that I personally consider a
> flaw. I would like to hear your opinion.
>
> I mean this constructor of std::vector and its kin that takes one argumen=
t
> of type size_type:
>
> explicit vector(size_type n, const Allocator& =3D Allocator());
>
> It is the source of two confusions:
>
> Problem 1:
> vector<int> v(2);
> vector<int> w{2};
>
> The above two declarations trigger different constructors and render a
> different value. This is an unnecessary point of confusion and a source o=
f
> problems. For a more detailed discussion see here.
>
> Problem 2:
> In declaration:
> vector<T> v(100);
> People happen to mistakenly think that that this reserves the capacity of
> 100 rather than setting the size. This confusion is enforced by the fact
> that similar libraries in other languages mean capacity in this case, e.g=
..,
> java.util.ArrayList<E>. Also, in my personal experience, initial capacity=
 is
> something that I require more often that initial size.
>
> What I propose is to remove the said constructor (and similar one taking
> default T), add replace them with constructors taking tags that enforce t=
he
> user to explicitly state their intent:
>
> constexpr class with_size_t{} with_size{};
> constexpr class with_capacity_t{} with_capacity{};
>
> explicit vector(with_size_t, size_type n, const Allocator& =3D Allocator(=
));
> explicit vector(with_size_t, size_type n, const T& value, const Allocator=
& =3D
> Allocator());
> explicit vector(with_capacity_t, size_type c, const Allocator& =3D
> Allocator());
> explicit vector(with_capacity_t, size_type c, with_size_t, size_type n,
> const Allocator& =3D Allocator());
> explicit vector(with_capacity_t, size_type c, with_size_t, size_type n,
> const T& value, const Allocator& =3D Allocator());
>
> This is a lot of overloads, but what it gives instead is zero ambiguity.
> What do you think?
>
> Regards,
> &rzej
>
> --
>
> ---
> 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/.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

> constexpr class with_size_t{} with_size{};
> constexpr class with_capacity_t{} with_capacity{};
>=20
> explicit vector(*with_size_t*, size_type n, const Allocator& =3D Allocato=
r());
> explicit vector(*with_size_t*, size_type n, const T& value, const=20
> Allocator& =3D Allocator());
> explicit vector(*with_capacity_t*, size_type c, const Allocator& =3D=20
> Allocator());
> explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type =
n,=20
> const Allocator& =3D Allocator());
> explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type =
n,=20
> const T& value, const Allocator& =3D Allocator());
>=20
> This is a lot of overloads, but what it gives instead is zero ambiguity.
> What do you think?

Looks really terrible to me. Why not just use private constructor and
static functions:

    auto v2 =3D vector<int>::of_size(n, [initial_value]);
    auto v1 =3D vector<int>::of_capacity(n);
    auto v3 =3D vector<int>::of_size_and_capacity(n, [initial_value]);

(where "[initial_value]" means just an optional argument, not a special
syntax of some kind). I've met such an approach in Scala's standard
library, where it looks pretty nice:

    val array =3D Array.ofDim[Double](2, 3)

(creates two dimensional array 2=C3=973, with default values for data type
"Double").

=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

------=_Part_137_203561582.1425484034745
Content-Type: multipart/alternative;
 boundary="----=_Part_138_318059003.1425484034745"

------=_Part_138_318059003.1425484034745
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 4 marca 2015 16:44:52 UTC+1 u=C5=BCytkownik Pavel Kretov=
 napisa=C5=82:
>
> > constexpr class with_size_t{} with_size{};=20
> > constexpr class with_capacity_t{} with_capacity{};=20
> >=20
> > explicit vector(*with_size_t*, size_type n, const Allocator& =3D=20
> Allocator());=20
> > explicit vector(*with_size_t*, size_type n, const T& value, const=20
> > Allocator& =3D Allocator());=20
> > explicit vector(*with_capacity_t*, size_type c, const Allocator& =3D=20
> > Allocator());=20
> > explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_typ=
e=20
> n,=20
> > const Allocator& =3D Allocator());=20
> > explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_typ=
e=20
> n,=20
> > const T& value, const Allocator& =3D Allocator());=20
> >=20
> > This is a lot of overloads, but what it gives instead is zero ambiguity=
..=20
> > What do you think?=20
>
> Looks really terrible to me. Why not just use private constructor and=20
> static functions:=20
>
>     auto v2 =3D vector<int>::of_size(n, [initial_value]);=20
>     auto v1 =3D vector<int>::of_capacity(n);=20
>     auto v3 =3D vector<int>::of_size_and_capacity(n, [initial_value]);=20
>
> (where "[initial_value]" means just an optional argument, not a special=
=20
> syntax of some kind). I've met such an approach in Scala's standard=20
> library, where it looks pretty nice:=20
>
>     val array =3D Array.ofDim[Double](2, 3)=20
>
> (creates two dimensional array 2=C3=973, with default values for data typ=
e=20
> "Double").=20
>
> =E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.=20
>

You need a way to specify the allocator also in all the above cases.=20

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_138_318059003.1425484034745
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 4 marca 2015 16:44:52 UTC+1 u=
=C5=BCytkownik Pavel Kretov napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">&gt; constexpr class with_size_t{} with_size{};
<br>&gt; constexpr class with_capacity_t{} with_capacity{};
<br>&gt;=20
<br>&gt; explicit vector(*with_size_t*, size_type n, const Allocator&amp; =
=3D Allocator());
<br>&gt; explicit vector(*with_size_t*, size_type n, const T&amp; value, co=
nst=20
<br>&gt; Allocator&amp; =3D Allocator());
<br>&gt; explicit vector(*with_capacity_t*, size_type c, const Allocator&am=
p; =3D=20
<br>&gt; Allocator());
<br>&gt; explicit vector(*with_capacity_t, *size_type c,* with_size_t*, siz=
e_type n,=20
<br>&gt; const Allocator&amp; =3D Allocator());
<br>&gt; explicit vector(*with_capacity_t, *size_type c,* with_size_t*, siz=
e_type n,=20
<br>&gt; const T&amp; value, const Allocator&amp; =3D Allocator());
<br>&gt;=20
<br>&gt; This is a lot of overloads, but what it gives instead is zero ambi=
guity.
<br>&gt; What do you think?
<br>
<br>Looks really terrible to me. Why not just use private constructor and
<br>static functions:
<br>
<br>&nbsp; &nbsp; auto v2 =3D vector&lt;int&gt;::of_size(n, [initial_value]=
);
<br>&nbsp; &nbsp; auto v1 =3D vector&lt;int&gt;::of_capacity(n);
<br>&nbsp; &nbsp; auto v3 =3D vector&lt;int&gt;::of_size_and_<wbr>capacity(=
n, [initial_value]);
<br>
<br>(where "[initial_value]" means just an optional argument, not a special
<br>syntax of some kind). I've met such an approach in Scala's standard
<br>library, where it looks pretty nice:
<br>
<br>&nbsp; &nbsp; val array =3D Array.ofDim[Double](2, 3)
<br>
<br>(creates two dimensional array 2=C3=973, with default values for data t=
ype
<br>"Double").
<br>
<br>=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.
<br></blockquote><div><br>You need a way to specify the allocator also in a=
ll the above cases. <br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_138_318059003.1425484034745--
------=_Part_137_203561582.1425484034745--

.

------=_Part_6283_62525184.1425484200497
Content-Type: multipart/alternative;
 boundary="----=_Part_6284_741264105.1425484200497"

------=_Part_6284_741264105.1425484200497
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

While we're in there, std::vector (and probably std::deque) should have a=
=20
way to default-initialize their contents. Sized construction and insertion=
=20
uses value-initialization, but not everyone wants to pay that cost, and=20
there's no way to not pay it currently.

My suggestion would be an additional overload that takes some=20
"default_initial" type. So the user would see (using the new containing=20
type someone else suggested):

std::vector v =3D {std::sizer(5), std::default_init};

By default, it would still value-initialize the contents.

On Wednesday, March 4, 2015 at 5:40:47 AM UTC-5, Andrzej Krzemie=C5=84ski w=
rote:
>
> Hi Everyone,
> I can see that the Committee considers providing a second incarnation of=
=20
> the STL, in order to facilitate Concepts Lite and the new range interface=
=20
> in a backwards-incompatible manner.
>
> If this path is ever chosen, I see it as an opportunity to fix other=20
> things in the STL also. Below I present one thing that I personally=20
> consider a flaw. I would like to hear your opinion.
>
> I mean this constructor of std::vector and its kin that takes one argumen=
t=20
> of type size_type:
>
> explicit vector(size_type n, const Allocator& =3D Allocator());
>
> It is the source of two confusions:
>
> *Problem 1:*
> vector<int> v(2);
> vector<int> w{2};=20
>
> The above two declarations trigger different constructors and render a=20
> different value. This is an unnecessary point of confusion and a source o=
f=20
> problems. For a more detailed discussion see here=20
> <https://akrzemi1.wordpress.com/2013/06/05/intuitive-interface-part-i/>.
>
> *Problem 2:*
> In declaration:
> vector<T> v(100);
> People happen to mistakenly think that that this reserves the capacity of=
=20
> 100 rather than setting the size. This confusion is enforced by the fact=
=20
> that similar libraries in other languages mean capacity in this case, e.g=
..,=20
> java.util.ArrayList<E>=20
> <http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList.html>.=20
> Also, in my personal experience, initial capacity is something that I=20
> require more often that initial size.
>
> What I propose is to remove the said constructor (and similar one taking=
=20
> default T), add replace them with constructors taking tags that enforce t=
he=20
> user to explicitly state their intent:
>
> constexpr class with_size_t{} with_size{};
> constexpr class with_capacity_t{} with_capacity{};
>
> explicit vector(*with_size_t*, size_type n, const Allocator& =3D=20
> Allocator());
> explicit vector(*with_size_t*, size_type n, const T& value, const=20
> Allocator& =3D Allocator());
> explicit vector(*with_capacity_t*, size_type c, const Allocator& =3D=20
> Allocator());
> explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type=
=20
> n, const Allocator& =3D Allocator());
> explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type=
=20
> n, const T& value, const Allocator& =3D Allocator());
>
> This is a lot of overloads, but what it gives instead is zero ambiguity.
> What do you think?
>
> Regards,
> &rzej
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_6284_741264105.1425484200497
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While we're in there, std::vector (and probably std::deque=
) should have a way to default-initialize their contents. Sized constructio=
n and insertion uses value-initialization, but not everyone wants to pay th=
at cost, and there's no way to not pay it currently.<br><br>My suggestion w=
ould be an additional overload that takes some "default_initial" type. So t=
he user would see (using the new containing type someone else suggested):<b=
r><br>std::vector v =3D {std::sizer(5), std::default_init};<br><br>By defau=
lt, it would still value-initialize the contents.<br><br>On Wednesday, Marc=
h 4, 2015 at 5:40:47 AM UTC-5, Andrzej Krzemie=C5=84ski wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi Everyone,<br>I can see =
that the Committee considers providing a second incarnation of the STL, in =
order to facilitate Concepts Lite and the new range interface in a backward=
s-incompatible manner.<br><br>If this path is ever chosen, I see it as an o=
pportunity to fix other things in the STL also. Below I present one thing t=
hat I personally consider a flaw. I would like to hear your opinion.<br><br=
>I mean this constructor of std::vector and its kin that takes one argument=
 of type size_type:<br><br>explicit vector(size_type n, const Allocator&amp=
; =3D Allocator());<br><br>It is the source of two confusions:<br><br><b>Pr=
oblem 1:</b><br>vector&lt;int&gt; v(2);<br>vector&lt;int&gt; w{2}; <br><br>=
The above two declarations trigger different constructors and render a diff=
erent value. This is an unnecessary point of confusion and a source of prob=
lems. For a more detailed discussion <a href=3D"https://akrzemi1.wordpress.=
com/2013/06/05/intuitive-interface-part-i/" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%=
2Fakrzemi1.wordpress.com%2F2013%2F06%2F05%2Fintuitive-interface-part-i%2F\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNE3yOlHOX-b053yHOVHfSXge1VJNw';return true=
;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fakr=
zemi1.wordpress.com%2F2013%2F06%2F05%2Fintuitive-interface-part-i%2F\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNE3yOlHOX-b053yHOVHfSXge1VJNw';return true;">se=
e here</a>.<br><br><b>Problem 2:</b><br>In declaration:<br>vector&lt;T&gt; =
v(100);<br>People happen to mistakenly think that that this reserves the ca=
pacity of 100 rather than setting the size. This confusion is enforced by t=
he fact that similar libraries in other languages mean capacity in this cas=
e, e.g., <a href=3D"http://docs.oracle.com/javase/6/docs/api/java/util/Arra=
yList.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fdocs.oracle.com%2Fjavase%2F6%2Fd=
ocs%2Fapi%2Fjava%2Futil%2FArrayList.html\46sa\75D\46sntz\0751\46usg\75AFQjC=
NHovuHCJ5QdqACuJigYy8rwgP1jFQ';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fdocs.oracle.com%2Fjavase%2F6%2Fdocs%2F=
api%2Fjava%2Futil%2FArrayList.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHovuH=
CJ5QdqACuJigYy8rwgP1jFQ';return true;">java.util.ArrayList&lt;E&gt;</a>. Al=
so, in my personal experience, initial capacity is something that I require=
 more often that initial size.<br><br>What I propose is to remove the said =
constructor (and similar one taking default T), add replace them with const=
ructors taking tags that enforce the user to explicitly state their intent:=
<br><br>constexpr class with_size_t{} with_size{};<br>constexpr class with_=
capacity_t{} with_capacity{};<br><br>explicit vector(<b>with_size_t</b>, si=
ze_type n, const Allocator&amp; =3D Allocator());<br>explicit vector(<b>wit=
h_size_t</b>, size_type n, const T&amp; value, const Allocator&amp; =3D All=
ocator());<br>explicit vector(<b>with_capacity_t</b>, size_type c, const Al=
locator&amp; =3D Allocator());<br>explicit vector(<b><b>with_capacity_t</b>=
, </b>size_type c,<b> with_size_t</b>, size_type n, const Allocator&amp; =
=3D Allocator());<br>explicit vector(<b><b>with_capacity_t</b>, </b>size_ty=
pe c,<b> with_size_t</b>, size_type n, const T&amp; value, const Allocator&=
amp; =3D Allocator());<br><br>This is a lot of overloads, but what it gives=
 instead is zero ambiguity.<br>What do you think?<br><br>Regards,<br>&amp;r=
zej<br></div></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6284_741264105.1425484200497--
------=_Part_6283_62525184.1425484200497--

.

------=_Part_6585_130142703.1425485538569
Content-Type: multipart/alternative;
 boundary="----=_Part_6586_1170056675.1425485538569"

------=_Part_6586_1170056675.1425485538569
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 4, 2015 at 10:44:52 AM UTC-5, Pavel Kretov wrote:
>
> > constexpr class with_size_t{} with_size{};
> > constexpr class with_capacity_t{} with_capacity{};
> >
> > explicit vector(*with_size_t*, size_type n, const Allocator& =
> Allocator());
> > explicit vector(*with_size_t*, size_type n, const T& value, const
> > Allocator& = Allocator());
> > explicit vector(*with_capacity_t*, size_type c, const Allocator& =
> > Allocator());
> > explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type
> n,
> > const Allocator& = Allocator());
> > explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type
> n,
> > const T& value, const Allocator& = Allocator());
> >
> > This is a lot of overloads, but what it gives instead is zero ambiguity.
> > What do you think?
>
> Looks really terrible to me. Why not just use private constructor and
> static functions:
>

Because it doesn't let you use {}, which is a good portion of the point.

If you're in template code, and you don't know what the type is, and
someone gives you a bunch of parameters to initialize the type with, what
you want to do is this:

T v{params...};

With the above code (or better yet, the defined types that Joel proposed),
that can work.

--

---
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/.

------=_Part_6586_1170056675.1425485538569
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 4, 2015 at 10:44:52 AM UTC-5, Pavel Kr=
etov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; constexpr clas=
s with_size_t{} with_size{};
<br>&gt; constexpr class with_capacity_t{} with_capacity{};
<br>&gt;=20
<br>&gt; explicit vector(*with_size_t*, size_type n, const Allocator&amp; =
=3D Allocator());
<br>&gt; explicit vector(*with_size_t*, size_type n, const T&amp; value, co=
nst=20
<br>&gt; Allocator&amp; =3D Allocator());
<br>&gt; explicit vector(*with_capacity_t*, size_type c, const Allocator&am=
p; =3D=20
<br>&gt; Allocator());
<br>&gt; explicit vector(*with_capacity_t, *size_type c,* with_size_t*, siz=
e_type n,=20
<br>&gt; const Allocator&amp; =3D Allocator());
<br>&gt; explicit vector(*with_capacity_t, *size_type c,* with_size_t*, siz=
e_type n,=20
<br>&gt; const T&amp; value, const Allocator&amp; =3D Allocator());
<br>&gt;=20
<br>&gt; This is a lot of overloads, but what it gives instead is zero ambi=
guity.
<br>&gt; What do you think?
<br>
<br>Looks really terrible to me. Why not just use private constructor and
<br>static functions:
<br></blockquote><div><br>Because it doesn't let you use {}, which is a goo=
d portion of the point.<br><br>If you're in template code, and you don't kn=
ow what the type is, and someone gives you a bunch of parameters to initial=
ize the type with, what you want to do is this:<br><br>T v{params...};<br><=
br>With the above code (or better yet, the defined types that Joel proposed=
), that can work.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6586_1170056675.1425485538569--
------=_Part_6585_130142703.1425485538569--

.

------=_Part_645_1611464160.1426279562005
Content-Type: multipart/alternative;
 boundary="----=_Part_646_1961864803.1426279562005"

------=_Part_646_1961864803.1426279562005
Content-Type: text/plain; charset=UTF-8

I would argue that the default should be default-initialize. It is what
happens elsewhere in the language.

Imagine trying to teach someone c++ and having to tell them that there is
default initialization, but by default c++ value-initializes contents in
these obsure cases...

On Wednesday, 4 March 2015 07:50:00 UTC-8, Nicol Bolas wrote:
>
>
> By default, it would still value-initialize the contents.
>

--

---
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/.

------=_Part_646_1961864803.1426279562005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I would argue that the default should be default-initializ=
e. It is what happens elsewhere in the language.&nbsp;<div><br></div><div>I=
magine trying to teach someone c++ and having to tell them that there is de=
fault initialization, but by default c++ value-initializes contents in thes=
e obsure cases...<br><br>On Wednesday, 4 March 2015 07:50:00 UTC-8, Nicol B=
olas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br>By default, it would still value-initialize the contents.</div></blockqu=
ote></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_646_1961864803.1426279562005--
------=_Part_645_1611464160.1426279562005--

.

------=_Part_1237_2080824974.1426283147907
Content-Type: multipart/alternative;
 boundary="----=_Part_1238_654146623.1426283147907"

------=_Part_1238_654146623.1426283147907
Content-Type: text/plain; charset=UTF-8

On Friday, March 13, 2015 at 4:46:02 PM UTC-4, Chet wrote:
>
> I would argue that the default should be default-initialize. It is what
> happens elsewhere in the language.
>
> Imagine trying to teach someone c++ and having to tell them that there is
> default initialization, but by default c++ value-initializes contents in
> these obsure cases...
>

True, but the entire standard library can't really be considered an
"obscure" case.

Would you want to extend it to every standard library class? Could you have
default-initialized std::shared_ptr's? Or unique_ptr's?

The problem is that the standard library has very *consistently* been
written such that the default constructor value-initializes. Which means
that the odd-man-out is really the *language*, not the library. In terms of
the number of types, the language is the one who has the fewer types with
default-initialization-by-default.

The way I see it, the benefits of having default value-initialization
trumps the consistency argument.

--

---
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/.

------=_Part_1238_654146623.1426283147907
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, March 13, 2015 at 4:46:02 PM UTC-4, Chet wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I would argue=
 that the default should be default-initialize. It is what happens elsewher=
e in the language.&nbsp;<div><br></div><div>Imagine trying to teach someone=
 c++ and having to tell them that there is default initialization, but by d=
efault c++ value-initializes contents in these obsure cases...</div></div><=
/blockquote><div><br>True, but the entire standard library can't really be =
considered an "obscure" case.<br><br>Would you want to extend it to every s=
tandard library class? Could you have default-initialized std::shared_ptr's=
? Or unique_ptr's?<br><br>The problem is that the standard library has very=
 <i>consistently</i> been written such that the default constructor value-i=
nitializes. Which means that the odd-man-out is really the <i>language</i>,=
 not the library. In terms of the number of types, the language is the one =
who has the fewer types with default-initialization-by-default.<br><br>The =
way I see it, the benefits of having default value-initialization trumps th=
e consistency argument.<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1238_654146623.1426283147907--
------=_Part_1237_2080824974.1426283147907--

.

------=_Part_545_1573850001.1426494079125
Content-Type: multipart/alternative;
 boundary="----=_Part_546_1140886708.1426494079125"

------=_Part_546_1140886708.1426494079125
Content-Type: text/plain; charset=UTF-8

This may or may not be weird:

constructed_t operator""constructed(size_t);
reserved_t operator""reserved(size_t);

vector<int> u{1024constructed};
vector<int> v{4096reserved};

Just throwing this out there.

While we're at it, fixing the allocator model wouldn't be a bad idea,
either (get rid of reference_type, construct(), destroy(), etc...). Unless
reflection provides some way to forward an interface, reference_type is
utterly useless.

--

---
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/.

------=_Part_546_1140886708.1426494079125
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This may or may not be weird:<br><br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">constructed_t </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">""</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">constructed</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">size_t</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>reserved_t </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">""</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">reserved</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">size_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><br><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"pret=
typrint"><span style=3D"color: #000;" class=3D"styled-by-prettify">vector&l=
t;int&gt; u{1024constructed};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></code>vector</span><span style=3D"color: #08=
0;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">4096reserved</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span></div></code></div><br>Just throwing this out there.<=
br><br>While we're at it, fixing the allocator model wouldn't be a bad idea=
, either (get rid of reference_type, construct(), destroy(), etc...). Unles=
s reflection provides some way to forward an interface, reference_type is u=
tterly useless.<br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_546_1140886708.1426494079125--
------=_Part_545_1573850001.1426494079125--

.

--001a11c34c54b02370051166bc3e
Content-Type: text/plain; charset=UTF-8

It don't seem to work with more complex types than int,
in particular when there is more than one constructor parameter.

On Mon, Mar 16, 2015 at 9:21 AM, Chris Gary <cgary512@gmail.com> wrote:

> This may or may not be weird:
>
> constructed_t operator""constructed(size_t);
> reserved_t operator""reserved(size_t);
>
> vector<int> u{1024constructed};
> vector<int> v{4096reserved};
>
> Just throwing this out there.
>
> While we're at it, fixing the allocator model wouldn't be a bad idea,
> either (get rid of reference_type, construct(), destroy(), etc...). Unless
> reflection provides some way to forward an interface, reference_type is
> utterly useless.
>
> --
>
> ---
> 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/.
>

--

---
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/.

--001a11c34c54b02370051166bc3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It don&#39;t seem to work with more complex types than int=
,<div>in particular when there is more than one constructor parameter.</div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Ma=
r 16, 2015 at 9:21 AM, Chris Gary <span dir=3D"ltr">&lt;<a href=3D"mailto:c=
gary512@gmail.com" target=3D"_blank">cgary512@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This may or may not b=
e weird:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#000">constructed_t </span><span style=3D=
"color:#008">operator</span><span style=3D"color:#080">&quot;&quot;</span><=
span style=3D"color:#000">constructed</span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#000">size_t</span><span style=3D"color:#660">);</=
span><span style=3D"color:#000"><br>reserved_t </span><span style=3D"color:=
#008">operator</span><span style=3D"color:#080">&quot;&quot;</span><span st=
yle=3D"color:#000">reserved</span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">size_t</span><span style=3D"color:#660">);</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#000"></span><br><spa=
n style=3D"color:#000"><code><span style=3D"color:#000">vector&lt;int&gt; u=
{1024constructed};</span><span style=3D"color:#000"><br></span></code>vecto=
r</span><span style=3D"color:#080">&lt;int&gt;</span><span style=3D"color:#=
000"> v</span><span style=3D"color:#660">{</span><span style=3D"color:#066"=
>4096reserved</span><span style=3D"color:#660">};</span><span style=3D"colo=
r:#000"><br></span></div></code></div><br>Just throwing this out there.<br>=
<br>While we&#39;re at it, fixing the allocator model wouldn&#39;t be a bad=
 idea, either (get rid of reference_type, construct(), destroy(), etc...). =
Unless reflection provides some way to forward an interface, reference_type=
 is utterly useless.<br></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c34c54b02370051166bc3e--

.

------=_Part_329_49996985.1426529383851
Content-Type: multipart/alternative;
 boundary="----=_Part_330_633220918.1426529383851"

------=_Part_330_633220918.1426529383851
Content-Type: text/plain; charset=UTF-8

On Monday, March 16, 2015 at 3:21:19 AM UTC-5, Chris Gary wrote:
>
> While we're at it, fixing the allocator model wouldn't be a bad idea,
> either (get rid of reference_type, construct(), destroy(), etc...). Unless
> reflection provides some way to forward an interface, reference_type is
> utterly useless.
>

Not to derail the discussion, but reference hasn't been part of the
Allocator requirements since C++11. std::allocator provides it only for
backward compatibility. construct and destroy are critical hooks for
providing custom functionality. std::scoped_allocator, for example, hooks
construct to pass an additional allocator argument to the constructor of
the target object.

--

---
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/.

------=_Part_330_633220918.1426529383851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 16, 2015 at 3:21:19 AM UTC-5, Chris Gary =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">While w=
e're at it, fixing the allocator model wouldn't be a bad idea, either (get =
rid of reference_type, construct(), destroy(), etc...). Unless reflection p=
rovides some way to forward an interface, reference_type is utterly useless=
..<br></div></blockquote><div><br></div><div>Not to derail the discussion, b=
ut&nbsp;<font face=3D"courier new, monospace">reference</font> hasn't been =
part of the Allocator requirements since C++11.&nbsp;<font face=3D"courier =
new, monospace">std::allocator</font> provides it only for backward compati=
bility. <font face=3D"courier new, monospace">construct</font> and <font fa=
ce=3D"courier new, monospace">destroy</font> are critical hooks for providi=
ng custom functionality. <font face=3D"courier new, monospace">std::scoped_=
allocator</font>, for example, hooks <font face=3D"courier new, monospace">=
construct</font>&nbsp;to pass an additional allocator argument to the const=
ructor of the target object.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_330_633220918.1426529383851--
------=_Part_329_49996985.1426529383851--

.

------=_Part_506_1713451329.1426551854225
Content-Type: multipart/alternative;
 boundary="----=_Part_507_220780233.1426551854225"

------=_Part_507_220780233.1426551854225
Content-Type: text/plain; charset=UTF-8


>
> construct and destroy are critical hooks for providing custom
> functionality.
>

I'm of the opinion that allocators should just allocate.

Containers (or something else) ought to be responsible for object lifetime,
as the majority have to wrap their value types in some kind of node anyway.

Just opinions, though.

--

---
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/.

------=_Part_507_220780233.1426551854225
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
<font face=3D"courier new, monospace">construct</font> and <font face=3D"co=
urier new, monospace">destroy</font> are critical hooks for providing custo=
m functionality.<br></blockquote><br>I'm of the opinion that allocators sho=
uld just allocate.<br><br>Containers
 (or something else) ought to be responsible for object lifetime, as the
 majority have to wrap their value types in some kind of node anyway.<br><b=
r>Just opinions, though.</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_507_220780233.1426551854225--
------=_Part_506_1713451329.1426551854225--

.

------=_Part_268_4126751.1426587554427
Content-Type: multipart/alternative;
 boundary="----=_Part_269_638827353.1426587554428"

------=_Part_269_638827353.1426587554428
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The problem with use of constructed_t or reserved_t instead of empty tag=20
structs is that this solution does not really resolve the problem (as=20
Andrzej said before). Consider following example:
std::vector<constructed_t> v{1024constructed};
Does it allocate vector with 1 element or 1024 elements? And having vector=
=20
of sizes may be actually usefull.

W dniu poniedzia=C5=82ek, 16 marca 2015 09:21:19 UTC+1 u=C5=BCytkownik Chri=
s Gary=20
napisa=C5=82:
>
> This may or may not be weird:
>
> constructed_t operator""constructed(size_t);
> reserved_t operator""reserved(size_t);
>
> vector<int> u{1024constructed};
> vector<int> v{4096reserved};
>
> Just throwing this out there.
>
> While we're at it, fixing the allocator model wouldn't be a bad idea,=20
> either (get rid of reference_type, construct(), destroy(), etc...). Unles=
s=20
> reflection provides some way to forward an interface, reference_type is=
=20
> utterly useless.
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_269_638827353.1426587554428
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The problem with use of constructed_t or reserved_t instea=
d of empty tag structs is that this solution does not really resolve the pr=
oblem (as Andrzej said before). Consider following example:<br>std::vector&=
lt;constructed_t&gt; v{1024constructed};<br>Does it allocate vector with 1 =
element or 1024 elements? And having vector of sizes may be actually useful=
l.<br><br>W dniu poniedzia=C5=82ek, 16 marca 2015 09:21:19 UTC+1 u=C5=BCytk=
ownik Chris Gary napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">This may or may not be weird:<br><br><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#00=
0">constructed_t </span><span style=3D"color:#008">operator</span><span sty=
le=3D"color:#080">""</span><span style=3D"color:#000">constructed</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">size_t</span><sp=
an style=3D"color:#660">);</span><span style=3D"color:#000"><br>reserved_t =
</span><span style=3D"color:#008">operator</span><span style=3D"color:#080"=
>""</span><span style=3D"color:#000">reserved</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#000">size_t</span><span style=3D"color:#6=
60">);</span><span style=3D"color:#000"><br></span><span style=3D"color:#00=
0"></span><br><span style=3D"color:#000"><code><span style=3D"color:#000">v=
ector&lt;int&gt; u{1024constructed};</span><span style=3D"color:#000"><br><=
/span></code>vector</span><span style=3D"color:#080">&lt;int&gt;</span><spa=
n style=3D"color:#000"> v</span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#066">4096reserved</span><span style=3D"color:#660">};</span><=
span style=3D"color:#000"><br></span></div></code></div><br>Just throwing t=
his out there.<br><br>While we're at it, fixing the allocator model wouldn'=
t be a bad idea, either (get rid of reference_type, construct(), destroy(),=
 etc...). Unless reflection provides some way to forward an interface, refe=
rence_type is utterly useless.<br></div></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_269_638827353.1426587554428--
------=_Part_268_4126751.1426587554427--

.

------=_Part_471_1064485510.1426619646211
Content-Type: multipart/alternative;
 boundary="----=_Part_472_121703413.1426619646211"

------=_Part_472_121703413.1426619646211
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Would it really be a problem if we disallowed vectors of these special=20
types? Can we just say this is an use case that will need special handling?

You would still be allowed to have a vector of size_t which would fullfill=
=20
most use cases. Or what about about inventing an element wrapper type that=
=20
would need to be used to create containers of the special types?

vector<size_t> v{1024constructed}; // creates 1024 elements
vector<constructed_t> v{1024constructed}; //error not allowed.
vector<element<constructed>> v{1024constructed}; // creates 1024 elements
vector<element<constructed>> v{make_element(1024constructed)}; // creates 1=
=20
elements=20

On Tuesday, 17 March 2015 03:19:14 UTC-7, Tomasz wrote:
>
> The problem with use of constructed_t or reserved_t instead of empty tag=
=20
> structs is that this solution does not really resolve the problem (as=20
> Andrzej said before). Consider following example:
> std::vector<constructed_t> v{1024constructed};
> Does it allocate vector with 1 element or 1024 elements? And having vecto=
r=20
> of sizes may be actually usefull.
>
> W dniu poniedzia=C5=82ek, 16 marca 2015 09:21:19 UTC+1 u=C5=BCytkownik Ch=
ris Gary=20
> napisa=C5=82:
>>
>> This may or may not be weird:
>>
>> constructed_t operator""constructed(size_t);
>> reserved_t operator""reserved(size_t);
>>
>> vector<int> u{1024constructed};
>> vector<int> v{4096reserved};
>>
>> Just throwing this out there.
>>
>> While we're at it, fixing the allocator model wouldn't be a bad idea,=20
>> either (get rid of reference_type, construct(), destroy(), etc...). Unle=
ss=20
>> reflection provides some way to forward an interface, reference_type is=
=20
>> utterly useless.
>>
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_472_121703413.1426619646211
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Would it really be a problem if we disallowed vectors of t=
hese special types? Can we just say this is an use case that will need spec=
ial handling?<div><br></div><div>You would still be allowed to have a vecto=
r of size_t which would fullfill most use cases. Or what about about invent=
ing an element wrapper type that would need to be used to create containers=
 of the special types?<div><br></div><div>vector&lt;size_t&gt; v{1024constr=
ucted}; // creates 1024 elements</div><div>vector&lt;constructed_t&gt; v{10=
24constructed}; //error not allowed.</div><div>vector&lt;element&lt;constru=
cted&gt;&gt; v{1024constructed}; // creates 1024 elements<br></div><div>vec=
tor&lt;element&lt;constructed&gt;&gt; v{make_element(1024constructed)}; // =
creates 1 elements&nbsp;</div><div><br></div><div>On Tuesday, 17 March 2015=
 03:19:14 UTC-7, Tomasz  wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">The problem with use of constructed_t or reserved_t inste=
ad of empty tag structs is that this solution does not really resolve the p=
roblem (as Andrzej said before). Consider following example:<br>std::vector=
&lt;constructed_t&gt; v{1024constructed};<br>Does it allocate vector with 1=
 element or 1024 elements? And having vector of sizes may be actually usefu=
ll.<br><br>W dniu poniedzia=C5=82ek, 16 marca 2015 09:21:19 UTC+1 u=C5=BCyt=
kownik Chris Gary napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">This may or may not be weird:<br><br><div style=3D"background-=
color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bor=
der-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">c=
onstructed_t </span><span style=3D"color:#008">operator</span><span style=
=3D"color:#080">""</span><span style=3D"color:#000">constructed</span><span=
 style=3D"color:#660">(</span><span style=3D"color:#000">size_t</span><span=
 style=3D"color:#660">);</span><span style=3D"color:#000"><br>reserved_t </=
span><span style=3D"color:#008">operator</span><span style=3D"color:#080">"=
"</span><span style=3D"color:#000">reserved</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">size_t</span><span style=3D"color:#660=
">);</span><span style=3D"color:#000"><br></span><span style=3D"color:#000"=
></span><br><span style=3D"color:#000"><code><span style=3D"color:#000">vec=
tor&lt;int&gt; u{1024constructed};</span><span style=3D"color:#000"><br></s=
pan></code>vector</span><span style=3D"color:#080">&lt;int&gt;</span><span =
style=3D"color:#000"> v</span><span style=3D"color:#660">{</span><span styl=
e=3D"color:#066">4096reserved</span><span style=3D"color:#660">};</span><sp=
an style=3D"color:#000"><br></span></div></code></div><br>Just throwing thi=
s out there.<br><br>While we're at it, fixing the allocator model wouldn't =
be a bad idea, either (get rid of reference_type, construct(), destroy(), e=
tc...). Unless reflection provides some way to forward an interface, refere=
nce_type is utterly useless.<br></div></blockquote></div></blockquote></div=
></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_472_121703413.1426619646211--
------=_Part_471_1064485510.1426619646211--

.

--089e01229de0685d1c05118a8497
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Would if you like to allocate the a memory for multiple vectors in one
area. Firstly you would like to compute size of each vector and store this
sizes in other vector. The simplest solution is to have a vector of
constructed_t.

Also, I do not see point in complicating teh solution via dissallowing
certain specialization, creating a wrapper class, where alternative
solution that does not have such problems existis:
std::vector<size_t> v{with_size, 1024};


2015-03-17 20:14 GMT+01:00 Chet <chet.skolos@gmail.com>:

> Would it really be a problem if we disallowed vectors of these special
> types? Can we just say this is an use case that will need special handlin=
g?
>
> You would still be allowed to have a vector of size_t which would fullfil=
l
> most use cases. Or what about about inventing an element wrapper type tha=
t
> would need to be used to create containers of the special types?
>
> vector<size_t> v{1024constructed}; // creates 1024 elements
> vector<constructed_t> v{1024constructed}; //error not allowed.
> vector<element<constructed>> v{1024constructed}; // creates 1024 elements
> vector<element<constructed>> v{make_element(1024constructed)}; // creates
> 1 elements
>
> On Tuesday, 17 March 2015 03:19:14 UTC-7, Tomasz wrote:
>>
>> The problem with use of constructed_t or reserved_t instead of empty tag
>> structs is that this solution does not really resolve the problem (as
>> Andrzej said before). Consider following example:
>> std::vector<constructed_t> v{1024constructed};
>> Does it allocate vector with 1 element or 1024 elements? And having
>> vector of sizes may be actually usefull.
>>
>> W dniu poniedzia=C5=82ek, 16 marca 2015 09:21:19 UTC+1 u=C5=BCytkownik C=
hris Gary
>> napisa=C5=82:
>>>
>>> This may or may not be weird:
>>>
>>> constructed_t operator""constructed(size_t);
>>> reserved_t operator""reserved(size_t);
>>>
>>> vector<int> u{1024constructed};
>>> vector<int> v{4096reserved};
>>>
>>> Just throwing this out there.
>>>
>>> While we're at it, fixing the allocator model wouldn't be a bad idea,
>>> either (get rid of reference_type, construct(), destroy(), etc...). Unl=
ess
>>> reflection provides some way to forward an interface, reference_type is
>>> utterly useless.
>>>
>>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-9ZG33IZ5n8/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--089e01229de0685d1c05118a8497
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Would if you like to allocate the a memory for m=
ultiple vectors in one area. Firstly you would like to compute size of each=
 vector and store this sizes in other vector. The simplest solution is to h=
ave a vector of constructed_t.<br><br></div>Also, I do not see point in com=
plicating teh solution via dissallowing certain specialization, creating a =
wrapper class, where alternative solution that does not have such problems =
existis:<br></div>std::vector&lt;size_t&gt; v{with_size, 1024};<br><br></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-03-17 20:1=
4 GMT+01:00 Chet <span dir=3D"ltr">&lt;<a href=3D"mailto:chet.skolos@gmail.=
com" target=3D"_blank">chet.skolos@gmail.com</a>&gt;</span>:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">Would it really be a problem if we dis=
allowed vectors of these special types? Can we just say this is an use case=
 that will need special handling?<div><br></div><div>You would still be all=
owed to have a vector of size_t which would fullfill most use cases. Or wha=
t about about inventing an element wrapper type that would need to be used =
to create containers of the special types?<div><br></div><div>vector&lt;siz=
e_t&gt; v{1024constructed}; // creates 1024 elements</div><div>vector&lt;co=
nstructed_t&gt; v{1024constructed}; //error not allowed.</div><div>vector&l=
t;element&lt;constructed&gt;&gt; v{1024constructed}; // creates 1024 elemen=
ts<br></div><div>vector&lt;element&lt;constructed&gt;&gt; v{make_element(10=
24constructed)}; // creates 1 elements=C2=A0</div><div><div class=3D"h5"><d=
iv><br></div><div>On Tuesday, 17 March 2015 03:19:14 UTC-7, Tomasz  wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The problem with us=
e of constructed_t or reserved_t instead of empty tag structs is that this =
solution does not really resolve the problem (as Andrzej said before). Cons=
ider following example:<br>std::vector&lt;constructed_t&gt; v{1024construct=
ed};<br>Does it allocate vector with 1 element or 1024 elements? And having=
 vector of sizes may be actually usefull.<br><br>W dniu poniedzia=C5=82ek, =
16 marca 2015 09:21:19 UTC+1 u=C5=BCytkownik Chris Gary napisa=C5=82:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This may or may not be w=
eird:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><=
code><div><span style=3D"color:#000">constructed_t </span><span style=3D"co=
lor:#008">operator</span><span style=3D"color:#080">&quot;&quot;</span><spa=
n style=3D"color:#000">constructed</span><span style=3D"color:#660">(</span=
><span style=3D"color:#000">size_t</span><span style=3D"color:#660">);</spa=
n><span style=3D"color:#000"><br>reserved_t </span><span style=3D"color:#00=
8">operator</span><span style=3D"color:#080">&quot;&quot;</span><span style=
=3D"color:#000">reserved</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">size_t</span><span style=3D"color:#660">);</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#000"></span><br><span s=
tyle=3D"color:#000"><code><span style=3D"color:#000">vector&lt;int&gt; u{10=
24constructed};</span><span style=3D"color:#000"><br></span></code>vector</=
span><span style=3D"color:#080">&lt;int&gt;</span><span style=3D"color:#000=
"> v</span><span style=3D"color:#660">{</span><span style=3D"color:#066">40=
96reserved</span><span style=3D"color:#660">};</span><span style=3D"color:#=
000"><br></span></div></code></div><br>Just throwing this out there.<br><br=
>While we&#39;re at it, fixing the allocator model wouldn&#39;t be a bad id=
ea, either (get rid of reference_type, construct(), destroy(), etc...). Unl=
ess reflection provides some way to forward an interface, reference_type is=
 utterly useless.<br></div></blockquote></div></blockquote></div></div></di=
v></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/-9ZG33IZ5n8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-9ZG33IZ5n8=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01229de0685d1c05118a8497--

.

------=_Part_238_1442450585.1427417272870
Content-Type: multipart/alternative;
 boundary="----=_Part_239_324091112.1427417272870"

------=_Part_239_324091112.1427417272870
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

My two cents here are that having tagged constructors by default is really,=
=20
really ugly.

Instead I would go with

explicit vector(size_type reserved)
vector(size_type size, const T& filler)

where the difference between reserving and filling constructor would be=20
that filling requires explicitly providing value to be filled in. There is=
=20
no convenience lost when you want to initialize vector's elements to=20
something different from T() and only small amount of convenience lost when=
=20
you want to initialize them to T(). (Unless your T is something like=20
vector<map<pair<...>, vector<...>>> in which case, you really should=20
rethink the design anyway)

On Wednesday, 4 March 2015 11:40:47 UTC+1, Andrzej Krzemie=C5=84ski wrote:
>
> Hi Everyone,
> I can see that the Committee considers providing a second incarnation of=
=20
> the STL, in order to facilitate Concepts Lite and the new range interface=
=20
> in a backwards-incompatible manner.
>
> If this path is ever chosen, I see it as an opportunity to fix other=20
> things in the STL also. Below I present one thing that I personally=20
> consider a flaw. I would like to hear your opinion.
>
> I mean this constructor of std::vector and its kin that takes one argumen=
t=20
> of type size_type:
>
> explicit vector(size_type n, const Allocator& =3D Allocator());
>
> It is the source of two confusions:
>
> *Problem 1:*
> vector<int> v(2);
> vector<int> w{2};=20
>
> The above two declarations trigger different constructors and render a=20
> different value. This is an unnecessary point of confusion and a source o=
f=20
> problems. For a more detailed discussion see here=20
> <https://akrzemi1.wordpress.com/2013/06/05/intuitive-interface-part-i/>.
>
> *Problem 2:*
> In declaration:
> vector<T> v(100);
> People happen to mistakenly think that that this reserves the capacity of=
=20
> 100 rather than setting the size. This confusion is enforced by the fact=
=20
> that similar libraries in other languages mean capacity in this case, e.g=
..,=20
> java.util.ArrayList<E>=20
> <http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList.html>.=20
> Also, in my personal experience, initial capacity is something that I=20
> require more often that initial size.
>
> What I propose is to remove the said constructor (and similar one taking=
=20
> default T), add replace them with constructors taking tags that enforce t=
he=20
> user to explicitly state their intent:
>
> constexpr class with_size_t{} with_size{};
> constexpr class with_capacity_t{} with_capacity{};
>
> explicit vector(*with_size_t*, size_type n, const Allocator& =3D=20
> Allocator());
> explicit vector(*with_size_t*, size_type n, const T& value, const=20
> Allocator& =3D Allocator());
> explicit vector(*with_capacity_t*, size_type c, const Allocator& =3D=20
> Allocator());
> explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type=
=20
> n, const Allocator& =3D Allocator());
> explicit vector(*with_capacity_t, *size_type c,* with_size_t*, size_type=
=20
> n, const T& value, const Allocator& =3D Allocator());
>
> This is a lot of overloads, but what it gives instead is zero ambiguity.
> What do you think?
>
> Regards,
> &rzej
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_239_324091112.1427417272870
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My two cents here are that having tagged constructors by d=
efault is really, really ugly.<div><br></div><div>Instead I would go with</=
div><div><br></div><div>explicit vector(size_type reserved)</div><div>vecto=
r(size_type size, const T&amp; filler)</div><div><br>where the difference b=
etween reserving and filling constructor would be that filling requires exp=
licitly providing value to be filled in. There is no convenience lost when =
you want to initialize vector's elements to something different from T() an=
d only small amount of convenience lost when you want to initialize them to=
 T(). (Unless your T is something like vector&lt;map&lt;pair&lt;...&gt;, ve=
ctor&lt;...&gt;&gt;&gt; in which case, you really should rethink the design=
 anyway)<br><br>On Wednesday, 4 March 2015 11:40:47 UTC+1, Andrzej Krzemie=
=C5=84ski  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Hi Everyone,<br>I can see that the Committee considers providing a seco=
nd incarnation of the STL, in order to facilitate Concepts Lite and the new=
 range interface in a backwards-incompatible manner.<br><br>If this path is=
 ever chosen, I see it as an opportunity to fix other things in the STL als=
o. Below I present one thing that I personally consider a flaw. I would lik=
e to hear your opinion.<br><br>I mean this constructor of std::vector and i=
ts kin that takes one argument of type size_type:<br><br>explicit vector(si=
ze_type n, const Allocator&amp; =3D Allocator());<br><br>It is the source o=
f two confusions:<br><br><b>Problem 1:</b><br>vector&lt;int&gt; v(2);<br>ve=
ctor&lt;int&gt; w{2}; <br><br>The above two declarations trigger different =
constructors and render a different value. This is an unnecessary point of =
confusion and a source of problems. For a more detailed discussion <a href=
=3D"https://akrzemi1.wordpress.com/2013/06/05/intuitive-interface-part-i/" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.=
google.com/url?q\75https%3A%2F%2Fakrzemi1.wordpress.com%2F2013%2F06%2F05%2F=
intuitive-interface-part-i%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNE3yOlHOX-b=
053yHOVHfSXge1VJNw';return true;" onclick=3D"this.href=3D'https://www.googl=
e.com/url?q\75https%3A%2F%2Fakrzemi1.wordpress.com%2F2013%2F06%2F05%2Fintui=
tive-interface-part-i%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNE3yOlHOX-b053yH=
OVHfSXge1VJNw';return true;">see here</a>.<br><br><b>Problem 2:</b><br>In d=
eclaration:<br>vector&lt;T&gt; v(100);<br>People happen to mistakenly think=
 that that this reserves the capacity of 100 rather than setting the size. =
This confusion is enforced by the fact that similar libraries in other lang=
uages mean capacity in this case, e.g., <a href=3D"http://docs.oracle.com/j=
avase/6/docs/api/java/util/ArrayList.html" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fd=
ocs.oracle.com%2Fjavase%2F6%2Fdocs%2Fapi%2Fjava%2Futil%2FArrayList.html\46s=
a\75D\46sntz\0751\46usg\75AFQjCNHovuHCJ5QdqACuJigYy8rwgP1jFQ';return true;"=
 onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fdocs.or=
acle.com%2Fjavase%2F6%2Fdocs%2Fapi%2Fjava%2Futil%2FArrayList.html\46sa\75D\=
46sntz\0751\46usg\75AFQjCNHovuHCJ5QdqACuJigYy8rwgP1jFQ';return true;">java.=
util.ArrayList&lt;E&gt;</a>. Also, in my personal experience, initial capac=
ity is something that I require more often that initial size.<br><br>What I=
 propose is to remove the said constructor (and similar one taking default =
T), add replace them with constructors taking tags that enforce the user to=
 explicitly state their intent:<br><br>constexpr class with_size_t{} with_s=
ize{};<br>constexpr class with_capacity_t{} with_capacity{};<br><br>explici=
t vector(<b>with_size_t</b>, size_type n, const Allocator&amp; =3D Allocato=
r());<br>explicit vector(<b>with_size_t</b>, size_type n, const T&amp; valu=
e, const Allocator&amp; =3D Allocator());<br>explicit vector(<b>with_capaci=
ty_t</b>, size_type c, const Allocator&amp; =3D Allocator());<br>explicit v=
ector(<b><b>with_capacity_t</b>, </b>size_type c,<b> with_size_t</b>, size_=
type n, const Allocator&amp; =3D Allocator());<br>explicit vector(<b><b>wit=
h_capacity_t</b>, </b>size_type c,<b> with_size_t</b>, size_type n, const T=
&amp; value, const Allocator&amp; =3D Allocator());<br><br>This is a lot of=
 overloads, but what it gives instead is zero ambiguity.<br>What do you thi=
nk?<br><br>Regards,<br>&amp;rzej<br></div></blockquote></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_239_324091112.1427417272870--
------=_Part_238_1442450585.1427417272870--

.

------=_Part_392_1376242031.1427437615559
Content-Type: multipart/alternative;
 boundary="----=_Part_393_2100936827.1427437615559"

------=_Part_393_2100936827.1427437615559
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

How this would resolve original problem? Following constructions:
std::vector<int> v1(10), v2{10};
std::vector<int> b1(10,20), b2{10, 20};
Would still trigger different constructors and product different values.

On Friday, March 27, 2015 at 1:47:52 AM UTC+1, Martin Ho=C5=99e=C5=88ovsk=
=C3=BD wrote:
>
> My two cents here are that having tagged constructors by default is=20
> really, really ugly.
>
> Instead I would go with
>
> explicit vector(size_type reserved)
> vector(size_type size, const T& filler)
>
> where the difference between reserving and filling constructor would be=
=20
> that filling requires explicitly providing value to be filled in. There i=
s=20
> no convenience lost when you want to initialize vector's elements to=20
> something different from T() and only small amount of convenience lost wh=
en=20
> you want to initialize them to T(). (Unless your T is something like=20
> vector<map<pair<...>, vector<...>>> in which case, you really should=20
> rethink the design anyway)
>
>
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_393_2100936827.1427437615559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How this would resolve original problem? Following constru=
ctions:<br>std::vector&lt;int&gt; v1(10), v2{10};<br>std::vector&lt;int&gt;=
 b1(10,20), b2{10, 20};<br>Would still trigger different constructors and p=
roduct different values.<br><br>On Friday, March 27, 2015 at 1:47:52 AM UTC=
+1, Martin Ho=C5=99e=C5=88ovsk=C3=BD wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr">My two cents here are that having tagged cons=
tructors by default is really, really ugly.<div><br></div><div>Instead I wo=
uld go with</div><div><br></div><div>explicit vector(size_type reserved)</d=
iv><div>vector(size_type size, const T&amp; filler)</div><div><br>where the=
 difference between reserving and filling constructor would be that filling=
 requires explicitly providing value to be filled in. There is no convenien=
ce lost when you want to initialize vector's elements to something differen=
t from T() and only small amount of convenience lost when you want to initi=
alize them to T(). (Unless your T is something like vector&lt;map&lt;pair&l=
t;...&gt;, vector&lt;...&gt;&gt;&gt; in which case, you really should rethi=
nk the design anyway)<br><br><br></div></div></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_393_2100936827.1427437615559--
------=_Part_392_1376242031.1427437615559--

.

--089e015382b644c6af051244d338
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On an orthogonal though on some of the issues here trying to determine
whether 'vector<constructed_t> v{1024constructed};' should construct a
vector of 1 or 1024 elements, there's a crazy thought that has been going
through my mind for the last couple of years... what if the initializer
list required an additional set or braces?

std::vector<int> v{{1, 2, 3, 4}};

The syntax could not be too onerous, it would be different from aggregate
initialization (con) but it would be clearly identifiable as a different
entity.  That would solve the problem here, but also others, like being
able to construct a vector of 100 elements in a return statement (without
having to type 100 values) which would be a bit more in the lines of A bit
in the lines of n4029:

std::vector<int> f(bool x) {
    if (x) return { 100 };     // return 100 element vector
    else  return {{ 100 }};   // return 1 element vector
}

Or removing other ambiguities for the (few) types that are constructible
from initializer_list<>'s. Just food for thought, it is too late to play
with the initialization syntax at this point.

    David

On Fri, Mar 27, 2015 at 2:26 AM, <anna.salwa.05@gmail.com> wrote:

> How this would resolve original problem? Following constructions:
> std::vector<int> v1(10), v2{10};
> std::vector<int> b1(10,20), b2{10, 20};
> Would still trigger different constructors and product different values.
>
> On Friday, March 27, 2015 at 1:47:52 AM UTC+1, Martin Ho=C5=99e=C5=88ovsk=
=C3=BD wrote:
>>
>> My two cents here are that having tagged constructors by default is
>> really, really ugly.
>>
>> Instead I would go with
>>
>> explicit vector(size_type reserved)
>> vector(size_type size, const T& filler)
>>
>> where the difference between reserving and filling constructor would be
>> that filling requires explicitly providing value to be filled in. There =
is
>> no convenience lost when you want to initialize vector's elements to
>> something different from T() and only small amount of convenience lost w=
hen
>> you want to initialize them to T(). (Unless your T is something like
>> vector<map<pair<...>, vector<...>>> in which case, you really should
>> rethink the design anyway)
>>
>>
>>  --
>
> ---
> 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/.
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--089e015382b644c6af051244d338
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On an orthogonal though on some of the issues here trying =
to determine whether &#39;<span style=3D"font-size:12.8000001907349px">vect=
or&lt;constructed_t&gt; v{1024constructed};&#39; should construct a vector =
of 1 or 1024 elements, there&#39;s a crazy thought that has been going thro=
ugh my mind for the last couple of years... what if the initializer list re=
quired an additional set or braces?<br><br>std::vector&lt;int&gt; v{{1, 2, =
3, 4}};<br><br>The syntax could not be too onerous, it would be different f=
rom aggregate initialization (con) but it would be clearly identifiable as =
a different entity.=C2=A0 That would solve the problem here, but also other=
s, like being able to construct a vector of 100 elements in a return statem=
ent (without having to type 100 values) which would be a bit more in the li=
nes of=C2=A0</span><span style=3D"font-size:12.8000001907349px">A bit in th=
e lines of n4029:</span><br><br><span style=3D"font-size:12.8000001907349px=
">std::vector&lt;int&gt; f(bool x) {</span><br><span style=3D"font-size:12.=
8000001907349px">=C2=A0 =C2=A0 if (x) return { 100 }; =C2=A0 =C2=A0 // retu=
rn 100 element vector</span><br><span style=3D"font-size:12.8000001907349px=
">=C2=A0 =C2=A0 else =C2=A0return {{ 100 }}; =C2=A0 // return 1 element vec=
tor</span><br><span style=3D"font-size:12.8000001907349px">}</span><br><br>=
Or removing other ambiguities for the (few) types that are constructible fr=
om initializer_list&lt;&gt;&#39;s. Just food for thought, it is too late to=
 play with the initialization syntax at this point.<br><br>=C2=A0 =C2=A0 Da=
vid</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, =
Mar 27, 2015 at 2:26 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:anna.salw=
a.05@gmail.com" target=3D"_blank">anna.salwa.05@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">How this would reso=
lve original problem? Following constructions:<br>std::vector&lt;int&gt; v1=
(10), v2{10};<br>std::vector&lt;int&gt; b1(10,20), b2{10, 20};<br>Would sti=
ll trigger different constructors and product different values.<span class=
=3D""><br><br>On Friday, March 27, 2015 at 1:47:52 AM UTC+1, Martin Ho=C5=
=99e=C5=88ovsk=C3=BD wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">My two cents here are that having tagged constructors by default i=
s really, really ugly.<div><br></div><div>Instead I would go with</div><div=
><br></div><div>explicit vector(size_type reserved)</div><div>vector(size_t=
ype size, const T&amp; filler)</div><div><br>where the difference between r=
eserving and filling constructor would be that filling requires explicitly =
providing value to be filled in. There is no convenience lost when you want=
 to initialize vector&#39;s elements to something different from T() and on=
ly small amount of convenience lost when you want to initialize them to T()=
.. (Unless your T is something like vector&lt;map&lt;pair&lt;...&gt;, vector=
&lt;...&gt;&gt;&gt; in which case, you really should rethink the design any=
way)<br><br><br></div></div></blockquote></span></div><div class=3D"HOEnZb"=
><div class=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e015382b644c6af051244d338--

.

It wouldn't, but that quirk is probably with us to stay, because the
alternative is tagged constructor and I really, really, really don't
want beginners's first impression of standard library be that of
tagged constructors.

It resolves the problem of "reserved construction", that is that if
you want vector that is able to hold 100 items, but doesn't hold them
yet, you have to do

vector<foo> vec;
vec.reserve(100);

and that the "obvious way to do it"

vector<foo> vec(100);

leads to unexpected results.

On 27 March 2015 at 07:26,  <anna.salwa.05@gmail.com> wrote:
> How this would resolve original problem? Following constructions:
> std::vector<int> v1(10), v2{10};
> std::vector<int> b1(10,20), b2{10, 20};
> Would still trigger different constructors and product different values.
>
> On Friday, March 27, 2015 at 1:47:52 AM UTC+1, Martin Ho=C5=99e=C5=88ovsk=
=C3=BD wrote:
>>
>> My two cents here are that having tagged constructors by default is
>> really, really ugly.
>>
>> Instead I would go with
>>
>> explicit vector(size_type reserved)
>> vector(size_type size, const T& filler)
>>
>> where the difference between reserving and filling constructor would be
>> that filling requires explicitly providing value to be filled in. There =
is
>> no convenience lost when you want to initialize vector's elements to
>> something different from T() and only small amount of convenience lost w=
hen
>> you want to initialize them to T(). (Unless your T is something like
>> vector<map<pair<...>, vector<...>>> in which case, you really should ret=
hink
>> the design anyway)
>>
>>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-9ZG33IZ5n8/=
unsubscribe.
> To unsubscribe from this group and all its topics, 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/.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

--Apple-Mail=_C4088F14-CD69-4CCB-9EA7-558315773167
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9303=E2=80=9327, at 9:43 PM, Martin Ho=C5=99e=C5=88ovsk=C3=
=BD <martin.horenovsky@gmail.com> wrote:
>=20
> It wouldn't, but that quirk is probably with us to stay, because the
> alternative is tagged constructor and I really, really, really don't
> want beginners's first impression of standard library be that of
> tagged constructors.

Another alternative is named arguments, or their close cousins, designated =
initializers. In the straightforward extrapolation to C++, designated names=
 in initializer lists would resolve overloads by removing candidates withou=
t matching names.

template< typename t >
struct replication {
    t proto; // Perhaps t const& instead?
    size_t count;
};

template< typename elem, typename alloc >
class vector {
    /* implicit */ vector( replication< elem > const & );
    =E2=80=A6
};

std::vector< foo > vec { .proto: { "hi" }, .count: 30 };
std::vector< foo > vec2 { .count: 30 }; // .proto is default-initialized

The main problem I see with designated initializers is the introduction of =
another point of difference between aggregate initialization and constructo=
rs. The =E2=80=9Cvalue prototype=E2=80=9D part of my categorized classes pr=
oposal (N4149) hints at a workaround, allowing aggregate initialization to =
generate non-aggregate objects. However, EWG thought it was a bit evil, and=
 I don=E2=80=99t know how such a type could be worked into a parameter decl=
aration. It does suggest, though, that the problem is surmountable.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_C4088F14-CD69-4CCB-9EA7-558315773167
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=
=E2=80=9327, at 9:43 PM, Martin Ho=C5=99e=C5=88ovsk=C3=BD &lt;<a href=3D"ma=
ilto:martin.horenovsky@gmail.com" class=3D"">martin.horenovsky@gmail.com</a=
>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><=
span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px; float: none; display: inline !important;" class=3D""=
>It wouldn't, but that quirk is probably with us to stay, because the</span=
><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; dis=
play: inline !important;" class=3D"">alternative is tagged constructor and =
I really, really, really don't</span><br style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><spa=
n style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px; float: none; display: inline !important;" class=3D"">wa=
nt beginners's first impression of standard library be that of</span><br st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-siz=
e: 12px; font-style: normal; font-variant: normal; font-weight: normal; let=
ter-spacing: normal; line-height: normal; orphans: auto; text-align: start;=
 text-indent: 0px; text-transform: none; white-space: normal; widows: auto;=
 word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: i=
nline !important;" class=3D"">tagged constructors.</span><br style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;" class=3D""></div></blockquote><div><br class=3D""></div><div>Another a=
lternative is named arguments, or their close cousins, designated initializ=
ers. In the straightforward extrapolation to C++, designated names in initi=
alizer lists would resolve overloads by removing candidates without matchin=
g names.</div><div><br class=3D""></div><div><font face=3D"Courier" class=
=3D"">template&lt; typename t &gt;</font></div><div><font face=3D"Courier" =
class=3D"">struct replication {</font></div><div><font face=3D"Courier" cla=
ss=3D"">&nbsp; &nbsp; t proto; // Perhaps t const&amp; instead?</font></div=
><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; size_t count;</font><=
/div><div><font face=3D"Courier" class=3D"">};</font></div><div><font face=
=3D"Courier" class=3D""><br class=3D""></font></div><div><font face=3D"Cour=
ier" class=3D"">template&lt; typename elem, typename alloc &gt;</font></div=
><div><font face=3D"Courier" class=3D"">class vector {</font></div><div><fo=
nt face=3D"Courier" class=3D"">&nbsp; &nbsp; /* implicit */ vector( replica=
tion&lt; elem &gt; const &amp; );</font></div><div><font face=3D"Courier" c=
lass=3D"">&nbsp; &nbsp; =E2=80=A6</font></div><div><font face=3D"Courier" c=
lass=3D"">};</font></div><div><font face=3D"Courier" class=3D""><br class=
=3D""></font></div><div><font face=3D"Courier" class=3D"">std::vector&lt; f=
oo &gt; vec { .proto: { "hi" }, .count: 30 };</font></div><span style=3D"fo=
nt-family: Courier;" class=3D"">std::vector&lt; foo &gt; vec2 { .count: 30 =
}; // .proto is default-initialized</span></div><div class=3D""><font face=
=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D"">The mai=
n problem I see with designated initializers is the introduction of another=
 point of difference between aggregate initialization and constructors. The=
 =E2=80=9Cvalue prototype=E2=80=9D part of my categorized classes proposal =
(N4149) hints at a workaround, allowing aggregate initialization to generat=
e non-aggregate objects. However, EWG thought it was a bit evil, and I don=
=E2=80=99t know how such a type could be worked into a parameter declaratio=
n. It does suggest, though, that the problem is surmountable.</div></body><=
/html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_C4088F14-CD69-4CCB-9EA7-558315773167--

.

------=_Part_719_177868480.1427488386617
Content-Type: multipart/alternative;
 boundary="----=_Part_720_138306736.1427488386617"

------=_Part_720_138306736.1427488386617
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, March 27, 2015 at 2:43:59 PM UTC+1, Martin Ho=C5=99e=C5=88ovsk=
=C3=BD wrote:
>
> It wouldn't, but that quirk is probably with us to stay, because the=20
> alternative is tagged constructor and I really, really, really don't=20
> want beginners's first impression of standard library be that of=20
> tagged constructors.=20
>
>
I think that tagged constructors are simpler/better to expose to the=20
beginners, than the alternative we currently have that exposes the quirks=
=20
of brace versus parenthesis on such simple thing like vector of integers.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_720_138306736.1427488386617
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, March 27, 2015 at 2:43:59 PM UTC+1, Martin Ho=
=C5=99e=C5=88ovsk=C3=BD wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
It wouldn't, but that quirk is probably with us to stay, because the
<br>alternative is tagged constructor and I really, really, really don't
<br>want beginners's first impression of standard library be that of
<br>tagged constructors.
<br>
<br></blockquote><div><br>I think that tagged constructors are simpler/bett=
er to expose to the beginners, than the alternative we currently have that =
exposes the quirks of brace versus parenthesis on such simple thing like ve=
ctor of integers.<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_720_138306736.1427488386617--
------=_Part_719_177868480.1427488386617--

.

------=_Part_1275_1679812332.1427488544352
Content-Type: multipart/alternative;
 boundary="----=_Part_1276_1785840462.1427488544352"

------=_Part_1276_1785840462.1427488544352
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Friday, March 27, 2015 at 4:49:38 PM UTC+1, David Krauss wrote:
>
>
> On 2015=E2=80=9303=E2=80=9327, at 9:43 PM, Martin Ho=C5=99e=C5=88ovsk=C3=
=BD <martin.h...@gmail.com=20
> <javascript:>> wrote:
>
> It wouldn't, but that quirk is probably with us to stay, because the
> alternative is tagged constructor and I really, really, really don't
> want beginners's first impression of standard library be that of
> tagged constructors.
>
>
> Another alternative is named arguments, or their close cousins, designate=
d=20
> initializers. In the straightforward extrapolation to C++, designated nam=
es=20
> in initializer lists would resolve overloads by removing candidates witho=
ut=20
> matching names.
>
> template< typename t >
> struct replication {
>     t proto; // Perhaps t const& instead?
>     size_t count;
> };
>
> template< typename elem, typename alloc >
> class vector {
>     /* implicit */ vector( replication< elem > const & );
>     =E2=80=A6
> };
>
> std::vector< foo > vec { .proto: { "hi" }, .count: 30 };
> std::vector< foo > vec2 { .count: 30 }; // .proto is default-initialized
>
> The main problem I see with designated initializers is the introduction o=
f=20
> another point of difference between aggregate initialization and=20
> constructors. The =E2=80=9Cvalue prototype=E2=80=9D part of my categorize=
d classes proposal=20
> (N4149) hints at a workaround, allowing aggregate initialization to=20
> generate non-aggregate objects. However, EWG thought it was a bit evil, a=
nd=20
> I don=E2=80=99t know how such a type could be worked into a parameter dec=
laration.=20
> It does suggest, though, that the problem is surmountable.
>

Having a proto for every sized constructor will reintroduce requirement=20
that the value_type to be CopyConstructible. This is why in C++11 the=20
signature (std::size_t count, T const& val =3D T()) was splitted in to two=
=20
separate ones (size_t count) and (std::size_t count, T const& val) so the=
=20
container can value-initialize every element instead of using=20
copy-initialization.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_1276_1785840462.1427488544352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, March 27, 2015 at 4:49:38 PM UTC+1, Dav=
id Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"=
word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=
=9303=E2=80=9327, at 9:43 PM, Martin Ho=C5=99e=C5=88ovsk=C3=BD &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"yWHWOStU8KYJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;">martin.h...@gmail.com</a>&gt=
; wrote:</div><br><div><span style=3D"font-family:Helvetica;font-size:12px;=
font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:nor=
mal;line-height:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;float:none;display:inline!important">I=
t wouldn't, but that quirk is probably with us to stay, because the</span><=
br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var=
iant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;tex=
t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"><span style=3D"font-family:Helvetica;font-size:12px;font-style:=
normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-he=
ight:normal;text-align:start;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px;float:none;display:inline!important">alternative =
is tagged constructor and I really, really, really don't</span><br style=3D=
"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal=
;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
><span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font=
-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px;float:none;display:inline!important">want beginners's first =
impression of standard library be that of</span><br style=3D"font-family:He=
lvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:no=
rmal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px"><span style=3D=
"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal=
;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
float:none;display:inline!important">tagged constructors.</span><br style=
=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px"></div></blockquote><div><br></div><div>Another alternative is named arg=
uments, or their close cousins, designated initializers. In the straightfor=
ward extrapolation to C++, designated names in initializer lists would reso=
lve overloads by removing candidates without matching names.</div><div><br>=
</div><div><font face=3D"Courier">template&lt; typename t &gt;</font></div>=
<div><font face=3D"Courier">struct replication {</font></div><div><font fac=
e=3D"Courier">&nbsp; &nbsp; t proto; // Perhaps t const&amp; instead?</font=
></div><div><font face=3D"Courier">&nbsp; &nbsp; size_t count;</font></div>=
<div><font face=3D"Courier">};</font></div><div><font face=3D"Courier"><br>=
</font></div><div><font face=3D"Courier">template&lt; typename elem, typena=
me alloc &gt;</font></div><div><font face=3D"Courier">class vector {</font>=
</div><div><font face=3D"Courier">&nbsp; &nbsp; /* implicit */ vector( repl=
ication&lt; elem &gt; const &amp; );</font></div><div><font face=3D"Courier=
">&nbsp; &nbsp; =E2=80=A6</font></div><div><font face=3D"Courier">};</font>=
</div><div><font face=3D"Courier"><br></font></div><div><font face=3D"Couri=
er">std::vector&lt; foo &gt; vec { .proto: { "hi" }, .count: 30 };</font></=
div><span style=3D"font-family:Courier">std::vector&lt; foo &gt; vec2 { .co=
unt: 30 }; // .proto is default-initialized</span></div><div><font face=3D"=
Courier"><br></font></div><div>The main problem I see with designated initi=
alizers is the introduction of another point of difference between aggregat=
e initialization and constructors. The =E2=80=9Cvalue prototype=E2=80=9D pa=
rt of my categorized classes proposal (N4149) hints at a workaround, allowi=
ng aggregate initialization to generate non-aggregate objects. However, EWG=
 thought it was a bit evil, and I don=E2=80=99t know how such a type could =
be worked into a parameter declaration. It does suggest, though, that the p=
roblem is surmountable.</div></div></blockquote><div><br>Having a proto for=
 every sized constructor will reintroduce requirement that the value_type t=
o be CopyConstructible. This is why in C++11 the signature (std::size_t cou=
nt, T const&amp; val =3D T()) was splitted in to two separate ones (size_t =
count) and (std::size_t count, T const&amp; val) so the container can value=
-initialize every element instead of using copy-initialization.<br></div></=
div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1276_1785840462.1427488544352--
------=_Part_1275_1679812332.1427488544352--

.

------=_Part_27_976086563.1427495880776
Content-Type: multipart/alternative;
 boundary="----=_Part_28_459284908.1427495880777"

------=_Part_28_459284908.1427495880777
Content-Type: text/plain; charset=UTF-8

On Friday, March 27, 2015 at 8:49:38 AM UTC-7, David Krauss wrote:
>
> Another alternative is named arguments, or their close cousins, designated
> initializers.
>

Or we could always end tagging and other tricks entirely by directly
proposing some form of named constructors. This has proven to be a common
enough issue that it warrants consideration.

--

---
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/.

------=_Part_28_459284908.1427495880777
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, March 27, 2015 at 8:49:38 AM UTC-7, David Kraus=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wra=
p:break-word"><div><div>Another alternative is named arguments, or their cl=
ose cousins, designated initializers.</div></div></div></blockquote><div><b=
r></div><div>Or we could always end tagging and other tricks entirely by di=
rectly proposing some form of named constructors. This has proven to be a c=
ommon enough issue that it warrants consideration.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_28_459284908.1427495880777--
------=_Part_27_976086563.1427495880776--

.

--Apple-Mail=_FC5B2D7E-9BCF-45E7-B3DC-00E68151C970
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9303=E2=80=9328, at 4:35 AM, Tomasz <tomaszkam@gmail.com> w=
rote:
>=20
> Having a proto for every sized constructor will reintroduce requirement t=
hat the value_type to be CopyConstructible. This is why in C++11 the signat=
ure (std::size_t count, T const& val =3D T()) was splitted in to two separa=
te ones (size_t count) and (std::size_t count, T const& val) so the contain=
er can value-initialize every element instead of using copy-initialization.

I don=E2=80=99t think such a struct is appropriate for each and every const=
ructor; that=E2=80=99s not what I=E2=80=99m proposing. Only struct replicat=
ion where there=E2=80=99s an ambiguity to be resolved. There would be an in=
consistency in vec{ .count: 30 } and vec( 30 ) doing slightly different thi=
ngs, which is a problem.

std::optional would provide a workaround, by the way.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_FC5B2D7E-9BCF-45E7-B3DC-00E68151C970
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=
=E2=80=9328, at 4:35 AM, Tomasz &lt;<a href=3D"mailto:tomaszkam@gmail.com" =
class=3D"">tomaszkam@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><div dir=3D"ltr" style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D"">Having a proto for every sized constructor will reintroduce requireme=
nt that the value_type to be CopyConstructible. This is why in C++11 the si=
gnature (std::size_t count, T const&amp; val =3D T()) was splitted in to tw=
o separate ones (size_t count) and (std::size_t count, T const&amp; val) so=
 the container can value-initialize every element instead of using copy-ini=
tialization.</div></div></blockquote><div><br class=3D""></div><div>I don=
=E2=80=99t think such a struct is appropriate for each and every constructo=
r; that=E2=80=99s not what I=E2=80=99m proposing. Only <font face=3D"Courie=
r" class=3D"">struct replication</font> where there=E2=80=99s an ambiguity =
to be resolved. There would be an inconsistency in <font face=3D"Courier" c=
lass=3D"">vec{ .count: 30 }</font> and <font face=3D"Courier" class=3D"">ve=
c( 30 )</font> doing slightly different things, which is a problem.</div><d=
iv><br class=3D""></div><div><font face=3D"Courier" class=3D"">std::optiona=
l</font>&nbsp;would provide a workaround, by the way.</div></div></body></h=
tml>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_FC5B2D7E-9BCF-45E7-B3DC-00E68151C970--

.

------=_Part_1541_1125537256.1427511465063
Content-Type: multipart/alternative;
 boundary="----=_Part_1542_1868698816.1427511465063"

------=_Part_1542_1868698816.1427511465063
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This would change the meaning of working code.  Currently, the code=20
vector<int> v(10);

constructs a vector with 10 default-constructed elements.  Under your=20
change it would construct an empty vector with capacity() >=3D 10 Whether i=
t=20
was a good decision to define the constructor that way is debatable, but=20
that decision was made, and I can't see any way of changing it without=20
silently breaking any code that was written using this constructor.

Joe Gottman


On Thursday, March 26, 2015 at 8:47:52 PM UTC-4, Martin Ho=C5=99e=C5=88ovsk=
=C3=BD wrote:
>
> My two cents here are that having tagged constructors by default is=20
> really, really ugly.
>
> Instead I would go with
>
> explicit vector(size_type reserved)
> vector(size_type size, const T& filler)
>
> where the difference between reserving and filling constructor would be=
=20
> that filling requires explicitly providing value to be filled in. There i=
s=20
> no convenience lost when you want to initialize vector's elements to=20
> something different from T() and only small amount of convenience lost wh=
en=20
> you want to initialize them to T(). (Unless your T is something like=20
> vector<map<pair<...>, vector<...>>> in which case, you really should=20
> rethink the design anyway)
>
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_1542_1868698816.1427511465063
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>This would change the meaning of working code.&nbsp; C=
urrently, the code <br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">vector</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">10</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div><br>constructs a vector with 10 default-constructed elements.&nbsp; Un=
der your change it would construct an empty vector with capacity() &gt;=3D =
10 Whether it was a good decision to define the constructor that way is deb=
atable, but that decision was made, and I can't see any way of changing it =
without silently breaking any code that was written using this constructor.=
<br><br>Joe Gottman<br><br><br>On Thursday, March 26, 2015 at 8:47:52 PM UT=
C-4, Martin Ho=C5=99e=C5=88ovsk=C3=BD wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">My two cents here are that having tagged con=
structors by default is really, really ugly.<div><br></div><div>Instead I w=
ould go with</div><div><br></div><div>explicit vector(size_type reserved)</=
div><div>vector(size_type size, const T&amp; filler)</div><div><br>where th=
e difference between reserving and filling constructor would be that fillin=
g requires explicitly providing value to be filled in. There is no convenie=
nce lost when you want to initialize vector's elements to something differe=
nt from T() and only small amount of convenience lost when you want to init=
ialize them to T(). (Unless your T is something like vector&lt;map&lt;pair&=
lt;...&gt;, vector&lt;...&gt;&gt;&gt; in which case, you really should reth=
ink the design anyway)<br><br></div></div></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1542_1868698816.1427511465063--
------=_Part_1541_1125537256.1427511465063--

.

On 2015-03-27 18:38, Matt Calabrese wrote:
> On Friday, March 27, 2015 at 8:49:38 AM UTC-7, David Krauss wrote:
>> Another alternative is named arguments, or their close cousins, designated
>> initializers.
>>
>
> Or we could always end tagging and other tricks entirely by directly
> proposing some form of named constructors. This has proven to be a common
> enough issue that it warrants consideration.

Like this?

  auto myvec = std::vector<int>::reserved(capacity);

With move semantics, I'm not aware that there is any notable cost to
implementing such ctors as static methods on the class (which is the
usual, existing paradigm). It would just be a matter of proposing the
addition of such. They can also be added to existing containers.

Possibilities:

  vector&& reserved(size_t capacity);
  vector&& allocated(size_t size);
  vector&& allocated(size_t size, T const& value);

(I'll refer to other discussion why the two allocated() aren't merged.)

--
Matthew

--

---
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/.

.

--Apple-Mail=_4DF29BFB-7867-4C52-8EB2-173E809CBFAA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9303=E2=80=9330, at 11:18 PM, Matthew Woehlke <mw_triad@use=
rs.sourceforge.net> wrote:
>=20
>  auto myvec =3D std::vector<int>::reserved(capacity);

You win. It would be nice to see this formally proposed.

Another spelling would be reserved< std::vector< int > >( capacity ). A fre=
e function would avoid boilerplate in user-defined containers that want to =
maintain parity with the standard ones. But, this is a bit awkward and unus=
ual style.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_4DF29BFB-7867-4C52-8EB2-173E809CBFAA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=
=E2=80=9330, at 11:18 PM, Matthew Woehlke &lt;<a href=3D"mailto:mw_triad@us=
ers.sourceforge.net" class=3D"">mw_triad@users.sourceforge.net</a>&gt; wrot=
e:</div><br class=3D"Apple-interchange-newline"><div class=3D"">&nbsp;auto =
myvec =3D std::vector&lt;int&gt;::reserved(capacity);<br class=3D""></div><=
/blockquote><div><br class=3D""></div><div>You win. It would be nice to see=
 this formally proposed.</div><div><br class=3D""></div><div>Another spelli=
ng would be <font face=3D"Courier" class=3D"">reserved&lt; std::vector&lt; =
int &gt; &gt;( capacity )</font>. A free function would avoid boilerplate i=
n user-defined containers that want to maintain parity with the standard on=
es. But, this is a bit awkward and unusual style.</div></div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_4DF29BFB-7867-4C52-8EB2-173E809CBFAA--

.

On Tuesday 31 March 2015 19:00:27 David Krauss wrote:
> Another spelling would be reserved< std::vector< int > >( capacity ). A free
> function would avoid boilerplate in user-defined containers that want to
> maintain parity with the standard ones. But, this is a bit awkward and
> unusual style.

A free function may require friend rights to each container and most likely a
partial specialisation for each container template.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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/.

.

--047d7bd6b7fec4431005129971d7
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 30, 2015 at 8:18 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2015-03-27 18:38, Matt Calabrese wrote:
> > On Friday, March 27, 2015 at 8:49:38 AM UTC-7, David Krauss wrote:
> >> Another alternative is named arguments, or their close cousins,
> designated
> >> initializers.
> >>
> >
> > Or we could always end tagging and other tricks entirely by directly
> > proposing some form of named constructors. This has proven to be a common
> > enough issue that it warrants consideration.
>
> Like this?
>
>   auto myvec = std::vector<int>::reserved(capacity);
>

Something like that, yeah! I'd be very happy if we moved away from tags
like "piecewise_construct" and "allocator_arg" entirely and instead just
had a way to choose the constructor by name. Using tags is also really
tough to do correctly when you have multiple overloads that are templates.

With move semantics, I'm not aware that there is any notable cost to
> implementing such ctors as static methods on the class (which is the
> usual, existing paradigm). It would just be a matter of proposing the
> addition of such.


Oh, we're apparently talking about slightly different things. I meant an
actual language-level facility of named constructors. In other words,
"reserved" wouldn't be a static member function in the current sense, but
rather it would be a constructor with a name. Static member functions in
place of named construction is an okay workaround in plenty of cases, but
it ultimately still requires that the type in question is
move-constructible. We know that's true for a vector, but I'd personally
just rather see true named constructors. For instance:

std::vector<int>::reserved myvec(args, go, here);

would work similar to your above example. I don't know how good of an idea
that specific syntax would be, especially if you were to replace
std::vector<int> with a dependent type, but this is at least the general
idea.

Really I just want to stop having to work around the lack of actual named
constructors entirely, whether it be via tag types or static member
functions, since each of those solutions will always be limited in some way.

--

---
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/.

--047d7bd6b7fec4431005129971d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 30, 2015 at 8:18 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv class=3D"HOEnZb"><div class=3D"h5">On 2015-03-27 18:38, Matt Calabrese w=
rote:<br>
&gt; On Friday, March 27, 2015 at 8:49:38 AM UTC-7, David Krauss wrote:<br>
&gt;&gt; Another alternative is named arguments, or their close cousins, de=
signated<br>
&gt;&gt; initializers.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Or we could always end tagging and other tricks entirely by directly<b=
r>
&gt; proposing some form of named constructors. This has proven to be a com=
mon<br>
&gt; enough issue that it warrants consideration.<br>
<br>
</div></div>Like this?<br>
<br>
=C2=A0 auto myvec =3D std::vector&lt;int&gt;::reserved(capacity);<br></bloc=
kquote><div><br></div><div>Something like that, yeah! I&#39;d be very happy=
 if we moved away from tags like &quot;piecewise_construct&quot; and &quot;=
allocator_arg&quot; entirely and instead just had a way to choose the const=
ructor by name. Using tags is also really tough to do correctly when you ha=
ve multiple overloads that are templates.</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">With move semantics, I&#39;m not aware that there is any =
notable cost to<br>
implementing such ctors as static methods on the class (which is the<br>
usual, existing paradigm). It would just be a matter of proposing the<br>
addition of such.</blockquote><div><br></div><div>Oh, we&#39;re apparently =
talking about slightly different things. I meant an actual language-level f=
acility of named constructors. In other words, &quot;reserved&quot; wouldn&=
#39;t be a static member function in the current sense, but rather it would=
 be a constructor with a name. Static member functions in place of named co=
nstruction is an okay workaround in plenty of cases, but it ultimately stil=
l requires that the type in question is move-constructible. We know that&#3=
9;s true for a vector, but I&#39;d personally just rather see true named co=
nstructors. For instance:</div><div><br></div><div>std::vector&lt;int&gt;::=
reserved myvec(args, go, here);</div><div><br></div><div>would work similar=
 to your above example. I don&#39;t know how good of an idea that specific =
syntax would be, especially if you were to replace std::vector&lt;int&gt; w=
ith a dependent type, but this is at least the general idea.</div><div><br>=
</div><div>Really I just want to stop having to work around the lack of act=
ual named constructors entirely, whether it be via tag types or static memb=
er functions, since each of those solutions will always be limited in some =
way.</div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd6b7fec4431005129971d7--

.

--001a11c2ff8a410ab90512997981
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 31, 2015 at 11:05 AM, Matt Calabrese <calabrese@google.com>
wrote:

> std::vector<int>::reserved myvec(args, go, here);
>

std::vector<int> myvec::reserved(args, go, here);

would probably be better actually.

--

---
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/.

--001a11c2ff8a410ab90512997981
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 31, 2015 at 11:05 AM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>std::vector&lt;int&gt=
;::reserved myvec(args, go, here);</div></div></div></div></blockquote><div=
><br></div><div>std::vector&lt;int&gt; myvec::reserved(args, go, here);</di=
v><div><br></div><div>would probably be better actually.=C2=A0</div></div><=
/div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2ff8a410ab90512997981--

.

------=_Part_5896_101657290.1427837652081
Content-Type: multipart/alternative;
 boundary="----=_Part_5897_1304573665.1427837652081"

------=_Part_5897_1304573665.1427837652081
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 31, 2015 at 2:07:38 PM UTC-4, Matt Calabrese wrote:
>
> On Tue, Mar 31, 2015 at 11:05 AM, Matt Calabrese <cala...@google.com
> <javascript:>> wrote:
>
>> std::vector<int>::reserved myvec(args, go, here);
>>
>
> std::vector<int> myvec::reserved(args, go, here);
>
> would probably be better actually.
>

Wouldn't we need a way of declaring reserved as a constructor?  I see how
the *use* is disambiguated here but it seems you would need some way of
telling the compiler that foo is a ctor for class C.

template<typename T>
  class vector
  {
    //  contextual keyword?
    reserved(args_t, go_t, here_t) constructor; // No..

    //  Or perhaps the absence of a return type for a member function
indicates constructor rather than error...
    reserved(args_t, go_t, here_t); // Seems better.  Maybe everyone
already knew that ;-)
  }

Obviously constructor forwarding in both directions...
template<typename T>
  vector<T>::reserved(args_t, go_t, here_t)
  : vector<T>(args_t)
  {}

And finally, killing all those damned initialize() I sometimes still see...
template<typename T>
  vector<T>:: vector(size_t, const T&)
  : reserved(size_t)
  {}

--

---
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/.

------=_Part_5897_1304573665.1427837652081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, March 31, 2015 at 2:07:38 PM UTC-4, Ma=
tt Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 11:05 AM, Mat=
t Calabrese <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"W60Q6R1rXSkJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">cala...@google.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>std::ve=
ctor&lt;int&gt;::reserved myvec(args, go, here);</div></div></div></div></b=
lockquote><div><br></div><div>std::vector&lt;int&gt; myvec::reserved(args, =
go, here);</div><div><br></div><div>would probably be better actually.&nbsp=
;</div></div></div></div></blockquote><div><br>Wouldn't we need a way of de=
claring reserved as a constructor?&nbsp; I see how the *use* is disambiguat=
ed here but it seems you would need some way of telling the compiler that f=
oo is a ctor for class C.<br><br>template&lt;typename T&gt;<br>&nbsp; class=
 vector<br>&nbsp; {<br>&nbsp;&nbsp;&nbsp; //&nbsp; contextual keyword?<br>&=
nbsp;&nbsp;&nbsp; reserved(args_t, go_t, here_t) constructor; // No..<br><b=
r>&nbsp;&nbsp;&nbsp; //&nbsp; Or perhaps the absence of a return type for a=
 member function indicates constructor rather than error...<br>&nbsp;&nbsp;=
&nbsp; reserved(args_t, go_t, here_t); // Seems better.&nbsp; Maybe everyon=
e already knew that ;-)<br>&nbsp; }<br><br>Obviously constructor forwarding=
 in both directions...<br>template&lt;typename T&gt;<br>&nbsp; vector&lt;T&=
gt;::reserved(args_t, go_t, here_t)<br>&nbsp; : vector&lt;T&gt;(args_t)<br>=
&nbsp; {}<br><br>And finally, killing all those damned initialize() I somet=
imes still see...<br>template&lt;typename T&gt;<br>&nbsp; vector&lt;T&gt;::=
 vector(size_t, const T&amp;)<br>&nbsp; : reserved(size_t)<br>&nbsp; {}<br>=
<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5897_1304573665.1427837652081--
------=_Part_5896_101657290.1427837652081--

.

--089e0153868826097f05129c7d7c
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 31, 2015 at 2:34 PM, <3dw4rd@verizon.net> wrote:

>
>
> On Tuesday, March 31, 2015 at 2:07:38 PM UTC-4, Matt Calabrese wrote:
>>
>> On Tue, Mar 31, 2015 at 11:05 AM, Matt Calabrese <cala...@google.com>
>> wrote:
>>
>>> std::vector<int>::reserved myvec(args, go, here);
>>>
>>
>> std::vector<int> myvec::reserved(args, go, here);
>>
>> would probably be better actually.
>>
>
> Wouldn't we need a way of declaring reserved as a constructor?  I see how
> the *use* is disambiguated here but it seems you would need some way of
> telling the compiler that foo is a ctor for class C.
>

Yeah. I'm not really proposing anything, I'm just making sure that the
notion of true named constructors doesn't get missed.


> template<typename T>
>   class vector
>   {
>     //  contextual keyword?
>     reserved(args_t, go_t, here_t) constructor; // No..
>
>     //  Or perhaps the absence of a return type for a member function
> indicates constructor rather than error...
>     reserved(args_t, go_t, here_t); // Seems better.  Maybe everyone
> already knew that ;-)
>   }
>

The only thing I don't like about the second one is that it's easy to
forget to write the return type of a void function and it wouldn't be too
great if the code simply compiled. Maybe that's an unnecessary concern,
though. Anyway, compiler people are probably better to figure out the
syntax, since they have a better understanding of what would be the
simplest (and unambiguous) way to specify it. I'm just putting forward that
we should probably investigate named constructors before creating more
tricks to emulate this functionality.

--

---
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/.

--089e0153868826097f05129c7d7c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 31, 2015 at 2:34 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:3dw4r=
d@verizon.net" target=3D"_blank">3dw4rd@verizon.net</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Tuesday, March=
 31, 2015 at 2:07:38 PM UTC-4, Matt Calabrese wrote:<span class=3D""><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote">On Tue, Mar 31, 2015 at 11:05 AM, Matt Calabrese <span dir=3D"ltr">=
&lt;<a rel=3D"nofollow">cala...@google.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><d=
iv>std::vector&lt;int&gt;::reserved myvec(args, go, here);</div></div></div=
></div></blockquote><div><br></div><div>std::vector&lt;int&gt; myvec::reser=
ved(args, go, here);</div><div><br></div><div>would probably be better actu=
ally.=C2=A0</div></div></div></div></blockquote></span><div><br>Wouldn&#39;=
t we need a way of declaring reserved as a constructor?=C2=A0 I see how the=
 *use* is disambiguated here but it seems you would need some way of tellin=
g the compiler that foo is a ctor for class C.<br></div></div></blockquote>=
<div><br></div><div>Yeah. I&#39;m not really proposing anything, I&#39;m ju=
st making sure that the notion of true named constructors doesn&#39;t get m=
issed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>template&lt;typename T&gt;<br>=C2=A0 class vector<br>=C2=A0 {<br>=C2=
=A0=C2=A0=C2=A0 //=C2=A0 contextual keyword?<br>=C2=A0=C2=A0=C2=A0 reserved=
(args_t, go_t, here_t) constructor; // No..<br><br>=C2=A0=C2=A0=C2=A0 //=C2=
=A0 Or perhaps the absence of a return type for a member function indicates=
 constructor rather than error...<br>=C2=A0=C2=A0=C2=A0 reserved(args_t, go=
_t, here_t); // Seems better.=C2=A0 Maybe everyone already knew that ;-)<br=
>=C2=A0 }<br></div></div></blockquote><div><br></div><div>The only thing I =
don&#39;t like about the second one is that it&#39;s easy to forget to writ=
e the return type of a void function and it wouldn&#39;t be too great if th=
e code simply compiled. Maybe that&#39;s an unnecessary concern, though. An=
yway, compiler people are probably better to figure out the syntax, since t=
hey have a better understanding of what would be the simplest (and unambigu=
ous) way to specify it. I&#39;m just putting forward that we should probabl=
y investigate named constructors before creating more tricks to emulate thi=
s functionality.</div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0153868826097f05129c7d7c--

.

On 2015-03-31 17:43, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals wrote:
> On Tue, Mar 31, 2015 at 2:34 PM, <3dw4rd@verizon.net> wrote:
>> template<typename T>
>>   class vector
>>   {
>>     //  contextual keyword?
>>     reserved(args_t, go_t, here_t) constructor; // No..
>>
>>     //  Or perhaps the absence of a return type for a member function
>> indicates constructor rather than error...
>>     reserved(args_t, go_t, here_t); // Seems better.  Maybe everyone
>> already knew that ;-)
>>   }
>
> The only thing I don't like about the second one is that it's easy to
> forget to write the return type of a void function and it wouldn't be too
> great if the code simply compiled.

There's an easy solution to that; introduce the 'implicit' keyword
already :-), and require a "named" ctor to be declared either implicit
or explicit. (And pleeeeease deprecate default-implicit ctors while
we're at it.)

--
Matthew

--

---
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/.

.

--Apple-Mail=_D1FADA9E-D7F2-43F7-97E2-64999CDB08F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9301, at 12:13 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> On Tuesday 31 March 2015 19:00:27 David Krauss wrote:
>> Another spelling would be reserved< std::vector< int > >( capacity ). A =
free
>> function would avoid boilerplate in user-defined containers that want to
>> maintain parity with the standard ones. But, this is a bit awkward and
>> unusual style.
>=20
> A free function may require friend rights to each container and most like=
ly a=20
> partial specialisation for each container template.

It would be generically implemented as:

template< typename container >
container reserved( typename container::size_type capacity ) {
    container ret;
    ret.reserve( capacity );
    return ret;
}

template< typename container >
container reserved( typename container::size_type capacity,
                    typename container::allocator_type const & allocator ) =
{
    container ret( allocator );
    ret.reserve( capacity );
    return ret;
}

I don=E2=80=99t see why a user wouldn=E2=80=99t be able to hook into this b=
y implementing reserve(). It wouldn=E2=80=99t need to be specialized nor fo=
und by ADL. The second overload is ignored if the container isn=E2=80=99t a=
llocator-aware.

Alternative constructor parameters would demand a custom overload, but that=
 would never be generically compatible with the standard ones, so it might =
as well go into the user=E2=80=99s namespace if it=E2=80=99s implemented at=
 all. Sugary shortcuts like this don=E2=80=99t need to cover every corner c=
ase.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_D1FADA9E-D7F2-43F7-97E2-64999CDB08F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9301, at 12:13 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">On Tuesday 31 March 2015 19:00:27=
 David Krauss wrote:<br class=3D""><blockquote type=3D"cite" class=3D"">Ano=
ther spelling would be reserved&lt; std::vector&lt; int &gt; &gt;( capacity=
 ). A free<br class=3D"">function would avoid boilerplate in user-defined c=
ontainers that want to<br class=3D"">maintain parity with the standard ones=
.. But, this is a bit awkward and<br class=3D"">unusual style.<br class=3D""=
></blockquote><br class=3D"">A free function may require friend rights to e=
ach container and most likely a <br class=3D"">partial specialisation for e=
ach container template.<br class=3D""></div></blockquote><div><br class=3D"=
"></div><div>It would be generically implemented as:</div><div><br class=3D=
""></div><div><font face=3D"Courier" class=3D"">template&lt; typename conta=
iner &gt;</font></div><div><font face=3D"Courier" class=3D"">container rese=
rved( typename container::size_type capacity ) {</font></div><div><font fac=
e=3D"Courier" class=3D"">&nbsp; &nbsp; container ret;</font></div><div><fon=
t face=3D"Courier" class=3D"">&nbsp; &nbsp; ret.reserve( capacity );</font>=
</div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; return ret;</fon=
t></div><div><font face=3D"Courier" class=3D"">}</font></div><div><br class=
=3D""></div><div><span style=3D"font-family: Courier;" class=3D"">template&=
lt; typename container &gt;</span></div><div><div><font face=3D"Courier" cl=
ass=3D"">container reserved( typename container::size_type capacity,</font>=
</div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; typename container::allocator_type =
const &amp; allocator ) {</font></div><div><font face=3D"Courier" class=3D"=
">&nbsp; &nbsp; container ret( allocator );</font></div><div><font face=3D"=
Courier" class=3D"">&nbsp; &nbsp; ret.reserve( capacity );</font></div><div=
><font face=3D"Courier" class=3D"">&nbsp; &nbsp; return ret;</font></div><d=
iv><font face=3D"Courier" class=3D"">}</font></div><div class=3D""><font fa=
ce=3D"Courier" class=3D""><br class=3D""></font></div></div><div>I don=E2=
=80=99t see why a user wouldn=E2=80=99t be able to hook into this by implem=
enting <font face=3D"Courier" class=3D"">reserve()</font>. It wouldn=E2=80=
=99t need to be specialized nor found by ADL. The second overload is ignore=
d if the container isn=E2=80=99t allocator-aware.</div><div><br class=3D"">=
</div><div>Alternative constructor parameters would demand a custom overloa=
d, but that would never be generically compatible with the standard ones, s=
o it might as well go into the user=E2=80=99s namespace if it=E2=80=99s imp=
lemented at all. Sugary shortcuts like this don=E2=80=99t need to cover eve=
ry corner case.</div></div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_D1FADA9E-D7F2-43F7-97E2-64999CDB08F2--

.

--Apple-Mail=_8F9634B4-AE5D-493A-8D67-801D4BBCF188
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

I have one wish for container constructors:=20

 vector(size_t size, const T2 &t); // T is constructible from T2

For a struct that contains POD data, this would allow me to make the vector=
=20
initialization shrink to a mere allocate function, even when the standard
constructor does something well behaved.

In a multithreaded setting, consider Amdahl=E2=80=99s law: having the vecto=
r
initialization run in the main thread and go through every single element=
=20
and setting it to some default value using a standard or copy constructor=
=20
weakens the multithreading potential.

My idea is to create a constructor that does nothing, using a global marker=
:

struct minimal_construct{};

class Point3d
{
public:
            Point3d(double x_=3D0, double y_=3D0, double z_=3D0) : x(x_), y=
(y_), z(z_)      {}
            Point3d(const minimal_construct &)                {}
....

and then use it to initialize the vector:

    vector<Point3d>   pts(100000, minimal_construct());

This code runs today, but creates a single unitialized point which is=20
then copied to every single element in the vector. That=E2=80=99s not what =
I want.

Thanks for reading!
Henrik

> 4 mar 2015 kl. 11:40 skrev Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>=20
> Hi Everyone,
> I can see that the Committee considers providing a second incarnation of =
the STL, in order to facilitate Concepts Lite and the new range interface i=
n a backwards-incompatible manner.
>=20
> If this path is ever chosen, I see it as an opportunity to fix other thin=
gs in the STL also. Below I present one thing that I personally consider a =
flaw. I would like to hear your opinion.
>=20
> I mean this constructor of std::vector and its kin that takes one argumen=
t of type size_type:
>=20
> explicit vector(size_type n, const Allocator& =3D Allocator());
>=20
> It is the source of two confusions:
>=20
> Problem 1:
> vector<int> v(2);
> vector<int> w{2};=20
>=20
> The above two declarations trigger different constructors and render a di=
fferent value. This is an unnecessary point of confusion and a source of pr=
oblems. For a more detailed discussion see here <https://akrzemi1.wordpress=
..com/2013/06/05/intuitive-interface-part-i/>.
>=20
> Problem 2:
> In declaration:
> vector<T> v(100);
> People happen to mistakenly think that that this reserves the capacity of=
 100 rather than setting the size. This confusion is enforced by the fact t=
hat similar libraries in other languages mean capacity in this case, e.g., =
java.util.ArrayList<E> <http://docs.oracle.com/javase/6/docs/api/java/util/=
ArrayList.html>. Also, in my personal experience, initial capacity is somet=
hing that I require more often that initial size.
>=20
> What I propose is to remove the said constructor (and similar one taking =
default T), add replace them with constructors taking tags that enforce the=
 user to explicitly state their intent:
>=20
> constexpr class with_size_t{} with_size{};
> constexpr class with_capacity_t{} with_capacity{};
>=20
> explicit vector(with_size_t, size_type n, const Allocator& =3D Allocator(=
));
> explicit vector(with_size_t, size_type n, const T& value, const Allocator=
& =3D Allocator());
> explicit vector(with_capacity_t, size_type c, const Allocator& =3D Alloca=
tor());
> explicit vector(with_capacity_t, size_type c, with_size_t, size_type n, c=
onst Allocator& =3D Allocator());
> explicit vector(with_capacity_t, size_type c, with_size_t, size_type n, c=
onst T& value, const Allocator& =3D Allocator());
>=20
> This is a lot of overloads, but what it gives instead is zero ambiguity.
> What do you think?
>=20
> Regards,
> &rzej
>=20
> --=20
>=20
> ---=20
> 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 <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_8F9634B4-AE5D-493A-8D67-801D4BBCF188
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">I =
have one wish for container constructors:&nbsp;</div><div class=3D""><br cl=
ass=3D""></div><div class=3D""><span class=3D"Apple-tab-span" style=3D"whit=
e-space:pre"> </span>vector(size_t size, const T2 &amp;t);<span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre"> </span>// T is constructible from =
T2</div><div class=3D""><br class=3D""></div><div class=3D"">For a struct t=
hat contains POD data, this would allow me to make the vector&nbsp;</div><d=
iv class=3D"">initialization shrink to a mere allocate function, even when =
the standard</div><div class=3D"">constructor does something well behaved.<=
/div><div class=3D""><br class=3D""></div><div class=3D"">In a multithreade=
d setting, consider Amdahl=E2=80=99s law: having the vector</div><div class=
=3D"">initialization run in the main thread and go through every single ele=
ment&nbsp;</div><div class=3D"">and setting it to some default value using =
a standard or copy constructor&nbsp;</div><div class=3D"">weakens the multi=
threading potential.</div><div class=3D""><br class=3D""></div><div class=
=3D""><div class=3D""><font face=3D"arial, sans-serif" class=3D"">My idea i=
s to create a constructor that does nothing, using a global marker:</font><=
/div><div class=3D""><font face=3D"arial, sans-serif" class=3D""><br class=
=3D""></font></div><div class=3D""><font size=3D"2" face=3D"arial, sans-ser=
if" class=3D""><span style=3D"color: blue;" class=3D"">struct</span>&nbsp;m=
inimal_construct{};<br class=3D""></font></div><div class=3D""><font size=
=3D"2" face=3D"arial, sans-serif" class=3D""><br class=3D""></font></div><d=
iv class=3D""><div style=3D"margin: 0cm 0cm 0.0001pt;" class=3D""><font siz=
e=3D"2" face=3D"arial, sans-serif" class=3D""><span lang=3D"EN-US" style=3D=
"color: blue;" class=3D"">class</span><span lang=3D"EN-US" class=3D"">&nbsp=
;Point3d<o:p class=3D""></o:p></span></font></div><div style=3D"margin: 0cm=
 0cm 0.0001pt;" class=3D""><span lang=3D"EN-US" class=3D""><font size=3D"2"=
 face=3D"arial, sans-serif" class=3D"">{<o:p class=3D""></o:p></font></span=
></div><div style=3D"margin: 0cm 0cm 0.0001pt;" class=3D""><font size=3D"2"=
 face=3D"arial, sans-serif" class=3D""><span lang=3D"EN-US" style=3D"color:=
 blue;" class=3D"">public</span><span lang=3D"EN-US" class=3D"">:<o:p class=
=3D""></o:p></span></font></div><div style=3D"margin: 0cm 0cm 0.0001pt;" cl=
ass=3D""><span lang=3D"EN-US" class=3D""><font size=3D"2" face=3D"arial, sa=
ns-serif" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Point3d(<spa=
n style=3D"color: blue;" class=3D"">double</span>&nbsp;x_=3D0,&nbsp;<span s=
tyle=3D"color: blue;" class=3D"">double</span>&nbsp;y_=3D0,&nbsp;<span styl=
e=3D"color: blue;" class=3D"">double</span>&nbsp;z_=3D0) : x(x_), y(y_), z(=
z_)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}<o:p class=3D""></o:p></font></span></d=
iv><div style=3D"margin: 0cm 0cm 0.0001pt;" class=3D""><span lang=3D"EN-US"=
 class=3D""><font size=3D"2" face=3D"arial, sans-serif" class=3D"">&nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Point3d(<span style=3D"color: blue;" clas=
s=3D"">const</span>&nbsp;minimal_construct &amp;)&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}<o:p cla=
ss=3D""></o:p></font></span></div><div style=3D"margin: 0cm 0cm 0.0001pt;" =
class=3D""><font size=3D"2" face=3D"arial, sans-serif" class=3D"">...</font=
></div><div style=3D"margin: 0cm 0cm 0.0001pt;" class=3D""><span lang=3D"EN=
-US" class=3D""><font size=3D"2" face=3D"arial, sans-serif" class=3D""><br =
class=3D""></font></span></div><p class=3D"MsoNormal" style=3D"margin: 0cm =
0cm 0.0001pt;"><font face=3D"arial, sans-serif" class=3D""><span lang=3D"EN=
-US" class=3D""></span></font></p><div class=3D""><font face=3D"arial, sans=
-serif" class=3D"">and then use it to initialize the vector:</font></div><d=
iv class=3D""><font face=3D"arial, sans-serif" class=3D""><br class=3D""></=
font></div><div class=3D""><font face=3D"arial, sans-serif" class=3D"">&nbs=
p; &nbsp; vector&lt;Point3d&gt; &nbsp; pts(100000,&nbsp;<span style=3D"font=
-size: small;" class=3D"">minimal_construct())</span><span style=3D"font-si=
ze: small;" class=3D"">;</span></font></div></div></div><div class=3D""><fo=
nt face=3D"arial, sans-serif" class=3D""><span style=3D"font-size: small;" =
class=3D""><br class=3D""></span></font></div><div class=3D""><font face=3D=
"arial, sans-serif" class=3D""><span style=3D"font-size: small;" class=3D""=
>This code runs today, but creates a single unitialized point which is&nbsp=
;</span></font></div><div class=3D""><font face=3D"arial, sans-serif" class=
=3D""><font size=3D"2" class=3D"">then copied to every single element in th=
e vector. That=E2=80=99s not what I want.</font></font></div><div class=3D"=
"><font face=3D"arial, sans-serif" class=3D""><font size=3D"2" class=3D""><=
br class=3D""></font></font></div><div class=3D""><font face=3D"arial, sans=
-serif" class=3D""><font size=3D"2" class=3D"">Thanks for reading!</font></=
font></div><div class=3D""><font face=3D"arial, sans-serif" class=3D""><fon=
t size=3D"2" class=3D"">Henrik</font></font></div><div class=3D""><br class=
=3D""></div><div><blockquote type=3D"cite" class=3D""><div class=3D"">4 mar=
 2015 kl. 11:40 skrev Andrzej Krzemie=C5=84ski &lt;<a href=3D"mailto:akrzem=
i1@gmail.com" class=3D"">akrzemi1@gmail.com</a>&gt;:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Hi Every=
one,<br class=3D"">I can see that the Committee considers providing a secon=
d incarnation of the STL, in order to facilitate Concepts Lite and the new =
range interface in a backwards-incompatible manner.<br class=3D""><br class=
=3D"">If this path is ever chosen, I see it as an opportunity to fix other =
things in the STL also. Below I present one thing that I personally conside=
r a flaw. I would like to hear your opinion.<br class=3D""><br class=3D"">I=
 mean this constructor of std::vector and its kin that takes one argument o=
f type size_type:<br class=3D""><br class=3D"">explicit vector(size_type n,=
 const Allocator&amp; =3D Allocator());<br class=3D""><br class=3D"">It is =
the source of two confusions:<br class=3D""><br class=3D""><b class=3D"">Pr=
oblem 1:</b><br class=3D"">vector&lt;int&gt; v(2);<br class=3D"">vector&lt;=
int&gt; w{2}; <br class=3D""><br class=3D"">The above two declarations trig=
ger different constructors and render a different value. This is an unneces=
sary point of confusion and a source of problems. For a more detailed discu=
ssion <a href=3D"https://akrzemi1.wordpress.com/2013/06/05/intuitive-interf=
ace-part-i/" class=3D"">see here</a>.<br class=3D""><br class=3D""><b class=
=3D"">Problem 2:</b><br class=3D"">In declaration:<br class=3D"">vector&lt;=
T&gt; v(100);<br class=3D"">People happen to mistakenly think that that thi=
s reserves the capacity of 100 rather than setting the size. This confusion=
 is enforced by the fact that similar libraries in other languages mean cap=
acity in this case, e.g., <a href=3D"http://docs.oracle.com/javase/6/docs/a=
pi/java/util/ArrayList.html" class=3D"">java.util.ArrayList&lt;E&gt;</a>. A=
lso, in my personal experience, initial capacity is something that I requir=
e more often that initial size.<br class=3D""><br class=3D"">What I propose=
 is to remove the said constructor (and similar one taking default T), add =
replace them with constructors taking tags that enforce the user to explici=
tly state their intent:<br class=3D""><br class=3D"">constexpr class with_s=
ize_t{} with_size{};<br class=3D"">constexpr class with_capacity_t{} with_c=
apacity{};<br class=3D""><br class=3D"">explicit vector(<b class=3D"">with_=
size_t</b>, size_type n, const Allocator&amp; =3D Allocator());<br class=3D=
"">explicit vector(<b class=3D"">with_size_t</b>, size_type n, const T&amp;=
 value, const Allocator&amp; =3D Allocator());<br class=3D"">explicit vecto=
r(<b class=3D"">with_capacity_t</b>, size_type c, const Allocator&amp; =3D =
Allocator());<br class=3D"">explicit vector(<b class=3D""><b class=3D"">wit=
h_capacity_t</b>, </b>size_type c,<b class=3D""> with_size_t</b>, size_type=
 n, const Allocator&amp; =3D Allocator());<br class=3D"">explicit vector(<b=
 class=3D""><b class=3D"">with_capacity_t</b>, </b>size_type c,<b class=3D"=
"> with_size_t</b>, size_type n, const T&amp; value, const Allocator&amp; =
=3D Allocator());<br class=3D""><br class=3D"">This is a lot of overloads, =
but what it gives instead is zero ambiguity.<br class=3D"">What do you thin=
k?<br class=3D""><br class=3D"">Regards,<br class=3D"">&amp;rzej<br class=
=3D""></div><div class=3D""><br class=3D"webkit-block-placeholder"></div>

-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" class=3D"">http://groups.google.com/a/isocpp.org/group/std-=
proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_8F9634B4-AE5D-493A-8D67-801D4BBCF188--

.

------=_Part_279_2106208248.1430826237383
Content-Type: multipart/alternative;
 boundary="----=_Part_280_2069070635.1430826237383"

------=_Part_280_2069070635.1430826237383
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 24 kwietnia 2015 11:39:41 UTC+2 u=C5=BCytkownik HenrikV=
allgren=20
napisa=C5=82:
>
> I have one wish for container constructors:=20
>
> vector(size_t size, const T2 &t); // T is constructible from T2
>
> For a struct that contains POD data, this would allow me to make the=20
> vector=20
> initialization shrink to a mere allocate function, even when the standard
> constructor does something well behaved.
>
> In a multithreaded setting, consider Amdahl=E2=80=99s law: having the vec=
tor
> initialization run in the main thread and go through every single element=
=20
> and setting it to some default value using a standard or copy constructor=
=20
> weakens the multithreading potential.
>
> My idea is to create a constructor that does nothing, using a global=20
> marker:
>
> struct minimal_construct{};
>
> class Point3d
> {
> public:
>             Point3d(double x_=3D0, double y_=3D0, double z_=3D0) : x(x_),=
=20
> y(y_), z(z_)      {}
>             Point3d(const minimal_construct &)                {}
> ...
>
> and then use it to initialize the vector:
>
>     vector<Point3d>   pts(100000, minimal_construct());
>
> This code runs today, but creates a single unitialized point which is=20
> then copied to every single element in the vector. That=E2=80=99s not wha=
t I want.
>
> Thanks for reading!
> Henrik
>

I recently had a need for something similar. Perhaps we need a more general=
=20
version:

template <typename... Args>
explicit vector(with_size_t, size_type n, in_place_t, const Args&... args)

It initializes n elements by calling emplace_back(args...);=20

Perfect forwarding cannot be applied, because we read the same objects n=20
times.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_280_2069070635.1430826237383
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 24 kwietnia 2015 11:39:41 UTC+=
2 u=C5=BCytkownik HenrikVallgren napisa=C5=82:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div style=3D"word-wrap:break-word"><div>I have one wish fo=
r container constructors:&nbsp;</div><div><br></div><div><span style=3D"whi=
te-space:pre"> </span>vector(size_t size, const T2 &amp;t);<span style=3D"w=
hite-space:pre"> </span>// T is constructible from T2</div><div><br></div><=
div>For a struct that contains POD data, this would allow me to make the ve=
ctor&nbsp;</div><div>initialization shrink to a mere allocate function, eve=
n when the standard</div><div>constructor does something well behaved.</div=
><div><br></div><div>In a multithreaded setting, consider Amdahl=E2=80=99s =
law: having the vector</div><div>initialization run in the main thread and =
go through every single element&nbsp;</div><div>and setting it to some defa=
ult value using a standard or copy constructor&nbsp;</div><div>weakens the =
multithreading potential.</div><div><br></div><div><div><font face=3D"arial=
, sans-serif">My idea is to create a constructor that does nothing, using a=
 global marker:</font></div><div><font face=3D"arial, sans-serif"><br></fon=
t></div><div><font face=3D"arial, sans-serif" size=3D"2"><span style=3D"col=
or:blue">struct</span>&nbsp;minimal_construct{};<br></font></div><div><font=
 face=3D"arial, sans-serif" size=3D"2"><br></font></div><div><div style=3D"=
margin:0cm 0cm 0.0001pt"><font face=3D"arial, sans-serif" size=3D"2"><span =
style=3D"color:blue" lang=3D"EN-US">class</span><span lang=3D"EN-US">&nbsp;=
Point3d</span></font></div><div style=3D"margin:0cm 0cm 0.0001pt"><span lan=
g=3D"EN-US"><font face=3D"arial, sans-serif" size=3D"2">{</font></span></di=
v><div style=3D"margin:0cm 0cm 0.0001pt"><font face=3D"arial, sans-serif" s=
ize=3D"2"><span style=3D"color:blue" lang=3D"EN-US">public</span><span lang=
=3D"EN-US">:</span></font></div><div style=3D"margin:0cm 0cm 0.0001pt"><spa=
n lang=3D"EN-US"><font face=3D"arial, sans-serif" size=3D"2">&nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; Point3d(<span style=3D"color:blue">double</span=
>&nbsp;x_=3D0,&nbsp;<span style=3D"color:blue">double</span>&nbsp;y_<wbr>=
=3D0,&nbsp;<span style=3D"color:blue">double</span>&nbsp;z_=3D0) : x(x_), y=
(y_), z(z_)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}</font></span></div><div style=
=3D"margin:0cm 0cm 0.0001pt"><span lang=3D"EN-US"><font face=3D"arial, sans=
-serif" size=3D"2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Point3d(<span =
style=3D"color:blue">const</span>&nbsp;minimal_<wbr>construct &amp;)&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; {}</font></span></div><div style=3D"margin:0cm 0cm 0.0001pt"><font=
 face=3D"arial, sans-serif" size=3D"2">...</font></div><div style=3D"margin=
:0cm 0cm 0.0001pt"><span lang=3D"EN-US"><font face=3D"arial, sans-serif" si=
ze=3D"2"><br></font></span></div><p class=3D"MsoNormal" style=3D"margin:0cm=
 0cm 0.0001pt"><font face=3D"arial, sans-serif"><span lang=3D"EN-US"></span=
></font></p><div><font face=3D"arial, sans-serif">and then use it to initia=
lize the vector:</font></div><div><font face=3D"arial, sans-serif"><br></fo=
nt></div><div><font face=3D"arial, sans-serif">&nbsp; &nbsp; vector&lt;Poin=
t3d&gt; &nbsp; pts(100000,&nbsp;<span style=3D"font-size:small">minimal_con=
struct(<wbr>))</span><span style=3D"font-size:small">;</span></font></div><=
/div></div><div><font face=3D"arial, sans-serif"><span style=3D"font-size:s=
mall"><br></span></font></div><div><font face=3D"arial, sans-serif"><span s=
tyle=3D"font-size:small">This code runs today, but creates a single unitial=
ized point which is&nbsp;</span></font></div><div><font face=3D"arial, sans=
-serif"><font size=3D"2">then copied to every single element in the vector.=
 That=E2=80=99s not what I want.</font></font></div><div><font face=3D"aria=
l, sans-serif"><font size=3D"2"><br></font></font></div><div><font face=3D"=
arial, sans-serif"><font size=3D"2">Thanks for reading!</font></font></div>=
<div><font face=3D"arial, sans-serif"><font size=3D"2">Henrik</font></font>=
</div></div></blockquote><div><br>I recently had a need for something simil=
ar. Perhaps we need a more general version:<br><br>template &lt;typename...=
 Args&gt;<br>explicit vector(with_size_t, size_type n, in_place_t, const Ar=
gs&amp;... args)<br><br>It initializes n elements by calling emplace_back(a=
rgs...); <br><br>Perfect forwarding cannot be applied, because we read the =
same objects n times.<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_280_2069070635.1430826237383--
------=_Part_279_2106208248.1430826237383--

.

--001a113507f08920d10515578a79
Content-Type: text/plain; charset=UTF-8

the only kind of OO Pascal used to be named ones declared via the
'constructor' keyword, but pascal is long dead by now.

2015-04-01 2:30 GMT+04:30 Matthew Woehlke <mw_triad@users.sourceforge.net>:

> On 2015-03-31 17:43, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals wrote:
> > On Tue, Mar 31, 2015 at 2:34 PM, <3dw4rd@verizon.net> wrote:
> >> template<typename T>
> >>   class vector
> >>   {
> >>     //  contextual keyword?
> >>     reserved(args_t, go_t, here_t) constructor; // No..
> >>
> >>     //  Or perhaps the absence of a return type for a member function
> >> indicates constructor rather than error...
> >>     reserved(args_t, go_t, here_t); // Seems better.  Maybe everyone
> >> already knew that ;-)
> >>   }
> >
> > The only thing I don't like about the second one is that it's easy to
> > forget to write the return type of a void function and it wouldn't be too
> > great if the code simply compiled.
>
> how about a none-return function with explicit 'this' argument:

class Foo{
....
    int mI;
public:
    ctor1(auto this,int i)//named ctor
        :mI{i}
    {};
};

Foo test_obj.ctor1{0};

class Bar: Foo{
....
public:
    Bar(): ctor1{1}
    {};
};

regards,
FM.

--
---------------------------------------------------------------------------------------------------------------
how am I supposed to end the twisted road of  your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!

--

---
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/.

--001a113507f08920d10515578a79
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"rtl"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 dir=3D"ltr">the only kind of OO Pascal used to be named ones declared via =
the &#39;constructor&#39; keyword, but pascal is long dead by now.</div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr">2015-04-01 2:30 GMT+04:30 Matthew =
Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mw_triad@users.sourceforge.=
net" target=3D"_blank">mw_triad@users.sourceforge.net</a>&gt;</span>:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div style=3D"text-align:left">On 2015-03-31 17:43, &#39;M=
att Calabrese&#39; via ISO C++ Standard - Future</div>
<span class=3D""><div style=3D"text-align:left">Proposals wrote:</div><div =
style=3D"text-align:left">&gt; On Tue, Mar 31, 2015 at 2:34 PM, &lt;<a href=
=3D"mailto:3dw4rd@verizon.net">3dw4rd@verizon.net</a>&gt; wrote:</div>
</span><span class=3D""><div style=3D"text-align:left">&gt;&gt; template&lt=
;typename T&gt;</div><div style=3D"text-align:left">&gt;&gt;=C2=A0 =C2=A0cl=
ass vector</div><div style=3D"text-align:left">&gt;&gt;=C2=A0 =C2=A0{</div>=
<div style=3D"text-align:left">&gt;&gt;=C2=A0 =C2=A0 =C2=A0//=C2=A0 context=
ual keyword?</div><div style=3D"text-align:left">&gt;&gt;=C2=A0 =C2=A0 =C2=
=A0reserved(args_t, go_t, here_t) constructor; // No..</div><div style=3D"t=
ext-align:left">&gt;&gt;</div><div style=3D"text-align:left">&gt;&gt;=C2=A0=
 =C2=A0 =C2=A0//=C2=A0 Or perhaps the absence of a return type for a member=
 function</div><div style=3D"text-align:left">&gt;&gt; indicates constructo=
r rather than error...</div><div style=3D"text-align:left">&gt;&gt;=C2=A0 =
=C2=A0 =C2=A0reserved(args_t, go_t, here_t); // Seems better.=C2=A0 Maybe e=
veryone</div><div style=3D"text-align:left">&gt;&gt; already knew that ;-)<=
/div><div style=3D"text-align:left">&gt;&gt;=C2=A0 =C2=A0}</div><div style=
=3D"text-align:left">&gt;</div><div style=3D"text-align:left">&gt; The only=
 thing I don&#39;t like about the second one is that it&#39;s easy to</div>=
<div style=3D"text-align:left">&gt; forget to write the return type of a vo=
id function and it wouldn&#39;t be too</div><div style=3D"text-align:left">=
&gt; great if the code simply compiled.</div></span><div class=3D""><div cl=
ass=3D"h5">
<div style=3D"text-align:left"><br></div></div></div></blockquote></div><di=
v style=3D"text-align:left"><div dir=3D"ltr">how about a none-return functi=
on with explicit &#39;this&#39; argument:</div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr">class Foo{</div><div dir=3D"ltr">...</div><div dir=3D"ltr">=
=C2=A0 =C2=A0 int mI;</div><div dir=3D"ltr">public:</div><div dir=3D"ltr">=
=C2=A0 =C2=A0 ctor1(auto this,int i)//named ctor</div><div dir=3D"ltr">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 :mI{i}</div><div dir=3D"ltr">=C2=A0 =C2=A0 {};</di=
v><div dir=3D"ltr">};</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Foo =
test_obj.ctor1{0};</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">class B=
ar: Foo{</div><div dir=3D"ltr">...</div><div dir=3D"ltr">public:</div><div =
dir=3D"ltr">=C2=A0 =C2=A0 Bar(): ctor1{1}</div><div dir=3D"ltr">=C2=A0 =C2=
=A0 {};</div><div dir=3D"ltr">};</div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr">regards,</div><div dir=3D"ltr">FM.</div></div><div><br></div>-- <b=
r><div class=3D"gmail_signature"><div dir=3D"ltr">-------------------------=
---------------------------------------------------------------------------=
-----------</div><div dir=3D"ltr">how am I supposed to end the twisted road=
 of=C2=A0 your hair in the dark night??<br>unless the candle of your face d=
oes turn a lamp up on my way!!!<br></div></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113507f08920d10515578a79--

.