Index a #define string

[David Harmon]

Re: Index a #define string

On Sat, 17 Apr 2004 14:54:12 -0600 in comp.lang.c++, Julie
<julie@nospam.c om> wrote,[color=blue]
>
>Do you agree that the offsetof() macro is an example of a 'non-evil' macro or
>not?[/color]

It is very nasty in both intent and action. I think it would not exist
in C++ except for the need for backwards C compatibility.

In intent, it breaks encapsulation and encourages dependence on the
low-level layout and implementation of objects. Depend only upon the
classes' public interface. Use "pointer-to-member" when called for.

In action, it relies on non-portable tricks and cannot be defined within
standard C++. Or even C, I think, which is probably why it is in the
library instead of expecting self-abusers to supply their own.

[Paul Mensonides]

Re: Index a #define string

"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message
[color=blue]
> When we say avoid the use of macros, is because the use of macros is
> inherently dangerous,[/color]

If you're going to make unilateral statements such as this, you need to actually
back it up with specifics instead of repeating prejudicial generalizations .
Macros are *not* inherently dangerous. Certain *uses* of macros are dangerous
and have other pitfalls, but by no means does this extend to the general notion
of macros. This extends to other constructs as well that have, at times, even
greater pitfalls in C++. The way to deal with these pitfalls is through idioms
and techniques that are not enforced by the language itself except in some cases
through diagnostics (and sometimes with no diagnostic required by the standard).
The preprocessor, and the macro mechanism in particular, is simply easier to
target as an isolated entity. The pronouncement that "macros are evil" is
merely an act of people being to lazy to define exactly what sorts of usages are
or are not evil with respect to macros. It is as ridiculous as saying that
templates are evil because undetected POI issues exist.
[color=blue]
> it may behave in an unexpected way, and bugs caused by
> macro substitution of a macro defined in a header file which used in another
> header file, which is used in our code are of the most difficult to trace.
>
> C++ provides a superior alternative to macros (and void *s by the way) ,
> templates. They are compile time checked and type safe.[/color]

Here your making another gross oversimplificat ion. C++ provides a superior
alternative to using macros to define type/value generic constructs (such as
classes and functions) and inline functions (and sometimes constants). That
doesn't even come close to covering the range of uses of macros.
[color=blue][color=green]
> > The notion that "all macros are bad" is more dangerous than the potential
> > misuse of macros.[/color][/color]

I totally agree with this. Specifically, notions like the above are dangerous
because they show a lack of understanding and thought about when and where which
tool should be applied. It shows a serious lack of lateral thinking and logical
deduction.
[color=blue]
> Well it is apparent that we will stick to our own opinions.
>
>[color=green]
> > Chew on that for a while, once you get out of the box.[/color]
>
>
> I am not in the box, i am in the hug of my LCD monitor. :-)[/color]

:)

A statement like "macros are inherently dangerous" comes straight out of the
box. Consider Boost, which contains a great deal of out-of-the-box thinking
resulting in some incredible libraries that push the boundaries of all
previously existing design technique. And then consider further, that many of
those libraries are generated *with macros that have never caused a name clash
despite the relatively widespread use of Boost*. I'm not saying that macros are
the end-all-and-be-all, and I'm not saying that many uses (if not *most* uses in
practice) are not dangerous. What I am saying is that there are both good uses
and bad uses--just like with every other language feature or intersection of
features. Anything else is the result of people being too lazy to actually pin
down the problems or naivety caused by blind application of guidelines that are
themselves a product of previous laziness.

Regards,
Paul Mensonides

[Ioannis Vranos]

Re: Index a #define string

"Paul Mensonides" <leavings@comca st.net> wrote in message
news:SemdncpnT8 feXxzdRVn-gQ@comcast.com. ..[color=blue]
>
> If you're going to make unilateral statements such as this, you need to[/color]
actually[color=blue]
> back it up with specifics instead of repeating prejudicial[/color]
generalizations .[color=blue]
> Macros are *not* inherently dangerous. Certain *uses* of macros are[/color]
dangerous[color=blue]
> and have other pitfalls, but by no means does this extend to the general[/color]
notion[color=blue]
> of macros. This extends to other constructs as well that have, at times,[/color]
even[color=blue]
> greater pitfalls in C++. The way to deal with these pitfalls is through[/color]
idioms[color=blue]
> and techniques that are not enforced by the language itself except in some[/color]
cases[color=blue]
> through diagnostics (and sometimes with no diagnostic required by the[/color]
standard).[color=blue]
> The preprocessor, and the macro mechanism in particular, is simply easier[/color]
to[color=blue]
> target as an isolated entity. The pronouncement that "macros are evil" is
> merely an act of people being to lazy to define exactly what sorts of[/color]
usages are[color=blue]
> or are not evil with respect to macros. It is as ridiculous as saying[/color]
that[color=blue]
> templates are evil because undetected POI issues exist.[/color]


