On 23.01.2024 18:21, Lew Pitcher wrote:

On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:

On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:

On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:

... I don't use the matching names in C++ either ...

I do, if/when I do use C++ and C. Don’t you think it improves readability:

It breaks the rule that, in C, variables and functions are alphnumeric,
whilst operators are symbols. sizeof is an exception, but a justified
one. However it's harder to justify a symbol for "plus" but a word for "or".

Less importantly, it also violates the convention that C macros are named in upper case to distinguish them from keywords and "regular" identifiers.

Interestingly the convention had been (AFAICT) to uppercase *all* CPP
items, _mostly_. But in practice we've seen CPP function macros that
were lowercase even in system headers (ISTR some functions in stdio).
It certainly has advantages to uppercase macro functions to be sure
about possible side effects, like in FUNCT(a++). OTOH, for plain CPP
constants literals it's probably unnecessary to capitalize them.

[...]

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 23.01.2024 18:21, Lew Pitcher wrote:

On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:

On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:

On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:

... I don't use the matching names in C++ either ...

I do, if/when I do use C++ and C. Don’t you think it improves readability:

It breaks the rule that, in C, variables and functions are alphnumeric,
whilst operators are symbols. sizeof is an exception, but a justified
one. However it's harder to justify a symbol for "plus" but a word for "or".

Less importantly, it also violates the convention that C macros are named in >> upper case to distinguish them from keywords and "regular" identifiers.

Interestingly the convention had been (AFAICT) to uppercase *all* CPP
items, _mostly_. But in practice we've seen CPP function macros that
were lowercase even in system headers (ISTR some functions in stdio).
It certainly has advantages to uppercase macro functions to be sure
about possible side effects, like in FUNCT(a++). OTOH, for plain CPP constants literals it's probably unnecessary to capitalize them.

You might think, but due to scoping, they can cause problems, unless
they are namespaced. If you define macro like

#define speed 42.0

anything which includes this cannot use the speed identifier
for any purpose. Not as a structure member name, enumerator, parameter
name, function name, typedef, goto label, nothing.

If we use SPEED instead, and never use such an identifier as a function, parameter, or any of those roles I mentioned, then we have a kind of
namespace separation.

This is why simple constants are capitalized.

What we don't want to capitalize are function-like macros (those
that take parameters) which are well-behaved and blend nicely into the language. Making them SHOUT just reduces the nice blending.

A function-like macro is not invoked if it is not followed by an open parenthesis, which reduces the possibility of a clash.

Macros that do weird things, and/or have severe or bizarre contextual restrictions on their use probably ought to SHOUT.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24.01.2024 09:25, Kaz Kylheku wrote:

On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 23.01.2024 18:21, Lew Pitcher wrote:

On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:

On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:

On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:

... I don't use the matching names in C++ either ...

I do, if/when I do use C++ and C. Don’t you think it improves readability:

It breaks the rule that, in C, variables and functions are alphnumeric, >>>> whilst operators are symbols. sizeof is an exception, but a justified
one. However it's harder to justify a symbol for "plus" but a word for "or".

Less importantly, it also violates the convention that C macros are named in
upper case to distinguish them from keywords and "regular" identifiers.

Interestingly the convention had been (AFAICT) to uppercase *all* CPP
items, _mostly_. But in practice we've seen CPP function macros that
were lowercase even in system headers (ISTR some functions in stdio).
It certainly has advantages to uppercase macro functions to be sure
about possible side effects, like in FUNCT(a++). OTOH, for plain CPP
constants literals it's probably unnecessary to capitalize them.

You might think, but due to scoping, they can cause problems, unless
they are namespaced. If you define macro like

#define speed 42.0

anything which includes this cannot use the speed identifier
for any purpose. Not as a structure member name, enumerator, parameter
name, function name, typedef, goto label, nothing.

Umm.., but that is just a normal name clash situation.

I mean I see where you're coming from but that doesn't seem convincing.
The convention then "disallows" (sort of) use of
char* TLA = "three letter acronym";
because its lexical form is "reserved" (in an artificial name-space)
for CPP entities?

