Function template checking

[Surya Kiran]

Hi all,
I've written a function template. say

template <class T>
fn (T var) { ... }

Is there any way, from within the function, can we check what type of
argument we've passed on to the function (double, float etc) ??

Thanks in advance,
Surya

 

[Alf P. Steinbach]

Is there any way, from within the function, can we check what type of
argument we've passed on to [a template] function (double, float etc)?

Yes.

The easiest I think would be dynamic_cast of pointers, which in this
context would not be a runtime operation.

But what is it that you want to do that for?

It's nearly 100% certain that there are easier ways to do whatever it is.

General advice: when something is "hard", consider the approach.

 

[Attila Feher]

Hi all,
I've written a function template. say

template <class T>
fn (T var) { ... }

Is there any way, from within the function, can we check what type of
argument we've passed on to the function (double, float etc) ??

Usually you don't do that, but you specialize your template for the type in
question.

 

[Kevin Saff]

Is there any way, from within the function, can we check what type of
argument we've passed on to [a template] function (double, float etc)?

Yes.

The easiest I think would be dynamic_cast of pointers, which in this
context would not be a runtime operation.

No, dynamic_cast is only for polymorphic types, not doubles, floats, etc;
however, typeid works for nonpolymorphic types at compile time:

if (typeid(foo) == typeid(float))
doSomething();

This is one way to do it. I agree with another poster that specialization is
preferable.

 

[Dan McLeran]

See http://www.boost.org/libs/type_traits/index.htm

 

[Alf P. Steinbach]

Is there any way, from within the function, can we check what type of
argument we've passed on to [a template] function (double, float etc)?

Yes.

The easiest I think would be dynamic_cast of pointers, which in this
context would not be a runtime operation.

No, dynamic_cast is only for polymorphic types, not doubles, floats, etc;

That's both incorrect and irrelevant (great work).

With such immense belief in knowing what you don't know I expect some
follow-up "argument".

In that case I require relevant quotes from the C++ _standard_ regarding
the correctness of the statement, and discussion of its relevance.

typeid works for nonpolymorphic types at compile time:
Wow.


I agree with another poster that specialization is preferable.

And that's twice incorrect (great work, again!).

First, no-one except you have said that.

Second, specialization is not a technique for finding out types from
within the function (the OP's question). It can avoid the need for
doing such finding-out. Presumably the OP knows that, since he's using
a _template_ function, and so specialization is not an option.

 

[White Wolf]

That's both incorrect and irrelevant (great work).

It is correct and relevant.

With such immense belief in knowing what you don't know I expect some
follow-up "argument".

In that case I require relevant quotes from the C++ _standard_
regarding
the correctness of the statement, and discussion of its relevance.

Is it indeed? So let's see it:

In 5.2.7/1 Simon says:

<<<The result of the expression dynamic_cast<T>(v) is the result of
converting the expression v to type T. T shall be a pointer or reference to
a complete class type, or "pointer to cv void".>>>

WAIT ALF! It says: *shall be a pointer or reference to a complete class
type, or "pointer to cv void"*

GOT IT? Pointer to int, float, sink and other fundamental types just do not
cut it!

Simon does not stop talling you are wrong, (boy that guy is mean), because
in 5.2.7/2 he says:

<<<If T is a pointer type, v shall be an rvalue of a pointer to complete
class type,>>>

Complete class type. Hmmm. Not int, not float, not double, not triple.
Class type.

(((May I quote the OP here? Of course:
Is there any way, from within the function, can we check what type of
argument we've passed on to the function (double, float etc) ??
)))

Wow.

What did you eat today Alf? I am sure it was no cat, then your aren't so
sarcastic. ;-) What did this guy to make you so upset, that you even forget
C++?

I am not going to quote the whole 5.2.7 here. Read the standard.
dynamic_cast cannot be used for what you want to use it.

And that's twice incorrect (great work, again!).

Nope Alf, wrong again.

First, no-one except you have said that.

Really???? AM I A NO-ONE???
http://www.google.com/[email protected]>&lr=&hl=en

http://tinyurl.com/nl14

Second, specialization is not a technique for finding out types from
within the function (the OP's question).

No. It is a technique to avoid Java stupidity (are you a Car? No? Oh.
Well then. Then you must be an Airplane! No? Oh my. Are you a Person
then...). It is to avoid the absolutely silly act of asking for the type
when all you need to do is that if you need anything special for that type:
you specialize. WOW.

It can avoid the need for
doing such finding-out. Presumably the OP knows that, since he's
using a _template_ function, and so specialization is not an option.

ALF! MY GOD! Did someone STEAL your ID and keeps posting here to make you
look bad? The OP is using a FUNCTION TEMPLATE. There is no such things as
a template function! And it CAN be specialized. It cannot be PARTIALLY
specialized.

 

[Alf P. Steinbach]

It is correct and relevant.

Bah. It's not correct (dynamic_cast is not limited to polymorphic
types, as you _yourself_ point out below), and it's not relevant.