With only few exceptions like inclusion guards, you can do whatever you can
do with macros with templates. So what remains at the end are the dangerous
uses.



[color=blue][color=green]
> > it may behave in an unexpected way, and bugs caused by
> > macro substitution of a macro defined in a header file which used in[/color][/color]
another[color=blue][color=green]
> > header file, which is used in our code are of the most difficult to[/color][/color]
trace.[color=blue][color=green]
> >
> > C++ provides a superior alternative to macros (and void *s by the way) ,
> > templates. They are compile time checked and type safe.[/color]
>
> Here your making another gross oversimplificat ion. C++ provides a[/color]
superior[color=blue]
> alternative to using macros to define type/value generic constructs (such[/color]
as[color=blue]
> classes and functions) and inline functions (and sometimes constants).[/color]
That[color=blue]
> doesn't even come close to covering the range of uses of macros.[/color]


So do you think macros should be used in every day's code?


[color=blue]
> I totally agree with this. Specifically, notions like the above are[/color]
dangerous[color=blue]
> because they show a lack of understanding and thought about when and where[/color]
which[color=blue]
> tool should be applied. It shows a serious lack of lateral thinking and[/color]
logical[color=blue]
> deduction.[/color]


I never said that "macros are evil". But (obviously) in the contrary of you,
i consider a good practice to try avoid using macros as much as it is
possible.

[color=blue]
>
> A statement like "macros are inherently dangerous" comes straight out of[/color]
the[color=blue]
> box.[/color]


And also i never said the above. What i said is

"We must try to avoid using macros completely (mainly by using templates),
with very few exceptions that this can't be done (mainly the #ifndef
stuff)."

[color=blue]
> Consider Boost, which contains a great deal of out-of-the-box thinking
> resulting in some incredible libraries that push the boundaries of all
> previously existing design technique. And then consider further, that[/color]
many of[color=blue]
> those libraries are generated *with macros that have never caused a name[/color]
clash[color=blue]
> despite the relatively widespread use of Boost*. I'm not saying that[/color]
macros are[color=blue]
> the end-all-and-be-all, and I'm not saying that many uses (if not *most*[/color]
uses in[color=blue]
> practice) are not dangerous. What I am saying is that there are both good[/color]
uses[color=blue]
> and bad uses--just like with every other language feature or intersection[/color]
of[color=blue]
> features. Anything else is the result of people being too lazy to[/color]
actually pin[color=blue]
> down the problems or naivety caused by blind application of guidelines[/color]
that are[color=blue]
> themselves a product of previous laziness.[/color]


Well i agree. But i like to term the meaning of your phrase

"What I am saying is that there are both good uses and bad uses--just like
with every other language feature or intersection of features."

as

"We must avoid using macros where possible".






Ioannis Vranos

[Paul Mensonides]

Re: Index a #define string

"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message
[color=blue]
> With only few exceptions like inclusion guards, you can do whatever you can
> do with macros with templates. So what remains at the end are the dangerous
> uses.[/color]

No, you can't. For instance, you cannot generate the source code of templates
with templates, but you can with macros. You cannot generate a set of typesafe
overloaded functions with arity ranging from zero to any conceivable number of
parameters with templates, but you can with macros. You cannot define constants
that are usable to choose between various implementations each of which will
compile only on specific compilers on specific operating systems with underlying
language constants, but you can with macros. This list goes on and on.
[color=blue][color=green][color=darkred]
> > > it may behave in an unexpected way, and bugs caused by
> > > macro substitution of a macro defined in a header file which used in[/color][/color]
> another[color=green][color=darkred]
> > > header file, which is used in our code are of the most difficult to[/color][/color]
> trace.[color=green][color=darkred]
> > >
> > > C++ provides a superior alternative to macros (and void *s by the way) ,
> > > templates. They are compile time checked and type safe.[/color]
> >
> > Here your making another gross oversimplificat ion. C++ provides a[/color]
> superior[color=green]
> > alternative to using macros to define type/value generic constructs (such[/color]
> as[color=green]
> > classes and functions) and inline functions (and sometimes constants).[/color]
> That[color=green]
> > doesn't even come close to covering the range of uses of macros.[/color]
>
>
> So do you think macros should be used in every day's code?[/color]

"Every day code" is too general; it depends on what you are writing. If, for
example, you are writing a generic component (maybe some sort of "bind",
"compose", or "closure") you should, by all means, use the preprocessor to
generate code for you, such that you minimize the number of maintenance points
and increase the scalability of the component. OTOH, using macro definitions
instead of typedefs or using macro definitions instead of constant variables,
*is* pure evil most (but not all) of the time. Otherwise, macros can be used
locally (i.e. defined, used, undefined) for simple syntactic convenience. So,
to answer the question is, "Macros should be used when the use of macros is
better, and macros should not be used when the use of macros is not better."
Notice that the above doesn't present any black-and-white solution--it means you
have to *know* in any specific situation whether the use of macros is good,
evil, or the lesser of two evils.
[color=blue][color=green]
> > I totally agree with this. Specifically, notions like the above are[/color]
> dangerous[color=green]
> > because they show a lack of understanding and thought about when and where[/color]
> which[color=green]
> > tool should be applied. It shows a serious lack of lateral thinking and[/color]
> logical[color=green]
> > deduction.[/color]
>
>
> I never said that "macros are evil". But (obviously) in the contrary of you,
> i consider a good practice to try avoid using macros as much as it is
> possible.[/color]

You said that one should avoid using macros because macros are "inherently
dangerous."
That statement is incorrect. How about using some guidelines that have a
modicum of validity? Like:

1) use all uppercase names only for macros
2) macros defined in headers (that are intended to propogate out of those
headers) should always be prefixed with some project/library prefix (i.e. a name
space)
3) macros defined in headers for local use only need not be prefixed, but should
specifically *not* be all uppercase and should *always* be undefined after use
(i.e. to prevent the possibility of a clash with an actual "external" macro
name).

Even with these guidelines there are some exceptions. The point, in any case,
is that the avoidance of macros in general is not a good guideline. Rather,
avoidance of certain usages of macros are good guidelines, and so on.
Otherwise, you are just tying your hands behind your back.
[color=blue][color=green]
> >
> > A statement like "macros are inherently dangerous" comes straight out of[/color]
> the[color=green]
> > box.[/color]
>
>
> And also i never said the above. What i said is
>
> "We must try to avoid using macros completely (mainly by using templates),
> with very few exceptions that this can't be done (mainly the #ifndef
> stuff)."[/color]

And that is simply false; it should be, "We must try to avoid using macros for
these kinds of purposes ... unless there is an exceptional reason to use them,"
and also, "If macros are to be used, they should be used according to these
guidelines ... unless there is an exceptional reason not to." Anything else is
presumptious and leads to brain-dead coding.
[color=blue][color=green]
> > Consider Boost, which contains a great deal of out-of-the-box thinking
> > resulting in some incredible libraries that push the boundaries of all
> > previously existing design technique. And then consider further, that[/color]
> many of[color=green]
> > those libraries are generated *with macros that have never caused a name[/color]
> clash[color=green]
> > despite the relatively widespread use of Boost*. I'm not saying that[/color]
> macros are[color=green]
> > the end-all-and-be-all, and I'm not saying that many uses (if not *most*[/color]
> uses in[color=green]
> > practice) are not dangerous. What I am saying is that there are both good[/color]
> uses[color=green]
> > and bad uses--just like with every other language feature or intersection[/color]
> of[color=green]
> > features. Anything else is the result of people being too lazy to[/color]
> actually pin[color=green]
> > down the problems or naivety caused by blind application of guidelines[/color]
> that are[color=green]
> > themselves a product of previous laziness.[/color]
>
>
> Well i agree. But i like to term the meaning of your phrase[/color]

Obviously you don't, because you obviously have no idea how macros are used in
modern libraries such as Boost. If you did, you would effectively be saying
that Boost is poorly implemented. If you are saying that, fine, but you have an
awfully high opinion of yourself to say such a thing. If you aren't saying
that, then you are naive regarding many of the issues involved in day to day
generic programming.
[color=blue]
> "What I am saying is that there are both good uses and bad uses--just like
> with every other language feature or intersection of features."
>
> as
>
> "We must avoid using macros where possible".[/color]

The two are quite different, and the bad uses of macros do not outweight their
good uses enought (if they do at all) to draw an equivalence between the two
statements. According to your logic, you should also be saying, "We must avoid
using templates where possible." I.e. just because something *can* be used
poorly, doesn't mean that something cannot be used well, and, similarly, just
because something *can* be used well, doesn't mean that something cannot be used
poorly. In the case of templates, finding template-related bugs can be far far
worse than anything related to macros at all. Moral of the story, you cannot
condense good programming to a set of near black-and-white guidelines.

Regards,
Paul Mensonides

[David Harmon]

Re: Index a #define string

On Sat, 17 Apr 2004 21:07:07 -0700 in comp.lang.c++, "Paul Mensonides"
<leavings@comca st.net> wrote,[color=blue]
>"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message
>[color=green]
>> With only few exceptions like inclusion guards, you can do whatever you can
>> do with macros with templates. So what remains at the end are the dangerous
>> uses.[/color]
>
>No, you can't. For instance, you cannot generate the source code of templates
>with templates, but you can with macros. You cannot generate a set of typesafe
>overloaded functions with arity ranging from zero to any conceivable number of
>parameters with templates, but you can with macros.[/color]

Oh, that is all sophistry. You are saying basically, that you cannot
use templates in the identical fashion that you use macros. Well, so
what? The point is that you can accomplish the reasonable purpose
formerly served by macros, with templates, consts, and other C++
constructs that offer the advantages of being integrated with the
language. That you cannot perform exactly the same gyrations on the way
to getting there is not a bug, it's a feature.

