Topic: std::vector (and other containers) to have a


Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 11 Nov 2015 10:01:55 +0100
Raw View
2015-11-11 9:52 GMT+01:00  <leni536@gmail.com>:
> Hi,
>
> I didn't find a topic like this, so here it is. Something like this would be
> nice:
>
> template <class... Args>
> vector(size_type n,Args&&... args);
>
> It would perfect forward args to value_type's constructor. Since vector uses
> its allocator to construct, and in C++11 std::allocator already has a
> perfect forwarding "construct" member function, it could use that. The only
> problem I see that it would hijack other constructors so maybe it would need
> tag dispatching to work.
>
> vector(size_type n,vector::perfect_forward_type,Args&&... args);
>
> I see that this is a bit uglier, but at least it would work.

I consider the combination of "perfect forwarding" and the additional
size information as a potential dangerous combination. If a
constructor with size information would get any rvalues via args, the
first vector element construction might move the arguments into the
target and the second, third, etc. vector element constructed from the
same argument pack would try to become constructed from already moved
arguments. For exactly this reason any existing container member
function that provides a size information and a "prototype" value
expects that value as const value_type& and not as a potentially
movable argument.

- Daniel

--

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

.


Author: leni536@gmail.com
Date: Wed, 11 Nov 2015 01:20:01 -0800 (PST)
Raw View
------=_Part_761_1031011390.1447233601836
Content-Type: multipart/alternative;
 boundary="----=_Part_762_1085229922.1447233601837"

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


On Wednesday, November 11, 2015 at 10:01:56 AM UTC+1, Daniel Kr=C3=BCgler w=
rote:
>
> I consider the combination of "perfect forwarding" and the additional=20
> size information as a potential dangerous combination. If a=20
> constructor with size information would get any rvalues via args, the=20
> first vector element construction might move the arguments into the=20
> target and the second, third, etc. vector element constructed from the=20
> same argument pack would try to become constructed from already moved=20
> arguments. For exactly this reason any existing container member=20
> function that provides a size information and a "prototype" value=20
> expects that value as const value_type& and not as a potentially=20
> movable argument.=20
>
> - Daniel=20
>

Yeah, that was truly a mistake by me, perfect forwarding really doesn't=20
make sense in this context. Shouldn't this work though?

vector(size_type n,vector::forward_args_type,Args&... args);

=20
This way even if something in args is an rvalue reference its type would be=
=20
deduced to be an lvalue reference.

- L=C3=A9n=C3=A1rd

--=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_762_1085229922.1447233601837
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, November 11, 2015 at 10:01:56 AM UTC+1, =
Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I co=
nsider the combination of &quot;perfect forwarding&quot; and the additional
<br>size information as a potential dangerous combination. If a
<br>constructor with size information would get any rvalues via args, the
<br>first vector element construction might move the arguments into the
<br>target and the second, third, etc. vector element constructed from the
<br>same argument pack would try to become constructed from already moved
<br>arguments. For exactly this reason any existing container member
<br>function that provides a size information and a &quot;prototype&quot; v=
alue
<br>expects that value as const value_type&amp; and not as a potentially
<br>movable argument.
<br>
<br>- Daniel
<br></blockquote><div><br></div><div>Yeah, that was truly a mistake by me, =
perfect forwarding really doesn&#39;t make sense in this context. Shouldn&#=
39;t this work though?</div><div><br></div><div><span style=3D"font-family:=
 monospace; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);"><di=
v class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word=
-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">vector</span><span style=3D"color: rgb(102, 102, 0)=
;"><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">size_type n</spa=
n><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">vector</span><span style=3D"color: rgb(102, 102, 0)=
;"><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span></spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">forward_args_ty=
pe</span><span style=3D"color: rgb(102, 102, 0);"><wbr><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span></span><span style=3D"color: =
rgb(102, 0, 102);"><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Args</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&amp;...</span></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> args</span><span style=3D=
"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div><div><span style=3D"color: rgb(102, 102, 0);"><br=
></span></div></code></div></span>=C2=A0<span style=3D"font-family: monospa=
ce; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);"><br></span>=
</div><div>This way even if something in args is an rvalue reference its ty=
pe would be deduced to be an lvalue reference.</div><div><br></div><div>- L=
=C3=A9n=C3=A1rd</div><div><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_762_1085229922.1447233601837--
------=_Part_761_1031011390.1447233601836--

