
C++11 FQA anyone? - signa11
http://yosefk.com/blog/c11-fqa-anyone.html
======
inglor
This is a very interesting read but it's full of FUD.

You'd expect `==` to work in PHP because it compares value. With a char*
reference the syntax and everything around it indicates that you're working
with well... pointers (and you shouldn't be having char pointers for strings
anyway). Don't even mention PHP references etc.

C++ still has a lot of going for it - no one thinks it's terribly great and
awesome - but the reason people ridicule PHP and admire C++ is that it solves
a much bigger problem.

\- In PHP you don't have resource management, the process kind of just dies
and resources get deallocated. In C++ that's not acceptable for perfomance. \-
In PHP you have memory safety - oh wait you really don't, if you do silly
things like use raw references you can still get screwed.. experienced C++
programmers don't fall to that pit either. \- In PHP you don't have to
explicitly deal with memory which is again because you're solving a much
easier problem. When your whole world is an immutable page request response
cycle life is rainbows and sunshine.

Comparing languages is always ridiculous and populistic but that comparison
was just bonkers. Not that C++ doesn't have quirks - it sure does, but
comparing it to PHP is just silly.

(Not saying anything about PHP being a bad or good language here, just that
the comparison is ridiculous)

~~~
jordigh
FTFA:

    
    
        I have observed someone do this: _myarr[5]={0}; – they had in the
        .h file the definition int _myarr[5] and they remembered that this
        thing could be initialized with {0} in other contexts. What they
        did wouldn't compile in C++98; in C++11 it promptly assigned the
        int 0 to the non-existent 5th element of _myarr, and the usual
        hilarity ensued. Imagine how PHP would be ridiculed for this kind
        of little behavior – and PHP at least would never overwrite an
        unrelated variable with garbage. Imagine how with C++, the poor
        programmer will be ridiculed instead.
    

Let me repeat that one more time,

    
    
        the poor programmer will be ridiculed instead.
    