[Ioannis Vranos]

Re: Index a #define string

"Paul Mensonides" <leavings@comca st.net> wrote in message
news:xpOdnW5Bqo tsYxzdRVn-jA@comcast.com. ..[color=blue]
>
> The two are quite different, and the bad uses of macros do not outweight[/color]
their[color=blue]
> good uses enought (if they do at all) to draw an equivalence between the[/color]
two[color=blue]
> statements. According to your logic, you should also be saying, "We must[/color]
avoid[color=blue]
> using templates where possible." I.e. just because something *can* be[/color]
used[color=blue]
> poorly, doesn't mean that something cannot be used well, and, similarly,[/color]
just[color=blue]
> because something *can* be used well, doesn't mean that something cannot[/color]
be used[color=blue]
> poorly. In the case of templates, finding template-related bugs can be[/color]
far far[color=blue]
> worse than anything related to macros at all. Moral of the story, you[/color]
cannot[color=blue]
> condense good programming to a set of near black-and-white guidelines.[/color]



I think it is a matter of views. I did not say to remove macros from the
language but i do not consider the macros matter as a balanced issue - that
there are as many good uses as bad uses. Macros are not to be used in daily
application programming.

For example i program C++ applications for .NET and i see no need to use
macros. On the other hand you seem to work in libraries area and you use
macros daily to get the job done. So perhaps the "default" for each one of
us is different. I can understand the use of macros in libraries, but still
even in that case my "default" would not be to use macros but only where i
can't do work without them.

There are things one can do only with macros, and i would use macros only to
do those.


Some quotes from TC++PL 3:


Page 10:

"The template facility was primarily designed to support statically typed
containers (such as lists, vectors, and maps) and to support elegant and
efficient use of such containers (generic programming). A key aim was to
reduce the use of macros and casts (explicit type conversion)."


Page 14:

"1.6.1 Suggestions for C Programmers

The better one knows C, the harder it seems to be to avoid writing C++ in C
style, thereby losing some of the potential benefits of C++. Please take a
look at Appendix B, which describes the differences between C and C++. Here
are a few pointers to the areas in which C++ has better ways of doing
something than C has:

[1] Macros are almost never necessary in C++. Use const (§5.4) or enum
(§4.8) to define manifest constants, inline (§7.1.1) to avoid function
calling overhead, templates (Chapter 13) to specify families of functions
and types, and namespaces (§8.2) to avoid name clashes."



Page 160:

"7.8 Macros

Macros are very important in C but have far fewer uses in C++. The first
rule about macros is: Don't use them unless you have to. Almost every macro
demonstrates a flaw in the programming language, in the program, or in the
programmer. Because they rearrange the program text before the compiler
proper sees it, macros are also a major problem for many programming tools.
So when you use macros, you should expect inferior service from tools such
as debuggers, crossreference tools, and profilers. If you must use macros,
please read the reference manual for your own implementation of the C++
preprocessor carefully and try not to be too clever. Also to warn readers,
follow the convention to name macros using lots of capital letters."


Page 161:

"Using macros, you can design your own private language. Even if you prefer
this ''enhanced language'' to plain C++, it will be incomprehensibl e to most
C++ programmers. Furthermore, the C preprocessor is a very simple macro
processor. When you try to do something non-trivial, you are likely to find
it either impossible or unnecessarily hard to do. The const, inline,
template, and namespace mechanisms are intended as alternatives to many
traditional uses of preprocessor constructs.

For example:

const int answer = 42;
template<class T> inline T min(T a, T b) { return (a<b)?a:b; }"





Page 163:

"7.9 Advice

[1] Be suspicious of non-const reference arguments; if you want the function
to modify its arguments, use pointers and value return instead; §5.5.
[2] Use const reference arguments when you need to minimize copying of
arguments; §5.5.
[3] Use const extensively and consistently; §7.2.
[4] Avoid macros; §7.8."







Ioannis Vranos

[Paul Mensonides]

Re: Index a #define string

"David Harmon" <source@netcom. com> wrote in message
news:40d1cdf6.2 27441193@news.w est.earthlink.n et...[color=blue]
> On Sat, 17 Apr 2004 21:07:07 -0700 in comp.lang.c++, "Paul Mensonides"
> <leavings@comca st.net> wrote,[color=green]
> >"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message
> >[color=darkred]
> >> With only few exceptions like inclusion guards, you can do whatever you can
> >> do with macros with templates. So what remains at the end are the dangerous
> >> uses.[/color]
> >
> >No, you can't. For instance, you cannot generate the source code of[/color][/color]
templates[color=blue][color=green]
> >with templates, but you can with macros. You cannot generate a set of[/color][/color]
typesafe[color=blue][color=green]
> >overloaded functions with arity ranging from zero to any conceivable number[/color][/color]
of[color=blue][color=green]
> >parameters with templates, but you can with macros.[/color]
>
> Oh, that is all sophistry. You are saying basically, that you cannot
> use templates in the identical fashion that you use macros. Well, so
> what? The point is that you can accomplish the reasonable purpose
> formerly served by macros, with templates, consts, and other C++
> constructs that offer the advantages of being integrated with the
> language. That you cannot perform exactly the same gyrations on the way
> to getting there is not a bug, it's a feature.[/color]

