Topic: Making std::vector<std::unique_ptr<void>> not be copy
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Fri, 23 Aug 2013 16:08:51 +0200
Raw View
First of all, let's make sure we are all aware of the fact that an
expression that would normally be ill-formed may still count as
"well-formed" for some purposes:
http://stackoverflow.com/q/14815998/46642
Now, as far as I can see, the standard makes
std::vector<std::unique_ptr<void>> have a copy constructor, even
though it makes any program that instantiates it ill-formed as a
consequence of its defined semantics. Please correct me if my reading
of the standard here is wrong and makes all of this moot.
These two facts explain why this program is well-formed:
http://coliru.stacked-crooked.com/view?id=3D735d0e4868baddb9fa210cbf18ca02e=
7-f0bd80647c520ac4f6fb0347af37c64b
And this is merely the best example I came up with. There are other
similar issues the standard library, and there is also the general
case of traits testing arbitrary functions in other libraries (which I
first explored here
http://flamingdangerzone.com/cxx11/2013/02/11/to-sfinae-or-not-to-sfinae)
This is quite unfortunate, I'd say. As a library designer the
inability to work around this is something that has been annoying me
for a while.
I have been wondering about two possible changes to ease this
nuissance. The first one would be to fix the standard library so that
the constructor is only there for actually copy constructible Ts (and
similar fixes to other functions). I don't know how much code this
would break, and more importantly, how much non-iffy code this would
break.
The second one would involve giving library designers the ability to
look past the "immediate context", something like `wellformed(expr)`
operator. I also don't know how feasible that would be and it would
certainly make this part of the language even more complex.
I know the deadline for submissions is soon, and I don't think I would
have the time to think everything through to make a decent proposal.
But I want to know if others think this is a problem that needs
solving like I do, and if the solutions are worth making into a future
proposal, potentially for C++17.
Mit freundlichen Gr=FC=DFen,
Martinho
--=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/.
.