.


Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 11 Nov 2015 10:33:47 +0100
Raw View
2015-11-11 10:20 GMT+01:00  <leni536@gmail.com>:
> Yeah, that was truly a mistake by me, perfect forwarding really doesn't make
> sense in this context. Shouldn't this work though?
>
> vector(size_type n,vector::forward_args_type,Args&... args);
>
> This way even if something in args is an rvalue reference its type would be
> deduced to be an lvalue reference.

I would say the arguments should also be declared as references to
const, because you can also have the same effect for mutable lvalues.
And surely you would like to construct from a pack from literals
(which are rvalues in basically all cases), which would not be
possible with your revised form:

std::vector<Foo> v(100, 12.123); // Wouldn't work

- Daniel

--

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

.


Author: leni536@gmail.com
Date: Wed, 11 Nov 2015 02:53:15 -0800 (PST)
Raw View
------=_Part_3216_194931952.1447239196036
Content-Type: multipart/alternative;
 boundary="----=_Part_3217_812763143.1447239196036"

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

Ok, this is my last try :).

What if we use the first declaration:

vector(size_type n,vector::forward_args_type,Args&&... args);

But inside vector's constructor we convert every rvalue references in args=
=20
to const ref. Of course this behavior should be well documented and I maybe=
=20
this can be confusing.

About converting rvalue references one can define the following type:

template<typename T>
using forward_for_copy=3Dstd::conditional_t< std::is_rvalue_reference<T>{},
                                           const T&,
                                           T >;

Can be used this way:
template<class... Args>
int f(Args&&... args)
{
        h(static_cast<forward_for_copy<Args>>(args)...);
        return 0;
}

(Maybe "forward for copy" is not the best name though.) The main idea that=
=20
vector's constructor would forward args this way to std::allocator's=20
"construct" member function. The constructor would accept literals, but it=
=20
wouldn't move objects even if they are movable.

I'm getting a little bit lost here though, maybe this suggestion adds even=
=20
more problems than what it solves.

- L=C3=A9n=C3=A1rd

--=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_3217_812763143.1447239196036
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ok, this is my last try :).<div><br></div><div>What if we =
use the first declaration:</div><div><br></div><div><div class=3D"prettypri=
nt" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; b=
ackground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: rgb(0, 0, 0);"><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">vector</span></span><span style=3D=
"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span></span><span style=3D"color: rgb(0, 0, 0);"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">size_type n</span></span><sp=
an style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span></span><span style=3D"color: rgb(0, 0, 0);"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">vector</span></span=
><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">forward_args</span></span><span style=3D"color: rgb(0, 0, =
0);"><span style=3D"color: #000;" class=3D"styled-by-prettify">_type</span>=
</span><span style=3D"color: rgb(102, 102, 0);"><wbr><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span></span><span style=3D"color: rg=
b(102, 0, 102);"><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Args</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&amp;&amp;...</span></span><span =
style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> args</span></span><span style=3D"color: rgb(102, 102, 0);"><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div><br>But inside vector&#39;s constructor we convert every rvalue =
references in args to const ref. Of course this behavior should be well doc=
umented and I maybe this can be confusing.</div><div><br></div><div>About c=
onverting rvalue references one can define the following type:</div><div><b=
r></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187,=
 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"fon=
t-family: Arial, Helvetica, sans-serif;"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span></span></div></code><div class=3D"subprettyprint">using =
forward_for_copy=3Dstd::conditional_t&lt; std::is_rvalue_reference&lt;T&gt;=
{},</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const T&amp;,</div><div class=
=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0T &gt;;</div></div><br>Can be used this way:</div><=
div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187=
); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"font-family:=
 Arial, Helvetica, sans-serif;"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">class</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&amp;&amp;...</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> args</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span></span></div></code><div class=3D"subprettyprint">{</div=
><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 h(static_cast&lt=
;forward_for_copy&lt;Args&gt;&gt;(args)...);</div><div class=3D"subprettypr=
int">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;</div><div class=3D"subprettyprin=
t">}</div></div><br>(Maybe &quot;forward for copy&quot; is not the best nam=
e though.) The main idea that vector&#39;s constructor would forward args t=
his way to std::allocator&#39;s &quot;construct&quot; member function. The =
constructor would accept literals, but it wouldn&#39;t move objects even if=
 they are movable.</div><div><br></div><div>I&#39;m getting a little bit lo=
