Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk