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]

Re: Function template checking

On 16 Sep 2003 01:23:30 -0700, skg@fluent.co.i n (Surya Kiran) wrote:
[color=blue]
>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)?[/color]

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]

Re: Function template checking

Surya Kiran wrote:[color=blue]
> 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) ??[/color]

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

--
Attila aka WW

[Kevin Saff]

Re: Function template checking


"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f66cac8.3 30783875@News.C IS.DFN.DE...[color=blue]
> On 16 Sep 2003 01:23:30 -0700, skg@fluent.co.i n (Surya Kiran) wrote:
>[color=green]
> >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)?[/color]
>
> Yes.
>
> The easiest I think would be dynamic_cast of pointers, which in this
> context would not be a runtime operation.[/color]

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]

Re: Function template checking

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

[Alf P. Steinbach]

Re: Function template checking

On Tue, 16 Sep 2003 14:15:28 GMT, "Kevin Saff" <google.com@kev in.saff.net> wrote:
[color=blue]
>
>"Alf P. Steinbach" <alfps@start.no > wrote in message
>news:3f66cac8. 330783875@News. CIS.DFN.DE...[color=green]
>> On 16 Sep 2003 01:23:30 -0700, skg@fluent.co.i n (Surya Kiran) wrote:
>>[color=darkred]
>> >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)?[/color]
>>
>> Yes.
>>
>> The easiest I think would be dynamic_cast of pointers, which in this
>> context would not be a runtime operation.[/color]
>
>No, dynamic_cast is only for polymorphic types, not doubles, floats, etc;[/color]

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.


[color=blue]
>typeid works for nonpolymorphic types at compile time:[/color]

Wow.

[color=blue]
>I agree with another poster that specialization is preferable.[/color]

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]

Re: Function template checking

Alf P. Steinbach wrote:[color=blue][color=green][color=darkred]
>>> The easiest I think would be dynamic_cast of pointers, which in this
>>> context would not be a runtime operation.[/color]
>>
>> No, dynamic_cast is only for polymorphic types, not doubles, floats,
>> etc;[/color]
>
> That's both incorrect and irrelevant (great work).[/color]

It is correct and relevant.
[color=blue]
> 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.[/color]

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) ??
)))
[color=blue][color=green]
>> typeid works for nonpolymorphic types at compile time:[/color]
>
> Wow.[/color]

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.
[color=blue][color=green]
>> I agree with another poster that specialization is preferable.[/color]
>
> And that's twice incorrect (great work, again!).[/color]

Nope Alf, wrong again.
[color=blue]
> First, no-one except you have said that.[/color]

Really???? AM I A NO-ONE???

http://www.google.com/groups?safe=off&ie=UTF-8&oe=UTF-8&as_umsgid=%3Cbk6j7r%246pl%241@newstree.wise.edt.ericsson.se%3E&lr=&hl=en

http://tinyurl.com/nl14

[color=blue]
> Second, specialization is not a technique for finding out types from
> within the function (the OP's question).[/color]

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.
[color=blue]
> 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.[/color]

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.

--
WW aka Attila

[Alf P. Steinbach]

Re: Function template checking

On Tue, 16 Sep 2003 22:37:04 +0300, "White Wolf" <wolof@freemail .hu> wrote:
[color=blue]
>Alf P. Steinbach wrote:[color=green][color=darkred]
>>>> 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;[/color]
>>
>> That's both incorrect and irrelevant (great work).[/color]
>
>It is correct and relevant.[/color]

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


[color=blue][color=green]
>> 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.[/color]
>
>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![/color]

Hallelujah, a correct statement.


[color=blue]
>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.[/color]

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


[color=blue]
>(((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) ??
>)))
>[color=green][color=darkred]
>>> typeid works for nonpolymorphic types at compile time:[/color]
>>
>> Wow.[/color]
>
>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,[/color]

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).


[color=blue]
> that you even forget C++?[/color]

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


[color=blue]
>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.[/color]

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<C heck<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.

