In C++ a statement like this is valid:
&Variable;
IMO it doesn't make any sense, so my question is, if you do this, will it affect the compiled result in any way, or will the compiler optimize it away?
Thanks!
+1
A:
That depends entirely on the compiler and the compilation options you use. There is nothing in the C++ Standard to prevent a compiler from generating code for such a statement.
anon
2009-07-17 10:05:59
thanks! in my case i use VS 2005.
clamp
2009-07-17 10:09:03
It will most probably be optimised away.
Goz
2009-07-17 10:10:32
Does the C++ standard say anything about generated code?
Steve Jessop
2009-07-17 10:50:03
Not that I'm aware of.
anon
2009-07-17 11:06:08
Good. My plans for a fully-interpreted C++ implementation are still on track ;-)
Steve Jessop
2009-07-17 11:31:43
Combining a normal C++ implementation and an emulator for the target system give you an interpreted C++ implementation. Without any of the advantages of an interpreter.
AProgrammer
2009-07-17 12:40:23
Nah, that doesn't count as interpreted. It can't implement "eval" as an extension unless the emulated OS's compiler is included in the host. Minimum acceptable usage: `eval("#include <iostream>\nvoid doit() { std::cout<<\"hello world\n\"; }","doit");` This should behave like writing the string to a file, compiling it to a dynamic library, linking it, opening its symbol table, looking up the function pointer and calling it ;-)
Steve Jessop
2009-07-17 15:49:01
Ideally you'd want to eval one-liners operating on the current local context, of course...
Steve Jessop
2009-07-17 15:50:03
+6
A:
It's worth remembering that operator&() might be overloaded for the variable type, have some side effects and optimizing away such statement would change program behaviour.
One example is a smart pointer used for controlling the non-C++ objects - _com_ptr_t. It has an overloaded _com_ptr_t::operator&() which checks whether the pointer inside already stores some non-null address. If it turns out that the stored address is non-null it means that the pointer is already attached to some object. If that happens the _com_ptr_t::operator&() disconnects the object - calls IUnknown::Release() and sets the pointer to null.
The side effect here is necessary because the typical usage is this:
_com_ptr_t<Interface> pointer;
// some other code could be here
CoCreateInstance( ..., &pointer, ...);// many irrelevant parameters here
CoCreateInstance() or other object retrieval code has no idea about C++ and _com_ptr_t so it simply overwrites the address passed into it. That's why the _com_ptr_t::operator&() must first release the object the pointer is attached to if any.
So for _com_ptr_t this statement:
&variable;
will have the same effect as
variable = 0;
and optimizing it away would change program behaviour.
sharptooth
2009-07-17 10:09:29
+1 good answer. That property of _com_ptr_t bit me in the arse once royally - I'd prefer if it that functionality would be in a member function.
peterchen
2009-07-17 13:35:26
What i wanted to say - you might want to add that without overload it is likely to be optimized away
peterchen
2009-07-17 13:36:34
+1
A:
Do you want to remove it, but are worried that you may alter the behavior of the program?
It could have side-effects if Variable's class overrides the address-of-operator (operator&).
Kim Gräsman
2009-07-17 10:09:38
Well, understand my comment as critic about C++ in general. In short: the concept of operator overloading at all is one cause of very subtle bugs in C++; without it nobody would even consider writing as a statement.So the only possibility to check if it's operator overloading or not is checking the assembly or reading through all header files which are in scope, really great!So my conclusion in general is: operator overloading is a big DON'T in C++ and I judge that C++ code is bad once it uses it. Honestly, I only tolerate a very small C++ subset...
anselm
2009-07-17 12:12:40
+9
A:
Consider this snippet:
#include <iostream>
class A {
public:
A* operator &() {
std::cout << "aaa" << std::endl;
return this;
}
};
int main() {
A a;
&a;
return 0;
};
In this case, "&a;" will generate code.
Alex B
2009-07-17 10:13:07
+1
A:
Yes, such statement is likely to be optimized. It means to take a reference to variable and throw it away. While at 'no optimization' setting your compiler may generate some code for this statement, it is essentially no-op and with optimization this statement should go away.
Nopik
2009-07-17 10:14:05
A:
It seems you take a reference to a local variable on stack or register. The best way to find out what the compiler does at the moment is to view the Disassembly view in Visual Studio.
zproxy
2009-07-17 10:17:22