No, it isn't sophistry. It's simply a gross reduction of solutions to issues of
which you apparently have no conception. I'm not talking about generating
functions or classes with varying types, and I'm certainly not advocating that
macros be used for such a purpose without a really good reason--that is what
templates are for. I'm talking about generating source code, be it templates or
overloaded functions or whatever (a lexical analyzer, perhaps) that is
impossible to achieve otherwise without an external code generator or with
excessive manual copying. The first requires another build step--which is
terrible in a library context--and the second dramatically increases the number
of maintenance points.

The point is that you can accomplish many *but by no means all* purposes
formally served by macros. I'm not disagreeing that there are better solutions
to many things that macros were used for at one time. It isn't a question of
getting to the same place a different way; instead, it is that the destination
is quite different. One way to look at it is that the preprocessor is to
templates as templates are to classes and functions. (That certainly doesn't
summarize the entire field, but it does summarize a large portion of it.)

Regarding your "bug/feature" statement... You are certainly correct that
templates are a great feature for what they are intended to do. The same
extends to constant variables vs. macros, but to a slightly lesser degree. I'm
not arguing that, and I never will. What I am arguing is that statements such
as "macros are evil" or "macros are inherently dangerous" (which are both common
statements) are prejudicial generalizations that simply aren't true. Macros are
not evil, certain usages of them are. Macros are not inherently dangerous,
certain uses of them are. That is no different than any other language feature
or intersection of features. The only difference is that many have been too
brainwashed by statements like the above to investigate the cause-and-effect of
feature intersections within the preprocessor (within macro expansion in
particular) and feature intersections between the preprocessor and the language
proper--like they have with the underlying language.

As an aside, the core language is no more protected from name clashes than the
preprocessor. Namespaces serve to classify and organize names, but they do not,
at a language level, protect them. The only things that stop name collision are
1) utilize existing and well-known idioms and techniques such as documenting
which namespaces are considered "owned" by a component or library and 2)
decrease the likelihood of a clash by effectively extending the name (i.e.
namespace qualification). For example, say some component/library has this code
in a header:

// library.h

namespace library {
struct abc {
operator int() const {
return 0;
}
};
}

And then some other library or project header has this code:

namespace library {
const struct {
int operator()() const {
return 1;
}
} abc = { };
}

The above two declarations can silently coexist, but the expression "abc()" can
silently mean a different thing depending on where it is used. Obviously, a
scenario such as the above is very unlikely, but the point remains--the language
does not protect against name clashes in general. Only good conventions like
"don't use the same namespace" protect code against such collisions. The same
is true for macros, but instead of having an explicit qualification syntax, you
have prefixing (such as LIBRARY_ABC) (or suffixing) and good conventions like
"use all uppercase names for macros and only for macros". Together, it
accomplishes the same thing--protection against name interference--as the use of
namespaces and the accompanying conventions that are relied on by namespace
authors and users. That is certainly not the only sort of problem that the use
of macros can cause, but it is a major one. There are many other examples,
similar to the above, that illustrate the lack of true name encapsulation in the
core language. Most of the time such a name clash isn't silent--just as it
usually isn't with macros. (In fact, silent changes (i.e. the *really* hard
ones to deal with) are rare even without the application of any convention
whatsoever.) Nevertheless, the problems that can surface can be extremely
roundabout--such as dealing with subtle POI issues in different translation
units--where a diagnostic is not required by standard. Consider, for example,
what can the following can do, in the right circumstances, to constant
expressions involving enumerations (e.g. template metaprogramming that doesn't
use static const):

template<class T, class U> T operator+(T, U);

It once again shows that names are not encapsulated--only organized, and why
convention is the true means of encapsulation against name clash. A reasonable
convention to handle the above would be "do not declare completely generic
operator overloads".

Regards,
Paul Mensonides

[Ioannis Vranos]

Re: Index a #define string