[color=blue][color=green][color=darkred]
>>> I agree with another poster that specialization is preferable.[/color]
>>
>> And that's twice incorrect (great work, again!).[/color]
>
>Nope Alf, wrong again.
>[color=green]
>> First, no-one except you have said that.[/color]
>
>Really???? AM I A NO-ONE???
>http://www.google.com/groups?safe=of...e%3E&lr=&hl=en
>
>http://tinyurl.com/nl14[/color]

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


[color=blue][color=green]
>> Second, specialization is not a technique for finding out types from
>> within the function (the OP's question).[/color]
>
>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.
>[color=green]
>> 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.[/color]
>
>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.[/color]

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]

Re: Function template checking

Alf P. Steinbach wrote:[color=blue]
> On Tue, 16 Sep 2003 22:37:04 +0300, "White Wolf" <wolof@freemail .hu>
> wrote:
>[color=green]
>> Alf P. Steinbach wrote:[color=darkred]
>>>>> 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).[/color]
>>
>> It is correct and relevant.[/color]
>
> Bah. It's not correct (dynamic_cast is not limited to polymorphic
> types, as you _yourself_ point out below), and it's not relevant.[/color]

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) ??>>>

[color=blue][color=green][color=darkred]
>>> In that case I require relevant quotes from the C++ _standard_
>>> regarding
>>> the correctness of the statement, and discussion of its relevance.[/color]
>>
>> 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![/color]
>
> Hallelujah, a correct statement.[/color]

It is, isn't it?
[color=blue][color=green]
>> 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.[/color]
>
> Don't troll -- Kevin talked about dynamic casts of float etc., not
> I;
> I said dynamic cast _of pointers_.[/color]

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.
[color=blue][color=green]
>> 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,[/color]
>
> 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).[/color]

It was correct. :-) The message was: you cannot use dynamic_cast on
pointers to fundamental types. And you cannot.
[color=blue][color=green]
>> that you even forget C++?[/color]
>
> I didn't forget any C++. You pretend that you did (you're trolling
> again). See above, and below.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> Yes, it can, e.g.[/color]

No, it cannot.
[color=blue]
> template< typename T > struct Check { virtual Check* x(){ return
> this; } };
>
> template< typename T, typename U >
> bool isType( U const& arg )
> {
> return (dynamic_cast<C heck<T>*>( Check<U>().x() ) != 0);
> }
>
>
> ...
> if( isType<float>( myArg ) )
> {
> ...
> }[/color]

What does this have to do with the OPs question about _fundamental_ types?
[color=blue]
> Kevin was right that type-info is simpler, but for all the wrong
> reasons, including directly incorrect statements.[/color]

Alf. You cannot use dynamic_cast on a fundamental type (a pointer to it).
It will not compile.
[color=blue]
> I think I was wrong that current compilers probably will optimize this
> to compile-time, but then, can't be right _all_ the time... ;-)[/color]

Depending on how difficult the code is they might just do it.
[color=blue]
> Nothing
> like an actual implementation when discussing optimizations. I don't
> do that for every little posting here, though.[/color]

Ahha. I do not understand what you are saying, so I agree with you and look
smart. :-)
[color=blue][color=green][color=darkred]
>>>> I agree with another poster that specialization is preferable.
>>>
>>> And that's twice incorrect (great work, again!).[/color]
>>
>> Nope Alf, wrong again.
>>[color=darkred]
>>> First, no-one except you have said that.[/color]
>>
>> Really???? AM I A NO-ONE???
>>[/color][/color]
http://www.google.com/groups?safe=of...e%3E&lr=&hl=en[color=blue][color=green]
>>
>> http://tinyurl.com/nl14[/color]
>
> I didn't realize you meant such a stupid thing. Oh well.[/color]

??????? Alf. Don't do this please. Do not flame.
[color=blue]
> Wow. Did you know, C++ has a type called 'int'?[/color]

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. :-)
[color=blue]
> Stop trolling, and even if you don't, at least stop using all caps.[/color]

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.

--
WW aka Attila

[Alf P. Steinbach]

