Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-05-05 19:18:34

> Vicente BOTET <vicente.botet <at> wanadoo.fr> writes:
> ...
>> template <>
>> default_value
>> {
>> static example apply() { return example(3); }
>> };
>> 
>> quite bothersome as I know I really do not have to. In the original wacky
> design
>> the fallback and the default were synonyms. Now you are introducing an
>> additional piece of machinery/code that is needed to deploy a class with
>> conversion and I have to provide the default and the fallback. With that in
>> mind
>> I am not sure I am personally warming up for default_value concept yet.
> 
> I was not talking here of the fallback.
> 
> Note that you don't need to do that for the classes having a default 
> constructor, which are most of them.

Vicente,

If I were proposing something for a potentially wide user-base, then I'd
personally be probably cautious with "most of them" statements. The classes you
happen to write/come across might indeed have default constructors. My projects
do not. In fact, only a small fraction of (relatively low-level) classes will
have default constructors. Our classes happen to be quite complex and require
parameters to be created. Those classes cannot be instantiated with default
constructors. One could argue that the default constructor *could* be still
provided for those classes by creating invalid instances. I argue that that's a
bad idea as from the design perspectives that code pollution to work around
limitations of some other library.

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? 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". 

V.