st here though, maybe this suggestion adds even more problems than what it =
solves.</div><div><br></div><div>- L=C3=A9n=C3=A1rd</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_3217_812763143.1447239196036--
------=_Part_3216_194931952.1447239196036--

.


Author: leni536@gmail.com
Date: Wed, 11 Nov 2015 03:52:37 -0800 (PST)
Raw View
------=_Part_280_1923550331.1447242757223
Content-Type: multipart/alternative;
 boundary="----=_Part_281_757264474.1447242757223"

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

Oh, also about mutable lvalues. I see no reason to not accept them=20
especially if value_type's constructor accepts them (like passing a random=
=20
engine, which is mutable).

On Wednesday, November 11, 2015 at 10:33:49 AM UTC+1, Daniel Kr=C3=BCgler w=
rote:
>
> 2015-11-11 10:20 GMT+01:00  <len...@gmail.com <javascript:>>:=20
> > Yeah, that was truly a mistake by me, perfect forwarding really doesn't=
=20
> make=20
> > sense in this context. Shouldn't this work though?=20
> >=20
> > vector(size_type n,vector::forward_args_type,Args&... args);=20
> >=20
> > This way even if something in args is an rvalue reference its type woul=
d=20
> be=20
> > deduced to be an lvalue reference.=20
>
> I would say the arguments should also be declared as references to=20
> const, because you can also have the same effect for mutable lvalues.=20
> And surely you would like to construct from a pack from literals=20
> (which are rvalues in basically all cases), which would not be=20
> possible with your revised form:=20
>
> std::vector<Foo> v(100, 12.123); // Wouldn't work=20
>
> - Daniel=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_281_757264474.1447242757223
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oh, also about mutable lvalues. I see no reason to not acc=
ept them especially if value_type&#39;s constructor accepts them (like pass=
ing a random engine, which is mutable).<br><br>On Wednesday, November 11, 2=
015 at 10:33:49 AM UTC+1, Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">2015-11-11 10:20 GMT+01:00 =C2=A0&lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nC95ruAgFwAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;javascript:&#39;;return true;">len...@gmail.com</a>&=
gt;:
<br>&gt; Yeah, that was truly a mistake by me, perfect forwarding really do=
esn&#39;t make
<br>&gt; sense in this context. Shouldn&#39;t this work though?
<br>&gt;
<br>&gt; vector(size_type n,vector::forward_args_type,<wbr>Args&amp;... arg=
s);
<br>&gt;
<br>&gt; This way even if something in args is an rvalue reference its type=
 would be
<br>&gt; deduced to be an lvalue reference.
<br>
<br>I would say the arguments should also be declared as references to
<br>const, because you can also have the same effect for mutable lvalues.
<br>And surely you would like to construct from a pack from literals
<br>(which are rvalues in basically all cases), which would not be
<br>possible with your revised form:
<br>
<br>std::vector&lt;Foo&gt; v(100, 12.123); // Wouldn&#39;t work
<br>
<br>- Daniel
<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_281_757264474.1447242757223--
------=_Part_280_1923550331.1447242757223--

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 11 Nov 2015 09:34:28 -0500
Raw View
On 2015-11-11 03:52, leni536@gmail.com wrote:
> I didn't find a topic like this, so here it is. Something like this would
> be nice:
>
> template <class... Args>
> vector(size_type n,Args&&... args);
>
> 1) It could be faster than vector(n,value_type(args)) if value_type's copy
> constructor is more expensive than its constructor with "args" parameters
> (I don't know a good example though).

Interesting idea. And since vector(n, value_type(...)) invokes
value_type's copy ctor, it is in fact a subset of the proposed syntax,
i.e. that form could be deprecated / removed in favor of the proposed
"emplace" version.

> 2) If value_type's different constructors are not deterministic then maybe
> it's desirable to call the constructor multiple times instead of copying
> one constructed element. One example if value_type has a constructor taking
> a random generator as an argument.

