value for member of non-instantiated class?

[wretch]

I was sort of expecting this code to blow up, but it doesn't. What does accessing a class member do if the class is not instantiated yet? In this example, I think the only memory that has been allocated is for a pointer, there has been no memory allocated for an integer? It prints garbage, but it prints something.

#include <stdlib.h>
#include <string>
#include <iostream>

using namespace std;

class mainClass {
public:
    int mainInt;
};

int main() {
    mainClass *mc1;
     
    cout << "intValue: " << mc1->mainInt << "\n";
    cout << "exiting normally" << "\n";
    
    return (0);
}

[helios]

You're dereferencing an invalid pointer. Never do that. If it didn't crash this time, it may crash the next.

[wretch]

It's interesting how different systems treat this. In VC++ 2008 Express I get "run-time check failure #3 ... mc1 being used without being initialized". In gcc (MinGW) on Windows I get a value of zero, and in Netbeans/Linux I get a number but it's garbage.

Do C++ standards ever dictate what to do if something illegal is done (as in dereferencing uninitialized pointer)? Or do C++ standards only define what is legal vs. illegal, and then leave it up to the implementation to handle how illegal operations are handled?

[helios]

Do C++ standards ever dictate what to do if something illegal is done

It's not illegal from the language's point of view, therefore the standard doesn't define what should happen when an invalid pointer is dereferenced. This is known as undefined behavior. When undefined behavior occurs, anything -- and I mean anything -- could possibly happen. Modern OSs crash the program if it tries to access memory that doesn't belong to it, but it's not unthinkable that a system may actually let the program access the entirety of available memory. When that's the case, it's possible to overwrite anything. Other programs', system, or even BIOS data or code.

[kempofighter]

I remember trying this with visual studio and I thought that visual studio actually throws an exception. However, in that case I had at least initialized the pointer to 0. This is why pointer initialization is so important. Some systems might be able to catch the exception if the pointer is 0 initialized. If it is filled with random data, it would be impossible for an unmanaged application to figure out that the memory address is invalid because unmanaged applications don't have a way of double checking that the address refers to something that had been returned by a previous operator new call. that is one reason why unmanaged applications have better run-time efficiency but the trade off is that the developer has a huge responsibility to manage memory correctly.

I've seen situations where calls to functions using unintialized pointers actually resulted in reasonable looking data being returned! You could have a problem in your program and not even know it for months until you happen to be stepping through the code with a debugger.

[kempofighter]

Helios has got me thinking about "undefined behavior." I'd be surprised if an OS would allow memory to be overwritten outside of the program's address space. Real-time OS systems used in airplanes are required to be very secure. Even PCs should be secure enough to prevent applications from screwing up things like BIOS data accidentally. I'm not sure how the OS could prevent that but you would think that a good OS would prevent a defective application from destroying the PC accidentally. On the other hand, I don't know how that could be done. it is a very scary thought but I'm not a compiler or OS expert so I'm not sure how that type of dangerous side effect could be prevented, even by a really secure OS.

[helios]

OSs (at least x86 OSs) implement memory protection at the CPU level. IINM, the CPU produces an interrupt when a thread attempts to access memory it doesn't own. I imagine the OS sets the relevant parameters in the CPU through virtual memory and other black magicky things I know little about.
An OS running in real mode, such as ancient versions of DOS, has none of these protections, so any program can crash the entire system with little difficulty if something goes terribly wrong.