• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 21 subscribers
  • Views 3176 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange compilier's behaviour with function template, NAN and default parameter

kyb

I have got an error message with next code

template< typename Type >
int func( Type as, float fl=NAN );

error:  #109: expression preceding parentheses of apparent call must have (pointer-to-) function type

It seems the problem is with resolving NAN, defined in math.h at line 249

#   define NAN (__ESCAPE__(0f_7FC00000))

There is no problem if no NAN used

template< typename Type >
int func( Type as, float fl=0 );

There is no problem if template not used

int func( int as, float fl=NAN );

There is no problem with GCC.

Compilier version

*** Using Compiler 'V5.05 update 2 (build 169)'

Parents
  • 0 in reply to edPer Westermark

    Ah - so basically it already is a no-op.

    Not quite. ARM wouldn't have to go this far out of their way just to create a no-op. Just writing nothing at all would have the same effect.

    And with another compiler:

    int func( Type as, float fl= );

    No. With any other compiler, you get.

    int func( Type as, float fl= __ESCAPE__(0f_7FC00000) );

    What that actually turns into depends entirely on what the user of the alien compiler decides to #define __ESCAPE__ as to fix this obvious syntax error.

    But OTOH that alien compiler would surely come with its own <math.h>. So there should never be a need to pull in the one from ARMCC's system include file collection.

    Using another implementation's Standard C Library headers is a Bad Thing, and one should fully expect bad things to happen because of it. As I take it, this macro may be just an elaborate, circuitous way of expressing "Here Be Dragons".

Reply
  • 0 in reply to edPer Westermark

    Ah - so basically it already is a no-op.

    Not quite. ARM wouldn't have to go this far out of their way just to create a no-op. Just writing nothing at all would have the same effect.

    And with another compiler:

    int func( Type as, float fl= );

    No. With any other compiler, you get.

    int func( Type as, float fl= __ESCAPE__(0f_7FC00000) );

    What that actually turns into depends entirely on what the user of the alien compiler decides to #define __ESCAPE__ as to fix this obvious syntax error.

    But OTOH that alien compiler would surely come with its own <math.h>. So there should never be a need to pull in the one from ARMCC's system include file collection.

    Using another implementation's Standard C Library headers is a Bad Thing, and one should fully expect bad things to happen because of it. As I take it, this macro may be just an elaborate, circuitous way of expressing "Here Be Dragons".

Children