From your response,

    
    
        (and you shouldn't be having char pointers for strings anyway)
    
         [...]
    
        experienced C++ programmers don't fall to that pit either
    

This is what the article is about, about what you are doing again. C++ is
weird, it has a bunch of unusual behaviours, and when pointed, people who fall
into those traps are the ones ridiculed, instead of the language.

I don't know if C++ could have been made less weird with the constraints that
it had, as others have pointed out in this thread (C compatibility with no
overhead). Perhaps it couldn't be. But this article is unhappy with the
attitude of defending C++'s weirdness and then blaming the programmers for
falling victims to this weirdness.

~~~
banachtarski
That isn't weird. At all. The language did precisely what the programmer asked
it to. When you make a language operate closely to the metal, you can expect
the syntax to be more abstruse. If this kind of mistake was possible in a
higher level language, I would expect that to be a language pitfall.

~~~
fiatmoney
"When you make a language operate closely to the metal, you can expect the
syntax to be more abstruse"

It's the exact opposite. Close-to-the-metal, the syntax is actually very
friendly - you've got values, and you can bash them in like a half-dozen ways.
C is incredibly simple (I suppose their pointer syntax is a little janky, but
one can always express it "one level at a time" via typedefs).

The really complicated parts come from making high-level operations seem
"easy". There is no close-to-the-metal notion of char* vs a string, or a
lvalue vs an rvalue, let alone template metaprogramming.

~~~
banachtarski
What I should have said was provide high level abstractions while still
allowing low level operations. There is an impedance mismatch that the
language needs to address. Languages like Rust can get away with this by not
allowing the most low level operations that are deemed unsafe and so have a
more user friendly api. C on the other hand, makes no attempts at make the
abstraction so the syntax is just small by definition.

------
nly
After reading this I recommend people go watch this recent interview with
Bjarne[0] for some insight on the compromises taken by C++, a spot of history
with regard to its development in tandem with C, and what he thinks of the
'competition' between new languages.

I think it's only fair seeing as this article accuses Bjarne of "evilly
shrewd" moves, maliciously crippling Cs development, and "knocking C it in to
a coma". So watch it for Bjarnes perspective from his own mouth. You may as
well see get a biased view from both sides.

[https://www.youtube.com/watch?v=jDqQudbtuqo](https://www.youtube.com/watch?v=jDqQudbtuqo)

~~~
dmunoz
Bjarne has been on a bit of a promotion tour recently. Here is another Q&A
session he did with Slashdot on the 20th [0]. I suppose this is because of the
recent standardization of C++14.

One thing I don't particularly agree with is that some of his examples of C++
code use features that will not be made available for years, likely around or
after 2017 when C++17 should be standardized. This is assuming compilers
implement the standard quickly, which is worse on some platforms than others (
_cough_ Visual Studio _cough_ ). What I'm specifically talking about is any
example that mentions concepts, but at least he is clear that concepts are
only currently available in a branch of GCC.

[0]
[http://features.slashdot.org/story/14/08/20/011231/interview...](http://features.slashdot.org/story/14/08/20/011231/interviews-
bjarne-stroustrup-answers-your-questions)

~~~
nly
> What I'm specifically talking about is any example that mentions concepts,
> but at least he is clear that concepts are only currently available in a
> branch of GCC.

The syntax for concepts seems pretty well set now, and Alex Stepanov (author
of the STL, and worked with Bjarne on the new concept model), in his Amazon A9
lectures (available on YouTube) recommends you simply #define concept names to
"typename" so they at least exist in your code as documentation.

The most important thing however is really to get people writing their generic
code with a concious awareness of what their type requirements actually are,
and then to document and specify them correctly, just like you'd rightly
expect a function written in C99 to specify clearly what the pre and post
conditions are... something the compiler can't help you with even today.

------
overgard
Professional C++ programmer here, although previously I mostly worked in C#
and python. I have to admit, I'm pretty ambivalent about the language. For a
long time I loved it, and then for quite a while I really hated it (tracking
down segfault that only happens on a release build on a tight deadline will do
that to you). The thing is, all the terrible things people say about C++ are
true; but what else is there in that space? It seems like most language design
is aimed at a higher level. D seemed promising, but the whole standard library
issue seemed to derail its momentum, and as nice as the language is, it's
really complicated and the tool support kinda sucks. Rust is interesting but
too immature to sell to the decision makers at most companies.

I understand people going back to pure C, but man, as screwed up as C++ is
it's hard to give up things like vectors and strings and namespaces.

Everything else has a memory model that doesn't quite work, and look, I like
GC as much as anyone but sometimes you need a language where you can turn it
off when you need to guarantee there isn't going to be intermittent GC pauses.

~~~
TheDong
Google's go and Mozilla's rust both fit the same sort of space.

Rust especially.

------
copx
I do not see a double standard. There is a fundamental difference between PHP
and C++. PHP was simply a bad design, needlessly ugly.

In contrast, the design of C++ was constrained by the goals of

\- Compatibility with C (and later previous C++ standards)

\- Zero overhead / you do not pay for what you do not use

\- No GC

Those constrains are responsible for most of its ugliness, not poor design.

~~~
_yosefk
1\. From a user's perspective it doesn't matter if it's "constraints" or "poor
design".

2\. Blaming C does not explain C++'s undecidable grammar, the zillion ABI
incompatibilities introduced on top of C, lack of an alternative for #include
coupled with features like inlining and templates making it a disaster that it
never quite was in C, or many other of C++'s faults. How is PHP's grammar a
worse design than C++'s? I really want to know. I think PHP's is better.

3\. Source compatibility with C does _nothing_ for the user (who could have
lived with ABI compatibility just fine) and _everything_ for Stroustrup (who
managed to make his language that much more popular by an Embrace, Extend and
Exterminate approach).

4\. Design goals inevitably resulting in a bad language are bad design goals.
If I said that I designed an electric car that electrocutes you but that's
because it's compatible with an electric chair for which there's a lot of
existing demand, would you then publicly defend me?

5\. PHP is a child of Perl which is a child of shell, awk, sed and C. A lot of
heritage there to blame as well. So?

6\. PHP doesn't byte one's behind _nearly_ as badly as C++ and _that 's_ why
the double standard exists; because only a fraction of the people who try
manage to ever get anything done in C++ and a large subset of these people
feel entitled to be treated as an "elite". PHP programmers cannot afford to
delude themselves thusly because everyone can be productive in PHP... A funny
outcome, I find, given that it "should" have actually led to PHP being
praised.

~~~
marcosdumay
> 1\. From a user's perspective it doesn't matter if it's "constraints" or
> "poor design".

Of course it does. If it's poor design, one just don't use the language at
all. If it's constraints, any language that solves the same kinds of problems
will be just as bad, and - life just sucks - one must stop complaining.

~~~
cafard
"If it's poor design, one just don't use the language at all."

For greenfield development, sure. Many and maybe most of us don't work in that
space.

------
possibilistic
I've been using C++11, and I really like it. Together with RAII it seems
entirely modern and reasonable.

Is there a list somewhere that describes what the "bad parts" (in the
Crockford sense) of C++ are? Bad practices, bad feature interplay, etc.

I've been thinking of writing a little C++ transpiled language of a limited
feature set to make prototyping certain things easy. It would try to follow
the accepted best practice conventions. I imagine it to be Coffeescript-like,
with no separate header files, support abbreviated syntax, syntax for managed
pointers, etc. It would probably follow a rudimentary linking scheme.

It might be opinionated in ways that turn some people off: const vars and args
by default, virtual methods by default, auto virtual dtors, and probably other
"sensible" (in average usages) default patterns.

Finally, I would want to generate simple intuitive interfaces that are
linkable to existing C++ headers.

Anyways, this would just be a side project for fun. I don't do C++
professionally. Just for robotics and lasers and hobby stuff. Any information
on best practices and bad C++ usages would be awesome to have if I undertake
this.

~~~
yoodenvranx
I am dreaming of something similar. I'd like to see a simple language wich
looks a bit like python and compiles to C++. The central part of this language
would be an integrated package manager / module system which replaces make /
cmake. Why should I need make? I just want to tell the compiler the file with
main() and then it should figure the rest on it's own.

The one thing which stops me from writing more c++ is all the setup you have
to do to actually get an executable. In python I can just create a file,
import some stuff and run it. In C++ I have to deal with makefiles, vs
projects, paths and all that crap. Just give me a C++ where I can write
"import boost.xyz" and the compiler figures out what that means.

~~~
film42
Actually, I put a c++ project template together to solve this exact problem.
It uses cmake to generate a makefile (including IDE projects that just work),
and google mock for testing. You still have to add libraries like boost to the
CMakeLists.txt if you want to use it, but it's really easy. Just follow the
examples in the project.

Github: [https://github.com/film42/cpp-starter-
template/](https://github.com/film42/cpp-starter-template/)

------
eslaught
So the original guide seems not to have been updated since 2009 [1], and even
then only in minor ways. Are these criticisms still valid of C++, even without
the C++11 standard? Clearly the language issues won't have gotten any better
(without C++11), but many of the arguments in the FQA seem to call into
question the correctness of the compiler or the quality of the compiler's
optimizations (see e.g. [2] and [3]). Is this still valid for modern compilers
(GCC 4.8, Clang 3.4, etc.)?

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

[2]:
[http://yosefk.com/c++fqa/ctors.html#fqa-10.9](http://yosefk.com/c++fqa/ctors.html#fqa-10.9)

[3]:
[http://yosefk.com/c++fqa/templates.html#fqa-35.10](http://yosefk.com/c++fqa/templates.html#fqa-35.10)

~~~
rwallace
No. There was a time when you couldn't count on a lot of C++ features being
fully or correctly implemented, but that time has passed. A lot of the other
arguments revolve around slow compile times, which are fixed by having plenty
of fast hardware. Most of the remainder are divided between matters of taste,
and genuine sharp edges you have to be careful to avoid.

------
ChrisAntaki
> And Stroustrup says about himself that he "lacks marketing clout" and says
> Java and C# are bad for you because they're "platforms, not languages",
> whatever that means.

Perhaps Stroustrup is referring to the JVM and CLR, respectively?

~~~
fiatmoney
Right. Java-the-language depends heavily on JVM-the-environment to be usable.
Without an excellent GC (sometimes even with one) common coding patterns are
unworkable, and the design of the language lends itself heavily to GC-
dependent overall designs. There are also aspects of the implementation
details that dominate language design (eg, primitive boxing and the generics
implementation).

That said, if you know what you're doing it's a great platform.

------
putzdown
These kinds of rants sadden me. They purport to outline absolute, logically
inviolable reasons that a given language is "bad". What they really do is
express the writer's frustration, an emotional reaction that probably emerged
from working with language attributes and features that he in some cases
doesn't understand well or in other cases simply doesn't prefer. C++ works
beautifully for millions of programmers who happen to "get" it and like it,
just as Java does for others and C# does for others and Haskell does for
others and fill in your main squeeze here. Programmers are trees
([http://www.jeffwofford.com/?p=915](http://www.jeffwofford.com/?p=915)). We
each adapt to what we like and come to like what we adapt to. Let's not
pretend we alone have the One True Way or that our non-preferred way is
stupid.

~~~
izacus
While your point may be valid... let's also not pretend that some genuinely
bad solutions are just "non-preferred" ways and that C++ is not without it's
shortcomings and hidden pitfalls. After all, there is a reason that any style
guide for C++ will include a large list of features that should not be used.

I love the language and use it alot... but sadly, in many ways, this FQA is
just too true.

~~~
yid
You're just reinforcing the parent's point. Take this sentence:

> <PROGRAMMING_LANGUAGE> is not without it's shortcomings and hidden pitfalls.
> After all, there is a reason that any style guide for <PROGRAMMING_LANGUAGE>
> will include a large list of features that should not be used.

This holds true of pretty much any language. Take a look at Google's extensive
style guide library [1]; they all contain language features that should be
avoided for any language. It all just reflects the iterative nature of
programming language design.

[1] [http://code.google.com/p/google-
styleguide/](http://code.google.com/p/google-styleguide/)

~~~
jzwinck
Look at Google's Python Style Guide: [http://google-
styleguide.googlecode.com/svn/trunk/pyguide.ht...](http://google-
styleguide.googlecode.com/svn/trunk/pyguide.html)

There is almost nothing in there that sounds like a landmine. Rather, some
general guidance about "don't use global variables," "x may not be thread
safe," and "don't write overly complex lambdas."

My favorite "gotcha" in Python is using e.g. a list as a default argument.
That's in the guide, and it sucks, but Python has surprisingly few such
problems for newcomers.

~~~
YZF
I can think of two landmines that make most C++ issues pale. First is things
blowing up at run-time due to typos or syntax errors. Second (related) is that
you can't safely refactor because you don't really know the types that
functions take or where they're being called from. Sure C++ can be a pain but
you can build and maintain very large software in C++. It's a lot harder to do
in Python (without taking other considerations into account).

