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.