|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk