
Announcing the C++ FAQ - jlemoine
http://isocpp.org/blog/2014/03/faq/
======
AndrewBissell
I recently started working my way through the C++ Primer after years of
avoiding C++ and its reputation for complexity. My first impression is that it
has actually matured into quite a nice language which strikes a balance
between simplicity and programmer power which just isn't all that bad,
especially given its genesis.

There are some annoyances for sure -- lots of mentions of "subtle" differences
in how certain concepts work are already cropping up in introductory chapters.
I'm sure there's some reason that "auto" discards top-level qualifiers while
"decltype" does not, but trying to ingrain so many of those distinctions is a
pain.

I'm also glad to have learned both Java and C before trying C++. The former so
that I know some OO mistakes to avoid (I would _not_ want to discover the pain
of over-enthusiastic use of generics while knee deep in compiler template
errors), and the latter because learning manual memory management and the
stack/heap distinction is enough of a cognitive load without layering all of
C++'s extra features on top. It's also good to have a bit deeper understanding
of what's _really_ going on with the memory and pointers under the hood,
before handing over control to automatic resource management and smart
pointers and such.

~~~
userbinator
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.

~~~
pjmlp
> 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++

Never ever do this in 2014. It is the path of writing unsecure code.

Modern C++ has better, more secure, approaches how to write code.

Leave C like coding to legacy code.

~~~
userbinator
> It is the path of writing unsecure code.

Why? If anything you will learn _more_ about the types of bugs that lead to
security issues, and thus gain a better understanding of how to avoid them.

I feel like "security" is the new "think of the children" phrase these days.

~~~
pjmlp
\- Prefer STL data types (vector, string...) over the native ones

\- Use references for modifiable parameters. No need to check for null

\- Templates, enum classes, const/constexpr, inline calls instead of
preprocessor macros

\- Use of RAII and smart pointers over manual memory management

> I feel like "security" is the new "think of the children" phrase these days.

It was nothing new. It was present since the early days in the form of
languages like Mesa(1970), Modula-2 (1978), among others.

Just that developers got to forget about them when UNIX got out of the
universities into the enterprise. Nowadays we pay for it as we discover how
important it is to have secure software.

edit: typo (import => important )

~~~
userbinator
> Nowadays we pay for it as we discover how important it is to have secure
> software.

I'm going to give a very controversial perspective here: Things like
jailbreaks and homebrew on consoles are possible because of certain "security
flaws" that are more common in languages like C and C++. If everyone used
"safer" languages, wouldn't these become much rarer? If it weren't for this
"insecurity", would our computing devices and software be even more locked-
down and restricted against us and more control be put in the hands of large
corporate entities or governments? Making software more secure against
malicious attackers also makes it more secure against those fighting for
freedom and control. The world is not quite so black-and-white...

~~~
mpyne
> Things like jailbreaks and homebrew on consoles are possible because of
> certain "security flaws" that are more common in languages like C and C++.

Using C++ as if it were C but s/malloc/new/ and s/free/delete/ is certainly a
good way to get security vulns. But as pjmlp mentioned, that isn't how you
should be using C++ nowadays.

------
acc01
An essential companion to the consolidated C++ FAQ is the indispensable C++
FQA.

[http://yosefk.com/c++fqa/](http://yosefk.com/c++fqa/)

~~~
eps
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.

~~~
mikeash
It's strident and biased (and makes no attempt to hide either) but IMO it's
quite informative. I've learned a lot about C++ from it.

~~~
plorkyeran
I thought I learned a lot about C++ from it when I first read it, but I have
gradually come to realize that the things I learned were mostly a mix of
incorrect and irrelevant.

------
balls187
Communities like Node, Python, RoR, and even iOS (obj-c) have benefited from a
defacto centralized point of reference, and I think devs who come from those
communities will find it easier to be more productive in C++ with something
like this.

I always referred to Marshall Cline's FAQ as my reference point, but pulling
together Bjarne's and StackOverflows FAQ's is a great step.

------
brudgers

        Until now, there have been several different overlapping FAQs, including notably:
    
             Bjarne Stroustrup’s FAQ pages
             Marshall Cline’s popular C++ FAQs Online
             at least three different StackOverflow C++ FAQs in some form....
             and many others
    

What could be more apropos than multiple inheritance?

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

~~~
andrewflnr
Maybe, but how many other modern languages have the same diamond inheritance
problem? Most modern languages put more limits on MI.

~~~
pjmlp
All of them have the same problem. It just shows up in different ways.

In C++ case you have two main issues:

\- the decision to have or not virtual base classes, due to C++ design of only
paying for what you use, the common solution to duplicate data members in OO
languages is explicit in C++

\- even if one restricts him/herself to use pure abstract classes without data
members, as a way to implement interfaces, there is the problem of function
members collisions.

Some OO languages with inheritance of state usually get away with the data
member duplication, either by doing what C++ compilers do with virtual base
classes.

The ones that adopt only some form interfaces/traits, have to deal with name
clashes the same way as C++.

All the existing solutions are kind of good enough, but not perfect:

\- Using of some form of linearisation algorithm every developer needs to be
aware of, to understand which methods wins;

\- Members need to be renamed, thus changing the real interface meaning

\- Implementations are provided for each collided method, requiring either
casts to specific interfaces or explicit calls for the right method

\- Provide just one implementation, with the caveat the semantics might not
match all the interfaces that share the same method signature

\- Not allowing collisions, forcing the creation of an adapter interface

So it is not well in the MI solutions outside C++. Each approach has plus and
minus.

------
shmerl
Marshall Cline’s C++ FAQ is really great. Good to see it will be merged into
the new one.

Other resources I use regularly are:

* [http://en.cppreference.com](http://en.cppreference.com)

* [http://www.cplusplus.com](http://www.cplusplus.com)

------
omaranto
I enjoyed the wording of this question: "I’m from Missouri. Can you give me a
simple reason why virtual functions (dynamic binding, dynamic polymorphism)
and templates (static polymorphism) make a big difference?"

------
elnate
Did anyone else think of the XKCD comic on new standards?

[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
rkuykendall-com
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.

~~~
snogglethorpe
What _will_ happen to the other FAQs...? It seems like if they're pretty much
entirely incorporated into the official FAQ, they could (and maybe should) be
replaced by links to and/or mirrors of the official FAQ.

[At least in the case of Marshall Cline's FAQ, I've always found it somewhat
confusingly organized, although the actual content was pretty good once you
managed to find what you were looking for. My (brief!) initial impression is
that this official FAQ seems better organized, at least...]

~~~
xymostech
They say that the previous FAQs will be replaced by links:

> Both Marshall and Bjarne will be updating their FAQs to either forward or
> link to the new FAQ on a per-FAQ level.

------
e12e
I found the link to Stroustrup's "Learning Standard C++ as a New Language"
[edit: from 1998, which explains why I found it kind of familiar to my late
90s run-in with c++...] interesting[2,1]. But then I tried to find out what's
the current state of the art for idiomatic, cross-platform text processing (in
unicode, probably utf-8) -- and got a little sad.

There's still no way to write a ten(ish) line c++ program that reads and
writes text, that works both on the windows console, and under OS X/*bsd and
Linux?

(Lets go crazy, say you have to implement a minimal cat, tac (reverses stdin
on stdout) -- and also corresponding echo and ohce (I made that up, something
that takes string(s) as input, and outputs the characters reversed (ie: "ohce
olé there" outputs "ereht élo").

[2][edit] The direct link to Strostrup's paper is:

[http://stroustrup.com/new_learning.pdf](http://stroustrup.com/new_learning.pdf)

code:

[http://isocpp.org/wiki/faq/newbie#simple-
program](http://isocpp.org/wiki/faq/newbie#simple-program)

[1]

The FAQ briefly touches on Unicode, but it doesn't seem very helpful (to me):
[http://isocpp.org/wiki/faq/cpp11-language-
misc](http://isocpp.org/wiki/faq/cpp11-language-misc) (search page for
unicode)

Trying to look for a (simple, generally accepted) solution, I came across:

[http://www.utf8everywhere.org/](http://www.utf8everywhere.org/) (If I'm
reading this right, it says assume std::string is utf8, but I'm not sure if
there are std-lib funtions for doing stuff like getting the index of a glyph,
and reversing strings by glyph? And will they work on windows?)

[http://stackoverflow.com/questions/2037765/what-is-the-
optim...](http://stackoverflow.com/questions/2037765/what-is-the-optimal-
multiplatform-way-of-dealing-with-unicode-strings-under-c)

Which points to:
[http://utfcpp.sourceforge.net/](http://utfcpp.sourceforge.net/) which is the
best I'm aware of so far.

[http://stackoverflow.com/questions/8513249/handling-
utf-8-in...](http://stackoverflow.com/questions/8513249/handling-utf-8-in-c)

[http://stackoverflow.com/questions/402283/stdwstring-vs-
stds...](http://stackoverflow.com/questions/402283/stdwstring-vs-stdstring)

(Suggest using wstring on Windows and string on Linux -- for simple programs
that would effectively mean write to versions, one for each platform ..)

~~~
saurik
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/](http://mortoray.com/2013/11/27/the-string-type-is-broken/)

~~~
e12e
> Like, I challenge you to provide a working version of ohce in Python (2 or
> 3: your choice).

Not a full implementation, but wouldn't this approach actually work (note,
doesn't work for python2):

    
    
        $ python3
        Python 3.2.3 (default, Feb 20 2013, 14:44:27) 
        [GCC 4.7.2] on linux2
        Type "help", "copyright", "credits" or "license" for more information.
        >>> "abc"[::-1]
        'cba'
        >>> "øæåにほ言"[::-1]
        '言ほにåæø'
        [edit: with accents]:
        >>> "eẽêëèøæåにほ言"[::-1]
        '言ほにåæøèëêẽe'
    
        [edit2: formatting, indentation]
    

There might very well be problems with this, but I'm not aware of any?

[edit4: This is indeed broken for the ligature (baﬄe) case in python3. I'm not
entirely sure that is an entirely fair test (but it is very interesting). I
would argue that the ligature should probably be a replacement done for
display/print, not in a _text_ file. Just like the reverse of "æ" isn't a
reverse composition of "e" and "a" (even if "æ" might be seen as a compositon
of "a" and "e".

I'm not sure how it deals with changing direction (left-to-right, right-to-
left) -- comments welcome.]

[edit3, sorry for the many edits]

To be clear, I do not wish to "pick on c++", nor do I think the example _is_
trivial. I do think it probably _should_ be trivial -- it is something that
should be supported in a canonical way by a standard library/implementation.

Working with graphemes is a very fundamental part of working with text -- the
fact that half(?) of developers have been able to hide behind ascii isn't a
good excuse for not fixing it. How would one implement an editor if you can't
access graphemes in a reasonable way?

And more importantly, how would you test for palindromes? ;-)

