Professional C++

Pages: 123

Any part of it, it keeps repeating over and over that c++ should not be used (consistent with the started purpose of the website)

I agree this can be viewed as trolling; even though I think trolling is more about deliberately trying to annoy people, rather than consistently restating an unpopular conclusion, which you reached yourself and with technically accurate backing...

and it suggests the most atrocious approaches to programming instead of every language feature the author declares bad. One or two of those could pass as someone just being ignorant and stubbornly refusing to open a textbook, but entire website of anti~ practices is just trolling.

I don't understand what you mean. Again, I'm waiting for specific examples, by which you highlight technical inaccuracies and/or the correct approach, which evaded the FQA author.

Needles to say, anyone who follows FQA recommendations will quickly find c++ unusable, and the website would achieve its stated goal.

... and why is that a bad thing, if it would weed out mediocre programmers?

htirwin (1208)

I agree that site sucks. The sites stated goal.

The main purpose of this FQA is to convince people of the following:

There is no reason to use C++ for new projects. However, there are existing projects in C++ which might be worth working on. Weighting the positive aspects of such a project against the sad fact that C++ is involved is a matter of personal judgment...

http://yosefk.com/c++fqa/

Is this true; C++ should not be used on new projects?

Last edited on

Cubbi (4774)

I think trolling is more about deliberately trying to annoy people

Perhaps it is now, but the original Usenet meaning of trolling for newbies was to post something that is ignored by the regulars but attracts, misleads, and provokes fruitless discussion between newbies.

consistently restating an unpopular conclusion, which you reached yourself and with technically accurate backing...

\
FQA does none of that.

Again, I'm waiting for specific examples, by which you highlight technical inaccuracies and/or the correct approach

Are you *actually* serious?

Catfish2 (666)

I think it would be beneficial if you pointed out the "atrocious approaches" suggested by the FQA, and explain why they are so.

htirwin (1208)

...

private is almost useless. Specifically, it fails to provide encapsulation, and therefore is little more than a comment.
...

If you work on the internal interfaces between the different classes of a module, and you're stuck with C++, using private is surely better than defining all members public. This way, someone can easily tell that a member is not accessed outside of the class, and clarity is good. However, there is little reason to obsess with the fine details of access control in the internal interfaces.

This seams to be counter to what I've read from other sources. Can I get some more opinions on this?

BHX (3450)

I agree, I have been told and read that private helps for encapsulation. Though, generally, I don't take much stock in any site just because it says so. Even with this site, I compare what is said with what is in books and other sites before I believe it.

Catfish2 (666)

@ iseeplusplus:
From what I remember, the point is that C++ allows the programmer to bypass encapsulation, for example like this:

#include <iostream>

class Encapsulated {
public:
    explicit Encapsulated(int i=5):
        i(i)
    {
    }

    int value() const
    {
        return i;
    }

private:
    int i;
};

int main()
{
    Encapsulated e;

    std::cout << "Before:\t" << e.value() << std::endl;
    *reinterpret_cast<int *> (&e) = -777;
    std::cout << "After:\t" << e.value() << std::endl;
}

Before:	5
After:	-777

Edit: simplified example, then some more, then again some more.

Last edited on

closed account (3hM2Nwbp)

the point is that C++ allows the programmer to bypass encapsulation

The same kind of hackery can be applied to pretty much every language to accomplish the same nonsense, even the languages that have been designed to fix those type of things.

* The most obvious example being Java.

I guess that fact doesn't make the issue any better though.

Last edited on

Cubbi (4774)

C++ does not actually allow that practice:
*reinterpret_cast<int *> (&e) = -777;

test.cc:24:33: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing]

(although this particular setup hits a corner case, I think)
But even if this was generally legal, it does not "break encapsulation", because neither the purpose of the keyword private: nor the meaning of "encapsulation" have anything to do with data security or access to the object representation.

Last edited on

rapidcoder (1010)

* The most obvious example being Java.

Please show me how you can modify a private final field in Java outside of the class *in presence of a security manager* e.g. in an applet. Unless you find a vulnerability in JVM, you can't.

However the distinction is that in C++ you can easily *accidentally* break OOP encapsulation. And no, reinterpret_cast is not needed at all - just a small coding bug is enough. In other languages it is not possible, without deliberately using some hacky features.

Catfish2 (666)

@ Cubbi:
I don't get that warning, even if I compile with

g++ -Wall -Wextra -pedantic -Wstrict-aliasing -O3

using GCC 4.7.1 packed by Lavavej.

But even if this was generally legal, it does not "break encapsulation", because neither the purpose of the keyword private: nor the meaning of "encapsulation" have anything to do with data security or access to the object representation.

So if it doesn't break encapsulation, what does it do? To me it looks like it modifies a private member without trashing the object... which is pretty close to what I'd personally call "breaking encapsulation".

Also, could you please point out the "atrocious approaches" that the FQA suggests, and explain why they are so?

Edit: tried adding -O3.

Last edited on

Telion (129)