Is it indeed? So let's see it:

In 5.2.7/1 Simon says:

<<<The result of the expression dynamic_cast<T>(v) is the result of
converting the expression v to type T. T shall be a pointer or reference to
a complete class type, or "pointer to cv void".>>>

WAIT ALF! It says: *shall be a pointer or reference to a complete class
type, or "pointer to cv void"*

GOT IT? Pointer to int, float, sink and other fundamental types just do not
cut it!

Hallelujah, a correct statement.

Simon does not stop talling you are wrong, (boy that guy is mean), because
in 5.2.7/2 he says:

<<<If T is a pointer type, v shall be an rvalue of a pointer to complete
class type,>>>

Complete class type. Hmmm. Not int, not float, not double, not triple.
Class type.

Don't troll -- Kevin talked about dynamic casts of float etc., not I;
I said dynamic cast _of pointers_.

(((May I quote the OP here? Of course:
Is there any way, from within the function, can we check what type of
argument we've passed on to the function (double, float etc) ??
)))


What did you eat today Alf? I am sure it was no cat, then your aren't so
sarcastic. ;-) What did this guy to make you so upset,

He responded 'no' to something I wrote, and backed it up by an
incorrect statement (which you have now tried to say is correct,
while quoting the standard to the effect that it isn't, Jesus).

that you even forget C++?

I didn't forget any C++. You pretend that you did (you're trolling
again). See above, and below.

I am not going to quote the whole 5.2.7 here. Read the standard.
dynamic_cast cannot be used for what you want to use it.

Yes, it can, e.g.


template< typename T > struct Check { virtual Check* x(){ return this; } };

template< typename T, typename U >
bool isType( U const& arg )
{
return (dynamic_cast<Check<T>*>( Check<U>().x() ) != 0);
}


...
if( isType<float>( myArg ) )
{
...
}


Kevin was right that type-info is simpler, but for all the wrong
reasons, including directly incorrect statements.

I think I was wrong that current compilers probably will optimize this
to compile-time, but then, can't be right _all_ the time... ;-) Nothing
like an actual implementation when discussing optimizations. I don't
do that for every little posting here, though.

Nope Alf, wrong again.


Really???? AM I A NO-ONE???
http://www.google.com/[email protected]>&lr=&hl=en

http://tinyurl.com/nl14

I didn't realize you meant such a stupid thing. Oh well.

No. It is a technique to avoid Java stupidity (are you a Car? No? Oh.
Well then. Then you must be an Airplane! No? Oh my. Are you a Person
then...). It is to avoid the absolutely silly act of asking for the type
when all you need to do is that if you need anything special for that type:
you specialize. WOW.


ALF! MY GOD! Did someone STEAL your ID and keeps posting here to make you
look bad? The OP is using a FUNCTION TEMPLATE. There is no such things as
a template function! And it CAN be specialized. It cannot be PARTIALLY
specialized.

Wow. Did you know, C++ has a type called 'int'?

Stop trolling, and even if you don't, at least stop using all caps.

 

[White Wolf]

Bah. It's not correct (dynamic_cast is not limited to polymorphic
types, as you _yourself_ point out below), and it's not relevant.

Bah. The OP asked for *fundamental* types:

<<<Is there any way, from within the function, can we check what type of
argument we've passed on to the function (double, float etc) ??>>>

Hallelujah, a correct statement.

It is, isn't it?

Don't troll -- Kevin talked about dynamic casts of float etc., not
I;
I said dynamic cast _of pointers_.

Yes? Read the standard text again: They *must* be pointers pointing to
*complete class types*. Not fundamental types, as the OP asked for. So he
_cannot_ use dynamic_cast.

He responded 'no' to something I wrote, and backed it up by an
incorrect statement (which you have now tried to say is correct,
while quoting the standard to the effect that it isn't, Jesus).

It was correct. The message was: you cannot use dynamic_cast on
pointers to fundamental types. And you cannot.

I didn't forget any C++. You pretend that you did (you're trolling
again). See above, and below.

Alf, take a chill pill. I am not trolling, you are out of line with your
style. Remember: we have made friends once already. I am not attacking
you, I am just very much surprised on what you were saying.

Yes, it can, e.g.

No, it cannot.

template< typename T > struct Check { virtual Check* x(){ return
this; } };

template< typename T, typename U >
bool isType( U const& arg )
{
return (dynamic_cast<Check<T>*>( Check<U>().x() ) != 0);
}


