On Monday, 1 June 2015 at 16:57:00 UTC, Jonathan M Davis wrote:
I use macros for stuff like exceptions all the time - e.g.THROW(MyException, ("This value is wrong: %d", foo));
ick! Yes, if you want stack-trace like information in release-builds you need to use the macro system, but that's because __FILE__ and __LINE__ are macros! That's a C deficiency. Usually your debugger gets you what you are looking for without this in debug builds, right?
And your THROW macro does not help when you receive exceptions from libraries.
(I don't use exceptions in C++)
even come close. Without a macro, getting all of the information in C++ - and doing it consistently and correctly - would be a big problem.
You would need a core dump ;^), but consistently… well, if you don't use libraries.
Yes, macros should be avoided in general, but there are areas where you really don't have much choice, and saying that all macros are unequivocably bad is quite short-sighted. It's when macros are used when they aren't needed that it's a problem.
It's a problem if you need it. It is almost always used to address language design flaws or other structural flaws.
Coming out of college, I actually believed the dogma that all macros are bad, but experience has shown me that that's just not true. Sure, it would be nice if we had a better solution in C++, but sometimes we just don't.
Yet, some of programmers don't actually use it anymore. In C you need it, it is an integral part of the language design. In C++ you can avoid it for the most part or replace it with external code-gen ( + makefile ).
(I sometimes use macros for constants like π out of habit, but I consider it a bad habit :-P.)
