Announcing the C++ FAQ

I too have started learning C++11 recently after having never really had success picking up the language in the past.

Coming from C I found C++ to be really difficult when I tried to pick it up a few years ago. I have since learnt Python,Ruby and C# and now I am having alot more success. So I really do second your opinion that learning something like Java (in my case C#) really helps a ton.

I also highly recommend checking out the books recommended here: http://isocpp.org/get-started I am currently reading C++ Primer. :)

C++ is mostly an extension of C (there are some subtle differences like changes in the type system), so I also recommend C before C++; understanding how classes and methods are implemented (which would be the natural way to do it in C anyway) gives you better knowledge of practical, pragmatic use of OOP.

As you mention, the layering of C++ is another thing that can guide the approach to learning the language: begin with the simple concepts that C++ added, like classes with methods, and then move on to inheritance, virtual methods, overloading/overriding, operator overloading, exceptions, and then templates, making sure you understand the previous ones before proceeding to the next extension. It's a big language, with many features, not all of which you'll need to use for any one application.

Generally, the goal of auto is to create a variable whose purpose is to store a value of the type you have: you called a function, got a constant reference, but to store that you need a concrete value. Generally, the goal of decltype is to compute a type based on other code whose type you don't already know: a simple canonical example is to make a function that does something and transparently returns the result "as if" it were the original code. These are two drastically different use cases and, given the semantics of the various qualifiers, it makes sense to strip them for one and not for the other, lending to two different syntaxes. If you find yourself needing to transparently store the result of an expression, in C++14 you can use "decltype(auto) ;P".

It's also worth reading this:

http://stackoverflow.com/questions/3171647/errors-in-c-fqa

The only thing "essential" about FQA is that someone absolutely has to drop a link to it whenever there's "C++" and "FAQ" in the same sentence. It's known for being known. The actual content is utter junk - just try reading through it once.

For those who don't know, the FQA, unlike the FAQ is well known to be extremely biased and exaggerated. It is not a neutral resource - it was expressly written as a takedown, with exaggeration used to great effect.

C++ is an ugly, flawed language. Despite this, it can also genuinely be the best choice for certain applications, and so there is a need for a FAQ such as this one.

But it's not "essential" that any such reference be accompanied by a recitation of the reasons the language sucks (some of them legitimate, even). The FAQ is for people using a tool to make things; the FQA seems primarily used to score points in discussions such as this one.* I think working programmers generally have more use for the former.

* There is also a need for constructive criticism of language design choices, of course, but the FQA predominantly rejects C++'s design premises (such as static compile-time polymorphism and lack of a memory-managed runtime) rather than recognize their utility and suggest better ways to accomplish them (as Mozilla is trying to do with Rust).

Given that all modern languages do support some form of MI, maybe it is time to stop bashing C++ about it.

I immediately thought of this, but dismissed it after reading that 2 of the largest FAQs were being merged. This is made less important by the fact that neither of those FAQs are going offline, but at least it gives the impression that this will be replacing 2 and not just creating a third.

This. I am very happy with how C++ has evolved and how expressive it has become today, but decent Unicode support at least in the stdlib is something any programmer would(hopefully) look for in a modern language. Thanks for the interesting links, though.

There's ICU and boost.locale but unicode in C++ truly remains a pain in the ass.

I feel like C++ is still better as the "fast parts" language under a layer of Perl or whatever for the shoveling data and text around stuff.

FWIW I've submitted an improvement request to the c++ faq along these lines.

Writing tac in C++ is trivial: std::deque<std::string> lines; for (std::string line; std::getline(std::cin, line); ) lines.push_front(line); for (const auto &line : lines) std::cout << line << std::endl; // Note that I typed this quickly off the top of my head: I'm willing to believe there is a trivial typo the compiler would catch, but the overall implementation should be fine ;P.

As for ohce, you have defined a very very hard problem, one that it does not seem you realize is quite as hard as it actually is: if you have a sequence of Unicode codepoints and reverse their order you do not end up with a string of reversed characters, not in the general case, and not even for some reasonable encodings of seemingly-simple cases like an accented letter e.

Like, I challenge you to provide a working version of ohce in Python (2 or 3: your choice). Virtually no language actually provides a string type that makes this problem reasonable. It simply isn't fair to pick on C++ in this regard when no language "gets this right": at least C++ is being honest about the lack of guarantees it is making about string manipulation.

For more information, I recommend reading this article:

http://mortoray.com/2013/11/27/the-string-type-is-broken/

For the "reversing Unicode text" problem the easiest C++ solution is probably to use an external library such as QtCore or ICU (Qt uses ICU internally).

Unfortunately even in UTF-16 grapheme clusters do not correspond 1:1 with Unicode code points so you wouldn't be able to just reverse a list. But Qt can split up a QString into its grapheme clusters (a quick example I had made a couple of months ago):

    static QString reverse(QString src)
    {
        auto src_nfc = src.normalized(QString::NormalizationForm_C);
        QChar *start = src_nfc.data();
        int length = src_nfc.length();

        QTextBoundaryFinder finder(QTextBoundaryFinder::Grapheme, start, length);
        finder.toStart();

        // Reverse code elements that make up a code point when that code point has
        // been expressed in more than one code element (which is even possible in
        // UCS-4!)
        while(finder.position() < src_nfc.length()) {
            int oldPos = finder.position();
            finder.toNextBoundary();
            int newPos = finder.position();

            if(newPos - oldPos > 1) {
                std::reverse(start + oldPos, start + newPos);
            }
        }

        std::reverse(start, start + length);
        return src_nfc;
    }