Jeffrey Hellrung wrote:
initialized<T> was actually my initial thought; I chose a crappy name on purpose ;)
Cool :-)
I can think of two ways to implement boost::initialized<T> (and adapt value_initialized<T> accordingly): [...]
I'm partial to value_initialized being implemented in terms of initialized
Me too :-) I think there's a leak in the design when boost::initialized inherits publicly from boost::value_initialized. You know, currently any object held by value_initialized is either value-initialized or copy-constructed from another object held by value_initialized. So in the end, any such object originates from a value-initialized object. I would like to keep it that way!
Also, your initialized<T> does not have a default constructor. This makes sense, but I'm just double-checking that this is a conscious decision and not an oversight.
No, it's an oversight, sorry! I did not test any code from my last mail! BTW I'm not entirely sure if the initialized(T const&) constructor would need an "explicit" keyword. What do you think? Should the following be forbidden? boost::initialized<int> i = 42; If so, we might as well make it even more explicit, by adding a "tag" parameter of type direct_initialized_t to the constructor, as I proposed before at https://svn.boost.org/trac/boost/ticket/3472 so that users would have to explicitly specify that they want direct-initialization: boost::initialized<int> i(42, boost::direct_initialized); What do you think? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center