Peter
>
>I think you totally misunderstood my post (or I have inadequately explained my point):

Jos,
Let me assure you that my reaction was purely 'academic'. No offense meant of course. I indeed got the impression that your standpoint was something like "both sides have some valid arguments, but what does it matter". Your 4 points in your reply make your standpoint indeed more clear. I think that especcially the "what does it matter" impression has been tackled a bit by these 4 points.



>1) I am saying that whether macro substitution is slower or faster than alternative methods is often (not always) a mute point because the speed differences are not always noticeable in (a) the specific implementation i.e. small loops or single statements and (b) with the very fast processors and memory configs of modern PC's.
>
>2) I am not advising for or against macro substitution per se. I am using it myself in a variety of places. I clearly indicated this much and agree that it is "legitimate" programming technique.
>
>3) I still maintain there is no carte blanche right or wrong answer as to whether macros should be used or not. Sometimes they should and sometimes they should not. The answer will depend on the situation (and personal programming preference) and hence no right answer.
>
>4) Often the speed issue is a mute point because what may be faster on a perfect test-bed PC may not be perfect in the real world where users have less than perfect equipment with lots of other apps and processes running. In other words the bottlenecks in a deployed app may be in completely other areas.
>
>Jos

*** what was it about: ****

>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 :)