Printable View
If I have a function with a template type, how can I query that at runtime? For example, if I want to know if it's a primitive (int, long, bool, etc) I'll do one thing, otherwise something else.
Code:template <typename T>
void getData(const std::vector<T> &data)
{
//I essentially want to do something like this
if ( type_id( T ) == type_id( int ) ...
}
One option is to specialise the template.
Often you want the code to work regardless of type.
I got it to work!
Code:if ( typeid( T ) == typeid( int ) )...
If you can avoid RTTI, avoid it. If you specialise the template, there is no RTTI overhead (though you may add to executable code bloat).Quote:
I got it to work!
laserlight: why is RTTI so horrible?
i understand that in some applications, due to real time needs, you may be concerned.
but why should we avoid it, in general, for all kind of apps?
Using RTTI in a template defeats the entire purpose of templates, which is that you can specialize on specific types.Quote:
Originally Posted by manav
ok. so laserlight was saying that avoid RTTI in case of templates.
i thought he was saying avoid RTTI in general. always.
That is what I meant. Of course, "avoid ... always" is not correct, since situations may arise where RTTI is the best solution, given other factors. In more general cases, the kinds of problems for which RTTI may be a solution would be better solved with templates or virtual functions.Quote:
i thought he was saying avoid RTTI in general. always.
laserlight: i just read some info about RTTI. and yes, we don't need to avoid RTTI. in fact it is just not needed. always.
and it's much easier to use alternatives like templates and virtuals.
actually till now i never had to care about it.
No, it is needed in certain situations. Don't blam is just because you haven't had the need for it or because someone else just says so.
They say the same about multiple inheritance, but it isn't necessarily bad (I have used it plenty).
I was using the template because I need excatly the same thing for almost every case except for a few (int, short). In those cases, 50% of the code's the same and 50% is diff. Does it make more sense to overload the functions where I have one for int vectors, one for short vectors and one with a template for everything else instead of doing a few if...else statements? Why? (And will it even work to have the function overloaded with two specialized versions and one templated version?)Quote:
Originally Posted by laserlight
Thanks for the help!
Well, you probably need to write that 50% of different code a few times over either way, right? So by making a specialized template, you can avoid the RTTI (avoid using typeid()) and making the code overly complicated.
If you have code that is common to all cases, why not make that into a second template function?
--
Mats
I've had some bad experiences with RTTI when using it with derived classes... so I try to avoid it whenever possible.
I had a case where I needed a template to do one thing for signed numbers and another for unsigned. After some searching I came up with this non-RTTI solution:
Most of the time, you'll probably be able to find an equally simple non-RTTI solution if you search hard enough.Code:template <typename E,
typename T,
typename A,
typename N>
void StringToNum( const std::basic_string<E, T, A>& str,
N& num )
{
if ( std::numeric_limits<N>::is_signed == true )
{
signed long lnum = 0;
StringToNumHelper( str, lnum, num );
}
else
{
unsigned long lnum = 0;
StringToNumHelper( str, lnum, num );
}
}
Once I found out template using functions actually compile on run-time, it scared me away from them for good. (hopefully I'll never NEED them)
Eh, function templates are compiled at compile time.Quote:
Once I found out template using function actually compile on run-time, it scared me away from them for good.
Hmm, I was about to point you to that page that said that, but after reading it again, I realized it didn't!
Just because you can't see the alternate solution doesn't mean it isn't there. If 50% of the code is the same, then that 50% should be broken out into another function, so that only the changing 50% is written in the specializations.Quote:
Originally Posted by 6tr6tr
RTTI is a crutch. It often indicates poor programming.
Overloading would still be better here, I think. For example, like this:Quote:
Originally Posted by cpjust
Code:#include <boost/mpl/bool.hpp>
template <typename E,
typename T,
typename A,
typename N>
void StringToNumHelper( const std::basic_string<E, T, A>& str,
N& num, boost::bool_<true> )
{
// Signed implementation.
}
template <typename E,
typename T,
typename A,
typename N>
void StringToNumHelper( const std::basic_string<E, T, A>& str,
N& num, boost::bool_<false> )
{
// Unsigned implementation.
}
template <typename E,
typename T,
typename A,
typename N>
void StringToNum( const std::basic_string<E, T, A>& str,
N& num )
{
StringToNumHelper( str, num,
boost::bool_<std::numeric_limits<N>::is_signed>() );
}
Actually, the StringToNumHelper() implementation is exactly the same for signed & unsigned. The only difference is the signedness of the N type; and since I don't like to copy and paste code for no reason, I did it like that.Quote:
Originally Posted by CornedBee
I also could have overloaded StringToNum() for each signed & unsigned integer type, but I just felt like condensing it into 1 function.
I understand the value of doing it yourself, but wouldn't boost::lexical_cast<> serve the purpose you're trying for here?Quote:
Originally Posted by cpjust
If the implementation is the same, why have two functions at all?
Maybe... if I ever get the time to learn about all those cool Boost libraries.Quote:
Originally Posted by brewbuck
Because I need to pass either a long or unsigned long to the helper function to do it's job correctly here's the helper function:Quote:
Originally Posted by CornedBee
I was getting compile errors for everything I did if I tried to combine them into one function.Code:template <typename E,
typename T,
typename A,
typename LN, // long or unsigned long.
typename N>
void
StringToNumHelper( const std::basic_string<E, T, A>& str,
LN& lnum,
N& num )
{
std::basic_stringstream<E, T, A> ss( str );
if ( !(ss >> lnum) || (lnum < std::numeric_limits<N>::min()) || (lnum > std::numeric_limits<N>::max()) )
{
throw std::invalid_argument( "Error converting string to number!" );
}
num = static_cast<N>( lnum );
}
i was in a similar position once.
the solution i used was to create different derived classes for each type with virtual getters and setters.
I get it - you need a larger type to avoid overflow.
Not hard to solve with a simple metafunction, though. Boost might even have such a thing. But then, Boost also has lexical_cast.