"Paul Mensonides" <leavings@comca st.net> wrote in message
news:xImdnW5thI XSdh_d4p2dnA@co mcast.com...[color=blue]
>
> No, it isn't sophistry. It's simply a gross reduction of solutions to[/color]
issues of[color=blue]
> which you apparently have no conception. I'm not talking about generating
> functions or classes with varying types, and I'm certainly not advocating[/color]
that[color=blue]
> macros be used for such a purpose without a really good reason--that is[/color]
what[color=blue]
> templates are for. I'm talking about generating source code, be it[/color]
templates or[color=blue]
> overloaded functions or whatever (a lexical analyzer, perhaps) that is
> impossible to achieve otherwise without an external code generator or with
> excessive manual copying. The first requires another build step--which is
> terrible in a library context--and the second dramatically increases the[/color]
number[color=blue]
> of maintenance points.
>
> The point is that you can accomplish many *but by no means all* purposes
> formally served by macros. I'm not disagreeing that there are better[/color]
solutions[color=blue]
> to many things that macros were used for at one time. It isn't a question[/color]
of[color=blue]
> getting to the same place a different way; instead, it is that the[/color]
destination[color=blue]
> is quite different. One way to look at it is that the preprocessor is to
> templates as templates are to classes and functions. (That certainly[/color]
doesn't[color=blue]
> summarize the entire field, but it does summarize a large portion of it.)
>
> Regarding your "bug/feature" statement... You are certainly correct that
> templates are a great feature for what they are intended to do. The same
> extends to constant variables vs. macros, but to a slightly lesser degree.[/color]
I'm[color=blue]
> not arguing that, and I never will. What I am arguing is that statements[/color]
such[color=blue]
> as "macros are evil" or "macros are inherently dangerous" (which are both[/color]
common[color=blue]
> statements) are prejudicial generalizations that simply aren't true.[/color]
Macros are[color=blue]
> not evil, certain usages of them are. Macros are not inherently[/color]
dangerous,[color=blue]
> certain uses of them are. That is no different than any other language[/color]
feature[color=blue]
> or intersection of features. The only difference is that many have been[/color]
too[color=blue]
> brainwashed by statements like the above to investigate the[/color]
cause-and-effect of[color=blue]
> feature intersections within the preprocessor (within macro expansion in
> particular) and feature intersections between the preprocessor and the[/color]
language[color=blue]
> proper--like they have with the underlying language.[/color]



Macros must be avoided where possible. In an effort to not hurt your
feelings we can rephrase that "Use macros only when needed". Choose whatever
fits you better, they are both the same. And C++ is not C, you may have been
a C programmer for some long time and have done a lot of real and excellent
work with macros, but C++ is not C and in most cases the language provides
superior alternatives.

On the other hand, if you *still* program in C and you use macros, then what
we discuss here does not apply.

[color=blue]
> As an aside, the core language is no more protected from name clashes than[/color]
the[color=blue]
> preprocessor. Namespaces serve to classify and organize names, but they[/color]
do not,[color=blue]
> at a language level, protect them. The only things that stop name[/color]
collision are


Namespaces do not exist to protect from name collisions. Namespaces are the
implementation of the modular programming paradigm, that is to place the
data and its functions in an area (you can call it as the ancestor of OO
but it is a non-obsolete useful paradim), so as to have them together. E.g.:


namespace whatever
{
int x;

void somefunc(const int a) { /* Do things with x; */ }
int someotherfunc(i nt a) { /* Do some other things with x */ }
// ...
}



That's the modular paradigm namespaces was made for. Today we use this
paradigm with classes, etc too. And they help use different implementations
of the same facilities, e.g. std::vector vs
some_other_impl ementation::vec tor.

And something most do not know is that the use of a global namespace
declaration is not good. E.g.


#include <iostream>
#include <vector>

using namespace std;


int main()
{
// ..
}


is bad style. For accuracy it is an attempt to defeat the namespace system.
That's why a typical C++ standard library implementation of <stdio.h> is (or
better should be):


--- stdio.h ---

#include <cstdio>
using std::printf;
using std::sprintf;
// ...
using std::scanf;

// etc

--- end of C++ stdio.h ---


In summary, namespaces are not made to protect from name collisions among
functions doing different things, but to organize work and *protect* from
name collisions of facilities doing the same things.






Regards,

Ioannis Vranos

[Ioannis Vranos]

Re: Index a #define string

"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message
news:c5usbp$2hh o$1@ulysses.noc .ntua.gr...[color=blue]
>
> And something most do not know is that the use of a global namespace
> declaration is not good. E.g.
>
>
> #include <iostream>
> #include <vector>
>
> using namespace std;
>
>
> int main()
> {
> // ..
> }
>
>
> is bad style. For accuracy it is an attempt to defeat the namespace[/color]
system.[color=blue]
> That's why a typical C++ standard library implementation of <stdio.h> is[/color]
(or[color=blue]
> better should be):
>
>
> --- stdio.h ---
>
> #include <cstdio>
> using std::printf;
> using std::sprintf;
> // ...
> using std::scanf;
>
> // etc
>
> --- end of C++ stdio.h ---[/color]


Now it is an entirely new topic, but since i got in, it is not good to leave
it unexplained. In a brief summary we must try using namespace declarations
in as a small scope as possible in the style:

For a couple of facilities, we must use "using namespace_name: :facility;" in
as a small scope as possible. Example:


#include <iostream>

int main()
{
using std::cout;
using std::endl;

// ...

cout<</* ... */<<endl;

// ...

cout<</* ... */<<endl;
}


