private-members

After seeing this question a few minutes ago, I wondered why the language designers allow it as it allows indirect modification of private data. As an example class TestClass { private: int cc; public: TestClass(int i) : cc(i) {}; }; TestClass cc(5); int* pp = (int*)&cc; *pp = 70; // private member has been modified I tested the above code and indeed the private data has been modified. Is there any explanation of why this is allowed to happen or this just an oversight in the language? It seems to directly undermine the use of private data members. Because, as Bjarne puts it, C++ is designed to

Python provides private name mangling for class methods and attributes. Are there any concrete cases where this feature is required, or is it just a carry over from Java and C++? Please describe a use case where Python name mangling should be used, if any? Also, I'm not interested in the case where the author is merely trying to prevent accidental external attribute access. I believe this use case is not aligned with the Python programming model. It's partly to prevent accidental internal attribute access. Here's an example: In your code, which is a library: class YourClass: def __init__(self)

I've been working on creating a class and suddenly a thought came to my mind of what is the difference between the two codes: public readonly string ProductLocation; AND public string ProductLocation { get; private set; } Can you guys give me idea when to use the following better. thanks. Bruno Reis The first one is a read-only field, while the second one gets compiled as a pair of methods (and all reads of the property ProductLocation gets compiled into calls to the corresponding get method and writes to it gets compiled into calls to the set method; internally, these methods will read from /

I've been reading about OOP in C but I never liked how you can't have private data members like you can in C++. But then it came to my mind that you could create 2 structures. One is defined in the header file and the other is defined in the source file. // ========================================= // in somestruct.h typedef struct { int _public_member; } SomeStruct; // ========================================= // in somestruct.c #include "somestruct.h" typedef struct { int _public_member; int _private_member; } SomeStructSource; SomeStruct *SomeStruct_Create() { SomeStructSource *p =

I don't know if the question is descriptive enough but why and how does this behaviour exist?: public class Layer { public string Name { get; set; } private IEnumerable<Layer> children; public IEnumerable<Layer> Children { get { return this.children.Where ( c => c.Name != null ).Select ( c => c ); } set { this.children = value; } } public Layer ( ) { this.children = new List<Layer> ( ); // Fine Layer layer = new Layer ( ); layer.children = new List<Layer> ( ); // Isn't .children private from the outside? } } I can access layer.Children anywhere, that's fine, but how can I access layer.children

I have the following code: class A { private: int x; public: A() { x = 90; } A(A a1, A a2) { a1.x = 10; a2.x = 20; } int getX() { return this->x; } }; I know that code might be weird but I don't understand why a1 and a2 can access private data member x ? Good question. The point is that protection in C++ is class level , not object level. So a method being invoked on one object can access private members of any other instance of the same class. This makes sense if you see the role of protection being to allow encapsulation to ensure that the writer of a class can build a cohesive class, and

Is it appropriate to access a class' private members by casting it to a void pointer and then to a struct? I don't think I have permissions to modify the class that contains the data members that I need to access. I don't want to take a risk accessing the data members in an indirect way if it is not ethical. EDIT: Had to edit this further... I am pretty sure the class wouldn't be modified, so it's ok to that extent... my only concern is, if the person who coded that class gets to know of this, it might not go down well with him :(. "Never say never". I'm sure somewhere in the universe, there's