C++ problem

That is exactly my rule: ALL_CAPS_FOR_AN_IDENTIFIER is an alarm flag that indicates something special. If it behaves just like a normal object it should look like one, even_if_it_is_implemented_as_a_macro.

Whether something is a constant is a limitation on the use of that thing: it can't be changed by *that part of the code*. As such, a constant is nothing special, and might be a modifyable variable for other parts of the code.

Wouter van Ooijen

Then you aren't a true engineer...

--

Rick

Am 04.03.2016 um 16:28 schrieb Wouter van Ooijen:

The thing is: it really doesn't behave like a normal object. C has four or five types of "constants", depending on how far you're willing to stretch the concept.

1) literal numbers in the source 2) preprocessor macros expanding to literal numbers 3) enum values 4) object flagged "const" 5) addresses of statically located objects (including functions)

Of these, three really do not behave like normal objects. For starters, you can't take their address, nor query their size. And not coincidentally, you can use only those three in every place C requires a constant, most prominently to dimension a statically allocated array.

And only types 2 and 3 are usually recommended to be spelled in ALL_CAPS.

That's not true for the majority of types of constants; it only is for type 4 above, and then only if you're writing C. And nobody I know writes type 4 constant in ALL_CAPS --- nor have I ever seen anyone advocate doing so.

C++ changed this, partly in an effort to reduce the use of the preprocessor for things that C++ has supposedly better means for. So in C++ statically allocated, "const" flagged numericals are full constants, not just variables that code is forbidden to manipulate. This combination of features is new, so it's a new stylistic decision whether to spell them like C constants, or like C const variables.

I know many people use all caps for preprocessor macros, and some (far fewer) do so for enum values. But what is the point? /Why/ use all caps for these?

To me, "all caps" is shouting - it is a warning that there is something odd going on here. That makes sense if you have, for example, a macro that is defined on the command line rather than in the source code. Or if you have a macro that /looks/ like a function, but does not behave properly - perhaps it evaluates its arguments twice, so you need to be careful in using it.

But what is special about a literal value macro? If you write

#define noOfWotsits 23

why should you worry about using noOfWotsits in code? It has no need of a warning. It is true that you can't take its address, or assign a new value to it - but that would not make logical sense in the program, and the compiler will tell you that it can't be done. You don't need to shout at the reader or programmer to let them know. All you do is make it harder to read the rest of the program, and make /really/ dangerous macros harder to spot in the noise.

Exactly correct. For some types of "constants", you can't change them in /any/ part of the code - but the relevant point in the code you are working on here and now, is that they cannot change here and now.

Note that in both C and C++, if an object is /defined/ as const, then code cannot change them - they are not variables. The compiler can assume they will never change, and optimise accordingly - just like any of the other types of constants mentioned above. (This is distinct from casting something to const, or using a pointer-to-const, where you are just promising not to change them through the const version.)

The only difference between C++ and C here is that in C++, objects of literal types (including POD types) that are defined as const are considered constant expressions and can be used in things like array sizes, switch expressions, and templates.

but there is something odd going on here

there's a textual replacement being undertaken, not a function call. This may result in odd behaviour if the author hasn't defined their macro properly

tim

Op 06-Mar-16 om 9:17 AM schreef tim...:

If something hasn't been designed properly all bets are off.

The point is that a straightforward macro or constant doesn't need special attention from the reader. What does warrant special attention is something that doesn't behave as a constant or function call. SUCH a macro (if used at all!) deserves CAPITALS.

Wouter "object? No thanks!" van Ooijen

That's not "odd", it is a common part of the language.

If the author has done something silly, like write

#define noOfWotsits = 123;

(probably everyone has done that at least once)

then the compiler will complain. You don't need to use all-caps to warn the reader about things that the compiler will warn about anyway.

I was more thinking of:

#define noOfWotsitsB noOfWotsitsA + 1

and then doing:

x = noOfWotsitsB * 2;

tim

That is a mistake in the definition of noOfWotsitsB, not a mistake in its use. You don't need to have all-caps to warn about using noOfWotsitsB - you need to understand how to define such macros properly:

#define noOfWotsitsB (noOfWotsitsA + 1)

Using all-caps puts the emphasis and warning about possible mistakes in the wrong place.

I don't use all-caps to warn me about possible mistakes (!?) in my code. I use all-caps to clearly show in the source that the thing is not what it seems to be (regular variable or function call) but something different (may be just a simple constant but may be as well A LOT of code behind). This is what I want to know when seeing all-caps, this is what I intend when using all-caps.

Op 06-Mar-16 om 5:58 PM schreef snipped-for-privacy@gmail.com:

A function call can also have LOT of code behind it, so that doesn't seem to be a good justification to me.

Wouter "Objects? No thanks!" van Ooijen

duminic?, 6 martie 2016, 19:26:17 UTC+2, Wouter van Ooijen a scris:

n

. I use

ems to be

t t

ll-caps.

You didn't understand the detail: it's about what it looks like not what it really is. And for me a function call and LOT of inline code is different. Sometimes matters, sometimes not, but I want to see a difference when I loo k at it.

Op 06-Mar-16 om 6:35 PM schreef snipped-for-privacy@gmail.com:

A function call can BE a lot of inline code, that is up to the compiler to decide.

But your 'lot of code' aqrgument doen't match

#define number_of_objects 100

So you'd agree that such a macro should not be SHOUTING? (Apart from that is shouldn't be a macro in the first place...)

Wouter "Objects? No thanks!" van Ooijen

What I see being worth the warning is that it is a name that isn't confined by scope. As such, you need to think much more carefully about such names, and making them distinct typographically, you get less things that might conflict in usage.

On the contrary, when I see "number_of_objects" in the code I think it's a variable. If I see "NUMBER_OF_OBJECTS" I think it's a constant. They are very different things (for variables I will start thinking of where it is defined, is it properly initialized, why is it a variable (when is it changing) etc,) all-caps are a very cheap and fast "documentation" for that.

The lack of scoping is certainly one reason to prefer alternatives (especially "static const") to #define'd values, when possible. But is it a reason to make #define'd literals all-caps? Not in my opinion. Their scoping is not really much worse than anything else defined at the file level. If you define "static const int noOfWotsits = 12;" at file level, its scope exists throughout the file from that point onwards - just as if you used "#define noOfWotsits 12". You /can/ shadow the "static const" name with a different object of the same name within a function, and you /can/ define a struct called "struct noOfWotsits" - but doing so would generally be viewed as a bad idea.

What about "static const int number_of_objects = 100;" ? It is a constant, just as much as if you had used #define. The compiler will treat it as a constant (though not a "constant expression - you can't use it for an array size), and optimise it as being fixed and known at compile-time. Should it also be all-caps to be consistent with #define's? Should it be in normal text to be consistent with variables?

The CAPS vs nocaps is totally a style issue. If you work alone, pick a style and be consistent.

If you work in a group, there should be a style guide. Again, most important is to keep your style consistent.

If you maintain someone else's code, use their code style. IOW, keep any changes in the same consistent style.

I have worked many places and seen many coding styles in several programming languages. They all work IF you are consistent.

ed

That is all true - and keeping a consistent style is typically more important than the details of the style.

But the issue under discussion is whether or not using all-caps for simple macros is a good style with benefits and justification beyond just "other people do it". Imagine you were writing a new style guide for a new team on a new project, rather than following an existing one.