[utility] nonconstructible
Hi, I think it would be nice to have a "nonconstructible" class to derive from similar to noncopyable. Recently I was burned by a traits class that was getting constructed. I think this should also be used for template metafunctions. I envision something like the following: struct nonconstructible { private: nonconstructible() {} } template<typename T> struct my_traits : nonconstructible { typedef int my_type; }; Chris
I have a set of types, that are either native types or array types that have a typedef called value_type, which is a native type. I can get this value_type using the following metafunction: template<typename T> struct get_value_type { typedef typename T::value_type type; }; I was using mpl if_ incorrectly so that instead of creating an object of "value_type", I was creating an object of "get_value_type" like the following; struct MyType { typedef int value_type }; typedef MyType T; typedef mpl::if_<mpl::not<is_pod<T> >,get_value_type<T>,T>::type my_type; my_type t; It can be difficult to understand the difference between if_ and eval_if. If I derive get_value_type from nonconstructible, this would not have compiled. Chris On 7/24/06, Gennaro Prota <gennaro_prota@yahoo.com> wrote:
On Mon, 24 Jul 2006 15:54:33 -0400, "Chris Weed" <chrisweed@gmail.com> wrote:
Recently I was burned by a traits class that was getting constructed.
Out of curiosity, what problem did you have?
-- [ Gennaro Prota, C++ developer for hire ]
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, 24 Jul 2006 17:36:49 -0400, "Chris Weed" <chrisweed@gmail.com> wrote:
It can be difficult to understand the difference between if_ and eval_if. If I derive get_value_type from nonconstructible, this would not have compiled.
Regardless of what originally motivated it, nonconstructible (I'd prefer non_constructible, or non_instantiatable) is neither more nor less useful as noncopyable (note: I won't reply to aggressive follow-ups on this... resource management and all that). Some years ago I proposed a simple syntactical addition to mark member functions as "not defined", in the class declaration (typically copy constructors and copy assignment operators), so that a diagnostic could be immediately emitted on anything that needed their definition (rather than processing *all* the TUs to see if a definition existed somewhere). At that time it was mostly ignored, but I see that many of the ideas raised in newsgroups years ago are being reprised by prominent members of the committee, and have wide acceptance. So it could be that someone would grab that one too. To go back to your solution, I'd add a base class having a private copy constructor, so that "self-initialization" M m = m; would be inhibited as well. Keep it in your personal toolbox ;-) -- [ Gennaro Prota, C++ developer. For hire ]
"Chris Weed" <chrisweed@gmail.com> writes:
Hi, I think it would be nice to have a "nonconstructible" class to derive from similar to noncopyable.
Recently I was burned by a traits class that was getting constructed. I think this should also be used for template metafunctions.
I disagree, and strongly. Sometimes it's very useful to pass instances of these things around and I can't see any reason to prohibit it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Chris Weed -
David Abrahams -
Gennaro Prota