stefu,
honestly, in a lot of ways you are right -- there is nothing inherently wrong with using macros. The problem is more pragmatic. I *WISH* that while I was stepping through a macro-generated section of code, damn MSVC would offer me to auto-expand it so that I could see the code that it "sees" post-preprocessing.

But it doesn''t, and I can''t. So I get this cryptic garbage that is extremely inconvienent to debug and makes me curse the one who decided "Yes, a macro is appropriate here. It saves a few keystrokes, and no one will ever need to step through this!"

As an afterthought (I swear to god this is true), I was debugging today and ran across a suspicious macro that the author had commented as "This is somewhat complicated, if there is ever a problem, comment this out and uncomment the lines below." And below was a funcion call version, and within minutes I found the macro was at fault and my problem was solved. That is a good lesson to anyone who elects to go the macro route.

I am sure that there is often better way to do what I do with macros, without macros.. But as long as I am not highly professional I can take the easy way and use macros, and I often use very locally when there is much repetition of certain things. First I #define macro and then I use many times it just like in above example and then #undef it.

I am here to learn and was nice to ready your thoughts

I use the following two #defines to test whether our coding standard has been adhered to.

#define NULL 42
#define TRUE 0

I personally love macros and use them often.

"multiple argument evaluation is a problem"
Really? I''ve used many many arguments with no problems.

"multiple lines is a problem"
it''s so difficult to add an \ to continue onto the next line?

"no type-safety"
If you know what your doing this shouldn''t be a issue.
(The link on how "evil" macros are is down by the way..)

I''m not 100% sure but I''d think declaring things as const
or putting them as actual functions may have some extra load, wheras a #define is only considered at compile time..

"I want to see you debugging a programm full of those defines when your project is due,and every second you lose is fatal."
I don''t see how it''s different from any of the C++ code mentioned here. I can also write a program full of badly written classes and spend an equal amount of time debugging..

"I get cryptic garbage that is extremely inconvienent to debug"
Gcc has a nice little switch that will "translate"
your #defined code into it''s expanded-macro source..
It helps alot if you used macros and all hell broke loose,
and you need to know exactly what it expanded to.

"a good lesson to anyone who elects to go the macro route"
But you didn''t write it, he did. So he''s at fault.
If he knew how macros worked and actually tested it,
this couldn''t have happened.
He even states he doesn''t understand macros by what he said.
"Duh, if somethingz messed up it might be this.."
Yes.. very professional.. Why are you using this guys code??

quote:Original post by superpig

Hmm.. are you sure you can't get a listing out of the preprocessor? That would likely be a very useful thing to have...

You can with gcc (never used VC much), but if you include pretty much any standard header (iostream, stdio.h, whatever), you get reams and reams of code spit out at you.

[edited by - tortoise on August 20, 2003 1:06:58 PM]

quote:Original post by Anonymous Poster
GrinningGator: inline/__force inline only works in VS pro ed or?

I''m sorry, I don''t know if inline only works in VS pro or not. You''d have to check the docs on that, or maybe somebody with more experience will pipe up.

quote:Original post by Magmai Kai Holmlor
There are dozens of things macros can do that functions, even templated and/or inlined ones, cannot.

Very true. Perhaps I came across too strongly. There are of course times where macros are very useful and even desired. I have even been known to use them in my own code. But there are many common usages (many illustrated in this thread) where they offer no advantage and many dangers. I have learned this first hand and only seek to pass on my limited knowledge so that others can avoid my mistakes.

quote:Original post by stefu
It could be dangerous, but I am programmer!

I''m not trying to argue that if something is dangerous, it should never be used. If something is dangerous AND there is a safer way to accomplish the same task, why use the dangerous way? I was trying to point out the safer alternative ways to accomplish the same thing that macros posted earlier were designed to do.

If this had been a thread about cool things you could do with pointers, perhaps I would have posted a warning about how there are many dangers using pointers and offered suggestions about how you might avoid some of the pitfalls without sacrificing functionality/performance.

That link I posted before has a good discussion of what the author means when he says something is "evil". It doesn''t mean you never use it, it means if you have to use it (and you will use macros at some point if you''re a C++ programmer) you have to use it with a conscious understanding of all the pitfalls.

quote:Original post by Anonymous Poster
"multiple argument evaluation is a problem"
Really? I''ve used many many arguments with no problems.

Of course you can pass multiple arguments to a macro. By "multiple argument evaluation" I meant that an argument might be evaluated more that once when the macro is expanded. This could be very bad if you called a macro with "x++" (or another expression with side effects) as an argument. dorix posted an illustration of that earlier. Perhaps I should have said "arguments evaluated multiple times".