Professional C++

[Catfish2]

I enjoyed reading your post, Telion. But I'd comment on the last paragraph.

Hating RAII => std::vectors evil? I do not see the connection, and I can't remember reading about it in the FQA.

What does make vectors evil, as inferred from the FQA, is that they're templates. Otherwise please link to the relevant FQA text.

[iw0XoG1T]

Would someone please cite the accepted authority or authorities for the definitions of OOP and encapsulation.

I find it hard to believe that such abstract concepts like OOP, encapsulation, and God have universally accepted definitions.

I hope to be embarrassed by my arrogance--and be given definitions with credible citations, but I doubt it.

[Catfish2]

I find it hard to believe that such abstract concepts like OOP, encapsulation, and God have universally accepted definitions.

I also find that hard to believe, about anything else.
So how about we narrow it down, within the context of C++?

[moorecm]

You have to recompile client code if you change private inner things of the called code.

No. You likely have to because of poor (or non-existent) design for maintaining binary compatibility. For example, create a shared object using a proper API (encapsulation, no inlines, pimpl, high cohesion, loose coupling) and change its implementation without changing the interface itself. You will not have to recompile client code at all.

The problem I see with this thead is that many of these concepts all work together. Following best practices, using encapsulation, etc.. all go hand-in-hand or any of them can be discredited.

I strongly recommend API Design for C++:
http://www.apibook.com/blog/

Time and time again I read/hear things like, "A stuct should be used denote intent to represent a collection of public data and nothing more." All I can think is, "No!" In C++, there should be no such thing as a purposefully poorly-designed object (which is exactly what this object would be).

[BHX]

Encapsulation in itself basically tells you what the definition is. Encapsulation is nothing more than a fancy way of saying data hiding when it comes to OOD/OOP. It means that all of the object's data is contained and hidden in the object and access to it restricted to members of that class.

[rapidcoder]

It means that all of the object's data is contained and hidden in the object and access to it restricted to members of that class.

Agreed, but C++ doesn't provide that fully. Private section is a part of object ABI.

For example, create a shared object using a proper API (encapsulation, no inlines, pimpl, high cohesion, loose coupling) and change its implementation without changing the interface itself. You will not have to recompile client code at all.

This means you have to provide encapsulation manually, and *you* are responsible for it, not the langauge. Also keep in mind, pimpl slows down object construction / destruction. Well it is like saying you can do OOP in C, by function pointer magic to implement vtables. Albeit possible, it dosn't make C an OO language.

Contrary, in Java/C# if I write "private", I know it is definitely private. No code external to the class ever relies on the content of the private section, unless explicitly told to. In C++, all client code using the class, relies on the content of the private section. That is why it has to be in the header file.

[moorecm]

How many counterexamples does it take to disprove a statement?

[Abramus]

One. And?

From what I know, FQA does not state that client code must be recompiled each time you change the implementation. It states that client code must be recompiled each time you change the implementation if your interface has a form of class definitions with private sections. This shows how useless the private keyword is. I don't see how your examples disprove this statement.

[moorecm]

Do you understand the pimpl idiom that I mentioned? It's the trick. Recompilation is only necessary if one of the private members has changed.

[Abramus]

Yes, I understand it, and I agree that this technique (or one of a few dozens different ones) solves the issue. But it also shows the problem with private - if you use it in a straightforward, intended way, you're doing it wrong. So private doesn't help, nor is necessary to achieve encapsulation (at least to the point possible in non-managed environments).

[Cubbi]

But it also shows the problem with private - if you use it in a straightforward, intended way, you're doing it wrong.

it's not a problem with private, it's a problem with erroneous expectations. Encapsulation can be achieved through data hiding, but it does not need to be, and it is not in C++. Thinking private is for that is like thinking that volatile is for multithreading.

If you actually need a compilation firewall, then yes, a pointer (or, rather, unique_ptr these days) to some sort of implementation object holding all private and nonvirtual (but not protected) members is typically used. But not a whole lot of problem sets actually benefit from this.

[Abramus]

Maybe you're right, maybe those are erroneous expectations. But then we must accept the fact that C++'s OOP support is nothing more than some syntatic sugar.

[Cubbi]

we must accept the fact that C++'s OOP support is nothing more than some syntatic sugar.

That's just silly. What kind of language syntax would provide equal functionality if C++ had no class access specifiers? (not to mention the rest of OOP support)

[ResidentBiscuit]

This thread seems ridiculous. Are we really arguing that C++ has no OOP?

[Catfish2]

OOP is rather something a language supports, or doesn't.

What kind of language syntax would provide equal functionality if C++ had no class access specifiers?

Comments.

[moorecm]

There are plenty of reasons to use encapsulation (private access specifiers for members) over an everything-is-public-like-in-C struct. Pursuing binary compatibility is only a single one of the benefits.

[BHX]

Do you understand the pimpl idiom that I mentioned? It's the trick. Recompilation is only necessary if one of the private members has changed.

Forgive my ignorance, but wouldn't you have to recompile if you changed any part of the code not just the private members?

[moorecm]

Yes, if you change the API, you have broken binary compatibility.

[rapidcoder]

Yes, if you change the API, you have broken binary compatibility.

And that is bad, too. In Java/C# and many other languages I can freely change public API without breaking binary compatibility. I just have to be careful not to modify or remove anything that was used, but I can add new things.