From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-04-02 01:16:16
> 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.
An example?
> >
> >> 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.
Let's get back to the converter class. Do you invision somebody do something
like this:
struct myInt {...}the_int;
struct myFloat {};
a.cpp
template<>
conversion_traits<myInt,myFloat>
{
};
boost::numeric_cast<myFloat>( the_int );
b.cpp
template<>
conversion_traits<myInt,myFloat>
{
};
boost::numeric_cast<myFloat>( the_int );
And do you think it would be good idea?
How definitions in a.cpp and b.cpp could differ?
Gennadiy.