define vs typedef

Started by
21 comments, last by AcePilot 18 years, 11 months ago
This is yet another one of those cases where it depends on personal preference, and your situation. If you prefer to have more "freedom", you'd probably go with macros. If you need to have more accuracy and error checking, you'd probably go with the latter.
I personally prefer macros to typedefs simply because it is easier to memorize for me, plus you can make some pretty nifty functions with macros. Example:
//"CObject" is a base class for the objects to be registeredID object_register(CObject* (*_ptrFunc)(),string _name="",ID _parent=-1);#define OBJECT_REGISTER(name,class,parent) CObject* __NEW_##name() { return new class; } ID name=object_register(&__NEW_##name,#name,parent)//Note: This is in the declarations, not a function body.class CParent : public CObject { ... //Meat of class here};class CTimmy : public CParent { ... };//Register these objectsOBJECT_REGISTER(Parent,CParent,-1); //Declares: "CObject* __NEW_Parent()", and "ID Parent"OBJECT_REGISTER(Timmy,CTimmy,Parent); //Declares: "CObject* __NEW_Timmy()", and "ID Timmy"

As you can clearly see, this can NOT be acheived with any inline functions, therefore the macros are needed here.

Litany of precautions for supplial of source code snippets included here
"Litany" is teh roxors.
Projects:> Thacmus - CMS (PHP 5, MySQL)Paused:> dgi> MegaMan X Crossfire
Advertisement
Quote:Original post by Sneftel
No. Why would it?


just making sure :D
Quote:Original post by Sneftel
Yes. The difference is that you should never use macros when you can possibly avoid it. For instance, with the typedef, a programmer could have a variable somewhere named "byte" and it wouldn't cause problems; with the macro, it would be a syntax error. Also, a typedef can be placed in a namespace to avoid polluting the global scope; macros, in contrast, do not obey scoping rules.


Actually, wouldn't they both cause an error in that case? You'd just get a more descriptive error if you used a typedef.

Also, note that there is little difference in the posted example, however there's a bigger difference in:

#define pbyte unsigned char *
vs.
typedef unsigned char * pbyte;

If you don't see it, contemplate:
pbyte a, b;
Quote:Original post by darookie
Quote:Original post by pragma Fury
There is absolutely no reason to do this... You're much better off doing something like:
const static int SPRITE_BALL = 0;
const static int SPRITE_PADDLE = 0;

In C++ you would rather do this (assuming both constants really are to be declared locally):

namespace {
const int SPRITE_BALL = 0;
const int SPRITE_PADDLE = 0;
}

[wink]


In C you would rather do this:
#define SPRITE_BALL 0;
#define SPRITE_PADDLE 0;
because, in C, const means "read only" not "constant". Subtle difference, but it can make a difference. A const variable cannot (in C) be used in a context that expects a constant.
Quote:Original post by Anonymous Poster
Actually, wouldn't they both cause an error in that case? You'd just get a more descriptive error if you used a typedef.

You're correct. I had confused the typedef name-space with the struct name-space; the latter is separate from variables. For instance, the following compiles:
struct foo {};double foo;

(Of course, anybody who does this should be severely punished.)
Quote:Original post by deadimp
This is yet another one of those cases where it depends on personal preference, and your situation. If you prefer to have more "freedom", you'd probably go with macros. If you need to have more accuracy and error checking, you'd probably go with the latter.
I personally prefer macros to typedefs simply because it is easier to memorize for me, plus you can make some pretty nifty functions with macros. Example:
*** Source Snippet Removed ***
As you can clearly see, this can NOT be acheived with any inline functions, therefore the macros are needed here.

Litany of precautions for supplial of source code snippets included here
"Litany" is teh roxors.


That is pretty nasty. Macro functions suck. Sure they may work ok, but they completely bypass the language. Now in C there are times when macro functions are the only way to go, but in C++ templates, operator overloading, and a bunch of other stuff that makes c++ great, can completely replace macros and macro functions.

Now macro's still have their place, but more for like:

#ifdef USE_CRAPPY_FUNCTIONScrappy_type crap_func(crappy_type crap_arg1);#endif


Sure templates might require you to use your brain a little more but who cares.
It is foolish for a wise man to be silent, but wise for a fool.
A define is a preprocessor statement, so it will get replaced before the code is compiled, I think typedefs get compiled at run time. Defines can also be used for macros while typdef cant.

I dont see a problem with this... all its doing is saving you some typing, it doesnt require a function call

#define getmax(a,b) a>b?a:b
int x=5, y;
y = getmax(x,2);
Insufficent Information: we need more infromationhttp://staff.samods.org/aiursrage2k/
Quote:Original post by Aiursrage2k
I think typedefs get compiled at run time.


No it doesn't, there isn't even a compilation process going on at run-time in any case not in C/C++ that is.

Unless you mean macros are substituted just before compilation then yes but thats the whole point of the "pre-processor" but it makes relatively no difference.

At the end of the day if you want an alias for a type then use typedef thats what they are there for. Typedefs respect the language as they are part of the language they do not incur any cost, the pre-processor doesn't end of story.
Quote:Original post by Aiursrage2k
I dont see a problem with this... all its doing is saving you some typing, it doesnt require a function call

#define getmax(a,b) a>b?a:b
int x=5, y;
y = getmax(x,2);

Ooooh boy. Your macro demonstrates two classic macro bugs.

A quiz. What are the values of x and y in the following code?
    #define getmax(a,b) a>b?a:b    x = getmax(3&0xff, 5);    y = getmax(10, 5) * 10; 
If you think that x = 5 and y = 100, you get an F and you should never ever use macros.
If you think that x = 3 and y = 10, you get an A and probably already avoid using macros.

Of course, fixing this code is pretty trivial, but there are plenty of other problems with macros and that's why they always are so messy and complicated.
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
As a matter of interest can anyone come up with a way to implement what deadimp did without macros? To me it seems boiler plate code (such as deadimp's example) and conditional compiliation are the only things you'd actually need macros for.

Quote:all its doing is saving you some typing, it doesnt require a function call


An inlined templated version would basically give you the same code but as it's actually using features of the language rather than what is effectively a bind textual search-replace feature it's a better solution.

This topic is closed to new replies.

Advertisement