Hmm... for this case, you are thinking that one of the arguments is e.g.
a functor? And that the value_type copy ctor copies existing data, while
the ctor taking the functor uses the functor (which isn't stored) to
generate a value? Interesting notion...

> Workarounds:
> 2) Construct an empty vector, use reserve then emplace_back newly
> constructed elements one by one using value_type's constructor of choice.
> I'm not sure if this would be equally efficient.

Seems like it should be at least comparably efficient; I can't think
offhand what vector's sized constructor would do differently that would
make it more efficient. (Assuming that a default-constructed data has
SOO or otherwise doesn't allocate storage that gets thrown out by the
reserve().)

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

.


Author: leni536@gmail.com
Date: Wed, 11 Nov 2015 09:09:44 -0800 (PST)
Raw View
------=_Part_2761_1580705303.1447261784243
Content-Type: multipart/alternative;
 boundary="----=_Part_2762_1956493067.1447261784243"

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



On Wednesday, November 11, 2015 at 3:36:38 PM UTC+1, Matthew Woehlke wrote:
>
> On 2015-11-11 03:52, len...@gmail.com <javascript:> wrote:=20
> > I didn't find a topic like this, so here it is. Something like this=20
> would=20
> > be nice:=20
> >=20
> > template <class... Args>=20
> > vector(size_type n,Args&&... args);=20
> >=20
> > 1) It could be faster than vector(n,value_type(args)) if value_type's=
=20
> copy=20
> > constructor is more expensive than its constructor with "args"=20
> parameters=20
> > (I don't know a good example though).=20
>
> Interesting idea. And since vector(n, value_type(...)) invokes=20
> value_type's copy ctor, it is in fact a subset of the proposed syntax,=20
> i.e. that form could be deprecated / removed in favor of the proposed=20
> "emplace" version.


I don't think it's possible because of the optional "const allocator_type&"=
=20
argument. I don't know if it's explicitly forbidden or not, but my hunch is=
=20
that optional and variadic parameters don't mix well.=20

I think I made mistake in the usage of my "forward_for_copy" type trait,=20
one can use the following function instead:
template<typename T>
constexpr
decltype(auto)
forward_for_copy(std::remove_reference_t<T>& x) noexcept
{
        using ReturnType=3Dstd::conditional_t<
                std::is_rvalue_reference<T&&>{},
                const T&,=20
                T &>;=20
        return static_cast<ReturnType>(x);
}

Use similarly to "std::forward". What it does:

   1. Leaves lvalue references alone.
   2. Static casts all rvalue references to const lvalue references.

- L=C3=A9n=C3=A1rd

--=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_2762_1956493067.1447261784243
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, November 11, 2015 at 3:36:38 PM UTC+1, Matthew Woehlk=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-11 03:52, <=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nEAqKGcxF=
wAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">len...=
@gmail.com</a> wrote:
<br>&gt; I didn&#39;t find a topic like this, so here it is. Something like=
 this would=20
<br>&gt; be nice:
<br>&gt;=20
<br>&gt; template &lt;class... Args&gt;
<br>&gt; vector(size_type n,Args&amp;&amp;... args);
<br>&gt;=20
<br>&gt; 1) It could be faster than vector(n,value_type(args)) if value_typ=
e&#39;s copy=20
<br>&gt; constructor is more expensive than its constructor with &quot;args=
&quot; parameters=20
<br>&gt; (I don&#39;t know a good example though).
<br>
<br>Interesting idea. And since vector(n, value_type(...)) invokes
<br>value_type&#39;s copy ctor, it is in fact a subset of the proposed synt=
ax,
<br>i.e. that form could be deprecated / removed in favor of the proposed
<br>&quot;emplace&quot; version.</blockquote><div><br></div><div>I don&#39;=
t think it&#39;s possible because of the optional &quot;const allocator_typ=
e&amp;&quot; argument. I don&#39;t know if it&#39;s explicitly forbidden or=
 not, but my hunch is that optional and variadic parameters don&#39;t mix w=
ell.=C2=A0</div><div><br></div><div>I think I made mistake in the usage of =
my &quot;forward_for_copy&quot; type trait, one can use the following funct=
ion instead:</div><div><div class=3D"prettyprint" style=3D"border: 1px soli=
d rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250=
, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><div class=3D"subprettypr=
int">template&lt;typename T&gt;</div><div class=3D"subprettyprint">constexp=
r</div><div class=3D"subprettyprint">decltype(auto)</div><div class=3D"subp=
rettyprint">forward_for_copy(std::remove_reference_t&lt;T&gt;&amp; x) noexc=
ept</div><div class=3D"subprettyprint">{</div><div class=3D"subprettyprint"=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 using ReturnType=3Dstd::conditional_t&lt;</div=
><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 std::is_rvalue_reference&lt;T&amp;&amp;&gt;{},</div><div clas=
s=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 const T&amp;,=C2=A0</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T &amp;&gt;;=C2=A0</div><div clas=
s=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return static_cast&lt;Retu=
rnType&gt;(x);</div><div class=3D"subprettyprint">}</div></span></div></cod=
e></div></div><div><br></div><div>Use similarly to &quot;std::forward&quot;=
.. What it does:</div><div><ol><li><span style=3D"line-height: normal;">Leav=
es lvalue references alone.</span></li><li><span style=3D"line-height: norm=
al;">Static casts all rvalue references to const lvalue references.</span><=
/li></ol></div><div>- L=C3=A9n=C3=A1rd</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_2762_1956493067.1447261784243--
------=_Part_2761_1580705303.1447261784243--

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 11 Nov 2015 11:41:47 -0600
Raw View
--001a114c82c481a9da0524475941
Content-Type: text/plain; charset=UTF-8

On 11 November 2015 at 04:53, <leni536@gmail.com> wrote:

> Ok, this is my last try :).
>
> What if we use the first declaration:
>
> vector(size_type n,vector::forward_args_type,Args&&... args);
>
> But inside vector's constructor we convert every rvalue references in args
> to const ref.
>

