What you are talking about is really just the calling convention common on many machines. When you have a function returning a struct, what really happens is that the return address for the struct is passed as an extra argument. No construction of the struct happens prior to this, its just an address. Compilers are able to take advantage of this calling convention in many cases to elide copies, and the result is RVO/NRVO.
Are you alluding to some sort of hardware mechanism by mentioning machines? In what context are calling conventions machine dependent?
The reason it's notable in C++ is because the code that would normally be called in the constructor is not called as many times as the person writing the code might expect.
In C++ structs can have constructors, but usually have an empty default constructor supplied by the compiler, this is more of an issue when structs/classes have user supplied constructors.
Here's an article giving more specifics of the history of NVRO from Stan Lipmann. Interestingly, NVRO was not added to Visual C++ til 2003, and Lipmann prefers NVRO off by default. I think I recall an NVRO flag in that compiler. NVRO was available in cfront and Zortech compilers in the early nineties. [1]
The calling convention your compiler is using is dependent on a number of things [1]. It is this calling convention that dictates how values are returned from a function, not whether or not RVO/NRVO is happening. Also, what is being passed as an extra argument, according to many calling conventions, it not really an already constructed object, but an address for an object to be constructed into. Under certain situations the compiler is able to elide copes, which as you pointed out, leads to your copy constructor to never be called at all, even if it has visible side effects. I think these are important distinctions and hoped pointing them out would be beneficial.
Yes, thanks for pointing the calling conventions out, I didn't really know what you were getting at.
The hardware calling convention does dictate certainly what code the compiler can put out.
If the compiler does not support NVRO and emits code that causes multiple copy/constructions it doesn't matter if the hardware supports more efficient behaviour.
I edited my earlier comment with your correction, thanks.
