In C++, how does one rename a variable midway through a block? References and macros feel wrong.


the best option you have is to just create a new variable and set it equal to the old one then delete the old one. though I can't imagine why you would want to

You can't *delete* a vairable. Even if variable is a pointer, and you call *delete* on it, variable still will be here, although you'll free a memory block.
sure if you want to be pedantic, but anyone who is a c programmer understands that when you call delete you're not technically deleting anything, just freeing memory. sorry I was loose with my vocabulary.
+1  A: 

I guess you could do something awful like:

int _internal;

#define foo _internal
foo = 3;
#undef foo
#define bar _internal
std::cout << bar;

However I can see no good reason for this, ever.

I should point out that the fact that I made an error the first time I wrote this clearly indicates that this is something that should never be done.
+8  A: 

Use a reference.

int old_name = 1;
// ...
int& new_name = old_name;
new_name = 2;

But why do you want to do this?

but it feels wrong
probably because doing so serves no purpose?
Jon Cage
Sometimes it can be helpful for clarity. Rather than take an argument by reference and make an explicit copy to use as the return value, you can take the argument by value and create a reference to give it a more output-y name for the duration of the function.
Cogwheel - Matthew Orlando
Also, by making the copy implicit, you free the compiler to make certain optimizations it otherwise might not.
Cogwheel - Matthew Orlando
+11  A: 

You can't.

But you can make a reference to it and access it under different "name". If you really don't like the variable, just go out of current block, return from the function, leave the block.

+1. "You can't" is really the only correct answer to this question.
Logan Capaldo

Personnally, I think you should pick a name and stick with it throughout. When you go back and read your code more than a few weeks later, you're going to be scratching your head wondering what you were thinking. If you don't like the name you picked after you got going with your method or class, most IDE's provide some refactoring capability that you should be able to use to make the change quickly, completely, correctly and more or less painlessly. If you are using the same variable to perform multiple distinct purposes, then you should be using more variables, one for each of those distinct purposes.

+1  A: 

If the purpose of the variable changes half-way through the block, you probably want to split the block into two methods/functions, and pass the variable into each as a parameter.

Or, if the first half of the block generates the variable's value and the second half consumes it, then have the first function return the variable, and the second function use it.

(Edit) Also note, you can avoid temporary name clashes by putting local variables inside extra block definitions: e.g...

int x()
    int y = 0;
        int i = /* create i */;
        y = compute_y(i);

    int z = 0;
        int i = /* create another i */;
        z = compute_z(y, i);
    return z;

In this function, the variable i can be declared twice, in different sub-blocks and the names won't clash since the first i will go out of scope before the second i is created.

Personally, if I have functions big enough to need this kind of scoping, I would split it into multiple smaller functions instead, as I mention above.

Pat Wallace
+1  A: 

I'm with the others here - why would you want to do this? Because it is hard to imagine a sound reason. It is always possible there is a rational reason so offer it up.

There are good reason for the negative responses here. Doing what you are asking for could easily become a maintenance nightmare. There are plenty of words in the English language to properly name a variable and as a programmer you can make up your own.

In any event this is sort of like calling your daughter Jill since birth and then suddenly changing her name to Suzie on her thirteenth birthday. In effect causing troubles when your troubles are just beginning.


David Frantz