more auto_ptr confusion

[Bo Persson]

Why would it be loading it into an address register?

Because the calling convention specifies that the 'this' pointer is
passed in an address register.

Answer: it wouldn't. A call to A_x in the case when it is not
virtual
is resolved by the compiler. The result is the same as calling a
function. It wouldn't load into an address register because no
address
is accessed...not the one you are thinking is anyway.

So the standard specifies how address registers are handles in
function calls?

No, it doesn't. It is unspecified!

You are forgetting that the source code and the machine code do not
have to be at all equivelant. In these cases a-> doesn't actually
result in machine code that accesses a pointer...it results in a
function call that is passed a pointer.

And how is the pointer passed to the function?

It could be implemented so that all function calls really result in
something like:

It *could*, but the standard doesn't specify this, so it is undefined!


Bo Persson

 

[Noah Roberts]

Because the calling convention specifies that the 'this' pointer is
passed in an address register.

Cite please.

 

[liam_herron]

Here is a second example that crashes as expected:

#include <iostream>
#include <memory>

class A {
public:
A(double value) {
dynAllocMem = new double;
*dynAllocMem = value;
}
~A() {
delete dynAllocMem;
}
void say_hi() {
std::cout << "hi!" << *dynAllocMem << std::endl;
}
void say_ih() {
std::cout << "!ih" << *dynAllocMem << std::endl;
}
private:
double *dynAllocMem;

};


void f(std::auto_ptr<A> fs_pa) {
fs_pa->say_hi();
}

int main() {
std::auto_ptr<A> pa(new A(1.0));
pa->say_ih();
std::cout << &A::say_hi << std::endl;
f(pa);
std::cout << &A::say_hi << std::endl;
std::auto_ptr<A> pa2(new A(2.0));
pa->say_ih();
}

themachine:test $ ./a.out
!ih1
1
hi!1
1
Bus error



Hopefully that demonstrates the issue using a dynamically allocated
member variable as opposed to the vtable.

 

[Noah Roberts]

Here is a second example that crashes as expected:

Hopefully that demonstrates the issue using a dynamically allocated
member variable as opposed to the vtable.

Yes, anything that accesses a member variable of a that isn't static
will cause a crash in all implementations I know of due to the reasons
I mentioned. Anything else is very likely not to...for the reasons I
mentioned.

In the end this means undefined behavior does not necissarily mean a
crash all the time nor does it mean "unpredictable". All it means is
that the standard does not define what will happen, if anything. We
know what will occur in most, if not all, implementations and don't
have to pretend we don't even if the standard doesn't qualify what
happens. Sure, according to the standard you could suddenly give birth
to numerous nasal demons because you illicit undefined behavior in your
compiler...but that is a highly unlikely scenario in real practice.