C++: Local variable etiquette

[EvilManagedCare]

I want to get more familiar working with pointers so I'm working on implementing a linked list in C++, for my own enrichment NOT any type of homework.

Anyway, as I do this I am finding for several functions I am needing a temporary pointer to a Node. Is it poor form to repeatedly declare these temporary pointers as the functions require them (seems very repetitious), or better to just go ahead and declare a sort of all purpose pointer as a private variable for my Linked List class? My concern over the latter is having a pointer to an address when it really shouldn't be pointing at anything after it's temporary job is done. Is this being overprotective? This would leave me continually resetting the pointer's value to null. Is it really even necessary to do that all the time?


Thanks for the help.

 

[Ken g6]

My concern over the latter is having a pointer to an address when it really shouldn't be pointing at anything after it's temporary job is done.

That's the right thing to be concerned about, but that's not the only reason for concern. See, a local variable can go in one of two places. It can always go in a space on the stack. Adding one extra local variable on the stack only requires increasing the size of the memory allocated from the stack by the size of that variable. It doesn't change the runtime at all unless there were no other variables allocated. But if a local variable is not referenced by any pointer, it can go into a register instead. A class-level variable has to go in memory. And register access is much faster than even L1 cache memory access.

This would leave me continually resetting the pointer's value to null.

That's something you should be doing either way. It's good practice to initialize local variables at their declaration. There's no real advantage to a class-level variable, and there are serious disadvantages. So go ahead and make a local pointer in each function.

 

[IHateMyJob2004]

Implement your software in the most elegant way possible. If performance becomes and issue, fix it. Don't fix problems that do not exist.

So, bottom line. Write code that is easy to understand (and maintain)

<== 10 years softwre engineering

 

[GodlessAstronomer]

Never, ever, ever reuse global/class-level variables unless you have an extremely good reason. Variable are not a non-renewable resource, you're not saving the world. Use as many variables as you need and don't use a variable for more than one purpose, because it will lead to programming errors.

 

[Markbnj]

I want to get more familiar working with pointers so I'm working on implementing a linked list in C++, for my own enrichment NOT any type of homework.

Anyway, as I do this I am finding for several functions I am needing a temporary pointer to a Node. Is it poor form to repeatedly declare these temporary pointers as the functions require them (seems very repetitious), or better to just go ahead and declare a sort of all purpose pointer as a private variable for my Linked List class? My concern over the latter is having a pointer to an address when it really shouldn't be pointing at anything after it's temporary job is done. Is this being overprotective? This would leave me continually resetting the pointer's value to null. Is it really even necessary to do that all the time?


Thanks for the help.

Don't worry about saving stack space for local variables. It's almost never important and if it ever is you'll know it. The thing you want to be considering is scope. Scope for a given name is the part of the program in which that name is visible and can be referenced in expressions/statements. You can think of scope in a hierarchy from top to bottom, or from broadest to narrowest visibility.

If I recall correctly, the broadest scope in a C++ program is file scope. Variables declared at file level, i.e. outside any class declaration, are visible to every expression in the file. This includes variables declared outside any class declaration in included headers. The next would be class scope, in which declared variables are visible to other members of the class, then function (called 'local scope') in which a variable is visible from the point of its declaration to the closing bracket of the function, and finally block scope, in which variables are visible from their point of declaration to the closing bracket of the block.

What you should do is push your variable declarations down to the lowest scope that you can. Don't make the mistake of thinking that, because you use an int in one place, and another int for the same purpose in another place, that you should maybe collapse those two declarations into one at class scope. What you have done in that case is make it possible for state to be carried between those two places when it shouldn't be. It doesn't matter how often you declare and use temporary pointers in various places. If the _contents_ of those pointer variables do not need to be carried from function A over to another operation in function B then they should be separate variables declared at local scope. If you do need to transmit the state then of course the pointers aren't temporary at all.

It's permissable, and can even be good practice and reflective of good design, to use private class fields to carry state while an object is being used, but again you should only persist at class scope those items that truly need to be stored for the lifetime of the object. In general it is better to pass state around from call to call on the stack (i.e. as arguments to the call and return values).

 

[xtknight]

I have implemented doubly-linked linear and circular lists for my C++ class.

I think you are asking whether it would be faster to have a global variable that can be reused instead of redeclaring a local one every time? I'm not sure about this...

And although it's poor practice, leaving a pointer in memory pointing to something that doesn't exist won't cause any problems, as long as it's not referenced, and as long as that memory to which the pointer is pointing has been freed somewhere else (and it should be as long as you have a proper destructor). A pointer is just a long with a value inside of it. Whenever you make ints, longs, or chars, there will be a random value in there already to begin with, anyway, until you initialize it! So it really doesn't matter that there's a long in memory with some value in it. The memory for the long (pointer) itself will be freed, and what it's pointing to will be freed by the destructor of the linked list.

Markbnj, there can also be program scope. So, a global variable could be declared in one file and accessed in another C++ file as long as it's "prototyped" in that other C++ file, kind of like functions. Perhaps we could also differentiate between static and non-static class variables by saying class and instance scope, too...

 

[Markbnj]

Markbnj, there can also be program scope. So, a global variable could be declared in one file and accessed in another C++ file as long as it's "prototyped" in that other C++ file, kind of like functions. Perhaps we could also differentiate between static and non-static class variables by saying class and instance scope, too...

I might be picking nits, but I would say that the variable has been declared in each namespace separately, and that the declared name of the variable in one namespace is mapped to a definition in the other that has external linkage. You don't have a true program scope like BASIC did, for example (and a damn good thing, too).

 

[IHateMyJob2004]

Also, everyone needs to remember that modern compilers will make things faster before you will.