Re: Function template checking

On Tue, 16 Sep 2003 23:53:27 +0300, "White Wolf" <wolof@freemail .hu> wrote:
[color=blue]
>Alf P. Steinbach wrote:[color=green]
>> On Tue, 16 Sep 2003 22:37:04 +0300, "White Wolf" <wolof@freemail .hu>
>> wrote:
>>[color=darkred]
>>> Alf P. Steinbach wrote:
>>>>>> 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).
>>>
>>> It is correct and relevant.[/color]
>>
>> Bah. It's not correct (dynamic_cast is not limited to polymorphic
>> types, as you _yourself_ point out below), and it's not relevant.[/color]
>
>Bah. The OP asked for *fundamental* types:[/color]

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


[color=blue][color=green][color=darkred]
>>>> 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![/color]
>>
>> Hallelujah, a correct statement.[/color]
>
>It is, isn't it?[/color]

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

Did you note the example code?


[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>> Don't troll -- Kevin talked about dynamic casts of float etc., not
>> I;
>> I said dynamic cast _of pointers_.[/color]
>
>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.[/color]

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


[color=blue][color=green][color=darkred]
>>> 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,[/color]
>>
>> 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).[/color]
>
>It was correct. :-) The message was: you cannot use dynamic_cast on
>pointers to fundamental types. And you cannot.[/color]

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



[color=blue][color=green][color=darkred]
>>> that you even forget C++?[/color]
>>
>> I didn't forget any C++. You pretend that you did (you're trolling
>> again). See above, and below.[/color]
>
>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.[/color]

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?

[color=blue]
>[color=green][color=darkred]
>>> 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.[/color]
>>
>> Yes, it can, e.g.[/color]
>
>No, it cannot.
>[color=green]
>> template< typename T > struct Check { virtual Check* x(){ return
>> this; } };
>>
>> template< typename T, typename U >
>> bool isType( U const& arg )
>> {
>> return (dynamic_cast<C heck<T>*>( Check<U>().x() ) != 0);
>> }
>>
>>
>> ...
>> if( isType<float>( myArg ) )
>> {
>> ...
>> }[/color]
>
>What does this have to do with the OPs question about _fundamental_ types?[/color]

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... ;-)



[color=blue][color=green]
>> Kevin was right that type-info is simpler, but for all the wrong
>> reasons, including directly incorrect statements.[/color]
>
>Alf. You cannot use dynamic_cast on a fundamental type (a pointer to it).
>It will not compile.[/color]

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


[color=blue][color=green]
>> I think I was wrong that current compilers probably will optimize this
>> to compile-time, but then, can't be right _all_ the time... ;-)[/color]
>
>Depending on how difficult the code is they might just do it.[/color]

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.


[color=blue][color=green]
>> Nothing
>> like an actual implementation when discussing optimizations. I don't
>> do that for every little posting here, though.[/color]
>
>Ahha. I do not understand what you are saying, so I agree with you and look
>smart. :-)[/color]

The code above is an actual implementation.

Compiled with VC7 and g++ 3.2.3.


[color=blue]
> ...
>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. :-)[/color]

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


[color=blue]
>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.[/color]

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

[White Wolf]

Re: Function template checking

Alf P. Steinbach wrote:[color=blue]
> So what? Kevin, not the OP, made a statement about _polymorphic_
> types. That statement was incorrect and irrelevant.[/color]

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.
[color=blue][color=green][color=darkred]
>>>> GOT IT? Pointer to int, float, sink and other fundamental types
>>>> just do not
>>>> cut it!
>>>
>>> Hallelujah, a correct statement.[/color]
>>
>> It is, isn't it?[/color]
>
> Yep. But not very relevant to anything... ;-)
>
> Did you note the example code?[/color]

