Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-05 20:08:12

> Message du 06/05/11 01:19
> De : "Vladimir Batov" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> > Vicente BOTET  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.

I suspect that these complex classes you are talking off don't define the input/ouput stream operator to work with your conversion framework. Or did them?
The classes I expect to be used are regular classes with value semantics.
In any case, you have two options: the default value is created via a default_value function implicitly or explicitly via a constructor with parameters . As a user of a class I will prefer to don't have to create it explicitly. Of course this force the designer of the class to define a default value.

Could you give some more examples of regular classes that don't have a default constructor, neither a valid instance that can be constructed by a default value function?

> 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. I will define one of them as 0 and init the default constructor with it.

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

Best,
Vicente