Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-05-06 19:10:03

> 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.

> I'm not opposed to supporting non-default-constructable types, I'm opposed 
> to paying the cost of a more complicated interface to support them.

You certainly entitled to your opinion. Still, I'd expect a library to work 
equally hard to be equally useful for different use-cases. In reality I see 
it all the time that the interface is made a bit "more complicated" for a 
particular use-case to gain considerably wider audience by covering other 
use-cases. Again, opinions and experiences differ and that's healthy (I 
think :-) ). There is a convert_cast interface discussion gong on lead by 
Rob Stewart, please consider contributing your ideas and views so that there 
will be something tangible in the end.

V.