>Peter / Cetin
>
>Like so many issues of this type there is no right or wrong answer. Like the discussion on CDX bloat vs. performance thread its often a case of what's theoretically "right" vs. real world deployment issues which often make the point mute.

I understand what you're saying, but I tend not to agree.

First, with regard to this issue, there is a right and a wrong answer.

Second, probably, what you're seeing as the 'theoretically "right"' standpoint is what I'm seeing as the 'real world deployment'. And the other way around: What I'm seeing as the 'theoretically "right"' standpoint, is seen be you as the 'real world deployment'. Translated:
Those who think that macros should be avoided (according to theory), notice that macros are widely used in the real world, and they either don't mind too much or tell those developers that they ought not do so ("shame on you").
And the other way around: Those who think that macros are legitimate and occasionally even the better solution (according to theory), notice that a lot of developers don't dare to use macros in the real world, and they either don't mind too much or tell those developers that it's okay to use macros ("relax, it's okay").

IMO, it's not a mute point.


>Macro substitution is slower than the other solutions offered but, as Peter points out, if macro substitution is used in a small loop then the speed difference will not be noticeable, especially when combined with today's fast processors.
>
>In respect of readability - I agree, like Cetin, that readability is in the eye of the beholder.
>
>Macro substitution is obviously a legitimate programming technique and one which I think is awesomely powerful. However, it is also a very often miss-used technique.

No, it is a very often not-used, but legitimate, technique!

Regards :)