...
if( isType<float>( myArg ) )
{
...
}

What does this have to do with the OPs question about _fundamental_ types?

Kevin was right that type-info is simpler, but for all the wrong
reasons, including directly incorrect statements.

Alf. You cannot use dynamic_cast on a fundamental type (a pointer to it).
It will not compile.

I think I was wrong that current compilers probably will optimize this
to compile-time, but then, can't be right _all_ the time... ;-)

Depending on how difficult the code is they might just do it.

Nothing
like an actual implementation when discussing optimizations. I don't
do that for every little posting here, though.

Ahha. I do not understand what you are saying, so I agree with you and look
smart.

I didn't realize you meant such a stupid thing. Oh well.

??????? Alf. Don't do this please. Do not flame.

Wow. Did you know, C++ has a type called 'int'?

Do not take this tone with me young man. I do not know how much I know
about C++ (I know it is not enough) but it was enough to be invited to work
with the C++ comittee. Not an official invitation (I am not that good) but
several people (names you see every day on clc++mod) has expressed that they
think it is a good idea for me to be there and contribute. IMHO (since some
of these people know me personally, some others from newsgroups and mail)
this should mean something and I am proud of it. And I do not accept this
tone - not even from an online friend. Of course they might just tell me to
go there so that they can beat me up.

Stop trolling, and even if you don't, at least stop using all caps.

I did not troll, you have been flaming. I have tried to chill you by
getting here and there funny. I have quoted the parts of the standard,
which are relevant to the issue. I see no trolling.

So far I have considered you a friend (which in this case does not give
access to all the privates ;-) ) but you seem to be out of line in this
thread with this tone.

I really do not want to argue this. You are right in that dynamic_cast (in
special cases) can be used with non-polymorph class types as well. No
argument about that. So if you feel that you want to stop the pssing
contest let me know. I would mail you asking to help me with something C++
related - but I am not going to mail without your consent. (It is not
programming and it is not (I think) to much time.) Let me know.

 

[Alf P. Steinbach]

Bah. The OP asked for *fundamental* types:

So what? Kevin, not the OP, made a statement about _polymorphic_ types.
That statement was incorrect and irrelevant.

It is, isn't it?

Yep. But not very relevant to anything... ;-)

Did you note the example code?

Yes? Read the standard text again: They *must* be pointers pointing to
*complete class types*. Not fundamental types, as the OP asked for. So he
_cannot_ use dynamic_cast.

Oh yes he can. I already gave explicit code for that. It's not the
easiest way to do it, though.

It was correct. The message was: you cannot use dynamic_cast on
pointers to fundamental types. And you cannot.

The message was, quoting: "dynamic_cast is only for polymorphic types".
And that's simply not true.

Alf, take a chill pill. I am not trolling, you are out of line with your
style. Remember: we have made friends once already. I am not attacking
you, I am just very much surprised on what you were saying.

Hm. That means you didn't previously understand that a dynamic_cast, like
the code I presented, is a technically correct solution to the OP's problem?

No, it cannot.


What does this have to do with the OPs question about _fundamental_ types?

In the example code above, 'myArg' can be of a fundamental type.

The usage example checks for fundamental type 'float'.

Try it out if you don't believe it... ;-)

Alf. You cannot use dynamic_cast on a fundamental type (a pointer to it).
It will not compile.

That is correct, but so what? You're trolling.

Depending on how difficult the code is they might just do it.

Perhaps. I'm not sure. I think at least my statement about compile
time evaluation was not properly qualified... :-(

Much better if you had raised that issue, then I could have said,
whoops, instead of pointing out inconsistencies and such.

Ahha. I do not understand what you are saying, so I agree with you and look
smart.

The code above is an actual implementation.

Compiled with VC7 and g++ 3.2.3.

...
Do not take this tone with me young man. I do not know how much I know
about C++ (I know it is not enough) but it was enough to be invited to work
with the C++ comittee. Not an official invitation (I am not that good) but
several people (names you see every day on clc++mod) has expressed that they
think it is a good idea for me to be there and contribute. IMHO (since some
of these people know me personally, some others from newsgroups and mail)
this should mean something and I am proud of it. And I do not accept this
tone - not even from an online friend. Of course they might just tell me to
go there so that they can beat me up.

Heh, young man indeed. Thank you. Now if you could just stop trolling.

I really do not want to argue this. You are right in that dynamic_cast (in
special cases) can be used with non-polymorph class types as well. No
argument about that. So if you feel that you want to stop the pssing
contest let me know. I would mail you asking to help me with something C++
related - but I am not going to mail without your consent. (It is not
programming and it is not (I think) to much time.) Let me know.

Mail away... At least I'll answer "no time" if it seems too much.

 

[White Wolf]

So what? Kevin, not the OP, made a statement about _polymorphic_
types. That statement was incorrect and irrelevant.

That part of the statement was incorrect. But then again you can see that
statement in quite a few places and IMO what other possible uses I have seen
in the standard there you need no cast.

Yep. But not very relevant to anything... ;-)

