Keywords vs identifiers with special meaning!!!

Using a keyword as an identifier is a very bad idea. It may work with some compilers and not others. It make work in certain contexts and not others.

Most compilers are driven by a state machine. The state machine determines what tokens are expected in a certain context.

in some case as a 'normal' identifier would be beneficial.

How would it be beneficial? It would only serve to be confusing to a reader other than yourself. In general most variables should be nouns. delete is a verb (adds to the confusion).


namespaces should keep you safe.
you can make my::cout that is different from std::cout for example.

this seems like a bad idea to me, but its safe and doable.

that said its almost unpossible to NOT occasionally use a std::word by accident. There are so many of them. But do your best to not over-ride the common ones as that will confuse the reader of your code badly, even with the namespace, and worse, if someone used the namespaces, it would be a big mess to read and unravel.

keywords are something else. see above... I would not do that at all.
Last edited on
It's very likely that it would make the syntax ambiguous. For example:

1
2
3
4
5
6
void delete(int *ip) { cout << *ip;  }

int main() {
    int *ip = new ip;
    delete(ip);           // keyword delete or function call?
}


If you want to use a keyword as an identifier, just capitalize it:
1
2
3
int Delete;
char Switch;
extern void While(int Do, const string &Include);


In general most variables should be nouns
Not all identifiers are variables.
I think you are misunderstanding Vindieselwalker. I think he's talking about identifiers like override and final that has special meaning in certain contexts but is otherwise free to use as an identifier for your variables, functions, namespaces, etc.

-------------------------------------------------------------------------------------------------------------------------------------------

To me it seems like "identifiers with special meaning" are just a way to be able to use names that can't be made keywords because it would break too much existing code. In the case of delete I don't even think it would be possible (unless you use some very complicated rules that makes it only available as a normal identifier under certain conditions) because delete ptr; could then mean both delete the object that ptr points to and a variable of type delete named ptr.

I think the problem of making new keywords are shown by the current discussion around the coroutine keywords co_await, co_yield and co_return, that are planned for C++20. A lot of people don't seem to like the co_ prefix of these keywords. You might find it interesting reading a proposal to allow yield, await and return to be used a inside coroutines if it's marked with async, without making them proper keywords. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1485r0.html
Last edited on
It turns out the original OP (Vindieselwalker) is a spammer! He's just copying recent posts by various authors from reddit and later adding his own spam links.
Original post: https://www.reddit.com/r/cpp/comments/b6huaz/keywords_vs_identifiers_with_special_meaning/
Last edited on
I really don’t get behavior like that.

Why would a person go through all the trouble to create an account and post this stuff?
Is he getting some kind of remuneration for it?

Because I cannot imagine someone is so stupid to believe that they can keep a charade like this going, particularly among people who have expertise in programming, and among whom at least one will recognize the lie almost immediately.
Well, I only saw one of the spammer's posts and didn't immediately see that it was a spammer until I saw the other threads. If enough time or post count passes, then even experienced users can't remove the spam, and the account can keep spamming until twicker disables the account. I guess the goal is to hope that spam gets disguised by the noise of a busy forum, but this forum isn't that busy.
Last edited on
Topic archived. No new replies allowed.