From: "Jeff Flinn" <TriumphSprint2000@hotmail.com>
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.