Topic: [proposal] A fixed-capacity vector with
Author: Gonzalo BG <gonzalobg88@gmail.com>
Date: Fri, 9 Dec 2016 10:51:13 +0100
Raw View
--047d7bfcf59a005bff054336b34e
Content-Type: text/plain; charset=UTF-8
@Zach Laine:
Thanks for the feedback. I've filled github issues for all the points you
mentioned. I will report back here with the findings about the code-size
cost of explicit instantiations of embedded_vector for different Capacities.
> Regarding explicit instantiability, why wouldn't that already be the case
for any valid template instantiation?
Non-template member functions, which are instantiated on explicit template
instantiations, might not be properly constrained, so their instantiation
might fail "loudly". The way I've tried to "fix" this in the proposal is by
properly constraining all member functions using concepts, but this is an
aspect that I must iterate on with more feedback.
> At the last meeting, LEWG were taking the stance that (most) additions of
noexcept and constexpr would be left up to implementers until the
implications were better understood by the community as a whole.
Adding constexpr is a breaking change, since functions that were not
previously evaluated in unevaluated contexts, and thus could be SFINAEd
upon, become always potentially evaluated. This can break a lot of code,
and it already happened when libc++ made std::invoke constexpr "as a QoI"
feature, a change that needed to be reverted.
Second, embedded_vector can be used inside constexpr functions for trivial
types. To conditionally allow this, the API must be made conditionally
constexpr.
> That last one is not true -- if I insert a T before the first element,
I've invalidated all iterators into the vector, no? Did you meant
push_back() never invalidates?
Yes, good catch! I meant inserting elements at the end never invalidates
iterators.
@rhalbersma: first thank you a lot for the feedback, the devil is in the
details and I had completely missed all the issues you point out!
> emplace_back() returns a reference in C++17.
Indeed, I've added an issue to fix this, thanks!
> Second, you define the op== and other relational operators as friends,
which means they are generated as non-member functions at namespace scope.
However, all other Standard containers are defined as non-member function
templates. The difference is that the latter does not accept user-defined
conversions, and the former does. Also they don't have to be friends
either.
Indeed, I hadn't realized this until now. As you already know I've filled
some issues to improve these.
> The best way to declare the relational operators op== and op< is as
non-member non-friend function templates, that delegate to std::equal and
std::lexicographical_compare on the embedded_vector's iterator range. Then
the others can be defined as usual in terms of the former.
AFAIK std::lexicographical_compare is not constexpr in C++17, but whether
the op== and friends use it or not is an implementation detail of the
proposal's implementation rather than a blocker.
On Thu, Dec 8, 2016 at 9:14 PM, <rhalbersma@gmail.com> wrote:
>
>
> On Thursday, December 8, 2016 at 5:33:26 PM UTC+1, Gonzalo BG wrote:
>>
>> Hello world,
>>
>> I wrote a proposal for a fixed-capacity vector with embedded storage
>> since this is one of the data-structures that I use most along with
>> std::vector and boost::small_vector.
>>
>> You can find the proposal (and an implementation) here:
>>
>> https://github.com/gnzlbg/embedded_vector/blob/master/README.md
>>
>> Since this is the first proposal I write my experience writing proposals
>> is zero. Hopefully some of you might be kind enough to:
>>
>> - provide me feedback to improve the proposal,
>> - maybe be able to champion it in the next meeting (I don't think I will
>> be able to attend it unless it is close to Cologne, Germany),
>> - so that I can get a paper number for it and it can be discussed in the
>> next meeting.
>>
>> There are still some issues open in the github repo, which also contains
>> an implementation, but the implementation is a bit-out-of-sync with the
>> latest specification (that will be updated before submitting it).
>>
>>
> I like this proposal very much. I use boost::static_vector a lot and it
> has a shortcoming that your proposal fixes, namely not throwing upon
> exceeding the capacity. This saves on branching logic inside push_back().
>
> Two remarks. First, emplace_back() returns a reference in C++17.
>
> Second, you define the op== and other relational operators as friends,
> which means they are generated as non-member functions at namespace scope.
> However, all other Standard containers are defined as non-member function
> templates. The difference is that the latter does not accept user-defined
> conversions, and the former does. Also they don't have to be friends
> either.
>
> The best way to declare the relational operators op== and op< is as
> non-member non-friend function templates, that delegate to std::equal and
> std::lexicographical_compare on the embedded_vector's iterator range. Then
> the others can be defined as usual in terms of the former.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/f78f7191-b043-4e95-990d-
> a0f9baab9aec%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f78f7191-b043-4e95-990d-a0f9baab9aec%40isocpp.org?utm_medium=email&utm_source=footer>
> .
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPMgRLRWJRauPpx6DncUSZkt3M3kPfGezNzsNKPz3P-MufVtYg%40mail.gmail.com.
--047d7bfcf59a005bff054336b34e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Zach Laine: <br><br>Thanks for the feedback. I've fil=
led github issues for all the points you mentioned. I will report back here=
with the findings about the code-size cost of explicit instantiations of e=
mbedded_vector for different Capacities.<br><br>> Regarding explicit ins=
tantiability, why wouldn't that already be the case for any valid templ=
ate instantiation?<br><br>Non-template member functions, which are instanti=
ated on explicit template instantiations, might not be properly constrained=
, so their instantiation might fail "loudly". The way I've tr=
ied to "fix" this in the proposal is by properly constraining all=
member functions using concepts, but this is an aspect that I must iterate=
on with more feedback.<br><br>> At the last meeting, LEWG were taking t=
he stance that (most) additions of noexcept and constexpr would be left up =
to implementers until the implications were better understood by the commun=
ity as a whole.<br><br>Adding constexpr is a breaking change, since functio=
ns that were not previously evaluated in unevaluated contexts, and thus cou=
ld be SFINAEd upon, become always potentially evaluated. This can break a l=
ot of code, and it already happened when libc++ made std::invoke constexpr =
"as a QoI" feature, a change that needed to be reverted.<br><br>S=
econd, embedded_vector can be used inside constexpr functions for trivial t=
ypes. To conditionally allow this, the API must be made conditionally const=
expr.<br><br>> That last one is not true -- if I insert a T before the f=
irst element, I've invalidated all iterators into the vector, no?=C2=A0=
Did you meant push_back() never invalidates?<br><br>Yes, good catch! I mea=
nt inserting elements at the end never invalidates iterators. <br><br>@rhal=
bersma: first thank you a lot for the feedback, the devil is in the details=
and I had completely missed all the issues you point out!<br><div><br></di=
v><div>>=C2=A0<span style=3D"font-size:12.8px">emplace_back() returns a =
reference in C++17.=C2=A0<br><br>Indeed, I've added an issue to fix thi=
s, thanks!</span></div><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"fo=
nt-size:12.8px">Second, you define the op=3D=3D and other relational operat=
ors as friends, which means they are generated as non-member functions at n=
amespace scope. However, all other Standard containers are defined as non-m=
ember function templates. The difference is that the latter does not accept=
user-defined conversions, and the former does. Also they don't have to=
be friends either.=C2=A0<br><br>Indeed, I hadn't realized this until n=
ow. As you already know I've filled some issues to improve these.</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">=
The best way to declare the relational operators op=3D=3D and op< is as =
non-member non-friend function templates, that delegate to std::equal and s=
td::lexicographical_compare on the embedded_vector's iterator range. Th=
en the others can be defined as usual in terms of the former.</span></div><=
div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"f=
ont-size:12.8px">AFAIK std::lexicographical_compare is not constexpr in C++=
17, but whether the op=3D=3D and friends use it or not is an implementation=
detail of the proposal's implementation rather than a blocker.=C2=A0</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px"><br></span></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Thu, Dec 8, 2016 at 9:14 PM, <span dir=3D"=
ltr"><<a href=3D"mailto:rhalbersma@gmail.com" target=3D"_blank">rhalbers=
ma@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><span><br><br>On Thursday, December 8, 2016 at 5:33:26 PM UTC+1,=
Gonzalo BG 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"ltr">=
Hello world,<div><br></div><div>I wrote a proposal for a fixed-capacity vec=
tor with embedded storage since this is one of the data-structures that I u=
se most along with std::vector and boost::small_vector.=C2=A0</div><div><br=
></div><div>You can find the proposal (and an implementation) here:</div><d=
iv><br></div><div><a href=3D"https://github.com/gnzlbg/embedded_vector/blob=
/master/README.md" rel=3D"nofollow" target=3D"_blank">https://github.com/gn=
zlbg/embe<wbr>dded_vector/blob/master/README<wbr>.md</a><br><br>Since this =
is the first proposal I write my experience writing proposals is zero. Hope=
fully some of you might be kind enough to:</div><div><br></div><div>- provi=
de me feedback to improve the proposal,=C2=A0</div><div>- maybe be able to =
champion it in the next meeting (I don't think I will be able to attend=
it unless it is close to Cologne, Germany),</div><div>- so that I can get =
a paper number for it and it can be discussed in the next meeting.</div><di=
v><br></div><div>There are still some issues open in the github repo, which=
also contains an implementation, but the implementation is a bit-out-of-sy=
nc with the latest specification (that will be updated before submitting it=
).</div><div><br></div></div></blockquote><div><br></div></span><div>I like=
this proposal very much. I use boost::static_vector a lot and it has a sho=
rtcoming that your proposal fixes, namely not throwing upon exceeding the c=
apacity. This =C2=A0saves on branching logic inside push_back().<br></div><=
div><br></div><div>Two remarks. First, emplace_back() returns a reference i=
n C++17.=C2=A0</div><div><br></div><div>Second, you define the op=3D=3D and=
other relational operators as friends, which means they are generated as n=
on-member functions at namespace scope. However, all other Standard contain=
ers are defined as non-member function templates. The difference is that th=
e latter does not accept user-defined conversions, and the former does. Als=
o they don't have to be friends either.=C2=A0</div><div><br></div><div>=
The best way to declare the relational operators op=3D=3D and op< is as =
non-member non-friend function templates, that delegate to std::equal and s=
td::lexicographical_compare on the embedded_vector's iterator range. Th=
en the others can be defined as usual in terms of the former.</div></div><s=
pan>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f78f7191-b043-4e95-990d-a0f9baab9aec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/f78f=
7191-b043-4e95-990d-<wbr>a0f9baab9aec%40isocpp.org</a>.</blockquote></div><=
/div>
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPMgRLRWJRauPpx6DncUSZkt3M3kPfGezNzs=
NKPz3P-MufVtYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPMgRLRWJRauPpx6=
DncUSZkt3M3kPfGezNzsNKPz3P-MufVtYg%40mail.gmail.com</a>.<br />
--047d7bfcf59a005bff054336b34e--
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Fri, 9 Dec 2016 11:21:35 +0100
Raw View
--047d7bfe95426f552d0543371eb4
Content-Type: text/plain; charset=UTF-8
On Fri, Dec 9, 2016 at 10:51 AM, Gonzalo BG <gonzalobg88@gmail.com> wrote:
> @Zach Laine:
>
> Thanks for the feedback. I've filled github issues for all the points you
> mentioned. I will report back here with the findings about the code-size
> cost of explicit instantiations of embedded_vector for different Capacities.
>
> > Regarding explicit instantiability, why wouldn't that already be the
> case for any valid template instantiation?
>
> Non-template member functions, which are instantiated on explicit template
> instantiations, might not be properly constrained, so their instantiation
> might fail "loudly". The way I've tried to "fix" this in the proposal is by
> properly constraining all member functions using concepts, but this is an
> aspect that I must iterate on with more feedback.
>
> > At the last meeting, LEWG were taking the stance that (most) additions
> of noexcept and constexpr would be left up to implementers until the
> implications were better understood by the community as a whole.
>
> Adding constexpr is a breaking change, since functions that were not
> previously evaluated in unevaluated contexts, and thus could be SFINAEd
> upon, become always potentially evaluated. This can break a lot of code,
> and it already happened when libc++ made std::invoke constexpr "as a QoI"
> feature, a change that needed to be reverted.
>
> Second, embedded_vector can be used inside constexpr functions for trivial
> types. To conditionally allow this, the API must be made conditionally
> constexpr.
>
> > That last one is not true -- if I insert a T before the first element,
> I've invalidated all iterators into the vector, no? Did you meant
> push_back() never invalidates?
>
> Yes, good catch! I meant inserting elements at the end never invalidates
> iterators.
>
> @rhalbersma: first thank you a lot for the feedback, the devil is in the
> details and I had completely missed all the issues you point out!
>
> > emplace_back() returns a reference in C++17.
>
> Indeed, I've added an issue to fix this, thanks!
>
> > Second, you define the op== and other relational operators as friends,
> which means they are generated as non-member functions at namespace scope.
> However, all other Standard containers are defined as non-member function
> templates. The difference is that the latter does not accept user-defined
> conversions, and the former does. Also they don't have to be friends
> either.
>
> Indeed, I hadn't realized this until now. As you already know I've filled
> some issues to improve these.
>
> > The best way to declare the relational operators op== and op< is as
> non-member non-friend function templates, that delegate to std::equal and
> std::lexicographical_compare on the embedded_vector's iterator range. Then
> the others can be defined as usual in terms of the former.
>
> AFAIK std::lexicographical_compare is not constexpr in C++17, but whether
> the op== and friends use it or not is an implementation detail of the
> proposal's implementation rather than a blocker.
>
Indeed, the reference to <algorithm> was meant to illustrate that it was
not necessary to make the comparison operators friends, but that they could
be done through the public iterator interface (whether from <algorithm> or
hand-implemented to be constexpr).
Note that if you would have a std::array as back-end for this
embedded_vector, then you might want to check
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html which
has greatly expanded the constexpr-ness of std::array, but with the
exception of the op==/op< and swap/fill operations. The rationale being:
*Currently comparisons and swap/fill may be implemented with the help of
algorithms from <algorithm> header. Marking comparisons with constexpr will
break that ability and will potentially lead to performance degradations.*
A related proposal to make <algorithm> mostly constexpr
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r1.html has
not yet been adopted, mainly for concern on intrinsics and C helpers
(memset and friends).
So while I would certainly encourage you to push constexpr-ness as a
feature of your proposal, I would not expect this to be adopted without
discussion.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5XOZwqUDmGdMJg2SYnpAPuAZM_pD%3DohWEkg4eGFtvXscg%40mail.gmail.com.
--047d7bfe95426f552d0543371eb4
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 F=
ri, Dec 9, 2016 at 10:51 AM, Gonzalo BG <span dir=3D"ltr"><<a href=3D"ma=
ilto:gonzalobg88@gmail.com" target=3D"_blank">gonzalobg88@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr">@Zach Laine: <br><br>Thanks for the feedback. I've filled git=
hub issues for all the points you mentioned. I will report back here with t=
he findings about the code-size cost of explicit instantiations of embedded=
_vector for different Capacities.<br><br>> Regarding explicit instantiab=
ility, why wouldn't that already be the case for any valid template ins=
tantiation?<br><br>Non-template member functions, which are instantiated on=
explicit template instantiations, might not be properly constrained, so th=
eir instantiation might fail "loudly". The way I've tried to =
"fix" this in the proposal is by properly constraining all member=
functions using concepts, but this is an aspect that I must iterate on wit=
h more feedback.<br><br>> At the last meeting, LEWG were taking the stan=
ce that (most) additions of noexcept and constexpr would be left up to impl=
ementers until the implications were better understood by the community as =
a whole.<br><br>Adding constexpr is a breaking change, since functions that=
were not previously evaluated in unevaluated contexts, and thus could be S=
FINAEd upon, become always potentially evaluated. This can break a lot of c=
ode, and it already happened when libc++ made std::invoke constexpr "a=
s a QoI" feature, a change that needed to be reverted.<br><br>Second, =
embedded_vector can be used inside constexpr functions for trivial types. T=
o conditionally allow this, the API must be made conditionally constexpr.<b=
r><br>> That last one is not true -- if I insert a T before the first el=
ement, I've invalidated all iterators into the vector, no?=C2=A0 Did yo=
u meant push_back() never invalidates?<br><br>Yes, good catch! I meant inse=
rting elements at the end never invalidates iterators. <br><br>@rhalbersma:=
first thank you a lot for the feedback, the devil is in the details and I =
had completely missed all the issues you point out!<br><div><br></div><div>=
>=C2=A0<span style=3D"font-size:12.8px">emplace_back() returns a referen=
ce in C++17.=C2=A0<br><br>Indeed, I've added an issue to fix this, than=
ks!</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size=
:12.8px">Second, you define the op=3D=3D and other relational operators as =
friends, which means they are generated as non-member functions at namespac=
e scope. However, all other Standard containers are defined as non-member f=
unction templates. The difference is that the latter does not accept user-d=
efined conversions, and the former does. Also they don't have to be fri=
ends either.=C2=A0<br><br>Indeed, I hadn't realized this until now. As =
you already know I've filled some issues to improve these.</span></div>=
<span class=3D"gmail-"><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"fo=
nt-size:12.8px">The best way to declare the relational operators op=3D=3D a=
nd op< is as non-member non-friend function templates, that delegate to =
std::equal and std::lexicographical_compare on the embedded_vector's it=
erator range. Then the others can be defined as usual in terms of the forme=
r.</span></div><div><span style=3D"font-size:12.8px"><br></span></div></spa=
n><div><span style=3D"font-size:12.8px">AFAIK std::lexicographical_compare =
is not constexpr in C++17, but whether the op=3D=3D and friends use it or n=
ot is an implementation detail of the proposal's implementation rather =
than a blocker.=C2=A0</span></div></div></blockquote><div>=C2=A0</div><div>=
Indeed, the reference to <algorithm> was meant to illustrate that it =
was not necessary to make the comparison operators friends, but that they c=
ould be done through the public iterator interface (whether from <algori=
thm> or hand-implemented to be constexpr).</div><div><br></div><div>Note=
that if you would have a std::array as back-end for this embedded_vector, =
then you might want to check=C2=A0</div><div><a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html">http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/p0031r0.html</a> which has greatly expanded=
the constexpr-ness of std::array, but with the exception of the op=3D=3D/o=
p< and swap/fill operations. The rationale being:<br></div><div><br></di=
v></div></div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padd=
ing:0px"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><i><spa=
n style=3D"color:rgb(0,0,0);font-family:"times new roman";font-si=
ze:medium">Currently comparisons and=C2=A0</span><code style=3D"color:rgb(0=
,0,0)">swap</code><span style=3D"color:rgb(0,0,0);font-family:"times n=
ew roman";font-size:medium">/</span><code style=3D"color:rgb(0,0,0)">f=
ill</code><span style=3D"color:rgb(0,0,0);font-family:"times new roman=
";font-size:medium">=C2=A0may be implemented with the help of algorith=
ms from <algorithm> header. Marking comparisons with=C2=A0</span><cod=
e style=3D"color:rgb(0,0,0)">constexpr</code><span style=3D"color:rgb(0,0,0=
);font-family:"times new roman";font-size:medium">=C2=A0will brea=
k that ability and will potentially lead to performance degradations.</span=
></i></div><div><i><span style=3D"color:rgb(0,0,0);font-family:"times =
new roman";font-size:medium"><br></span></i></div></div></div></blockq=
uote>A related proposal to make <algorithm> mostly constexpr <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r1.html">h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r1.html</a> has=
not yet been adopted, mainly for concern on intrinsics and C helpers (mems=
et and friends).<div><br></div><div>So while I would certainly encourage yo=
u to push constexpr-ness as a feature of your proposal, I would not expect =
this to be adopted without discussion.=C2=A0<br><div>=C2=A0<br></div></div>=
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGBGO5XOZwqUDmGdMJg2SYnpAPuAZM_pD%3D=
ohWEkg4eGFtvXscg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5XOZwqUDm=
GdMJg2SYnpAPuAZM_pD%3DohWEkg4eGFtvXscg%40mail.gmail.com</a>.<br />
--047d7bfe95426f552d0543371eb4--
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Fri, 9 Dec 2016 12:57:02 +0100
Raw View
--089e0117664dbf5bc505433873ea
Content-Type: text/plain; charset=UTF-8
On Fri, Dec 9, 2016 at 12:42 PM, Gonzalo BG <gonzalobg88@gmail.com> wrote:
> @Rein Halbersma wrote:
>
> > Indeed, the reference to <algorithm> was meant to illustrate that it was
> not necessary to make the comparison operators friends, but that they could
> be done through the public iterator interface (whether from <algorithm> or
> hand-implemented to be constexpr).
> >
> >Note that if you would have a std::array as back-end for this
> embedded_vector, then you might want to check
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html
> which has greatly expanded the constexpr-ness of std::array, but with the
> exception of the op==/op< and swap/fill operations. The rationale being:
> >
> >Currently comparisons and swap/fill may be implemented with the help of
> algorithms from <algorithm> header. Marking comparisons with constexpr will
> break that ability and will potentially lead to performance degradations.
> >
> > A related proposal to make <algorithm> mostly constexpr
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r1.html has
> not yet been adopted, mainly for concern on intrinsics and C helpers
> (memset and friends).
> >
> > So while I would certainly encourage you to push constexpr-ness as a
> feature of your proposal, I would not expect this to be adopted without
> discussion.
>
> Thanks for these remarks. I've added a github issue to expand the design
> rationale of constexpr with mentions of those two paper. How I see it, is
> that if those papers are accepted, the implementation of the proposal might
> be greatly simplified. But if they are not accepted, the proposal can still
> be implemented as is; doing so just has a higher implementation cost.
>
AFAICS, the first (p0031r0) has already been accepted in the latest draft
Standard (N4618) (together with a constexpr reverse_iterator). The second
(p0202r1) might not have been discussed yet, I am not sure. You might want
to contact the author Antony Polukhin to ask what the Committee feedback
was. He is the main driver behind all the latest constexpr library
additions.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5VJM033wTxf9c4__EJrFDs972XtZ8Ne2Of%3DMJADv4-A1A%40mail.gmail.com.
--089e0117664dbf5bc505433873ea
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 F=
ri, Dec 9, 2016 at 12:42 PM, Gonzalo BG <span dir=3D"ltr"><<a href=3D"ma=
ilto:gonzalobg88@gmail.com" target=3D"_blank">gonzalobg88@gmail.com</a>>=
</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"><span sty=
le=3D"white-space:nowrap">@Rein Halbersma wrote:</span><br><div><span style=
=3D"white-space:nowrap"><br></span></div><div><div class=3D"gmail_quote"><s=
pan class=3D""><div>> Indeed, the reference to <algorithm> was mea=
nt to illustrate that it was not necessary to make the comparison operators=
friends, but that they could be done through the public iterator interface=
(whether from <algorithm> or hand-implemented to be constexpr).</div=
><div>><br>>Note that if you would have a std::array as back-end for =
this embedded_vector, then you might want to check <br><a href=3D"http://ww=
w.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html" target=3D"_bla=
nk">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0031=
r0.html</a> which has greatly expanded the constexpr-ness of std::array, bu=
t with the exception of the op=3D=3D/op< and swap/fill operations. The r=
ationale being:<br>><br>>Currently comparisons and swap/fill may be i=
mplemented with the help of algorithms from <algorithm> header. Marki=
ng comparisons with constexpr will break that ability and will potentially =
lead to performance degradations.<br>><br>> A related proposal to mak=
e <algorithm> mostly constexpr <a href=3D"http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2016/p0202r1.html" target=3D"_blank">http://www.ope=
n-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0202r1.html</a> has no=
t yet been adopted, mainly for concern on intrinsics and C helpers (memset =
and friends).<br>><br>> So while I would certainly encourage you to p=
ush constexpr-ness as a feature of your proposal, I would not expect this t=
o be adopted without discussion. <br> </div><div><br></div></span><div>Than=
ks for these remarks. I've added a github issue to expand the design ra=
tionale of constexpr with mentions of those two paper. How I see it, is tha=
t if those papers are accepted, the implementation of the proposal might be=
greatly simplified. But if they are not accepted, the proposal can still b=
e implemented as is; doing so just has a higher implementation cost.=C2=A0<=
/div></div></div></div></blockquote><div>=C2=A0</div><div>AFAICS, the first=
(p0031r0) has already been accepted in the latest draft Standard (N4618) (=
together with a constexpr reverse_iterator). The second (p0202r1) might not=
have been discussed yet, I am not sure. You might want to contact the auth=
or Antony Polukhin to ask what the Committee feedback was. He is the main d=
river behind all the latest constexpr library additions.</div></div><br></d=
iv></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGBGO5VJM033wTxf9c4__EJrFDs972XtZ8Ne=
2Of%3DMJADv4-A1A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5VJM033wT=
xf9c4__EJrFDs972XtZ8Ne2Of%3DMJADv4-A1A%40mail.gmail.com</a>.<br />
--089e0117664dbf5bc505433873ea--
.
Author: Zach Laine <whatwasthataddress@gmail.com>
Date: Fri, 9 Dec 2016 10:50:54 -0600
Raw View
--001a1142f230bc439805433c8e44
Content-Type: text/plain; charset=UTF-8
On Fri, Dec 9, 2016 at 3:51 AM, Gonzalo BG <gonzalobg88@gmail.com> wrote:
> @Zach Laine:
>
> Thanks for the feedback. I've filled github issues for all the points you
> mentioned. I will report back here with the findings about the code-size
> cost of explicit instantiations of embedded_vector for different Capacities.
>
> > Regarding explicit instantiability, why wouldn't that already be the
> case for any valid template instantiation?
>
> Non-template member functions, which are instantiated on explicit template
> instantiations, might not be properly constrained, so their instantiation
> might fail "loudly". The way I've tried to "fix" this in the proposal is by
> properly constraining all member functions using concepts, but this is an
> aspect that I must iterate on with more feedback.
>
Ah, got it. Perhaps just make that intention a bit more explicit? An FWIW,
I expect that feature to be quite controversial.
> At the last meeting, LEWG were taking the stance that (most) additions of
> noexcept and constexpr would be left up to implementers until the
> implications were better understood by the community as a whole.
>
> Adding constexpr is a breaking change, since functions that were not
> previously evaluated in unevaluated contexts, and thus could be SFINAEd
> upon, become always potentially evaluated.
>
I don't think anyone cares about breaking backwards-compatibility with
respect to SFINAE. If we did, nearly every change would be considered a
breaking change.
> This can break a lot of code, and it already happened when libc++ made
> std::invoke constexpr "as a QoI" feature, a change that needed to be
> reverted.
>
That's the whole point, as I understand it. Standardizing one way or the
other closes the door on implementers' making these kinds of mistakes --
and without those kinds of mistakes to inform the design, the right design
is harder to come up with.
Second, embedded_vector can be used inside constexpr functions for trivial
> types. To conditionally allow this, the API must be made conditionally
> constexpr.
>
Fair enough. But wasn't similar logic used to justify constexpr
std::invoke? I'm not advocating for one position or another -- I'm just
letting you know what the I took the atmosphere to be in LEWG at the last
meeting.
[snip]
Zach
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALOpkJByGkXrWXntcYMStk-MSkgAu_OvkF%3D3YXisr7ZgPszenA%40mail.gmail.com.
--001a1142f230bc439805433c8e44
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 F=
ri, Dec 9, 2016 at 3:51 AM, Gonzalo BG <span dir=3D"ltr"><<a href=3D"mai=
lto:gonzalobg88@gmail.com" target=3D"_blank">gonzalobg88@gmail.com</a>><=
/span> wrote:<br><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-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr">@Zach Laine: <br><br>Tha=
nks for the feedback. I've filled github issues for all the points you =
mentioned. I will report back here with the findings about the code-size co=
st of explicit instantiations of embedded_vector for different Capacities.<=
span class=3D"gmail-"><br><br>> Regarding explicit instantiability, why =
wouldn't that already be the case for any valid template instantiation?=
<br><br></span>Non-template member functions, which are instantiated on exp=
licit template instantiations, might not be properly constrained, so their =
instantiation might fail "loudly". The way I've tried to &quo=
t;fix" this in the proposal is by properly constraining all member fun=
ctions using concepts, but this is an aspect that I must iterate on with mo=
re feedback.</div></blockquote><div><br></div><div>Ah, got it. Perhaps just=
make that intention a bit more explicit?=C2=A0 An FWIW, I expect that feat=
ure to be quite controversial.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr"><span class=3D"gmail-">> At the last meeting, LEWG were taking=
the stance that (most) additions of noexcept and constexpr would be left u=
p to implementers until the implications were better understood by the comm=
unity as a whole.<br><br></span>Adding constexpr is a breaking change, sinc=
e functions that were not previously evaluated in unevaluated contexts, and=
thus could be SFINAEd upon, become always potentially evaluated.</div></bl=
ockquote><div><br></div><div>I don't think anyone cares about breaking =
backwards-compatibility with respect to SFINAE.=C2=A0 If we did, nearly eve=
ry change would be considered a breaking change.</div><div>=C2=A0</div><blo=
ckquote 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;paddi=
ng-left:1ex"><div dir=3D"ltr">This can break a lot of code, and it already =
happened when libc++ made std::invoke constexpr "as a QoI" featur=
e, a change that needed to be reverted.<br></div></blockquote><div><br></di=
v><div>That's the whole point, as I understand it.=C2=A0 Standardizing =
one way or the other closes the door on implementers' making these kind=
s of mistakes -- and without those kinds of mistakes to inform the design, =
the right design is harder to come up with.</div><div><br></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;padding-left=
:1ex"><div dir=3D"ltr">Second, embedded_vector can be used inside constexpr=
functions for trivial types. To conditionally allow this, the API must be =
made conditionally constexpr.</div></blockquote><div><br></div><div>Fair en=
ough.=C2=A0 But wasn't similar logic used to justify constexpr std::inv=
oke?=C2=A0 I'm not advocating for one position or another -- I'm ju=
st letting you know what the I took the atmosphere to be in LEWG at the las=
t meeting.</div><div><br></div><div>[snip]</div><div><br></div><div>Zach</d=
iv><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALOpkJByGkXrWXntcYMStk-MSkgAu_OvkF%3=
D3YXisr7ZgPszenA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALOpkJByGkXrWX=
ntcYMStk-MSkgAu_OvkF%3D3YXisr7ZgPszenA%40mail.gmail.com</a>.<br />
--001a1142f230bc439805433c8e44--
.