Re: [Boost-users] Library Interface Design

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-09-17 20:28:53

"Yuval Ronen" <ronen_yuval_at_[hidden]> wrote in message 
news:eekchf$a8f$1_at_sea.gmane.org...
...
>>   Or perhaps I misread your original poll question? I thought it was
>> about partial construction, not about objects which have an unuseable
>> default state.
>>
>>   If instead it was "how do you feel about objects which have an
>> unuseable default state?", then I change my answer to a shrug. After
>> all, I don't use char* unless I have assigned it, and if I can't put off
>> its declaration and can't assign it then I assign to 0.
>>
>>   But that's not the same as the antipattern of partial construction.
>
> But I don't agree with you here about the difference between "objects
> with uninitialized state" and "partial construction". I believe they are
> the same. As long the the constructor doesn't leave the object in 100%
> constructed state, it doesn't matter if it's 0% or 50%. It's not 100%
> either way. So I think the default constructor for std::ofstream and
> std::container::iterator are a defect in the standard (which is
> unfortunately probably too late to fix).

I agree wholeheartedly.

> If an uninitialized state is desired (which is sometimes the case, no
> doubt about it) then we can all thank God (and Fernando) for
> Boost.Optional. The usage of optional<> is good for two reasons:
...

> You might say something like "but the standard doesn't have optional, so
> it had to resolve to other means". Maybe so, but that doesn't make those
> default constructor not-a-defect; it only makes the lack of
> std::optional an additional defect as well as those default constructors.

The Optional(zero/one) concept also modeled by pointers(albeit with some 
performance implications dues to heap allocation and indirection), has been 
available for some time, has it not? So even non-boosted C++ has not had a 
'need' for partial or 2 phase constuction.

I think std::ofstream, the notions proposed in the book Scott referenced, 
and in fact most of MFC are all the result of mis-guided early optimization.

Jeff