Nasty fun things to do in C++ (AKA Things not to do in C++, AKA How to shoot yourself in the foot in C++):

Do you ever need to access private data members/functions in a class? Are you frustrated that you aren't allowed to do that? No problem - Just put this at the top of your source file:
#define private public
By re-defining private as public, you'll be able to access the private members of an object!

Do you think references are safe? Think again! Consider this code: ////////////////////////////////
int *dynamicInt = new int(3);
int& intRef(*dynamicInt);
cout << "intRef (1): " << intRef << endl;
delete dynamicInt;
cout << "intRef (2): " << intRef << endl;
////////////////////////////////
After executing 'delete dynamicInt;', your program is likely to crash when you try to use intRef again!

Do you think 'const' always guarantees constness? Think again! The const_cast operator can be used to remove constness. Consider this function:
void someFunc(const string& aString)
{
string& str(const_cast<string&>(aString));
str = "Hello";
}
Now, the value of aString has been changed by the function!

These are just a few of the many fun things you can get away with in C++ and potentially shoot yourself in the foot!

Nightfox

Redefining private to public is such a cheap trick.... A real programmer will simply take the address of the object and offset into it. Encapsulation is nothing but a compiler contrivance designed to force people into using the proper interfaces.

Here is an example:

class TestData
{
public:
uint32 pubVal;
private:
uint16 priVal;
};

TestData dataObj;

char* dataPtr = (char*) &dataObj;
unit privVal;
memcpy(&privVal, dataPtr + 4, 2);

--- Mystic BBS v1.10 A38 (Linux)
* Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX

Re: Re: Fun with C++
By: dx2 to Nightfox on Wed Nov 27 2013 00:20:00

Redefining private to public is such a cheap trick.... A real programmer will simply take the address of the object and offset into it. Encapsulation is nothing but a compiler contrivance designed to force people into using the proper interfaces.

char* dataPtr = (char*) &dataObj;
unit privVal;
memcpy(&privVal, dataPtr + 4, 2);

I think redefining private to public could be useful for testing purposes though, in situations where you can't change the code but want to verify that certain data members are what they should be. I think that's a simpler solution than taking the address of the object and getting the offset to the data member (which seems even more hacky). In order to do that, you'd need to know the order in which the data members are declared, and sometimes that could be difficult to determine. Also, I'm not sure that all compilers will create the same object code, so I'd wonder if that solution would work with all compilers.

Nightfox