Is using basic underscores really a problem?
The C / C ++ standard preserves all identifiers that contain an underscore (plus an uppercase letter if not in the global namespace) or contain two or more contiguous underscores , Example:
int _myGlobal;
namespace _mine
{
void Im__outta__control() {}
int _LivingDangerously;
}
But what if I just don't care? What if I decide to live dangerously and use these "reserved" identifiers? How dangerous is it to live?
Have you ever seen a compiler or linker issue arising from the use of Reserved User IDs?
Below are the answers to the following questions: "Why break the rules when it can cause problems?" But imagine that you already have a set of rules that break the rules. At what point does the cost of breaking the rules outweigh the cost of refactoring your code to comply? Or what if a programmer developed a personal coding style that calls for wild underscores (perhaps coming from a different language, for example)? Assuming that changing their coding style was more or less painful for them, what would motivate them to get over the pain?
Or I could ask the same question in reverse order. What specifically specifies that C / C ++ libraries work with reserved words that a user might break? Do they declare global variables that can create name conflicts? Functions? Classes? Naturally, each library is different, but how could this collision even appear?
I teach software students who come to me with questions like this, and all I can tell them is "It's against the rules." This is a superstitious, hand-waving answer. Moreover, in twenty years of programming in C ++, I have never seen compiler or linker errors that result from breaking the rules of the reserved word.
A good skeptic, faced with any rule, asks, "Why should I care?" So: why should I care?
source to share
Results may vary depending on the specific job seeker you will be using. Regarding the "severity level" - every time you get an error, you have to wonder if it is from your implemented logic or because you are not using the standard.
But that's not all ... let someone tell you, "It's completely safe!" So you can do it without any problem (just assuming ..) Will this redefine your thinking when you hit a mistake, or would you still wonder if there is a little pause that he was wrong ?: )
So you see, whatever answer you get it will never be good. (which makes me really look like your question)
source to share
I'm wondering now because I just ran into a bad luck with underscores, a large and old codebase mostly targeting Windows and compiled with VS2005, but some of them compiled on Linux as well. While analyzing updates for the newer gcc, I have rebuilt some of them under cygwin just for syntax checking convenience. I got totally incomprehensible errors (to my tiny brain) from a line like:
template< size_t _N = 0 > class CSomeForwardRef;
This threw an error like:
error: expected ‘>’ before numeric constant
Google popped up on this error https://svn.boost.org/trac/boost/ticket/2245 and https://svn.boost.org/trac/boost/ticket/7203 both of them hinted that stray ones #define
might get in the way. Obviously, looking at the preprocessed source with -E
and looking for the include path included some .h-related (forget that) bits that were defined _N
. Later in the same odyssey, I ran into a similar problem with _L
.
Edit: Not bit related, but char -related: /usr/include/ctype.h
- here are some examples along with how you ctype.h
use them:
#define _L 02
#define _N 04
.
.
.
#define isalpha(__c) (__ctype_lookup(__c)&(_U|_L))
#define isupper(__c) ((__ctype_lookup(__c)&(_U|_L))==_U)
#define islower(__c) ((__ctype_lookup(__c)&(_U|_L))==_L)
#define isdigit(__c) (__ctype_lookup(__c)&_N)
#define isxdigit(__c) (__ctype_lookup(__c)&(_X|_N))
I'll be checking the source for all the underlined IDs and pushing through the renaming of all the ones we created with an error ...
John
source to share
How dangerous will I live?
Dangerous enough to break the code in the next compiler update.
Think about the future, your code may not be portable and may break in the future, as future versions of improvements from your implementation may have the exact same symbol name as you are using.
Since the question has a pinch of "It may be wrong, but how much and when it was ever wrong," I think Murphy's Law answers this quite aptly:
"Anything that can go wrong will go wrong (when you least expect it)." [#]
[#](
, )
- my invention, but not Murphy.
source to share
If you try to build code anywhere there is a conflict, you will see strange build errors or worse, build errors and incorrect runtime behavior.
I saw someone using a reserved ID that had to be changed when it caused build problems on the new platform.
This is not all that is possible, but there is no reason for it.
source to share