Disadvantages of macros

Started by
16 comments, last by sprinter_trueno 20 years, 6 months ago
sBibi, read sprinter_trueno''s actual post, not the title of the thread. He is specifically looking for "pros and cons regarding the replacement of functions by macros". The comparisons others made between the two are valid for this thread.


- Houdini
- Houdini
Advertisement
Quite alot of input already !

thanks for the backup Houdini, seems like things get a little bit out of hand.

Of course doesn't mean that I do not appreaciate your views sBibi but...

quote: Original post by sBibi
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


I thought that Type-safety is a helpful feature (even though it can be a pain sometimes), how could it be a con ?

quote: Original post by sBibi
quote: Original post by sprinter_trueno

- Dangerous access to the data


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


The data becomes public, thus editable even though it might not have anything to do with the interface in the first place since it should originally only make up as a part of the implementation.

Bring it on

[edited by - sprinter_trueno on September 22, 2003 2:38:13 PM]
quote:Original post by Houdini
sBibi, read sprinter_trueno's actual post, not the title of the thread. He is specifically looking for "pros and cons regarding the replacement of functions by macros". The comparisons others made between the two are valid for this thread.


ok, my mistake then, I read that first sentence a bit too fast and focused more on the topic title... probably because I'm too much used to ppl saying macros are crap for everything... sorry if I went off topic

[edited by - sBibi on September 22, 2003 3:26:41 PM]
quote:Original post by sBibi
yes they can, it''s up to you to write them in the correct headers so they aren''t "anywhere"
So, you write code only for your personal use? Maybe then you won''t run into problems. But suppose everyone used macros a lot. Name clashes would start happening pretty soon and there''d be no namespaces to prevent it.
quote:
> [...] some windows header already defined max as a macro [...]

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.
I said a windows header. That means it was not written by me, as I don''t work for Microsoft. And I''m not going to e-mail MS and ask them to change max to MAX in windows.h (or somewhere deep within where it''s actually defined). Are you?
There are so many problems that macros can cause (many of which have been mentioned) that you almost always need to know the actual syntax of the macro to make sure you''re not calling it the wrong way. For example, if the macro involves a loop, then you can''t really use it as a term inside an expression.

This is fine if you''re writing the macro for yourself, because you know how the macro should be called. But it doesn''t work well if you want to have other people use your macro. Encapsulation means that you can call a function or something without needing to know how it works, and macros definitely don''t have that.

When I use macros, I do it to simplify a piece code that has complicated or repeated expressions. And I ALWAYS #undef a macro when I''m done with it. If I was going to write a piece of code that was available from multiple parts of the program, it would always be a function, never a macro.
quote:So, you write code only for your personal use? Maybe then you won''t run into problems. But suppose everyone used macros a lot. Name clashes would start happening pretty soon and there''d be no namespaces to prevent it.


well, if I had to write a lirbary that would be used by other people, I would use prefixes for all my functions/macros. and keep everything C-compliant.
look at CG or OpenGL names, that''s good examples of what I think is right to do when choosing names... but unfortunately not everyone does this...

quote:I said a windows header. That means it was not written by me, as I don''t work for Microsoft. And I''m not going to e-mail MS and ask them to change max to MAX in windows.h (or somewhere deep within where it''s actually defined). Are you?


ok, and no, I won''t, even if I really would like to... I''ve been _really_ ticked of with win32 API headers some time ago actually...
they''re the perfect example of headers that don''t use prefixes and that don''t seem to care about them... they appropriate themselves common names such as UINT or BOOL or BYTE or HANDLE, that should be left for the end application... not used by a library/api... I really hate that. (except for the standard C library)

and I didnt''t know they defined max, maybe because it''s a function you will find in unix''s math.h library? some kind of compatibility?

quote:This is fine if you''re writing the macro for yourself, because you know how the macro should be called. But it doesn''t work well if you want to have other people use your macro


that''s what documentations are made for isnt''it? or functions/macros descriptions in header files...

and I don''t think macros can replace functions in the first place... there are much more cons than pros for this usage...
quote:Original post by sBibi
that''s what documentations are made for isnt''it? or functions/macros descriptions in header files...


So you think that undocumented macros are more dangerous to advance with than undocumented functions ? (Might be a con)

quote:Original post by sBibi
and I don''t think macros can replace functions in the first place...


Well, that''s one of my thoughts and one of the reasons why I started this thread.

quote:Original post by sBibi
there are much more cons than pros for this usage...


If you have more than already posted here, then feel free to enlighten me (us). Thanks.


quote:So you think that undocumented macros are more dangerous to advance with than undocumented functions ? (Might be a con)


no, I think it is a good habit to comment both in a documentation file. that's what I do, even for my own functions and macros, and when I don't remember exactly how to use one, I find it much faster to go and have a look into a well organized html documentation rather than search the information in a header lost somewhere in the project directories


quote:If you have more than already posted here, then feel free to enlighten me (us). Thanks.


I said I thought there is more cons than pros, not that there is more cons than the cons you listed... that implies that I don't see some of your "pros" as real pros:

- Less code
as said before, more code at the end

- Better performance
same if inlined functions are used, as someone else said in the thread, and in some cases worse...

[edited by - sBibi on September 23, 2003 9:58:16 AM]

This topic is closed to new replies.

Advertisement