For more than a couple of things, we must use "using namespace
namespace_name; " in as a small scoe as possible. Example:


#include <iostream>
#include <vector>

int main()
{
using namespace std;

vector<int>what ever(10);

// ...

for(vector<int> ::size_type i=0; i<whatever.size (); ++i)
cout<<whatever[i]<<endl;

// ...

for(vector<int> ::size_type i=0; i<whatever.size (); ++i)
cout<<whatever[i]<<endl;
}






Ioannis Vranos

[David Harmon]

Re: Index a #define string

On Sun, 18 Apr 2004 13:55:36 -0700 in comp.lang.c++, "Paul Mensonides"
<leavings@comca st.net> wrote,[color=blue]
>I'm talking about generating source code, be it templates or
>overloaded functions or whatever (a lexical analyzer, perhaps) that is
>impossible to achieve otherwise without an external code generator or with
>excessive manual copying. The first requires another build step--which is
>terrible in a library context--and the second dramatically increases the number
>of maintenance points.[/color]

Lexical analyzer? Show me a C preprocessor implementation of anything
to compare with Joel de Guzman's Spirit parser template library.

http://spirit.sf.net

[Paul Mensonides]

Re: Index a #define string

Ioannis Vranos wrote:[color=blue]
> "Paul Mensonides" <leavings@comca st.net> wrote in message
> news:xpOdnW5Bqo tsYxzdRVn-jA@comcast.com. ..[color=green]
>>
>> The two are quite different, and the bad uses of macros do not
>> outweight their good uses enought (if they do at all) to draw an
>> equivalence between the two statements. According to your logic,
>> you should also be saying, "We must avoid using templates where
>> possible." I.e. just because something *can* be used poorly,
>> doesn't mean that something cannot be used well, and, similarly,
>> just because something *can* be used well, doesn't mean that
>> something cannot be used poorly. In the case of templates, finding
>> template-related bugs can be far far worse than anything related to
>> macros at all. Moral of the story, you cannot condense good
>> programming to a set of near black-and-white guidelines.[/color]
>
>
>
> I think it is a matter of views. I did not say to remove macros from
> the language but i do not consider the macros matter as a balanced
> issue - that there are as many good uses as bad uses. Macros are not
> to be used in daily application programming.[/color]

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.
[color=blue]
> For example i program C++ applications for .NET and i see no need to
> use macros. On the other hand you seem to work in libraries area and
> you use macros daily to get the job done. So perhaps the "default"
> for each one of us is different. I can understand the use of macros
> in libraries, but still even in that case my "default" would not be
> to use macros but only where i can't do work without them.[/color]

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.
[color=blue]
> There are things one can do only with macros, and i would use macros
> only to do those.[/color]

What about things that can be done much easier and much more efficiently in
terms of both run-time performance and maintenance?
[color=blue]
> Some quotes from TC++PL 3:
>
>
> Page 10:
>
> "The template facility was primarily designed to support statically
> typed containers (such as lists, vectors, and maps) and to support
> elegant and efficient use of such containers (generic programming). A
> key aim was to reduce the use of macros and casts (explicit type
> conversion)."[/color]

Yes, and for that purpose (and others) templates are great.
[color=blue]
> Page 14:
>
> "1.6.1 Suggestions for C Programmers
>
> The better one knows C, the harder it seems to be to avoid writing
> C++ in C style, thereby losing some of the potential benefits of C++.
> Please take a look at Appendix B, which describes the differences
> between C and C++. Here are a few pointers to the areas in which C++
> has better ways of doing something than C has:
>
> [1] Macros are almost never necessary in C++.[/color]

Wrong, for a variety of reasons. The most ironic of them is that various C++
implementations differ far more radically than various C implementations .
[color=blue]
> Use const (§5.4) or enum
> (§4.8) to define manifest constants,[/color]

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;
}
[color=blue]
> inline (§7.1.1) to avoid function
> calling overhead,[/color]

Yes, except in very special cases where you actually *do* know better than the
compiler.
[color=blue]
> templates (Chapter 13) to specify families of
> functions and types, and namespaces (§8.2) to avoid name clashes."[/color]

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.
[color=blue]
> Page 160:
>
> "7.8 Macros
>
> Macros are very important in C but have far fewer uses in C++.[/color]

Along certain lines, yes. Along other lines, the exact opposite is true.
[color=blue]
> The
> first rule about macros is: Don't use them unless you have to. Almost
> every macro demonstrates a flaw in the programming language, in the
> program, or in the programmer.[/color]

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".
[color=blue]
> Because they rearrange the program
> text before the compiler proper sees it, macros are also a major
> problem for many programming tools.[/color]

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.
[color=blue]
> So when you use macros, you
> should expect inferior service from tools such as debuggers,
> crossreference tools, and profilers.[/color]

