Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-04-01 11:48:50

Rozental, Gennadiy wrote:
>>> In most part proposed design looks reasonable. I have only
>> one major
>>> IMO concern.
>>> Issue: (Major) Why traits are template parameter of
>> converter? I've
>>> expressed my opinion in the matter before: Traits - as name suggest
>>> could not be policy. IOW should not be template parameters.
>> Traits are
>>> type specific and an ability to supply them independently to the
>>> primary type in most cases leads to invalid/too complicated design.
>>> Traits are not only template parameters of public
>> converter class
>>> but many other classes. IMO all of them should use S and T
>> as template
>>> parameters instead.
>> I have to disagree.
>> Traits are used as policies in too many designs, including
>> the STL itself, and I don't see a problem with that. I agree
> I don't say I like it either. Major issue with basic_string design
> IMO is that char_traits is template parameter
>> that traits classes are type specific, but they are used as
>> policies precisely because of that: if the user of a
>> parametrized facility wants a different treatment for a given
>> type, she can't change *the* traits for the type, all she can
>> do is pass in a different traits as a policy.
> Here is how I see it. Trait is something type specific, IOW specific
> to
> type, IOW uniquely defined by type. If you could provide trait along
> with the type as a template parameter, that mean you could change it
> independently from the type, IOW you could define different value for
> trait still using the same type. For example if you have component C
> defined like:
> template<typename T, typename Trait>
> struct C { ... };
> You could instantiate it like C<MyT,TraitValue1> or
> C<MyT,TraitValue2>. So
> as you could see trait value is not uniquely defined by the type.
> Proper design would be to have trait stand alone class, like this:
> template<typename T>
> struct Trait { value = ... };
> template<typename T>
> struct C { here we are using Trait<T>::value, where we used to use
> Trait. };
> Now if the user needs to define trait value (or change from using
> default value provided by most traits designs), she just need to
> define explicit/partial specialization for this type or types family.
What if there is already an specialization? That's the typical case with
standalone traits.

> On the other hand policy is something that is orthogonal to the
> primary type (actually in policy based design there may not be any
> primary type, but just an orthogonal policies), IOW you could use
> different policies in
> conjunction with the same type. And natural place for the policy is
> along with type in component definition among the template parameters.
Policies must be orthogonal between themselves, but not neccesarily w.r.t
the primary type(s).
In fact, many common policies (from common policy-based designs) are not.

>> If this were
>> not a policy, users would be stuck with the definition of the
>> default traits class. I agree that this opens a window to all
>> sort of problems in case a user plugs in an invalid traits,
>> but I think that should not constitute a reason for fixing
>> the traits into the converter. As always, "trust the programmer"
> So again Trait is not a Policy and let's not mix them
I disagree. A trait can _function_ as a policy IMO.

Well, I do follow your arguments but I'm still unconvinced.
A traits is type-specific, yes, but not necessarily _unique_.
You see it as unique, but why would it has to be like that?
It seems that that fundamental point of your argument is that traits are
uniquely defined by a type, and not just a type decoration.
If this were true, then I would agree, but I don't see why a type can't have
a set of "compatible" traits.

It would benefit your argument if you had some backup. That is, some
reference of others who think the same.

>>> 4. converter<>::convert converts only rvalue. Why?
>>> IMO we need second operation that works with lvalues.
>> What if I want
>>> to convert int& into char&?
>> This requires the target lvalue as a parameter instead of a
>> return value. It could be done yes, but I don't see the
>> reason. Why would want to do that?
> For example for [de]serialization solutions. What is in your opinion
> is problem domain for numeric conversion?
Well, numeric conversions :-)
Whenever you need to convert between numeric types... there is no particular
problem domain for this general need.

In a [de]serialization framework I would expect types to be
serialized/deserialized the same, so I don't quite see the use case for a
numeric conversion here.

Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at