Re: How to conditionally disable a copy constructor?
Am 24.11.2011 21:41, schrieb SG:
On 23 Nov., 23:40, Daniel Kr?gler wrote:
On 2011-11-23 17:07, SG wrote:
I wonder how std::vector is supposed to handle this. As far as I know,
you are allowed to define members which cannot be instantiated as long
as you don't try to instantiate them.
Yes for the second part. Does this answer your first question? Otherwise
I'm not sure what you exactly mean in regard to std::vector.
The problem I see with conditionally supporting copy construction with
a class template like std::vector is that you *could* just implement
the copy ctor and rely on people not using it for move-only types. No
instantiation = no errors. But what is
std::is_copy_constructible<MOC>::value supposed to evaluate to in case
MOC is a container of move-only elements (like a vector of
unique_ptrs)?
Well, the standard does not *require* that this works. This is QoI.
In an ideal world it would return false. But
is_copy_constructible<T> is defined in terms of
is_constructible<T,const T&>. Checking one of the latest C++ ISO
standard drafts I found the following part:
"...the predicate condition of is_constructible<T,Args...> shall
be satisfied if and only if the following variable definition
would be well-formed for some invented variable t:
T t (create<Args>()...);
Access checking is performed as if in a context unrelated to T
and any of the Args. Only the validity of the immediate context
of the variable initialization is considered. [ Note: The
evaluation of the initialization can result in side effects
such as instantiation of class template specializations and
function template specializations, the generation of implicitly-
defined functions, and so on. Such side effects are not in the
'immediate context' and can result in the program being ill-
formed. -- end note ]"
So, it seems like library implementers have to go a couple of extra
miles to make is_copy_constructible<vector<unique_ptr<int>>>::value
evaluate to false instead of failing to compile.
Note that library implementations can add (conditional)
noexcept-specifications in addition to what the standard library
requires, see [res.on.exception.handling] p1.
But we have to consider that C++11 has just been published, so the
library group was a bit conservative with required specifications. We
may need more in the future.
Arguably, this becomes complicated when taking the new allocator model
into account, because actually we don't have to consider
std::is_constructible, but we would need a new trait
std::is_copy_insertable and is_move_insertable. There is no reason why
implementations should not experiment with such internal traits.
My assumption is, that user experience in the following years might
impose enough pressure on implementations to provide better compile-time
support here, which again is the usual seed for standardization.
Side note: We don't need create<> anymore since we got declval<>,
right?
We really do need create() here, because we have the following problem:
is_constructible is defined as a variable definition and there does not
exist (to my knowledge) a simple transformation of such a beast into a
single, equivalent expression (It is possible to define a rather
complicated series of expressions that have the same effect, though).
Now, given expressions, we can easily talk about an unevaluated operand,
but we have no pendant for this for variable definitions. *If* we would
allow lambda expressions in unevaluated contexts, this would have been a
nice tool for this by simply writing something along the lines of:
decltype([]{ T t(std::declval<Args>()...); })
But such unevaluated lambda expressions would cause a lot of
specification problems, mostly in regard to equivalence of declarations
of functions or function templates, where the signature is defined in
terms of such expressions, so I believe there is a far route to go,
until finally lambda expressions would be allowed in unevaluated
expressions.
Given these limitations, it is not possible to specify
std::is_constructible in terms of std::declval, because this entity
would be considered as odr-used within the definition. This again would
make the variable definition ill-formed in (basically) every case. Since
this trait is defined in terms of well-formed code, the effect would be
that std::is_constructible would return false for nearly all
initialization cases ;-)
Summarizing, using create here is just a technical trick to solve a
subtle specification problem.
IMHO, C++ desperately needs a "requires" that's not only a native
enable_if replacement but can also enable/disable non-template members
of class templates. I'd even be happy about a requires-clause which
only takes a compile-time boolean and does not involve "modular type
checking".
In current C++11 this is possible for all members except for the special
members thanks to default template parameters.
I guess you mean ... by turning them into member templates +
exploiting SFINAE.
Yes, exactly, this is what I meant.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]