"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
And I think the same. IMO any example of trait/policy mixure in the same class would be an example of bad design.
I don't know; it seems to me that the
template <class T, class Policy = xxx_traits<T> > class Foo;
idiom might not be a bad one for some uses if xxx_traits is only supplying associated types. It allows customization of the meaning of Foo<X> for any X by specializing xxx_traits<X>, while also allowing users to explicitly choose Foo<X, Y> when they don't like the default for X.
And you get basic_string design as a result.
My problems with basic_string arise from other choices.
If user do not like default value for the trait.
It's not a default value of a trait. It's the default value of the Policy. The default value of xxx_traits<T>::whatever is given by the primary xxx_traits template.
It's value should be set *externally* to the component definition.
Why?
That is the major point I am trying to prove in regards to numeric_cast design and in thic generic discussion.
I don't know enough about how this relates to numeric_cast to comment. -- Dave Abrahams Boost Consulting www.boost-consulting.com