Wrong, or at least, not specific enough. This is entirely dependant on how
macros are used and for what purpose.
[color=blue]
> If you must use macros, please
> read the reference manual for your own implementation of the C++
> preprocessor carefully and try not to be too clever. Also to warn
> readers, follow the convention to name macros using lots of capital
> letters."[/color]

Absolutely. In addition, you should always undefine macros that are used only
locally.
[color=blue]
> Page 161:
>
> "Using macros, you can design your own private language. Even if you
> prefer this ''enhanced language'' to plain C++, it will be
> incomprehensibl e to most C++ programmers.[/color]

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. ;)
[color=blue]
> Furthermore, the C
> preprocessor is a very simple macro processor. When you try to do
> something non-trivial, you are likely to find it either impossible or
> unnecessarily hard to do.[/color]

Which is why you have libraries that specialize in this sort of thing.
[color=blue]
> The const, inline, template, and namespace
> mechanisms are intended as alternatives to many traditional uses of
> preprocessor constructs.[/color]

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.
[color=blue]
> Page 163:
>
> "7.9 Advice
>
> [1] Be suspicious of non-const reference arguments; if you want the
> function to modify its arguments, use pointers and value return
> instead; §5.5. [2] Use const reference arguments when you need to
> minimize copying of arguments; §5.5.
> [3] Use const extensively and consistently; §7.2.
> [4] Avoid macros; §7.8."[/color]

Which just illustrates Bjarne's well-known prejudice against macros resulting
from many of the traditional uses of them. So what?

Regards,
Paul Mensonides

[Paul Mensonides]

Re: Index a #define string

David Harmon wrote:[color=blue]
> On Sun, 18 Apr 2004 13:55:36 -0700 in comp.lang.c++, "Paul Mensonides"
> <leavings@comca st.net> wrote,[color=green]
>> I'm talking about generating source code, be it templates or
>> overloaded functions or whatever (a lexical analyzer, perhaps) that
>> is impossible to achieve otherwise without an external code
>> generator or with excessive manual copying. The first requires
>> another build step--which is terrible in a library context--and the
>> second dramatically increases the number of maintenance points.[/color]
>
> Lexical analyzer? Show me a C preprocessor implementation of anything
> to compare with Joel de Guzman's Spirit parser template library.
> http://spirit.sf.net[/color]

You want to know what is really funny about that? Joel de Guzman uses the
preprocessor in Spirit and Fusion for exactly the kind of stuff that I'm talking
about.

Regards,
Paul Mensonides

[Ioannis Vranos]

Re: Index a #define string

"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message
news:c5usbp$2hh o$1@ulysses.noc .ntua.gr...[color=blue]
>
> Namespaces do not exist to protect from name collisions. Namespaces are[/color]
the


Errata:

Namespaces do not exist to protect from general name collisions. Namespaces
are the






Regards,

Ioannis Vranos

[Ioannis Vranos]

Re: Index a #define string

"Paul Mensonides" <leavings@comca st.net> wrote in message
news:Sa-dnfQPkZyBYx_dRV n-vg@comcast.com. ..[color=blue]
>
> Which just illustrates Bjarne's well-known prejudice against macros[/color]
resulting[color=blue]
> from many of the traditional uses of them. So what?[/color]


So we reach nowhere. :-)






Regards,

Ioannis Vranos

[Paul Mensonides]

Re: Index a #define string

Ioannis Vranos wrote:[color=blue]
> "Paul Mensonides" <leavings@comca st.net> wrote in message[/color]
[color=blue]
> Macros must be avoided where possible. In an effort to not hurt your
> feelings we can rephrase that "Use macros only when needed".[/color]

You're not hurting my feelings, you're simply wrong and extremely naive.
[color=blue]
> Choose
> whatever fits you better, they are both the same.[/color]

No, they are not. You simply have no concept of the things that I am talking
about because they are so far above your level of expertise in the fields in
which they apply.
[color=blue]
> And C++ is not C,
> you may have been a C programmer for some long time and have done a
> lot of real and excellent work with macros, but C++ is not C and in
> most cases the language provides superior alternatives.[/color]

No, in *many* cases the language provides superior alternatives. What's amazing
here is your complete lack of willingness to accept that you don't know
everything. You think that you know what I'm talking about, but apparently you
have no idea. Otherwise, you wouldn't be saying that the functionality can be
replicated with, e.g., templates, because they can't.
[color=blue]
> On the other hand, if you *still* program in C and you use macros,
> then what we discuss here does not apply.[/color]

I'm not talking about C, and the context that applies to what I'm saying applies
far more in C++ (though it still does in C).
[color=blue][color=green]
>> As an aside, the core language is no more protected from name
>> clashes than the preprocessor. Namespaces serve to classify and
>> organize names, but they do not, at a language level, protect them.
>> The only things that stop name collision are[/color]
>
>
> Namespaces do not exist to protect from name collisions. Namespaces
> are the implementation of the modular programming paradigm[/color]

Which is exactly what I said, believe me, I know what namespaces are.

Regards,
Paul Mensonides