views:

355

answers:

10

e.g.

int a=3;//-----------------------(1)

and

int a_long_variable_name_used_instead_of_small_one=3;//-------------(2)

out of (1) and (2) which will acquire more memory space or equal space would be aquire?

+1  A: 

In modern compilers the name of a variable does not impact the amount of space that is required to hold it in C++.

wheaties
Even in older compilers, AFAIK. C++ never had any introspection feature. :)
Matteo Italia
+6  A: 

Both occupy the same amount of memory. Variable names are just to help you, the programmer, remember what the variable is for, and to help the compiler associate different uses of the same variable. With the exception of debugging symbols, they make no appearance in the compiled code.

Nick Meyer
Since he has tagged the question as language-agnostic (among others), how about languages that support reflection at runtime?
Space_C0wb0y
Or languages that use a simple map from variable name to value to lookup variables (I'm sure there are interpreted languages that do that)
sepp2k
@sepp2k: For example, global variables in Lua are looked up using a hash map.
DeadMG
Notice that, instead, class/struct names may matter if you enable RTTI, since their names in this case must be stored in the executable. EDIT: just to make it clear, I'm talking about C++.
Matteo Italia
@Space, @sepp2k: originally it was just tagged as C++.
Nick Meyer
+5  A: 

The name you give to a variable in C/C++ will not affect the size of the resulting executable code. When you declare a variable like that, the compiler reserves memory space (in the case of an int on x86/x64, four bytes) to store the value. To access or alter the value it will then use the address rather than the variable name (which is lost in the compilation process).

Martin Törnwall
A: 

No.. Both will occupy the equal space..

liaK
+2  A: 

If my understanding is correct, they'll take up the same amount of memory. I believe (and am ready to get shot down in flames) that in C++ the names are symbolic to help the user and the compiler will just create a block of memory sufficient to hold the type you're declaring, in this case an int. So, they should both occupy the same memory size, ie, the memory required to hold an address.

Rob Lowther
+6  A: 

In most interpreted languages, the name would be stored in a table somewhere in memory, thus taking up different amounts of space.

troelskn
+15  A: 

In C++ and most statically compiled languages, variable names may take up more space during the compilation process but by run time the names will have been discarded and thus take up no space at all.

In interpreted languages and compiled languages which provide run time introspection/reflection the name may take up more space.

Also, language implementation will affect how much space variable names take up. The implementer may have decided to use a fixed-length buffer for each variable name, in which case each name takes up the same space regardless of length. Or they may have dynamically allocated space based on the length.

Ferruccio
@Ferruccio: for C++, this depends if you compile with symbols or not. For debugging core dumps, I appreciate my symbols to be shipped in the binary / library, in this case however long names may affect the size (even though ONE long name wouldn't really...)
Matthieu M.
yes, it makes the file size bigger, bit it's not going to take any more memory unless you run it under a debugger
Ferruccio
+1  A: 

Field names (instance variable names) in Java use memory, but only once per field. This is for reflection to work. The same goes for other languages that are based on the JVM, and I guess for DotNet.

Thomas Mueller
+1  A: 

For C++,

$ cat name.cpp
int main() {
    int a = 74678;
    int bcdefghijklmnopqrstuvwxyz = 5664;
}
$ g++ -S name.cpp
$ cat name.s
        .file   "name.cpp"
        .text
        .align 2
.globl main
        .type   main, @function
main:
.LFB2:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $8, %esp
.LCFI2:
        andl    $-16, %esp
        movl    $0, %eax
        addl    $15, %eax
        addl    $15, %eax
        shrl    $4, %eax
        sall    $4, %eax
        subl    %eax, %esp
        movl    $74678, -4(%ebp)
        movl    $5664, -8(%ebp)
        movl    $0, %eax
        leave
        ret
.LFE2:
        .size   main, .-main
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.4.6 20060404 (Red Hat 3.4.6-11.0.1)"
$ 

As you can see, neither a nor bcdefghijklmnopqrstuvwxyz reflect in the assembler output. So, the length of the variable name does not matter at runtime in terms of memory.


But, variable names are huge contributors to the program design. Some programmers even rely on good naming conventions instead of comments to explain the design of their program.

A relevant quote from Hacker News,

Code should be written so as to completely describe the program's functionality to human readers, and only incidentally to be interpreted by computers. We have a hard time remembering short names for a long time, and we have a hard time looking at long names over and over again in a row. Additionally, short names carry a higher likelihood of collisions (since the search space is smaller), but are easier to "hold onto" for short periods of reading.

Thus, our conventions for naming things should take into consideration the limitations of the human brain. The length of a variable's name should be proportional to the distance between its definition and its use, and inversely proportional to its frequency of use.

Lazer
Superb answer........thanks
Guri
A: 

compilers are there for a reason... They optimize code to use a little space as possible and run as fast as possible especially modern ones.

Adam