Topic: [proposal] A fixed-capacity vector with embedded storage
Author: Gonzalo BG <gonzalobg88@gmail.com>
Date: Thu, 8 Dec 2016 08:33:26 -0800 (PST)
Raw View
------=_Part_186_1891343095.1481214806721
Content-Type: multipart/alternative;
boundary="----=_Part_187_1467226141.1481214806721"
------=_Part_187_1467226141.1481214806721
Content-Type: text/plain; charset=UTF-8
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).
Best regards,
Gonzalo
--
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/b6abc3db-61ca-4641-ad80-86a5da719a3a%40isocpp.org.
------=_Part_187_1467226141.1481214806721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello world,<div><br></div><div>I wrote a proposal for a f=
ixed-capacity vector with embedded storage since this is one of the data-st=
ructures that I use most along with std::vector and boost::small_vector.=C2=
=A0</div><div><br></div><div>You can find the proposal (and an implementati=
on) here:</div><div><br></div><div>https://github.com/gnzlbg/embedded_vecto=
r/blob/master/README.md<br><br>Since this is the first proposal I write my =
experience writing proposals is zero. Hopefully some of you might be kind e=
nough to:</div><div><br></div><div>- provide me feedback to improve the pro=
posal,=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><div><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-sync with the latest specification =
(that will be updated before submitting it).</div><div><br></div><div>Best =
regards,=C2=A0</div><div>Gonzalo</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/b6abc3db-61ca-4641-ad80-86a5da719a3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b6abc3db-61ca-4641-ad80-86a5da719a3a=
%40isocpp.org</a>.<br />
------=_Part_187_1467226141.1481214806721--
------=_Part_186_1891343095.1481214806721--
.
Author: Zach Laine <whatwasthataddress@gmail.com>
Date: Thu, 8 Dec 2016 11:54:16 -0600
Raw View
--001a114bcec278ad6c054329535c
Content-Type: text/plain; charset=UTF-8
This proposal is quite timely -- I was considering proposing static_vector
too. I'm glad to see this.
Some notes:
"
The main drawback of introducing a new type is, as the design document of
the EASTL points out, increased code size. Since this container type is
opt-in, only those users that need it will pay this cost. Common techniques
to reduce code size where explored in the prototype implementation (e.g.
implementing Capacity/value_type agnostic functionality in a base class)
without success, but implementations are encouraged to consider code-size
as a quality of implementation issue.
"
I really want to see some real numbers on this. Please instantiate several
kinds of static_vector-like things (hand-rolled struct consisting of
std::array + size_t, static_vector, your implementation, etc.) in scenarios
where you would expect there to be larger code size, and let's see some
assembly, or at least relative counts of instructions. Also, that EASTL
design doc link is broken.
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.
Regarding explicit instantiability, why wouldn't that already be the case
for any valid template instantiation?
"
Iterator invalidation
The iterator invalidation rules are different than those for std::vector,
since:
moving an embedded_vector invalidates all iterators,
swapping two embedded_vectors invalidates all iterators, and
inserting elements into an embedded_vector never invalidates iterators.
"
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?
Zach
On Thu, Dec 8, 2016 at 10:33 AM, Gonzalo BG <gonzalobg88@gmail.com> 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).
>
> Best regards,
> Gonzalo
>
> --
> 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/b6abc3db-61ca-4641-
> ad80-86a5da719a3a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6abc3db-61ca-4641-ad80-86a5da719a3a%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/CALOpkJBmL%3DDBGBPHuYdadhVkMaKC_hVY4xaHe9uQjgRk3uJ4Yw%40mail.gmail.com.
--001a114bcec278ad6c054329535c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This proposal is quite timely -- I was considering pr=
oposing static_vector too.=C2=A0 I'm glad to see this.</div><div><br></=
div><div>Some notes:</div><div><br></div><div>"</div>The main drawback=
of introducing a new type is, as the design document of the EASTL points o=
ut, increased code size. Since this container type is opt-in, only those us=
ers that need it will pay this cost. Common techniques to reduce code size =
where explored in the prototype implementation (e.g. implementing Capacity/=
value_type agnostic functionality in a base class) without success, but imp=
lementations are encouraged to consider code-size as a quality of implement=
ation issue.<br><div>"</div><div><br></div><div>I really want to see s=
ome real numbers on this.=C2=A0 Please instantiate several kinds of static_=
vector-like things (hand-rolled struct consisting of std::array + size_t, s=
tatic_vector, your implementation, etc.) in scenarios where you would expec=
t there to be larger code size, and let's see some assembly, or at leas=
t relative counts of instructions.=C2=A0 Also, that EASTL design doc link i=
s broken.</div><div><br></div><div><br></div><div>At the last meeting, LEWG=
were taking the stance that (most) additions of noexcept and constexpr wou=
ld be left up to implementers until the implications were better understood=
by the community as a whole.</div><div><br></div><div><br></div><div>Regar=
ding explicit instantiability, why wouldn't that already be the case fo=
r any valid template instantiation?</div><div><br></div><div><br></div><div=
>"</div><div><div>Iterator invalidation</div><div><br></div><div>The i=
terator invalidation rules are different than those for std::vector, since:=
</div><div><br></div><div>moving an embedded_vector invalidates all iterato=
rs,</div><div>swapping two embedded_vectors invalidates all iterators, and<=
/div><div>inserting elements into an embedded_vector never invalidates iter=
ators.</div></div><div>"</div><div><br></div><div>That last one is not=
true -- if I insert a T before the first element, I've invalidated all=
iterators into the vector, no?=C2=A0=C2=A0Did you meant push_back() never =
invalidates?</div><div><br></div><div>Zach</div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Thu, Dec 8, 2016 at 10:33 AM, Gonza=
lo BG <span dir=3D"ltr"><<a href=3D"mailto:gonzalobg88@gmail.com" target=
=3D"_blank">gonzalobg88@gmail.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">Hello world,<div><br></div><div>I wrote a p=
roposal 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::s=
mall_vector.=C2=A0</div><div><br></div><div>You can find the proposal (and =
an implementation) here:</div><div><br></div><div><a href=3D"https://github=
..com/gnzlbg/embedded_vector/blob/master/README.md" target=3D"_blank">https:=
//github.com/gnzlbg/<wbr>embedded_vector/blob/master/<wbr>README.md</a><br>=
<br>Since this is the first proposal I write my experience writing proposal=
s is zero. Hopefully some of you might be kind enough to:</div><div><br></d=
iv><div>- provide me feedback to improve the proposal,=C2=A0</div><div>- ma=
ybe 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 me=
eting.</div><div><br></div><div>There are still some issues open in the git=
hub repo, which also contains an implementation, but the implementation is =
a bit-out-of-sync with the latest specification (that will be updated befor=
e submitting it).</div><div><br></div><div>Best regards,=C2=A0</div><span c=
lass=3D"HOEnZb"><font color=3D"#888888"><div>Gonzalo</div></font></span></d=
iv><span class=3D"HOEnZb"><font color=3D"#888888">
<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@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b6abc3db-61ca-4641-ad80-86a5da719a3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b6ab=
c3db-61ca-4641-<wbr>ad80-86a5da719a3a%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></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/CALOpkJBmL%3DDBGBPHuYdadhVkMaKC_hVY4x=
aHe9uQjgRk3uJ4Yw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALOpkJBmL%3DDB=
GBPHuYdadhVkMaKC_hVY4xaHe9uQjgRk3uJ4Yw%40mail.gmail.com</a>.<br />
--001a114bcec278ad6c054329535c--
.
Author: rhalbersma@gmail.com
Date: Thu, 8 Dec 2016 12:14:26 -0800 (PST)
Raw View
------=_Part_285_1471207253.1481228066396
Content-Type: multipart/alternative;
boundary="----=_Part_286_1606574659.1481228066396"
------=_Part_286_1606574659.1481228066396
Content-Type: text/plain; charset=UTF-8
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/isocpp.org/d/msgid/std-proposals/f78f7191-b043-4e95-990d-a0f9baab9aec%40isocpp.org.
------=_Part_286_1606574659.1481228066396
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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;marg=
in-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-capacit=
y vector with embedded storage since this is one of the data-structures tha=
t I use most along with std::vector and boost::small_vector.=C2=A0</div><di=
v><br></div><div>You can find the proposal (and an implementation) here:</d=
iv><div><br></div><div><a href=3D"https://github.com/gnzlbg/embedded_vector=
/blob/master/README.md" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2F=
gnzlbg%2Fembedded_vector%2Fblob%2Fmaster%2FREADME.md\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNFb-SDKK0rBdCwxaVb_Es6Y5bomYg';return true;" onclick=
=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.c=
om%2Fgnzlbg%2Fembedded_vector%2Fblob%2Fmaster%2FREADME.md\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFb-SDKK0rBdCwxaVb_Es6Y5bomYg';return true;">http=
s://github.com/gnzlbg/<wbr>embedded_vector/blob/master/<wbr>README.md</a><b=
r><br>Since this is the first proposal I write my experience writing propos=
als is zero. Hopefully some of you might be kind enough to:</div><div><br><=
/div><div>- provide 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>- s=
o that I can get a paper number for it and it can be discussed in the next =
meeting.</div><div><br></div><div>There are still some issues open in the g=
ithub repo, which also contains an implementation, but the implementation i=
s a bit-out-of-sync with the latest specification (that will be updated bef=
ore submitting it).</div><div><br></div></div></blockquote><div><br></div><=
div>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 excee=
ding the capacity. This =C2=A0saves on branching logic inside push_back().<=
br></div><div><br></div><div>Two remarks. First, emplace_back() returns a r=
eference in 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 gene=
rated as non-member functions at namespace scope. However, all other Standa=
rd 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.=C2=A0</div><div><br><=
/div><div>The best way to declare the relational operators op=3D=3D and op&=
lt; is as non-member non-friend function templates, that delegate to std::e=
qual and std::lexicographical_compare on the embedded_vector's iterator=
range. Then the others can be defined as usual in terms of the former.</di=
v></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/f78f7191-b043-4e95-990d-a0f9baab9aec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f78f7191-b043-4e95-990d-a0f9baab9aec=
%40isocpp.org</a>.<br />
------=_Part_286_1606574659.1481228066396--
------=_Part_285_1471207253.1481228066396--
.
Author: Gonzalo BG <gonzalobg88@gmail.com>
Date: Fri, 9 Dec 2016 03:42:50 -0800 (PST)
Raw View
------=_Part_475_376919300.1481283770809
Content-Type: multipart/alternative;
boundary="----=_Part_476_186434506.1481283770809"
------=_Part_476_186434506.1481283770809
Content-Type: text/plain; charset=UTF-8
@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.
I think some aspects of the proposal are controversial. In particular, the
"conditionally noexcept interface" and the constexpr features. I actually
do not know if the proposal should have these features since there are a
lot of trade-offs at play. The features are however implementable, and they
do bring significant benefit in some use cases. I am assuming that the
proposal won't get accepted at its first revision, but rather that it will
at least be revised a couple of times. I thought that for a first revision
of the proposal it would be better to add these features to show that they
are implementable, that they bring benefit, and so that people can "play"
with them and see how they behave or find issues. If it turns out that they
should be removed in a second revision, then that's the way it is. But
removing them is easy, and maybe they can be pursued in future proposals
that are followups to the one you mentioned.
I should write this down in the paper to explain why I used these features.
I do not want the reader to be surprised with a "noexcept/constexpr
everywhere! that is not how the standard library does things!". What I
actually want is to inform the reader that it is possible to do this. That
doing so adds benefits, and that those benefits come with some
specification and implementation costs. I think the benefits outweigh the
costs (and I try to make a case for this), but I want the reader to be able
to form its own opinion about this so that the discussion at the committee
can be a constructive one.
--
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/b1520579-b1ff-4ea9-9c2c-36d4e99c447d%40isocpp.org.
------=_Part_476_186434506.1481283770809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=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"><div>> Indeed, the reference to <algorith=
m> was meant to illustrate that it was not necessary to make the compari=
son operators friends, but that they could be done through the public itera=
tor interface (whether from <algorithm> or hand-implemented to be con=
stexpr).</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://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html">h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html</a> whi=
ch has greatly expanded the constexpr-ness of std::array, but with the exce=
ption of the op=3D=3D/op< and swap/fill operations. The rationale being:=
<br>><br>>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 perform=
ance degradations.<br>><br>> A related proposal to make <algorithm=
> mostly constexpr <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2016/p0202r1.html">http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2016/p0202r1.html</a> has not yet been adopted, mainly for concern on i=
ntrinsics and C helpers (memset and friends).<br>><br>> So while I wo=
uld certainly encourage you to push constexpr-ness as a feature of your pro=
posal, I would not expect this to be adopted without discussion. <br> </div=
><div><br></div><div>Thanks for these remarks. I've added a github issu=
e to expand the design rationale of constexpr with mentions of those two pa=
per. 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 im=
plementation cost.=C2=A0</div><div><br></div><div>I think some aspects of t=
he proposal are controversial. In particular, the "conditionally noexc=
ept interface" and the constexpr features. I actually do not know if t=
he proposal should have these features since there are a lot of trade-offs =
at play. The features are however implementable, and they do bring signific=
ant benefit in some use cases. I am assuming that the proposal won't ge=
t accepted at its first revision, but rather that it will at least be revis=
ed a couple of times. I thought that for a first revision of the proposal i=
t would be better to add these features to show that they are implementable=
, that they bring benefit, and so that people can "play" with the=
m and see how they behave or find issues. If it turns out that they should =
be removed in a second revision, then that's the way it is. But removin=
g them is easy, and maybe they can be pursued in future proposals that are =
followups to the one you mentioned.=C2=A0</div><div><br></div><div>I should=
write this down in the paper to explain why I used these features. I do no=
t want the reader to be surprised with a "noexcept/constexpr everywher=
e! that is not how the standard library does things!". What I actually=
want is to inform the reader that it is possible to do this. That doing so=
adds benefits, and that those benefits come with some specification and im=
plementation costs. I think the benefits outweigh the costs (and I try to m=
ake a case for this), but I want the reader to be able to form its own opin=
ion about this so that the discussion at the committee can be a constructiv=
e one. =C2=A0</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/b1520579-b1ff-4ea9-9c2c-36d4e99c447d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1520579-b1ff-4ea9-9c2c-36d4e99c447d=
%40isocpp.org</a>.<br />
------=_Part_476_186434506.1481283770809--
------=_Part_475_376919300.1481283770809--
.
Author: "T. C." <rs2740@gmail.com>
Date: Fri, 9 Dec 2016 13:33:35 -0800 (PST)
Raw View
------=_Part_530_939762718.1481319215438
Content-Type: multipart/alternative;
boundary="----=_Part_531_235431767.1481319215439"
------=_Part_531_235431767.1481319215439
Content-Type: text/plain; charset=UTF-8
Some comments after looking through ~half of the page:
> If T's destructor throws the behavior is undefined.
That's implied by [res.on.functions]/2 and does not need to be repeated.
> The embedded_vector<T, Capacity>::size_type is the smallest unsigned
integer type that can represent Capacity.
This implies that `evec.size() +1` is sometimes unsigned and sometimes
signed, depending on whether size_type is subject to integral promotion. I
don't find that to be helpful.
> If the container is not empty, the member function data() returns a
pointer such that [data(), data() + size()) is a valid range
Shouldn't this *always* be a valid range regardless of whether the
container is empty?
> The whole API of embedded_vector<T, Capacity> is constexpr if
is_trivial<T> is true.
A trivial class may have deleted copy/move assignment. A "plain"
implementation of e.g. push_back with placement new would work with such a
type, but not if you pre-allocate and then attempt to assign.
> Making exceeding the capacity a precondition has some advantages: [...]
If it's a precondition, then it's narrow-contract, and LWG generally
doesn't like noexcept on narrow-contract functions. LWG doesn't really like
conditional noexcept either, except in a few cases.
Expect the noexcept on things like front()/back()/op[] to disappear.
> /* constexpr ~embedded_vector(); */ // implicitly generated
This comment makes no sense for non-trivially-destructible T.
> void reserve(size_type n) = delete;
> void shrink_to_fit() = delete;
What does deleting them add over simply not having those members?
> [detailed specification]
The elements of the specification should match [structure.specifications].
> constexpr embedded_vector(size_type n, const value_type& value);
> [...]
> Requirements: value_type shall be EmplaceConstructible into *this from
*first.
This doesn't make any sense.
> template<class InputIterator>
> constexpr embedded_vector(InputIterator first, InputIterator last);
> [...]
> Requirements: value_type shall be either:
> - CopyInsertable into *this if the reference type of InputIterator is
an lvalue reference, or
> - MoveInsertable into *this if the reference type of InputIterator is
an rvalue reference.
1) Are you intentionally not supporting the case where the value type of
the iterator is not the same as the value type of the vector? If so, why?
2) What if "reference" is not a reference type at all? (e.g.,
vector<bool>::iterator)
This is the one that should be using the EmplaceConstructible wording.
> Effects: exactly last - first calls to value_type[']s copy or move
constructor.
First, this might not invoke a copy or move ctor (unless you really meant
to ban mismatched value types). Second, last - first needs either the
appropriate wording from Clause 25's introduction or be replaced with
distance(first, last).
> template<std::size_t M, enable_if_t<(C != M)>>
> constexpr embedded_vector& operator=(embedded_vector<value_type, M>const&
other)
The SFINAE is unnecessary. The template/non-template tiebreaker is
sufficient to disambiguate.
--
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/929e9ef9-779a-46a3-b770-2d2cd0516003%40isocpp.org.
------=_Part_531_235431767.1481319215439
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Some comments after looking through ~half of the page=
:</div><div><br></div>> If T's destructor throws the behavior is und=
efined.<br><br>That's implied by [res.on.functions]/2 and does not need=
to be repeated.<br><br>> The embedded_vector<T, Capacity>::size_t=
ype is the smallest unsigned integer type that can represent Capacity.<br><=
div><br></div><div>This implies that `evec.size() +1` is sometimes unsigned=
and sometimes signed, depending on whether size_type is subject to integra=
l promotion. I don't find that to be helpful.<br><br>> If the contai=
ner is not empty, the member function data() returns a pointer such that [d=
ata(), data() + size()) is a valid range <br><br></div><div>Shouldn't t=
his *always* be a valid range regardless of whether the container is empty?=
<br><br>> The whole API of embedded_vector<T, Capacity> is constex=
pr if is_trivial<T> is true.<br><br></div><div>A trivial class may ha=
ve deleted copy/move assignment. A "plain" implementation of e.g.=
push_back with placement new would work with such a type, but not if you p=
re-allocate and then attempt to assign.</div><div><br></div>> Making exc=
eeding the capacity a precondition has some advantages: [...]<br><br>If it&=
#39;s a precondition, then it's narrow-contract, and LWG generally does=
n't like noexcept=C2=A0on narrow-contract functions. LWG doesn't re=
ally like conditional noexcept=C2=A0either, except in a few cases.<div><br>=
</div><div>Expect the noexcept on things like front()/back()/op[] to disapp=
ear.<br><div><br></div><div>> /* constexpr ~embedded_vector(); */ // imp=
licitly generated<div><br></div><div>This comment makes no sense for non-tr=
ivially-destructible T.</div><div><br></div>> void reserve(size_type n) =
=3D delete;=C2=A0<div>> void shrink_to_fit() =3D delete;=C2=A0</div><div=
><br></div><div>What does deleting them add over simply not having those me=
mbers?</div><div><br></div><div>> [detailed specification]</div></div></=
div><div><br></div><div>The elements of the specification should match [str=
ucture.specifications].=C2=A0</div><div><br></div><div>>=C2=A0constexpr =
embedded_vector(size_type n, const value_type& value);</div><div>> [=
....]<br>> Requirements: value_type shall be EmplaceConstructible into *t=
his from *first.<br><br>This doesn't make any sense.<br><br>> templa=
te<class InputIterator></div><div>> constexpr embedded_vector(Inpu=
tIterator first, InputIterator last);<br>> [...]<br>> Requirements: v=
alue_type shall be either:<br>> =C2=A0 =C2=A0- =C2=A0CopyInsertable into=
*this if the reference type of InputIterator is an lvalue reference, or<br=
>> =C2=A0 =C2=A0- =C2=A0MoveInsertable into *this if the reference type =
of InputIterator is an rvalue reference.</div><div><br></div><div>1) Are yo=
u intentionally not supporting the case where the value type of the iterato=
r is not the same as the value type of the vector? If so, why?</div><div>2)=
What if "reference" is not a reference type at all? (e.g., vecto=
r<bool>::iterator)</div><div><br></div><div>This is the one that shou=
ld be using the EmplaceConstructible wording.</div><br>> Effects: exactl=
y last - first calls to value_type[']s copy or move constructor.<div><b=
r></div><div>First, this might not invoke a copy or move ctor (unless you r=
eally meant to ban mismatched value types). Second, last - first needs eith=
er the appropriate wording from Clause 25's introduction or be replaced=
with distance(first, last).</div><br>> template<std::size_t M, enabl=
e_if_t<(C !=3D M)>><div>> constexpr embedded_vector& operat=
or=3D(embedded_vector<value_type, M>const& other)<br></div><div><=
br></div><div>The SFINAE is unnecessary. The template/non-template tiebreak=
er is sufficient to disambiguate.</div><div><br></div><div><br></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/929e9ef9-779a-46a3-b770-2d2cd0516003%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/929e9ef9-779a-46a3-b770-2d2cd0516003=
%40isocpp.org</a>.<br />
------=_Part_531_235431767.1481319215439--
------=_Part_530_939762718.1481319215438--
.