P
Paul Mensonides
Ioannis said:
And that is a wrong assessment. Macros are not to be used when the use of
something else is better--and vice versa. Whether it is library code or
application code is irrelevant. You cannot simplify it that easily.
I agree that the good uses of macros appear more often in library code than in
application code. However, there is no universally clear distinction between
what should be library code and what should be application code. And even if
there was, good uses for macros in application code still appear often enough
that such a generalization is invalid. It isn't that I disagree with you
regarding the use of templates, constant variables, inline functions, etc.. I
disagree that those things even come close to encompassing the totality of macro
use--many of which you probably aren't aware of. In essence, the guideline that
you espouse is invalid because it is too broad and needs to be broken down into
constituent guidelines which actually *are* valid. Otherwise, you propogate the
status quo of prejudice-oriented programming which avoids the singlular problem
of macro name collision while simultaneously producing suboptimal code that
likely includes maintenance nightmares. Use macros when macros are the best
option to do a thing, otherwise don't--no prejudice involved, but it implies
that you actually have to *know* what is good or bad and why. There is nothing
wrong with that at all--it is the antithesis of laziness.
What about things that can be done much easier and much more efficiently in
terms of both run-time performance and maintenance?
Yes, and for that purpose (and others) templates are great.
Wrong, for a variety of reasons. The most ironic of them is that various C++
implementations differ far more radically than various C implementations.
Most of time, yes--unless it is needed by the preprocessor for a good reason.
In such a case, it should be mirrored:
#define LIBRARY_XYZ 10
namespace library {
const int xyz = LIBRARY_XYZ;
}
Yes, except in very special cases where you actually *do* know better than the
compiler.
Namespaces don't avoid name clashes per se. They provide a means to structure
and classify names. That indirectly avoids name clashes by effectively
increasing the length of the relevant names. That's a minor point, however, and
otherwise I agree.
Along certain lines, yes. Along other lines, the exact opposite is true.
The "first rule about macros" is wrong. It should be, don't use them when there
is a superior alternative within the language proper--where "superior" means the
total set of all possible ways in which something can be superior or inferior
(some of which are subjective, some of which are not).
Many macros do indeed demonstrate flaws in the programming language--one of them
being the lack of power that macros have (compared to other macro mechanisms).
This also represents a broad class of language deficiencies that are never going
to change. Some will, yes, but otherwise, so what? Flaws in the program and in
the programmer obviously exist, and many times the use of macros demonstrates
that--as does the use of many combinations of language elements. In any case,
the above is true if "almost every macro" means almost every existing macro
currently in existence. The above is not true if "almost every macro" is
supposed to mean "almost every possible use of macros".
First, macros do not rearrange the program "text", they rearrange the program's
preprocessing tokens within a translation unit. Second, that is the fundamental
reason why the preprocessor is such a powerful tool in certain types of
situations. That is what provides both the power and the danger of the
preprocessor, and consequently (as a generalization) where and when the use of
macros can be good.
Wrong, or at least, not specific enough. This is entirely dependant on how
macros are used and for what purpose.
Absolutely. In addition, you should always undefine macros that are used only
locally.
The reference here is making C++ look like, for example, Pascal. I'm definitely
not advocating doing that--along with the reason given, you'd be trading a
concise language for an extremely verbose one.
Which is why you have libraries that specialize in this sort of thing.
And for many purposes, they are great alternatives. As I've said before, in
nearly all situations, these are better alternatives to their corresponding
macro formulations.
Which just illustrates Bjarne's well-known prejudice against macros resulting
from many of the traditional uses of them. So what?
Regards,
Paul Mensonides