class Anus { public: Anus(int n=123):hax(&num) { num=n; } void setNum(int n) { num=n; } const int *const hax; private: int num; } anus;
int main() { std::cout << *anus.hax << "\n";
anus.setNum(42); std::cout << *anus.hax << "\n";
return 0; }
Name:
Anonymous2014-04-29 7:35
lulz
Name:
Anonymous2014-04-29 12:24
Actually this pattern is pretty cool: your public data member is protected[1] and, at the same time, you avoid stupid calls to getters.
I would change just one stupid thing: - Anus(int n=123):hax(&num) { num=n; } + Anus(int n=123):hax(&num),num(n) {}
___________________ [1] - "protected" at compile time: you always can cast the l-value and modify the content, but reinterpreting pointers is always possible and dangerous.
Name:
Anonymous2014-04-29 12:32
>>3 Also, having a pointer is convenient: const int *p = anus.hax;
std::cout << *p << "\n";
anus.setNum(42); std::cout << *p << "\n";
(instead of doing calls to something like anus->getNum())
Name:
Anonymous2014-04-29 12:39
That is just retarded. Why not just make num be public? Then no need for stupid setter and the code would be more clean. If you later need to add setter (actually needed in 0.001% of use cases), just refactor all the code using Anus, it's not that a big deal.
Name:
Anonymous2014-04-29 12:56
Do you think encapsulation is ``retarded'' >>5-sun? :^)
Name:
Anonymous2014-04-29 14:45
>>6 Most of the time, yes, it is retarded. Sometimes it is useful (those 0.001%)
Name:
Anonymous2014-04-29 15:08
>>5 But what if later on we want to make the object store in an obfuscated form? We could make the change transparent to the user by using accessors and mutators as an interface.
I do prefer the C# way, which intercepts assignments and evaluations so that you don't need to use the dumb getters/setters methods.
Name:
Anonymous2014-04-29 15:44
>>8 encapsulation is also essential for a coherent concurrent design in c++
Name:
Anonymous2014-04-29 15:48
>>8 In C/C++ you can do int* i = &o->i;, which bypasses those.
Nigga, please. There can be no coherent concurrency with imperative shit.
Name:
Anonymous2014-04-29 16:44
I myself prefer This Heat over Gang of Four.
Name:
Anonymous2014-04-29 16:59
>>10 Yes, but you shouldn't. The publicly exposed members should act as an interface only. By expose i to such treatment, it's behavior internal to it's class can never change (well, it can, but it won't be very pretty).
That indicates you are making a library API. Of course, the API should use encapsulation and give access only to the needed bits. Because in case of library, we might not be able to refactor the using code (if we don't have access to user's code). But that's maybe the 0.001% of the code out there that needs to concern itself with this shit.
Name:
Anonymous2014-04-30 10:17
>>13 There could be many reasons to save a reference to an object inside of another. It looks like a bad idea for an int, but you can create data structures that reuse different index types using this method. If i was a list, you could have linked lists of os going in multiple directions. Encapsulation is an artificial limitation.
Name:
Anonymous2014-05-01 14:08
>>5,7,14 If you need to change the access method later, replacing all member references with accessor calls will work unless you have other code that accesses the members through pointers. On larger codebases doing it this way from the start can save a lot of pain. Here the accessor is trivially inlineable so there's really no reason not to use it.