>>51414417
>Why does C++ allow enforcing encapsulation with protected/private keywords? It's not really necessary unless the people who use your library are fucking retards.

its to ensure the users of your library know which functions are "safe" to use without having to read all the source code. cos you're right, they could work it out but why bother if you dont need to.

also, it helps you when you release version2,3,4... of your lib, as long as you dont change the public interface you can change your code with impunity (protected stuff is slightly different but the same sort of thing applies).

install C

>>51416092
"install" C ftw

>>51414417
>Why does C++ allow enforcing encapsulation with protected/private keywords?
Because C++ is the amalgamation of every feature Stroustrup found passingly interesting. Unlike Java you find a reasonable number of C++ programmers who make everything public because they don't feel the need for language enforcement.

DESU I think your typical C++ programmer is going to be smarter than a typical python programmer, which isn't to say I think the former is a better language but it's just more complicated/"rich" and generally takes more thinking to use well.

>>51414417
>inb4 "muh underscores" because that just doesn't count as enforced encapsulation.
It doesn't count but it seems quite a few find encapsulation necessary. Which is why they have to work around not having private members by using underscore prefix. So, why wasn't this oversight fixed? Why doesn't python allow enforcing private members?

>>51414417
It's what you get from design by committee, some retarded OO fag thought it would be 'nice' to be able to semantically mark up 'private' data and functions.
The sad things is it's doubly retarded in C++ because of the compilation model, if you change class private data you still have to recompile every user of the class anyway, so all the private and protected keywords accomplish is useless busy work for bureaucratic code monkeys.

>>51417083
You can use closure semantics if you really want "private" members but I don't think it's an oversight even if you couldn't. Convention works perfectly fine. A far greater number of people use style conventions for the class/instance distinction in Java, does that mean the lack of enforcement of capitalization style in Java was an oversight as well? Surely it couldn't be that every instance of convention is an example of language oversight.

>>51414417
>in most other cases C++ is fine with letting retards wreck their own shit, leak memory, write outside of array bounds
>what are smart pointers and STL containers

You can write safe programs in C++ you know. Encapsulation is a good thing. Python enforces more petty things, like forced formatting. In the end they both can't stop awful programmers being awful.

I like both languages though.

>>51417119
>what is pimpl

The worst part is the visibility system is completely non-functional. You can literally remove the private keyword from a codebase and the only thing you lose is an advisory error.

class A { };
class B { public: int x; };

class C : private A, public B { private: int x; };

void foo(A*);
void foo(B*);

int main() {
    C c;
    foo(&c); // ERROR: CALL TO 'foo' IS AMBIGIOUS
    c.x = 123; // ERROR: 'x' IS A PRIVATE MEMBER OF 'C'
}

>>51419045
>only thing you lose is an advisory error
I don't see how this makes it non functional?

>>51418668
this desu

I miss RAII in Python. Memory usage blows up when you load sizeable datasets with numpy. it always returns new arrays instead of inplace modify.

>>51418685
gross