From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-01-23 22:28:40
On Jan 23, 2004, at 9:24 PM, Reece Dunn wrote:
> I'm not sure of how is_convertable is implemented, but can't
> noncopyable be added as a special case, like generating a compile-time
> error when used as a parameter to it, e.g.
> error: cannot instantiate disallowed_conversion< noncopyable >
> from is_convertable< noncopyable, T >::type
> or something similar.
> This should be a case of adding some MPL code to detect is_same<
> noncopyable, T >. The only problem I forsee would be in compile time,
> or am I missing something?
> e.g. (pseudocode style):
> is_convertable_ex< T1, T2 >::type =
> or_< is_same< T1, noncopyable >, is_same< T2, noncopyable > >,
> disallowed_conversion< noncopyable >,
> is_convertable< T1, T2 >
The big picture is how does is_convertible handle types with private
copy ctors (as opposed to just deriving from noncopyable). And it is a
bigger problem than just saying: is_convertible should be a compiler
intrinsic and it should just do the right thing.
C++ is currently set up so that given a class:
If you change the access of foo::bar() from private to protected or
public, the behavior of your working program is guaranteed not to
change. This is a useful invariant in the language. This invariant
translates to compiler behavior as: Name lookup occurs without regard
to access. Access is checked after name lookup has identified a unique
So the suitability (lookup) of copy constructors and conversion
constructors is performed without regard to access (and that is how
is_convertible works). If we make is_convertible smarter than that
(via language changes), then a major cornerstone of the language is
changed: changing access can silently effect runtime behavior. I do
not currently possess the foresight to know if such a change would be
wise or not. I'm nervous enough to guess that it would be a bad
change. But perhaps others have better guesses. See D&E section 2.10
for a more informed discussion.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk