Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-05-05 20:57:17

> Vicente BOTET <vicente.botet <at> wanadoo.fr> writes:
> ..
> I suspect that these complex classes you are talking off don't define the
> input/ouput stream operator to work with your conversion framework. 

Jeez, is it really that hard to accept that 'convert' works and is used with
many classes complex or not. Say, a Train class is complex as it has a *lot* of
stuff. We serialize/unserialize the class to/from XML using 'convert'. Train has
op>>() op<<().

> The classes I expect to be used are regular classes with value semantics.

Our classes with value- and pointer-semantics (pimpl-based) are as
regular/normal. They just happen to be not your classes.

> In any case, you have two options: 
> the default value is created via a default_value function ...
> explicitly. Of course this force the designer of the class to define a
> default value.

I am not sure if I am being heard. I have no default values and I do not want to
provide anything resembling default value as it'll be misused by the library
user.

In fact, I have a solution to my problem. A library called 'convert'. So, if you
want me to switch to some library of yours, then you'll have to do better than
asking me to go an extra mile (like writing default_value<> specializations for
every class and then suffering through complains of those being
misused/misunderstood/whatever).

>> Even simple classes do not often have default constructors. Take the example
>> from my 'convert' documentation -- the direction class with up and dn values.
>> What do you consider the default constructor would do? 
> 
> I could try to follow the builtin behavior. 

It's not immediately obvious to me why (from the design perspectives and not due
to technical shortcomings) would a proper class "follow the builtin behavior".

> I will define one of them as 0
> and init the default constructor with it.

I know. The "builtin behavior". It's wrong but I am afraid emails are too hard a
medium to discuss that.  

>> Or you'd suggest
>> introducing another 'not-defined' state just to be user in the default
>> constructor? Then, it'll have far-reaching ripples through all the code as
>> now I
>> never know if my direction object is valid or not and, therefore, have to
>> always
>> write error-prone "if (dir != undefined) proceed". 
> 
> No please. Do not do that.

Here we go. After all I did not need to explain anything. That default '0' you
initially suggested is that 'undefined'.

V.