Did you note my (cut out by you) statement about (non existing) template
functions and the possibility to specialize function templates?
[color=blue][color=green][color=darkred]
>>> Don't troll -- Kevin talked about dynamic casts of float etc., not
>>> I;
>>> I said dynamic cast _of pointers_.[/color]
>>
>> 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.[/color]
>
> Oh yes he can. I already gave explicit code for that. It's not the
> easiest way to do it, though.[/color]

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 .
[color=blue][color=green]
>> It was correct. :-) The message was: you cannot use dynamic_cast on
>> pointers to fundamental types. And you cannot.[/color]
>
> The message was, quoting: "dynamic_ca st is only for polymorphic
> types".
> And that's simply not true.[/color]

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.
[color=blue]
> 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?[/color]

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.
[color=blue][color=green]
>> What does this have to do with the OPs question about _fundamental_
>> types?[/color]
>
> 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... ;-)[/color]

I believe it. I just do not think that this is a solution to be considered.
[color=blue][color=green][color=darkred]
>>> Kevin was right that type-info is simpler, but for all the wrong
>>> reasons, including directly incorrect statements.[/color]
>>
>> Alf. You cannot use dynamic_cast on a fundamental type (a pointer
>> to it). It will not compile.[/color]
>
> That is correct, but so what? You're trolling.[/color]

Alf, you are trolling and flaming. Stop the nonsense.
[color=blue]
> Perhaps. I'm not sure. I think at least my statement about compile
> time evaluation was not properly qualified... :-([/color]

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.
[color=blue]
> Much better if you had raised that issue, then I could have said,
> whoops, instead of pointing out inconsistencies and such.[/color]

Ahha. How is this 70ties thing? Whatever. :-)
[color=blue][color=green][color=darkred]
>>> Nothing
>>> like an actual implementation when discussing optimizations. I
>>> don't
>>> do that for every little posting here, though.[/color]
>>
>> Ahha. I do not understand what you are saying, so I agree with you
>> and look smart. :-)[/color]
>
> The code above is an actual implementation.
>
> Compiled with VC7 and g++ 3.2.3.[/color]

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();...
[color=blue]
> Heh, young man indeed. Thank you. Now if you could just stop
> trolling.[/color]

Go to hell Alf. And I say this with all the love in my hearth.
[color=blue][color=green]
>> 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.[/color]
>
> Mail away... At least I'll answer "no time" if it seems too much.[/color]

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.

--
WW aka Attila

[Alf P. Steinbach]

Re: Function template checking

On Wed, 17 Sep 2003 00:52:38 +0300, "White Wolf" <wolof@freemail .hu> wrote:
[color=blue]
>Alf P. Steinbach wrote:[color=green]
>> So what? Kevin, not the OP, made a statement about _polymorphic_
>> types. That statement was incorrect and irrelevant.[/color]
>
>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.
>[color=green][color=darkred]
>>>>> GOT IT? Pointer to int, float, sink and other fundamental types
>>>>> just do not
>>>>> cut it!
>>>>
>>>> Hallelujah, a correct statement.
>>>
>>> It is, isn't it?[/color]
>>
>> Yep. But not very relevant to anything... ;-)
>>
>> Did you note the example code?[/color]
>
>Did you note my (cut out by you) statement about (non existing) template
>functions and the possibility to specialize function templates?[/color]

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

[color=blue][color=green][color=darkred]
>>>> 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.[/color]
>>
>> Oh yes he can. I already gave explicit code for that. It's not the
>> easiest way to do it, though.[/color]
>
>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).[/color]

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.

[color=blue]
> ...
>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();...[/color]

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.

[color=blue][color=green]
>> Heh, young man indeed. Thank you. Now if you could just stop
>> trolling.[/color]
>
>Go to hell Alf. And I say this with all the love in my hearth.[/color]

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

[White Wolf]

Re: Function template checking

Alf P. Steinbach wrote:[color=blue][color=green][color=darkred]
>>> Heh, young man indeed. Thank you. Now if you could just stop
>>> trolling.[/color]
>>
>> Go to hell Alf. And I say this with all the love in my hearth.[/color]
>
> That's an invitation to a "devastatin g" response, commonly
> called trolling -- can't you just stop trolling?[/color]

Welcome to my killfile.

--
WW aka Attila