Did you note the example code?

Did you note my (cut out by you) statement about (non existing) template
functions and the possibility to specialize function templates?

Oh yes he can. I already gave explicit code for that. It's not the
easiest way to do it, though.

Not and IMHO it is absolutely unnecessary. You create a template code bloat
to support an absolutely wrong approach to programming (note to the reader:
not all compilers will just forget about instantiated templates, even if
they are inline).

The solution works, but it is IMHO way overcomplicated.

The message was, quoting: "dynamic_cast is only for polymorphic
types".
And that's simply not true.

The full message was: ", not doubles, floats, etc;" I think it is an
important part of it. And I believe that Kevin did not think that you will
come up with a two-pairs-of-template solution, out of which each will be
instantianed for all types ever used in that original function template as
well as for all the checked types - even if they never get used.

Hm. That means you didn't previously understand that a dynamic_cast,
like the code I presented, is a technically correct solution to the
OP's problem?

I understand that code. it works. It is also good for an obfuscated code
contest. IMHO it is way to overcomplicated. The OP needs to factor out
that type dependent part of his code into another function template (sort of
template method with templates way) and specialize this little piece for the
special ones, while giving a generic solution to all the others.

In the example code above, 'myArg' can be of a fundamental type.

The usage example checks for fundamental type 'float'.

Try it out if you don't believe it... ;-)

I believe it. I just do not think that this is a solution to be considered.

That is correct, but so what? You're trolling.

Alf, you are trolling and flaming. Stop the nonsense.

Perhaps. I'm not sure. I think at least my statement about compile
time evaluation was not properly qualified... :-(

As I saw in the standard it makes no statement about this issue at the
dynamic_cast pages. I am not sure if the standard ever says anything like
that.

Much better if you had raised that issue, then I could have said,
whoops, instead of pointing out inconsistencies and such.

Ahha. How is this 70ties thing? Whatever.

The code above is an actual implementation.

Compiled with VC7 and g++ 3.2.3.

Yep. It is. Who do you think would maintain a code like that? if (are you
crazy) handlecrazy; else if (are you flower) smellit(); else if (are you
hot) doher();...

Heh, young man indeed. Thank you. Now if you could just stop
trolling.

Go to hell Alf. And I say this with all the love in my hearth.

Mail away... At least I'll answer "no time" if it seems too much.

Oh. How nice of you. I will see if I have time to mail you. For those who
don't get it (as you seem): I have offered you a possible cooperation in
case you want to stop the pissing contest. I do not see that from your
post.

I was not humiliating myself but giving you a this opportunity as a token of
appreciation and a way to end this rather awkward tension I have experienced
from yout tone. Now as I see you do not really give me any kind of respect
here and do not stop your pissing contest and do nto stop repeating that I
troll. I do *not* appreciate this. So I think I will just stick with my
original reviewer. He has also promised that he will help if he has time.
He wrote a book about C++. And he has another important connection to the
language... Anyway: have fun. I do no really get it why do you keep
kicking everyone around here today, but I think I will chose not to
experience your attitude anymore.

 

[Alf P. Steinbach]

That part of the statement was incorrect. But then again you can see that
statement in quite a few places and IMO what other possible uses I have seen
in the standard there you need no cast.


Did you note my (cut out by you) statement about (non existing) template
functions and the possibility to specialize function templates?

No, I didn't see that. What's that got to do with anything?

Not and IMHO it is absolutely unnecessary. You create a template code bloat
to support an absolutely wrong approach to programming (note to the reader:
not all compilers will just forget about instantiated templates, even if
they are inline).

In other words, he _can_ use dynamic cast, as you've stated
repeatedly he cannot.

E.g. as shown in the example code earlier in this thread.

Other methods are better, though.

...
Yep. It is. Who do you think would maintain a code like that? if (are you
crazy) handlecrazy; else if (are you flower) smellit(); else if (are you
hot) doher();...

How to do that was the technical question.

Whether it's a good idea or not, that can't be answered without
more information about the context of the question.

Go to hell Alf. And I say this with all the love in my hearth.

That's an invitation to a "devastating" response, commonly
called trolling -- can't you just stop trolling?

 

[White Wolf]

That's an invitation to a "devastating" response, commonly
called trolling -- can't you just stop trolling?

Welcome to my killfile.