Hello, and welcome to C++ Weekly.
I'm your host, Jason Turner.
Now in this episode, I am going to try
to convince you to stop doing something
that I know that you are currently doing,
because virtually everyone is.
And to be fair, I regularly used to do this as well myself,
until I realized it was a bit of a problem.
We are using GCSE trunk right now,
not for any particular reason.
I'm just basically using Compiler Explorer as an editor
at this exact moment.
So I know that at your header files,
you like to do something like this.
Unfortunately, you've just invoked undefined behavior.
This might seem, why in the world is this a problem?
So let's just go ahead and flip over
to the standard, real quick.
And today, I'm looking at the ill.is online site
that lets us look through the current draft standard.
And don't think that this means that this is actually
from like an old, or brand new, copy of the standard,
or something like that.
Like, this is something that has been true since the beginning
of C++.
So we're in the lex.names section of the standard.
And if we scroll down here, we see each identifier
that contains a double underscore is
reserved to the implementation for any use.
So if we come back here then, we know
that this is reserved to the implementation
for any use at all.
I can't, I can't do this.
If I do this, then I'm invoking undefined behavior.
I have to remove these double underscores.
And well, I mean, even if I have them in the middle it had,
cannot contain a double underscore anywhere
in the identifier.
And so, well, that's kind of just the beginning
of the problem.
I also know that many of you like to do this.
You want to say, oh, this is my private data.
And well, now we get into the next bit the bit,
that I glossed over.
Where it says or begins with an underscore,
followed by an uppercase letter, is
reserved to the implementation for any use.
And you say, well, that's fine.
I'm not doing either of those things.
But perhaps you're doing something
like this, which I know some people like to do.
People like the underscores.
They like preceding things with underscores a lot.
And now we get to the next bit here.
Each identifier that begins with an underscore
is reserved to the implementation for use
as a name in the global namespace.
OK.
So there's no less than three different ways
that we can invoke undefined behavior here, basically.
Because if these are reserved for the standard,
for the implementation-- so they're reserved
for the compiler and they're reserved for the standard
library--
and we use them, we might be accidentally
conflicting with things that the standard library
is defining for us.
And there's lots of places where the compiler defines
things for us.
It creates hidden objects, and we've
played with some of these in the past, when I've
talked about peeking behind the curtain and GCSE,
when working with a ranged for loop and such.
So the compiler is free to create things
that begin with underscores.
The standard library basically must
use everything that begins with underscores, because it's
trying to protect themselves from us.
So if I do something like this, pound defined
underscore underscore data to 42,
there's a very good chance that somewhere
in our standard library implementation,
there is a value, an identifier, that
is underscore underscore data.
And if we do this as a pound define to 42,
we're probably conflicting with something
the standard library is doing, and we've just
broken our standard library implantation.
We're not allowed to do this.
So stop doing it.
Stop using these double underscores anywhere.
And the simple rule is to say, stop doing leading underscores
at all.
Because otherwise, keeping track of whether this
is global namespace, or some local namespace or whatever,
it's just not worth it.
So you know, you're free to do like trailing underscores,
if you really want to.
I know, in my best practices document,
I do something like this.
A lot of people don't like that.
You know, it's up to you.
Just pick something that isn't this.
Because you don't want to invoke undefined behavior.
So thank you for watching this episode of C++ Weekly.
I hope you enjoyed it and learned--