Re: Use a suffix or a type cast?

Ben C schrieb:
On 2006-07-06, Hamish M <hammer1234@xxxxxxxxxxxxxx> wrote:

Hi I am interested in opinions on this topic.

I have heard that a suffix is not a good solution and type casts are
much better

for example.

-----------------------------------------------------------------
#define MAX_UWORD (T_UWORD)65535

or

#define MAX_UWORD 65535u

-------------------------------------------------------------------

Where UWORD is unsigned short int.

What is your opinion? or why would someone have said using a suffix is
no good?


I once worked on a library where we used a lot of doubles, and wrote
constants of the kind:

#define ONE 1.0

We already had a typedef:

typedef double Real;

Then we ported to a machine with fast single precision fp, but slow
software-only doubles, so we changed the typedef:

typedef float Real;

So far so good. But whenever we used the constants, since they were
double precision, we ended up with everything being promoted to double
and a lot of slow software double-precision computation which we didn't
want.

What we needed of course was:

#define ONE 1.0f

But much easier than faffing with macros to try and achieve that was:

#define ONE ((Real) 1.0)

Now all the constants automatically pick up the same type as the
typedef.

So, I'd say, when you want a constant of a type that you want to
typedef, it works well to use a cast in the macro rather than a suffix.

The alternative: Whenever you create a typedef for a numeric type,
also provide the appropriate <TYPE>_C macro.

With
typedef float Real;
#define REAL_C(constant) constant##F
your symbolic constant is defined as
#define ONE REAL_C(1.0)
If you need the printf() family, appropriate conversion
and length modifier plus conversion macros should be defined
as well.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
.

Relevant Pages

  • Re: Use a suffix or a type cast?
    ... I have heard that a suffix is not a good solution and type casts are ... We already had a typedef: ... software-only doubles, ...
    (comp.lang.c)
  • Re: Is there a convention mandating macros to be all-uppper-case?
    ... typedef std::wstring tstring; ... to keep namespaces intact. ... Macros are even worse, because they make the substitution completely blindly, without any consideration to their real meaning. ... At least with typedef, you can be sure it's not going to disrupt types in other namespaces, member functions in other classes, etc. ...
    (microsoft.public.vc.language)
  • Re: Why we should (not?) have closures after all
    ... A typedef facility will allow programmers to use ... expressiveness, further decreasing maintenance costs. ... C macros are particularly limited, but a real macro facility is ... how to prevent programmers from doing bad things. ...
    (comp.lang.java.programmer)
  • Re: Operational and functional differences - #define vs typedef ?
    ... Most syntax checking and parsing occurs *after* macros are ... A typedef creates an alias for a type. ... type declarations is such that a macro isn't always going to work. ...
    (comp.lang.c)
  • Alternatives for redefining a typedef?
    ... The PROPERTY macros ... A typedef inside BEGIN_CLASS is almost good, ... BEGIN_CLASS would redefine ThisClass, causing a compile error. ... functions, and be redefined later, and also be used as a template ...
    (comp.lang.cpp)
Loading