But then it is no longer perfect forwarding, is it?  Worse, the signature
looks like it *should* do perfect forwarding.

For instance, if you have move-only parameters that get moved into the
object being constructed, it looks like it ought to work even though it
won't compile.  Take this example:

unique_ptr<int> p;
vector<unique_ptr<int>> v(1, forward_args_type(), std::move(p));


> I'm getting a little bit lost here though, maybe this suggestion adds even
> more problems than what it solves.
>

I think the idea was certainly worth exploring, but I'm leaning towards the
same conclusion.
--
 Nevin ":-)" Liber  <mailto:nevin@cpluscplusguy.com <nevin@eviloverlord.com>>
(847) 691-1404

--

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

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

<div dir=3D"ltr">On 11 November 2015 at 04:53,  <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:leni536@gmail.com" target=3D"_blank">leni536@gmail.com</a>&gt;=
</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">Ok, this is my last try :).<di=
v><br></div><div>What if we use the first declaration:</div><div><br></div>=
<div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;b=
ackground-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,0=
)"><span style=3D"color:#000">vector</span></span><span style=3D"color:rgb(=
102,102,0)"><span style=3D"color:#660">(</span></span><span style=3D"color:=
rgb(0,0,0)"><span style=3D"color:#000">size_type n</span></span><span style=
=3D"color:rgb(102,102,0)"><span style=3D"color:#660">,</span></span><span s=
tyle=3D"color:rgb(0,0,0)"><span style=3D"color:#000">vector</span></span><s=
pan style=3D"color:rgb(102,102,0)"><span style=3D"color:#660">::</span><spa=
n style=3D"color:#000">forward_args</span></span><span style=3D"color:rgb(0=
,0,0)"><span style=3D"color:#000">_type</span></span><span style=3D"color:r=
gb(102,102,0)"><span style=3D"color:#660">,</span></span><span style=3D"col=
or:rgb(102,0,102)"><span style=3D"color:#606">Args</span></span><span style=
=3D"color:rgb(102,102,0)"><span style=3D"color:#660">&amp;&amp;...</span></=
span><span style=3D"color:rgb(0,0,0)"><span style=3D"color:#000"> args</spa=
n></span><span style=3D"color:rgb(102,102,0)"><span style=3D"color:#660">);=
</span></span><span style=3D"color:#000"><br></span></div></code></div><br>=
But inside vector&#39;s constructor we convert every rvalue references in a=
rgs to const ref.</div></div></blockquote><div><br></div><div>But then it i=
s no longer perfect forwarding, is it?=C2=A0 Worse, the signature looks lik=
e it <i>should</i> do perfect forwarding.</div><div><br></div><div>For inst=
ance, if you have move-only parameters that get moved into the object being=
 constructed, it looks like it ought to work even though it won&#39;t compi=
