Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

sprinter_trueno

Disadvantages of macros

This topic is 5384 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi ppl, I am trying to collect pros and cons regarding the replacement of functions by macros. For example checking a state or flag of a module or object by using a getter function and doing the same by declaring the same variable extern in the header and using a macro to access it. What I found so far is: Cons: - No type-safety - Dangerous access to the data - No symbols are created for macros (how do you create a library using macros ?) - Makes the header ugly Pros: - Faster to do - Less code - Better performance Is there more ? Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by sprinter_trueno
- Faster to do
- Less code

These are pretty much the same.
quote:
- Better performance
This isn't correct, as inline functions are as fast as macros.

And I'd add one 'con':
- macros can be anywhere. Short macro names can make lots of working code broken.

I remember making a member function named "max" but simply defining this function (or was it calling) would cause a compiler error as some windows header already defined max as a macro. I had to add
#undef max
#undef min
for the code to work. Macros should have more features [*] and adhere to namespace rules, so they could be more useful. Currently, their use is recommended only in situations where functions and constants won't do. (e.g. macro that defines a function)

[*] Don't ask me


[edited by - civguy on September 22, 2003 4:23:23 AM]

Share this post


Link to post
Share on other sites
Pros: Better chance of winning the IOCCC.
Cons: this.

Could you elaborate on the point of no symbols being created for macros? I can think of at least one thing that only uses macros, and it seems to be doing just fine.

Share this post


Link to post
Share on other sites
Thanks for the input so far.

civguy:

Of course inline is as fast but if your compiler doesn''t support the typical inline functionality, a macro might be the only way to speed things up.

quote:

Pros: Better chance of winning the IOCCC.
Cons: this.



nice

quote:

Could you elaborate on the point of no symbols being created for macros?



Well, lets say I wanna have the address (symbol) of the function, hence to call it through a function pointer, then I simply have a problem ''cause there is none.

Thanks so far.

Share this post


Link to post
Share on other sites
Con:

If you use them too much, you''ll slow down your program, a lot.

Unlike functions, macros get pasted in everywhere you use them. Each reference to a function is a few bytes of code to call a single instance. Each macro is the entire function written out. This can cause your compiled code to become huge, resulting in frequent cache misses. For instance if you have a loop whose code is too large to fit in cache (typical consumer P4 has only 8KB of L1 cache for instance) you''ll be getting a cache miss several times for every iteration, causing the processor to stall while it loads the next section. The cost of a calling a function is almost nothing (because of some creative engineering the P4 can actually do some conditional jumps in *0* cycles by tagging correctly predicted jumps onto the instruction before them), so I''d really advise using them and letting the compiler decide when it can and should inline them.

Share this post


Link to post
Share on other sites
Macros don''t respect C++ namespaces, they can''t be overloaded, and they can potentially evaluage their arguments more (or less!) than once.

On the other hand, inline functions can''t textually symbol-mash their arguments and the like.

I''m hip because I say "M$" instead of "MS".

Share this post


Link to post
Share on other sites
i use macros to generate strings as in assert, to get the string of the statements.... and thats about all i use it for (and __LINE__ and __FILE__ and the like..)..




If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

Share this post


Link to post
Share on other sites
quote:
Original post by sprinter_trueno
What I found so far is:

Cons:

- No type-safety


I don''t really see why this is a con... it can also be a pro

quote:
- Dangerous access to the data


what do you mean by? O_o
a macro is just copy-pasted in you code by the preprocessor...

quote:
- No symbols are created for macros (how do you create a library using macros ?)


they aren''t made to be used for that... and can''t... if you want a symbol to be created, you use a function...

quote:
- Makes the header ugly


mmh, that''s very subjective... it much depends on your coding style. I think they make them look nicer actually

quote:

Pros:
- Faster to do
- Less code


depends.. less code for you to write, but often much more compiled code at the end, depends how you use them, and what for..

quote:
- Better performance


again, depends how you use them.
they can produce a worse execution performance.
and generally, when you use lots of macros (and imbricated macros), your compile time jumps up quite a bit

Beer Hunter> your first example is one of the worse things I''ve ever seen
your second example isn''t an example of how macros are crap, but an example of how macros are crap when ppl use them improperly...

quote:

And I''d add one ''con'':
- macros can be anywhere. Short macro names can make lots of working code broken.


yes they can, it''s up to you to write them in the correct headers so they aren''t "anywhere"

quote:
I remember making a member function named "max" but simply defining this function (or was it calling) would cause a compiler error as some windows header already defined max as a macro. I had to add
#undef max
#undef min
for the code to work. Macros should have more features [*] and adhere to namespace rules, so they could be more useful. Currently, their use is recommended only in situations where functions and constants won''t do. (e.g. macro that defines a function)



that''s again because your coding style isn''t strict enough...
personally, all my macros are uppercase, and my function/variable names lowercase. that way, I see immediately when something is a macro or not, and I haven''t got any kind of conflicts.

quote:
Well, lets say I wanna have the address (symbol) of the function, hence to call it through a function pointer, then I simply have a problem ''cause there is none.



then you use a function and not a macro... macros can''t be used as functions, they are completely different things, how can you even expect them to behave the same???

quote:
Con:

If you use them too much, you''ll slow down your program, a lot.

Unlike functions, macros get pasted in everywhere you use them. Each reference to a function is a few bytes of code to call a single instance. Each macro is the entire function written out. This can cause your compiled code to become huge, resulting in frequent cache misses. For instance if you have a loop whose code is too large to fit in cache (typical consumer P4 has only 8KB of L1 cache for instance) you''ll be getting a cache miss several times for every iteration, causing the processor to stall while it loads the next section. The cost of a calling a function is almost nothing (because of some creative engineering the P4 can actually do some conditional jumps in *0* cycles by tagging correctly predicted jumps onto the instruction before them), so I''d really advise using them and letting the compiler decide when it can and should inline them.



again, macros shouldn''t be used for everything everywhere, that would be stupid... the main advantage of macros is to make life easier for the programmer...

quote:
Macros don''t respect C++ namespaces, they can''t be overloaded, and they can potentially evaluage their arguments more (or less!) than once.



and ?
you''re comparing macros with things they can''t be compared with...

oh damm functions are complete crap, you can''t do something like this that will run at the same speed after compilation:

#define TOTO(a, b) a ## b
#define TATA(a, b) TOTO(a, b)
#define TITI(x) TATA(0x, x)



Share this post


Link to post
Share on other sites
Macros are not aware of C++ syntax. For instance, this code fragment will produce errors:

#define PRINTTYPE(x) printf("%s", #x)

...

PRINTTYPE(std::map<int, bool>);



How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!