extending type_traits::rank ?
I need an equivalent of type_traits::rank for a vector-matrix library I am working on so I thought about extending type_traits::rank for my own vector- and matrix-types. But is extending type_traits foreseen or even possible? And what is the best way to go about? The easiest way of course is to add a specialization for boost::type_traits::rank in my project's sources but this is not a very clean solution because this would require that I add stuff to the boost-namespace in my own project. Ideas? Thanks in advance, toon
Toon Knapen wrote:
I need an equivalent of type_traits::rank for a vector-matrix library I am working on so I thought about extending type_traits::rank for my own vector- and matrix-types. But is extending type_traits foreseen or even possible? And what is the best way to go about?
The easiest way of course is to add a specialization for boost::type_traits::rank in my project's sources but this is not a very clean solution because this would require that I add stuff to the boost-namespace in my own project. Ideas?
Unfortunately I think you need to define your own trait: the idea behind type-traits is that they work with the core C++ type system only, and that we don't extend them to classes that are "pretending" to be something else (like an array for example). Having just said that, I'm having trouble thinking of a reason why extending boost::rank in this way would cause problems in a way that extending is_pointer to smart-pointers would for example. So.... why not create your own traits class, call it rank if you want, place it in your projects own namespace, and have the primary template inherit from boost::rank. Does that make sense? John.
"John Maddock" <john@johnmaddock.co.uk> writes:
The easiest way of course is to add a specialization for boost::type_traits::rank in my project's sources but this is not a very clean solution because this would require that I add stuff to the boost-namespace in my own project. Ideas?
Unfortunately I think you need to define your own trait: the idea behind type-traits is that they work with the core C++ type system only, and that we don't extend them to classes that are "pretending" to be something else (like an array for example). Having just said that, I'm having trouble thinking of a reason why extending boost::rank in this way would cause problems in a way that extending is_pointer to smart-pointers would for example.
Most of the type traits are designed to do something legal and reasonable even when doing the right thing is impossible, e.g. remove_pointer<shared_ptr<T> >::type is designed to be shared_ptr<T>. If rank does somthing similar, like return zero when not passed a true array, then specializing it could break libraries. Besides which, it's just conceptually wrong ;-)
So.... why not create your own traits class, call it rank if you want, place it in your projects own namespace, and have the primary template inherit from boost::rank. Does that make sense?
That sounds sensible. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Most of the type traits are designed to do something legal and reasonable even when doing the right thing is impossible, e.g.
remove_pointer<shared_ptr<T> >::type
is designed to be shared_ptr<T>. If rank does somthing similar, like return zero when not passed a true array, then specializing it could break libraries. Besides which, it's just conceptually wrong ;-)
I actually agree with this.
So.... why not create your own traits class, call it rank if you want, place it in your projects own namespace, and have the primary template inherit from boost::rank. Does that make sense?
That sounds sensible.
will do that. Since type_traits is in TR1 and thus has a lot of visibility, I prefer to be close to the terminology used in the type-traits when rolling my own traits because this will be more intuitive for the users. So that's why I first thought about extending the type_traits::rank, but since I have to agree with Dave, now will go for solution John proposed. thanks, toon
participants (4)
-
David Abrahams -
Howard Hinnant -
John Maddock -
Toon Knapen