le.=C2=A0 Take this example:</div><div><br></div><div>unique_ptr&lt;int&gt;=
 p;</div><div>vector&lt;unique_ptr&lt;int&gt;&gt; v(1, forward_args_type(),=
 std::move(p));</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div> I&#39;m getting a little bit lost here though, maybe t=
his suggestion adds even more problems than what it solves.</div></div></bl=
ockquote><div><br></div><div>I think the idea was certainly worth exploring=
, but I&#39;m leaning towards the same conclusion.</div></div>-- <br><div c=
lass=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@cpluscpl=
usguy.com</a>&gt;=C2=A0 (847) 691-1404</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 />

--001a114c82c481a9da0524475941--

.


Author: leni536@gmail.com
Date: Wed, 11 Nov 2015 23:35:16 -0800 (PST)
Raw View
------=_Part_9378_1156900636.1447313716235
Content-Type: multipart/alternative;
 boundary="----=_Part_9379_710222595.1447313716236"

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



On Wednesday, November 11, 2015 at 6:42:29 PM UTC+1, Nevin ":-)" Liber=20
wrote:
>
> On 11 November 2015 at 04:53, <len...@gmail.com <javascript:>> wrote:
>
>> Ok, this is my last try :).
>>
>> What if we use the first declaration:
>>
>> vector(size_type n,vector::forward_args_type,Args&&... args);
>>
>> But inside vector's constructor we convert every rvalue references in=20
>> args to const ref.
>>
>
> But then it is no longer perfect forwarding, is it?
>
=20
I agree.=20

Worse, the signature looks like it *should* do perfect forwarding.
>
=20
I'm not familiar with the conventions of modern C++. Is it already settled=
=20
that if you see a universal reference in a signature it should be moved or=
=20
perfect forwarded (so eventually moved)? AFAIK rvalue references are only=
=20
candidates for moving. Anyway this convention (if it exist) seems too=20
limiting. I only use a variadic universal reference because AFAIK it's the=
=20
only way to catch mixed const and non-const lvalue references and keep=20
their "constness" in a variadic parameter.


> For instance, if you have move-only parameters that get moved into the=20
> object being constructed, it looks like it ought to work even though it=
=20
> won't compile.  Take this example:
>
> unique_ptr<int> p;
> vector<unique_ptr<int>> v(1, forward_args_type(), std::move(p));
>
=20
Well not compiling is not that bad. Maybe a static assert is possible with=
=20
useful information.=20

=20
>
>> I'm getting a little bit lost here though, maybe this suggestion adds=20
>> even more problems than what it solves.
>>
>
> I think the idea was certainly worth exploring, but I'm leaning towards=
=20
> the same conclusion.
>
=20
I worry more about more convoluted corner cases. I think this case is not=
=20
that bad.

- L=C3=A9n=C3=A1rd

