
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.