From: Simon Buchan (simon_at_[hidden])
Date: 2005-09-28 20:22:21
Robert Kawulak wrote:
>> void initialize(value_type & value_o);
>> value_type initialize();
>>Thus, when passed the data member to initialize, it can
>>initialize that object directly. Granted, (N)RVO can often avoid
>>the copy, but this change will ensure you get the efficiency.
> I don't think so, because your version of initialize couldn't be used to
> initialize a value in constructor's initialization list. So first the value
> would be default-constructed, and then assigned another value using
> In bounded policies I use
> passed_value_type initialize()
> where passed_value_type is value_type for integral types and const
> value_type & for other types. The second returns a reference to a static
> object - that's the most efficient method I can think of, initialization
> takes only one copy-construction (for details please look into the code).
ref to static? It feels cludgy. Just trust the RVO even for user
classes, IMHO, it's how the std lib works. Unfortunately the RVO can't
get rid of the side-effects of c/d'tors, so you should make sure it's
documented that values must have normal copy semantics if default
initialisation is used.
>>What you are suggesting is equivalent to suggesting that
>>std::vector should be named "vector_type" because it is a class
>>The purpose of the class template is to create objects through
>>instantiating specializations. It is those objects that are
>>actually used. Thus, the type name should be indicative of the
>>purpose and use of those objects. Those objects are values. The
>>class name should indicate the value nature of those objects.
> Uhh, maybe you're right ;-) I don't know why, but it just "byte my eyes"
> when I see a type named "something_value"... Nevermind, if people here
> really resist that it should be called constrained_value instead of
> constrained_type, then OK - I'll change it.
Why not just 'constrained'? ie. constrained<int>?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk