Boost logo

Boost :

Subject: Re: [boost] Transfer of Maintenance Rights (utility/value_init)
From: Niels Dekker - address until 2010-10-10 (niels_address_until_2010-10-10_at_[hidden])
Date: 2010-03-29 16:14:58

Edward Diener wrote about
> My suggested fix is so simple that it is hard for me to understand why
> it should take so long for a decision to be made on it unless he was
> no longer involved.

Fernando Cacciola wrote:
> Actually, your fix is NOT so simple, not conceptually.

Edward replied:
> I understand that, but I did mean syntax-wise.
> But clearly, as my argument shows, value_init can not be used in any
> situation in which an object including a value_init value is declared as
> a const object unless you allow the value initialized value to be
> initialized to something other than its value-initialized default upon
> construction ( which is my fix ). And since a developer can hardly
> control how an end-user uses his object, whether as const or non-const,
> essentially you are telling any developer that value_init is useless to
> him unless he enforces the fact that his own object which has a
> value_init value is never const, which in my opinion makes its practical
> usage much, much less than it conceptually could be.
> How many developers do you think want to restrict their own objects to
> non-const ? But currently value_init is practically useless to them
> unless they do. Which is fine if you want it that way, but clearly
> developers wanting a value_init value for a potentially const object
> will not use it and just revert back to a default constructed object
> which may be constructed based on an alternative constructor. Which is a
> shame because value initialization as you have conceived and coded it is
> much clearer and safer to use.

Edward, you know I agree that it would be useful to have an extra
value_inititialized<T> constructor to allow direct-initialization of the
wrapped T object. It's just that I'm not entirely sure if it's a good
idea to declare it as value_initialized(T const&).

I think it would be a bit safer to add an extra "tag" parameter, to
clarify that the constructed object is direct-initialized, instead of

   struct direct_initialized_t { };

   value_initialized(T const&, direct_initialized_t).

I know you prefer your own proposed constructor, value_initialized(T
const &), but does that mean that you're /opposed/ to having
value_initialized(T const&, direct_initialized_t) instead?

Kind regards,


Niels Dekker
Scientific programmer at LKEB, Leiden University Medical Center

Boost list run by bdawes at, gregod at, cpdaniel at, john at