Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-05-06 09:14:54

Vladimir Batov wrote:
>> Matthew Chambers <matt.chambers42 <at> gmail.com> writes:
>>
>> Did you ever use boost.convert on a non-defaultable type? I've never needed
>> that.
> 
> It might come a surprise but non-defaultable types are the overwhelming majority
> of our classes. Easily 9:1. And I'd like to stress *our* classes and not just
> wacko-Vladimir's. And, yes, 'convert' is used well beyond ints and the like. The
> direction class in 'convert' documentation is a real class and we have plenty of
> similar ones not to mention considerably more complex. An enumerator as simple as
> 
> enum hamlet_problem { to_be, not_to_be }; 
> 
> 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.

hamlet_problem shroedinger = 
static_cast<hamlet_problem>(xxx_cast<int>(s,0));

> enum hamlet_problem { to_be, not_to_be, i_dont_know }; 
> 
> will be helpful for poor Hamlet. From the design perspectives adding elements
> not relevant to the domain (i_dont_know) is pollution.

Hey, I just successfully compiled:

int main()
{
   enum X { y = 1, z = 2 };

   X x;
}

on MSVC8, XCode gcc4.0.1 and Codewarrior 3.2.5.

So doesn't:

   hamlet_problem shroedinger = xxx_cast<hamlet_problem>(s,to_be);

just work? I expect this standard, given the C-language lineage.

> I won't be surprised if you find a lot of non-defaultable types if you look
> closely around without pre-disposition that any class is supposed to have the
> default constructor. One needs to remember that the default constructor was
> introduced in C++ (if my memory serves me) so that objects would not be in an
> invalid state like 'int i;' can be. If one introduces the default constructor
> which does not, in fact, construct a valid object, then it seems to defeat the
> purpose. 

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

Jeff