«

Ioannis Vranos wrote:
> "Paul Mensonides" <> wrote in message
> news:ncmdnezGp5QscRjdRVn-...
>>
>> No, not for constants. Use all caps identifiers for one thing and
>> one thing only--macro names. Constants, which I assume you to mean
>> constant variables or enumerators, should definitely *not* be all
>> caps--otherwise you just reintroduce the likelihood of a name clash.
>
>
> And now we are at the beginning of YARW (yet another "religious"
> war). I define all my constants in upper case, macros or no, so as it
> to be evident in code that i have to do with a constant.

This isn't a religious issue. It is a practical one. Macro names should be all
caps to distinguish them from everything else--for a very good reason. When you
use all caps for constants, you introduce a loophole into the protection
techniques that would otherwise never fail (at least not silently). If it
wasn't for the (valid) conventions regarding macro naming, I'd say that it is
merely a matter of subjective preference (such as "int *x" vs. "int* x", but it
isn't. It is a practical issue.

Regards,
Paul Mensonides

"Paul Mensonides" <> wrote in message
news:Y5WdnUn3z7itnRvdRVn-...
>
> I think you are missing what I'm getting at. I'm not talking about
something
> trivial like min/max. I'm also not talking about something that has an
obvious
> and easy solution as either a macro or a template (or whatever).
>
> As an example, it is certainly possible to define a closure mechanism by
> manually (i.e. copy-and-paste) writing a bunch of
overloads/specializations with
> varying arities--say up to 20 arguments as a maximum. The point is that
doing
> that is ridiculous when the preprocessor provides the facilities needed to
do
> that for you. When you make 20 specializations, you introduce 20
(actually
> probably some multiple of 20) maintenance points into your source. A
slight
> step up is to use macros purely to reduce that burden in an isolated way,
where
> you factor out the things that change into macro arguments (changing arity
is
> not a good example here without variadic macros). A significant step up,
OTOH,
> is to generalize the concept of varying repetitions, so that it can be
used in
> many other places as well.


We discuss too general. Also void somefun(int a=0, int b=0, ..., int z=0);
is possible.



> What it comes down to, is that, fundamentally, you aren't doing anything
with
> macros that you can't directly write out. So, it isn't a question of
whether or
> not you can do something without macros (there are only two major
categories of
> things that you can only do with macros--alternate source blocks in code
> subjected to more than one environment and include guards). Even the
> stringizing operator (#) is unnecessary for assertions--you can simply
rewrite
> the expression in quotes. The question than becomes where is it *better*
to use
> the preprocessor and where it is not? In some cases, the answer is
simple, in
> others it is not, but in no cases can you apply the generalization "avoid
macros
> as much as possible" and expect to get the best possible solution in all
cases.
> It is simply too general. As I said before, you need to break that
> generalization down into constituent elements that are actually
worthwhile.



Ok, i can rephrase it to "Do not use macros unless it is unavoidable, or
their use yields significant benefits".






Ioannis Vranos

"Paul Mensonides" <> wrote in message
news:__GdnWHWp5fKmhvdRVn-...
>
> This isn't a religious issue. It is a practical one. Macro names should
be all
> caps to distinguish them from everything else--for a very good reason.
When you
> use all caps for constants, you introduce a loophole into the protection
> techniques that would otherwise never fail (at least not silently).


Well lets get into this war anyway. At first i do not use macros usually
in my daily code but that's another matter. Standard library macros like
assert() are in lowercase. Only constants like NULL are capitals. The same
convention applies both for macros and non-macros. Only contants should be
uppercase, and by doing this improves the visibility of the code. After all,
a library facility macro or not, should not make any difference for the end
user who has not to know about the implementation details.






Ioannis Vranos

Ioannis Vranos wrote:
> "Paul Mensonides" <> wrote in message

> I am not sure i am following you to this. Can you give a small
> concrete example?

Many STL functions require some user-defined operation which can usually be
regular pointer or reference to function. However, you cannot adapt them using
standard library facilities because they don't have the typedefs (obviously).
However, given a type that is a pointer or reference to function, you can easily
extract the types necessary to make it adaptable:

template<class> struct function_traits;

template<class R, class A, class B> struct function_traits<R (*)(A, B)> {
// make typedefs for R, A, and B
};

It is similar to the iterator_traits class that works with pointers and
class/struct iterators. However, with something like the above, you have to
define a lot more specializations that just one or two if you want to have a
truly general solution--instead of just unary and binary--and the same goes for
the adaptors and compose* elements as well. Arities ranging from 0-2, while
useful, is not enough and is not general.

Regards,
Paul Mensonides

Ioannis Vranos wrote:
> "Paul Mensonides" <> wrote in message
> news:__GdnWHWp5fKmhvdRVn-...
>>
>> This isn't a religious issue. It is a practical one. Macro names
>> should be all caps to distinguish them from everything else--for a
>> very good reason. When you use all caps for constants, you introduce
>> a loophole into the protection techniques that would otherwise never
>> fail (at least not silently).
>
>
> Well lets get into this war anyway. At first i do not use macros
> usually in my daily code but that's another matter. Standard library
> macros like assert() are in lowercase. Only constants like NULL are
> capitals. The same convention applies both for macros and non-macros.

Those standard library macros come from C--where name clashing issues are not
nearly as significant as they are in C++ (at least as far as cutting across all
underlying language scoping mechanisms go).

> Only contants should be uppercase, and by doing this improves the
> visibility of the code.

I disagree; I think that it clutters it, and more importantly makes it less
obvious when macros are involved. However, that just goes to show the
subjectiveness of this sort of thing. A subjective choice is perfectly fine
when there is no solid objective contradiction, but in this case, there is.

> After all, a library facility macro or not,
> should not make any difference for the end user who has not to know
> about the implementation details.

No, it definitely does make a difference--consider the min/max macro case for
example. One of the arguments is always evaluated twice. That is an important
distinction that is a product of its macro nature. That is why the C standard
has to make so many guarantees about that sort of thing because just about
everything in the standard library can be a macro so long as it has a function
also.

Regards,
Paul Mensonides

Julie wrote:

>> macros completely in C++. Perhaps we should say that macros are a
>> "necessary evil."
>
> What we _should_ say is:
>
> The preprocessor, specifically including macro expansion, is a
> language construct that should be fully understood prior to using in
> production-quality code.
>
> That's it -- it isn't good, it isn't bad, it just is.

Just so you don't feel left out, I think that's very well said.

Regards,
Paul Mensonides

Ioannis Vranos wrote:
> "Paul Mensonides" <> wrote in message
> news:Y5WdnUn3z7itnRvdRVn-...
>>
>> I think you are missing what I'm getting at. I'm not talking about
>> something trivial like min/max. I'm also not talking about
>> something that has an obvious and easy solution as either a macro or
>> a template (or whatever).
>>
>> As an example, it is certainly possible to define a closure
>> mechanism by manually (i.e. copy-and-paste) writing a bunch of
>> overloads/specializations with varying arities--say up to 20
>> arguments as a maximum. The point is that doing that is ridiculous
>> when the preprocessor provides the facilities needed to do that for
>> you. When you make 20 specializations, you introduce 20 (actually
>> probably some multiple of 20) maintenance points into your source.
>> A slight step up is to use macros purely to reduce that burden in an
>> isolated way, where you factor out the things that change into macro
>> arguments (changing arity is not a good example here without
>> variadic macros). A significant step up, OTOH, is to generalize the
>> concept of varying repetitions, so that it can be used in many other
>> places as well.
>
>
> We discuss too general. Also void somefun(int a=0, int b=0, ..., int
> z=0); is possible.

Not when dealing with higher-order programming--like closures, and it can be
significantly less efficient otherwise.

> Ok, i can rephrase it to "Do not use macros unless it is unavoidable,
> or their use yields significant benefits".

I can live with that.

Regards,
Paul Mensonides

"Paul Mensonides" <> wrote in message
news:e7mdnaClKP1okBvdRVn-...
>
> > Ok, i can rephrase it to "Do not use macros unless it is unavoidable,
> > or their use yields significant benefits".
>
> I can live with that.


Then we are in an agreement! Paul and Ioannis are shaking hands.






Ioannis Vranos