I suppose we just disagree on that point (or have other preferences).

If we use SPEED instead, and never use such an identifier as a function, parameter, or any of those roles I mentioned, then we have a kind of namespace separation.

This is why simple constants are capitalized.

What we don't want to capitalize are function-like macros (those
that take parameters) which are well-behaved and blend nicely into the language. Making them SHOUT just reduces the nice blending.

A function-like macro is not invoked if it is not followed by an open parenthesis, which reduces the possibility of a clash.

Macros that do weird things, and/or have severe or bizarre contextual restrictions on their use probably ought to SHOUT.

I'm familiar a design philosophy where it's even unnecessary to write parenthesis in function calls in case there's no arguments, so I know
what you're aiming at. Only the fact that the CPP is just a poor tool
that does simple replacements may lead to issues, say, FUN(a) a+a
and a call with FUN(b++) . Notwithstanding that we could discuss the responsibility of the macro designer, such behavior at least may be a
reason to clearly indicate that caution is necessary here.

I think we agree here.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/01/2024 09:25, Kaz Kylheku wrote:

On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 23.01.2024 18:21, Lew Pitcher wrote:

On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:

On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:

On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:

... I don't use the matching names in C++ either ...

I do, if/when I do use C++ and C. Don’t you think it improves readability:

It breaks the rule that, in C, variables and functions are alphnumeric, >>>> whilst operators are symbols. sizeof is an exception, but a justified
one. However it's harder to justify a symbol for "plus" but a word for "or".

Less importantly, it also violates the convention that C macros are named in
upper case to distinguish them from keywords and "regular" identifiers.

Interestingly the convention had been (AFAICT) to uppercase *all* CPP
items, _mostly_. But in practice we've seen CPP function macros that
were lowercase even in system headers (ISTR some functions in stdio).
It certainly has advantages to uppercase macro functions to be sure
about possible side effects, like in FUNCT(a++). OTOH, for plain CPP
constants literals it's probably unnecessary to capitalize them.

You might think, but due to scoping, they can cause problems, unless
they are namespaced. If you define macro like

#define speed 42.0

anything which includes this cannot use the speed identifier
for any purpose. Not as a structure member name, enumerator, parameter
name, function name, typedef, goto label, nothing.

If we use SPEED instead, and never use such an identifier as a function, parameter, or any of those roles I mentioned, then we have a kind of namespace separation.

This is why simple constants are capitalized.

A better choice would be:

static const double speed = 42.0;

That has none of the scoping or identifier issues that you mention.

Alternatively, if I had to use #define for some reason, I'd prefer:

#define maximum_speed 42.0

or some other appropriate name that would not clash with other
identifiers (in that translation unit) because it has a unique name that
will not be re-used. I find that far neater than using all-caps to make
an alternative namespace.

What we don't want to capitalize are function-like macros (those
that take parameters) which are well-behaved and blend nicely into the language. Making them SHOUT just reduces the nice blending.

A function-like macro is not invoked if it is not followed by an open parenthesis, which reduces the possibility of a clash.

Macros that do weird things, and/or have severe or bizarre contextual restrictions on their use probably ought to SHOUT.

Agreed.

I need good reasons to SHOUT an identifier - it needs to be something
that can easily have unexpected effects.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I think that macros should always be shouted, regardless of context,
because as nothing but text replacements they are inherently a little more spicy to deal with and functionlikemacros are not always interchangeäble
with subroutine calls—for instance, one cannot take the address of a functionlikemacro like they can with a subroutine.

On the other hand, i've seen instances of people making certain
exceptionally bizzare macros lowercase despite how weird the macros are—
see, for instance, the black magic that is <https://www.libcello.org/>.

--
Blue-Maned_Hawk│shortens to Hawk│/ blu.mɛin.dÊ°ak/ │he/him/his/himself/Mr.
blue-maned_hawk.srht.site
East, west, and C!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)