Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2011-05-06 19:28:45

On 05/06/2011 04:10 PM, Vladimir Batov wrote:
>> From: "Jeff Flinn" <TriumphSprint2000_at_[hidden]>
>>
>>> has no default. I am not sure if extending the above to
>>
>> But is an enum IStreamable? Aren't you relying on implicit conversion
>> to/from int for streaming? An int *is* default constructable.
>
> You are correct. The example I gave in a haste is probably more
> confusing than helping. A better (and real) example of objectified enum
> -- the direction class -- is in the 'convert' documentation.
>
>> Just as another data point, looking at *our* classes, I see many more
>> types that are not IStreamable, but are default-constructable. In
>> looking at my own types, those that are not default-constructable
>> would not make sense to be IStreamable. The types I find that are
>> non-default-constructable tend to hold references to items passed as a
>> ctor args.
>
> I am not sure what to say. I guess, our domains, programming styles,
> etc. differ. Does it mean that one needs to be better supported than the
> other or another?
>
> Still, I have a suspicion (and that's just that -- a suspicion) that
> many default-constructors can be reasonably questioned. Even a such a
> simlpe "class" as int default-constructed to 0. I am tempted to ask 'why
> 0?' why not MAX_INT or '-1'. My point is that an object needs to be
> constructed explicitly with the valu it needs to be assigned to, i.e.
>
> int v(0);
>
> that is for readability, maintainability, etc. Yes, built-in type do
> have default constructors. However, it was not a design choice but
> rather the practical necessity to be able to incorporate built-in types
> into C++ framework. However, that technical "hack" to a
> legacy-support-related issue as been misunderstood and carried over to
> proper classes. That's my view of course and as any view it can be wrong.

The fact that built-in types in C++ have a special "uninitialized" state 
separate from the default constructed state necessary makes them a 
special case.  Nonetheless, a default constructor is often useful even 
if it serves to create an arbitrary initial state with only the 
guarantee that it won't leak memory, etc.  Basically it allows the type 
to serve as its own optional<>, with the caveat that you cannot check if 
it has been initialized and don't need to dereference it explicitly.

This often is more convenient/leads to better syntax that having to use 
optional<> or a smart pointer of some type everywhere.

For instance, arrays (and some other containers) require a default 
constructor.  Also, if the type is a member of some other class, it may 
be convenient to be able to initialize it in the constructor body or 
elsewhere, as constructing it using the initializer list may be too 
limiting or inconvenient.