The FQA's definition of encapsulation is vastly different from how a computer scientist would define it. He claims encapsulation means that you can change private variables in a class without having to recompile other sources. He ignores the idea that encapsulation exists to stop the rest of the program from accessing the inner workings of the interface.

By his logic, Java is not object-oriented. Encapsulation is one of the requirements of an object-oriented language. Java compiles the entire program every time you run it. Therefore, changing a private variable requires recompiling the entire program. Therefore, Java has no encapsulation and is not object-oriented.

closed account (3hM2Nwbp)

rapidcoder wrote:
Please show me how you can modify a private final field in Java outside of the class in presence of a security manager e.g. in an applet. Unless you find a vulnerability in JVM, you can't.

I'm not an expert at Java, but my first approach would be to use an Agent to modify the class during its loading phase and strip the field of its final modifier (and do whatever other devious acts to it)...although I am unsure of how a SecurityManager would react to that. At that point, however, it's all just crazy-talk.

Oh, I just remembered. Why bother with that when I can do it through JNI?

P.S. Security management in Java still eludes me. Can you recommend a good book for becoming an expert in that department?

Last edited on

rapidcoder (1010)

He claims encapsulation means that you can change private variables in a class without having to recompile other sources.

This is perfectly right. Encapsulation means calling code need not know the structure of the called code (objects) to communicate with them. The inner workings are hidden and separated from it. The key benefit of encapsulation is you can change the inner things without breaking the client code. In C++, you get some kind of it at the source level (private modifier, but with many ways to get over it), but all encapsulation is lost at the binary module level. You have to recompile client code if you change private inner things of the called code. This is pretty bad if you don't have control over your client code, and you don't have all the sources. Quite easy to break compatibility. That is why many C++ libraries provide a public C interface, which is simple and non-OOP.

Contrary, in languages like Java, there is a separate compilation of each class. If you change a private member in Java, including changing its signature, the only thing that gets recompiled is the class that is owner of that member.

Java compiles the entire program every time you run it

Not true in general. And we are talking about compilation from the source level, not interpretation / execution. How JVM does this is completely irrelevant from OOP point of view. At machine code level all OOP is lost anyway.

Last edited on

Telion (129)

But that's not what encapsulation is. Encapsulation is a way to think in the problem domain rather than the solution domain. It means the calling programmer does not need to know about the internal workings of the class. It doesn't mean that the machine code itself needs to have no knowledge of private members; that's entirely a part of the solution domain.

Last edited on

BHX (3450)

According to several of my CS books, in the OOD and OOP section of the book, it defines encapsulation as:

Encapsulation -- The ability to combine data, and operations on that data, in a single unit

Encapsulation lends itself to data hiding, and private is just a way to help with data hiding (at least that is how I have come to understand it).

Last edited on by closed account z6A9GNh0

closed account (iw0XoG1T)

forgive me if I am wrong, but isn't true that there is neither an agreed definition for OOP or encapsulation.

So this discussion is really just a little debating game. Where you try to win your point by getting your opponent to agree to a definition that favors your argument.

Last edited on

htirwin (1208)

I'm just trying to understand. Should I bother worrying about encapsulation / access control. The author of the FAQ says that encapsulation doesn't exist in C++. He say's the only point in making members private, is so that someone can read it and see how the class is used.

Is this good advice in general?

The debate about what encapsulation is, is one thing, but the arguments made in the FQA, which are based on the statement that you cannot have encapsulation in C++, is another thing. How does his advice about the use of private members and friends relate to his definition of encapsulation?

Last edited on

BHX (3450)

chwsks wrote:
forgive me if I am wrong, but isn't true that there is neither an agreed definition for OOP or encapsulation.

No there are agreed definitions for OOD, OOP, and encapsulation. Just every language and programmer differ on how they think they should be implemented .

Telion (129)

forgive me if I am wrong, but isn't true that there is neither an agreed definition for OOP or encapsulation.

I think it's widely agreed that an OOP language is defined by having encapsulated classes with inheritance that supports runtime polymorphism. Within OOP, encapsulation is defined by information hiding and access control.

Recompiling the code has nothing to do with OOP because OOP designs the observable semantics in the program at runtime. In the FQA he argues that C++ has no "compile-time" encapsulation. This kind of encapsulation is not the same as the encapsulation used in OOP, and he's deliberately using the phrase "compile-time" to trick people.

You are normally concerned with the observable semantics of compilation. When he talks about compile-time in the FQA, he literally means the build process, not the result of the build process. You'll have a hard time finding any source that claims the goal of OOP is to reduce build times.

The biggest problem with the FQA is that the author hates RAII with a passion. This makes vectors evil (except when they should be built-in types...), which means you have to use arrays. But this forces you to use new, which leaks memory during exceptions. This means exceptions are evil too, which means constructors cannot fail. This makes constructors evil, so you can only make POD classes. But POD types aren't object oriented, so C++ must not be object oriented! If you don't like RAII, don't use C++.

Pages: 123