--=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_9379_710222595.1447313716236
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, November 11, 2015 at 6:42:29 PM UTC+1, Nevin &quot;:-=
)&quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On 11 November 2015 at 04:53,  <span dir=3D"ltr">&lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"e5b7Sos7FwAJ" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" on=
click=3D"this.href=3D&#39;javascript:&#39;;return true;">len...@gmail.com</=
a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><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">Ok, this is my last try :).<div><br></div><d=
iv>What if we use the first declaration:</div><div><br></div><div><div styl=
e=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-colo=
r:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,0)"><span style=
=3D"color:#000">vector</span></span><span style=3D"color:rgb(102,102,0)"><s=
pan style=3D"color:#660">(</span></span><span style=3D"color:rgb(0,0,0)"><s=
pan style=3D"color:#000">size_type n</span></span><span style=3D"color:rgb(=
102,102,0)"><span style=3D"color:#660">,</span></span><span style=3D"color:=
rgb(0,0,0)"><span style=3D"color:#000">vector</span></span><span style=3D"c=
olor:rgb(102,102,0)"><span style=3D"color:#660">::</span><span style=3D"col=
or:#000">forward_args</span></span><span style=3D"color:rgb(0,0,0)"><span s=
tyle=3D"color:#000">_type</span></span><span style=3D"color:rgb(102,102,0)"=
><span style=3D"color:#660">,</span></span><span style=3D"color:rgb(102,0,1=
02)"><span style=3D"color:#606">Ar<wbr>gs</span></span><span style=3D"color=
:rgb(102,102,0)"><span style=3D"color:#660">&amp;&amp;...</span></span><spa=
n style=3D"color:rgb(0,0,0)"><span style=3D"color:#000"> args</span></span>=
<span style=3D"color:rgb(102,102,0)"><span style=3D"color:#660">);</span></=
span><span style=3D"color:#000"><br></span></div></code></div><br>But insid=
e vector&#39;s constructor we convert every rvalue references in args to co=
nst ref.</div></div></blockquote><div><br></div><div>But then it is no long=
er perfect forwarding, is it?</div></div></div></div></blockquote><div>=C2=
=A0</div><div>I agree.=C2=A0</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Wo=
rse, the signature looks like it <i>should</i> do perfect forwarding.</div>=
</div></div></div></blockquote><div>=C2=A0</div><div>I&#39;m not familiar w=
ith the conventions of modern C++. Is it already settled that if you see a =
universal reference in a signature it should be moved or perfect forwarded =
(so eventually moved)? AFAIK rvalue references are only candidates for movi=
ng. Anyway this convention (if it exist) seems too limiting. I only use a v=
ariadic universal reference because AFAIK it&#39;s the only way to catch mi=
xed const and non-const lvalue references and keep their &quot;constness&qu=
ot; in a variadic parameter.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><b=
r></div><div>For instance, if you have move-only parameters that get moved =
into the object being constructed, it looks like it ought to work even thou=
gh it won&#39;t compile.=C2=A0 Take this example:</div><div><br></div><div>=
unique_ptr&lt;int&gt; p;</div><div>vector&lt;unique_ptr&lt;int&gt;&gt; v(1,=
 forward_args_type(), std::move(p));</div></div></div></div></blockquote><d=
iv>=C2=A0</div><div>Well not compiling is not that bad. Maybe a static asse=
rt is possible with useful information.=C2=A0</div><div><br></div><blockquo=
te 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"gma=
il_quote"><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div> I&#39;m getting a little bit lost here though, maybe this suggest=
ion adds even more problems than what it solves.</div></div></blockquote><d=
iv><br></div><div>I think the idea was certainly worth exploring, but I&#39=
;m leaning towards the same conclusion.</div></div></div></div></blockquote=
><div>=C2=A0</div><div>I worry more about more convoluted corner cases. I t=
hink this case is not that bad.</div><div><br></div><div>- L=C3=A9n=C3=A1rd=
</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_9379_710222595.1447313716236--
------=_Part_9378_1156900636.1447313716235--

.


Author: leni536@gmail.com
Date: Thu, 12 Nov 2015 01:14:30 -0800 (PST)
Raw View
------=_Part_145_209806065.1447319670643
Content-Type: multipart/alternative;
 boundary="----=_Part_146_2124678777.1447319670643"

------=_Part_146_2124678777.1447319670643
Content-Type: text/plain; charset=UTF-8

Here is my implementation for this type of constructor:

http://pastebin.com/GK5xn5tC

I inherit myvector from std::vector (including constructors) and only
implement the new constructor, including the static_assert for move-only
arguments.

--

---
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_146_2124678777.1447319670643
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Here is my implementation for this type of constructor:<di=
v><br></div><div>http://pastebin.com/GK5xn5tC<br></div><div><br></div><div>=
I inherit myvector from std::vector (including constructors) and only imple=
ment the new constructor, including the static_assert for move-only argumen=
ts.</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_146_2124678777.1447319670643--
------=_Part_145_209806065.1447319670643--

.