Why can't variable names be larger than 31/63 characters?
"only the first 31/63 characters of a variable name are significant".
Why specifically this number? And why is there a limit anyway?
Why specifically this number? And why is there a limit anyway?
| C requires that at least the following limits are supported by any standard-compliant implementation: (< C99) 31 significant initial characters in an internal identifier or a macro name (>= C99) 63 significant initial characters in an internal identifier or a macro name |
Also, this limitation applies only to C. C++ requires implementations to support identifiers of arbitrary length.
| Why specifically this number? |
| And why is there a limit anyway? |
|
|
a second answer is efficiency.
if you put a limit on it, the compiler writer can exploit that and possibly make a better product.
perhaps the c++ compiler you use is written in C, and the author wants to use char[64] as the type for variable tokens, instead of allocating a pointer that is grown to the correct size for each token. The array is safer (less prone to bugs ) and now there may be places where things are more efficient; for example if the compiler produces an intermediate file for the linker, and that format uses binary/serialized structs as the file format, with the structs containing fixed sized tokens, its just a read() call. If the binary data were variable in length, they have to parse something to figure out how to handle it, much more code needed than a read() call.
Variable sized things are nice when you need them, and often one does need them. But they charge you an overhead cost in dealing with that dynamic size. You see this in c++ all the time when you try to write a class with a STL container or strings to a file and have to take extra steps to handle that.
if you put a limit on it, the compiler writer can exploit that and possibly make a better product.
perhaps the c++ compiler you use is written in C, and the author wants to use char[64] as the type for variable tokens, instead of allocating a pointer that is grown to the correct size for each token. The array is safer (less prone to bugs ) and now there may be places where things are more efficient; for example if the compiler produces an intermediate file for the linker, and that format uses binary/serialized structs as the file format, with the structs containing fixed sized tokens, its just a read() call. If the binary data were variable in length, they have to parse something to figure out how to handle it, much more code needed than a read() call.
Variable sized things are nice when you need them, and often one does need them. But they charge you an overhead cost in dealing with that dynamic size. You see this in c++ all the time when you try to write a class with a STL container or strings to a file and have to take extra steps to handle that.
Last edited on
| only the first 31/63 characters of a variable name are significant. |
int thirtyOneCharactersIsReallyLongForAnIdent;The real question is "why are you using such enormous variable names?" They will really distract you from actually writing the code.
| Jonnin wrote: |
|---|
| a second answer is efficiency ... |
Hmm, so it would take longer to compile. I didn't realize that. Thanks.
Last edited on
Just because your last post has me a bit worried... please don't make unnecessarily short variable names for fear of long compile times. A compiler does MANY things, and the length of the variable name is positively insignificant except in the extremes.
Naming is hard enough as-is. Don't make it harder than it needs to be. Have a long-enough identifier to clearly communicate what the variable is.
https://www.youtube.com/watch?v=MBRoCdtZOYg
Naming is hard enough as-is. Don't make it harder than it needs to be. Have a long-enough identifier to clearly communicate what the variable is.
https://www.youtube.com/watch?v=MBRoCdtZOYg
| thirtyOneCharactersIsReallyLongForAnIdent |
Try to make names as short as possible, as succinctness is key in effective communication, but if it's a choice between making them shorter and making them easier to understand, choose the latter.
Hmm, so it would take longer to compile. I didn't realize that. Thanks. |
It would (possibly, most likely) take longer IF the compiler and standard allowed infinite length tokens due to having to handle that capability.
It does not.
But, one letter or 63 letters, it is equally efficient with a known max size (this is what we have).
Its just a rule of thumb, but again, most of the time having variable length support for data, you pay a penalty for it (this penalty could be microscopic or fairly stiff depending on the specifics from there).
Ok, technically 2 letters will take twice as long as 1 for some operations, but now we are down in in the billionths of a second realm. The variable length memory juggling is up in the milisecond realm, and adds up in larger programs.
Last edited on
Topic archived. No new replies allowed.