Sign in to follow this  
darkzerox

define vs typedef

Recommended Posts

Sneftel    1788
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.

The object code produced by the two will be identical.

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by darkzerox
ah. but it wouldn't be ever so slightly slower, or consume more memory then?


They both have absolutely no impact on preformance and do not consume memory. The difference is the former does not respect the semantics of the language (as is the case with the pre-processor) as it simply subsutuites text while the later is part of the language and does respect it.

typedef creates a type alias, it can be used in part of template meta-programming for type computations at compile-time. You can't really do that with the former.

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by darkzerox
ah. but it wouldn't be ever so slightly slower, or consume more memory then?

No. Why would it?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
I LOVE MACROS!!!! :P I use them in every game i create for example
#define SPRITE_BALL 0
#define SPRITE_PADDLE 0

and plus I think thats how microsoft defines all of its customized variable type names. and macros are replaced with their value at run time, so its like an inline function, except it holds a value, you should consider useing typedefs in certain instances because of the fact of the previous post

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by Anonymous Poster
#define SPRITE_BALL 0
#define SPRITE_PADDLE 0

O_O

Tell me, AP. Does the term "enumeration" mean anything to you?
Quote:
and plus I think thats how microsoft defines all of its customized variable type names.

They used to, yes. That is one of the big reasons why the win32api is so ugly to use.
Quote:
and macros are replaced with their value at run time,
No they aren't.
Quote:
so its like an inline functio
No it isn't.
Quote:
except it holds a value
No it doesn't.
Quote:
you should consider useing typedefs in certain instances because of the fact of the previous post
Hey, good idea.

Share this post


Link to post
Share on other sites
pragma Fury    343
Quote:
Original post by Anonymous Poster
I LOVE MACROS!!!! :P I use them in every game i create for example
#define SPRITE_BALL 0
#define SPRITE_PADDLE 0

and plus I think thats how microsoft defines all of its customized variable type names. and macros are replaced with their value at run time, so its like an inline function, except it holds a value, you should consider useing typedefs in certain instances because of the fact of the previous post


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;


You'll get exactly the same outcome, and you won't run into any problems because of the #defines.

Edit: And since when was MS's way of doing things the right way? They put a lot of thought into C# and their design for the .NET library interfaces, and you'll note that you can't do this anymore...

Share this post


Link to post
Share on other sites
Zahlman    1682
Quote:
Original post by Sneftel
Quote:
and macros are replaced with their value at run time,
No they aren't.
Quote:
so its like an inline functio
No it isn't.
Quote:
except it holds a value
No it doesn't.


Quoted for being concise and accurate pwnage.

Share this post


Link to post
Share on other sites
darookie    1441
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]

Share this post


Link to post
Share on other sites
deadimp    310
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 registered
ID 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 objects
OBJECT_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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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;

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Sneftel    1788
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.)

Share this post


Link to post
Share on other sites
TheRealMAN11    142
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_FUNCTIONS
crappy_type crap_func(crappy_type crap_arg1);
#endif


Sure templates might require you to use your brain a little more but who cares.

Share this post


Link to post
Share on other sites
Aiursrage2k    320
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);

Share this post


Link to post
Share on other sites
snk_kid    1312
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.

Share this post


Link to post
Share on other sites
JohnBolton    1372
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.

Share this post


Link to post
Share on other sites
Monder    993
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.

Share this post


Link to post
Share on other sites
deadimp    310
TheRealMAN11 >> Well, the reason I prefer macros over inline functions and templates and such, is that it is simply a, in a way, text replacement. Therefore, you have some more basic freedoms with macros. Unless I'm mistaken, inline functions can't exactly declare new functions or variables, can they?
I think I will leave the rest up to these words: Preference-Depedent.


EDIT: Along with the messiness [i or y?] as JohnBolton states comes ways to fix these little errors. Just keep in mind that this will work properly:
#define getmax(a,b) ((a)>(b)?(a):(b))
However, there isn't really a point to using this macro because there aren't any real special circumstances that inline or template functions can't handle.
NOTE: I'm not sure about the entire point of my post though... heh.

Share this post


Link to post
Share on other sites
darkzerox    112
*retracts his post*

didnt think such an arguement would occur over such a little question :p

guess thats what happens when people start debating the ever dreaded "define"

Share this post


Link to post
Share on other sites
AcePilot    252
I am assuming you are using the define keyword for variables. For me, it is
really a matter of preference, for example


#define MATRIX_def float[4][4]
typedef float MATRIX_tdef[4][4];

// MATRIX_def uses #define, while MATRIX_tdef is a typedef.

MATRIX_tdef mul(MATRIX_tdef a, MATRIX_tdef b)
{
MATRIX_tdef ret;
ret = a * b;// Dont try this code out, the multiplication operator wont work
return ret;
}

MATRIX_def mul(MATRIX_def a, MATRIX_def b)
{
MATRIX_def ret;
ret = a * b;// Dont try this code out, the multiplication operator wont work
return ret;
}




Both functions should work, after preprocessor-compilation, this is what the code should look like:



// preprocessor "#define" has been removed
typedef float MATRIX_tdef[4][4];



MATRIX_tdef mul(MATRIX_tdef a, MATRIX_tdef b)
{
MATRIX_tdef ret;
ret = a * b;
return ret;
}

float[4][4] mul(float[4][4] a, float[4][4] b)
{
float[4][4] ret;
ret = a * b;
return ret;
}
// MATRIX_def has been replaced by float[4][4]




So really, in my opinion, it doesnt really make a difference.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this