
Ways to Avoid Complexity in Modern C++ [pdf] - ingve
http://vitiy.info/Slides/MeetingCPP2015/MeetingCPP2015Complexity.pdf
======
xigency
Hm, this seems to be more advice on how to use C++14 as if it were its own
language, or as if it were Java, or as if it were Scheme.

One problem I have with the advice to use the newest language features in C++
is that it sacrifices one of the biggest advantages to writing code in C++:
the ability to compile for multiple platforms. It's extremely unlikely that
one has a compiler for every platform that supports all of these features.
Additionally, each of these language features adds a small bit of convenience
to the developer, while making the compiler substantially more complicated
(and hence, more prone to errors).

To summarize the points made in the first 10 slides, which is far as I read
(sorry)-

1) Always use auto.

2) Use for-each.

3) Don't use new or delete.

4) Use STL for everything.

5) Use smart pointers.

~~~
pjmlp
> biggest advantages to writing code in C++: the ability to compile for
> multiple platforms. It's extremely unlikely that one has a compiler for
> every platform that supports all of these features.

Do you have war wounds from the C++ ARM or K&R C days?

I have. That was one of the reasons many of us enjoyed using Java.

It was much easier than dealing with all compiler and OS compatibility issues.

The situation with C++14 compatibility is way better than on those days.

~~~
hermanhermitage
I agree strongly with these comments.

I used template heavy C++ back in the late 1990s, rolling container classes
implementing smart pointers it was tricky to get good code compatibility
across a range of compilers: Edison Design Group, icc, MSVC++, gcc. Ultimately
I found myself reassessing the tradeoffs in using C++ for many projects.

Fast forward to 2015 and the situation is much better - even for "soft"
embedded scenarios. GCC and clang have good reach and MSVC++ is evolving with
the language.

Engineering decisions are often about making tradeoffs and with the state of
C++14 and things like C++ Core Guidelines and good support for RVO/move
optimisations I find the appeal of C++ has broadened again. And there is good
support for modern C++ on many platforms.

Of course there are platforms out there where C++ is still not suitable. For
example I'm currently doing a lot of 8086 real mode work, where due to
external constraints all the code has to be written in assembler. Neither C or
C++ are candidates for me in this work. These platforms will always exist. But
many embedded platforms with smart phone level of processing power are solid
targets for modern C++.

------
hawski
For some time I think of C++ not as a programming language, but as a make-
your-own-programming-language-kit. It's because practically there is no the
C++. Everyone uses different subset or even coding style. C++ ABI is not as
interoperable as C ABI (if you can even say that it exists). Almost every
bigger library reimplements Object - the base interface of everything. Then
they need wrappers and adapters between those different object models. Qt for
example is not written in C++ - it has to be compiled with their MOC to add
signals/slots and introspection around other things. But all this ad-hoc
languages suck in regard of tools. Their error messages are unintelligible and
everything relies on convensions (hopefully enforced at least by code
reviews). I could paste here quote about ad-hoc reimplementations of Lisp...

C++ is still necessary (evil) in some cases, but as a C++ programmer I have
enough and I plan to move to other languages.

~~~
seivan
Yup, I've had the same experience. Every C++ project or framework pretty much
has its own style and I don't just mean code structure.

------
halayli
The advise is pretty useless. Complexity often comes from incorrect
abstractions, not from language features.

Programmers can build very complicated systems using the simplest languages
available.

~~~
sklogic
A language, and especially a low level language, often jumps in front of your
nice abstractions and obstructs them with all the unworthy low level details
and its exposed bare guts.

Techniques for eliminating this leaky abstraction are important indeed.

------
emcq
A little confused about the authors decision to do operator overloading with
the pipe operator rather than a function chaining interface for the functional
bit. Wouldn't a function chaining interface be simpler and use less magic?

~~~
vvanders
I think it approximates the pipe("|>") operator that you see in quite a few
functional languages.

~~~
restalis
And it is a poor choice to consider that in C++, because in here there already
is a default non-compatible interpretation for their expression.

~~~
CyberDildonics
It depends on the context. The pipe in a data flow sense will be working on
data structures, a bitwise or will need to work on two plain data types.

------
grabcocque
C interop. The cause of, and solution to, all of C++'s problems.

~~~
warmwaffles
Explain?

~~~
jcl
Presumably, C interop is the cause of C++'s problems because it was the
impetus for carrying forward all of C's warts into C++. And it is the solution
because it allows you to put C++ code behind a C-compatible interface so that
you can use it from a language that isn't C++.

~~~
pjmlp
The "Design and Evolution of C++" is a very nice book from Bjarne explaining
his compromises regarding what eventually became C++98.

------
armitron
Don't use it?

Nothing can salvage C++ at this point. It needs to be EOLed and put to rest.

~~~
vvanders
When you give me a language that I can specify explicit memory layout and
support for generics we can talk.

Otherwise C++ is going to continue filling the space for large, performance
sensitive applications.

~~~
krylon
No flame-bait here, but if you are seriously looking for that, how about Ada?

Realistically, I don't see C++ going away for a looong time (if ever), simply
because of the huge amounts of code written in it. But if one were looking for
an alternative that matches C++ both in performance and control over memory
layout, Ada is where I would start. It has generics, you can do OOP, it avoids
many of the syntactic pitfalls of C++... As a bonus, the language standard and
the rationale are available for free.

~~~
marvy
How much does Ada rely on garbage collection?

~~~
Solarsail
Doesn't have one. Reference counting is available as a (what looks like third-
party) library: [http://www.adacore.com/adaanswers/gems/gem-97-reference-
coun...](http://www.adacore.com/adaanswers/gems/gem-97-reference-counting-in-
ada-part-1/)

I guess you could say that is even less reliance on GC than C++ has, with
smart pointers being part of the standard.

------
PythonicAlpha
I used to program C++ a lot, several years ago.

My way, today, to avoid complexity in C++: Avoid C++!

C++ is at least three languages and the complexity is at least that of three
languages. If you really want to be faster at programming and don't need to
have the last 5% of performance, do you a favor and use an other language.

~~~
unabashedturtle
For some of us, that 5% is incredibly valuable. Really, any HPC application is
going to either be written in C/C++ or Fortran.

It goes without saying that modern fortran is a hideous language (even though
it's still better than Fortran 77). C is nice and simple but without things
like namespaces and classes you're going to end up with huge function names.
Not to mention a high risk of memory leaks.

C++ was awful years ago. Honestly C++11 allows you to write fairly nice code.
By no means a guarantee you'll write clean-ish code, but it definitely gives
you the tools to do so. Plus modern C++ compilers produce _really_ fast code
(that leverages SIMD/vectorization, etc.).

I'm a huge fan of Go and Rust but the former is often dogmatically minimalist
to the point of not including things like templates, operator overloading,
etc. Not to mention garbage collection/runtime which is a big no-no for
numerical computing use. The latter is still not mature enough to fully commit
to (and is nowhere near the speed of optimized C/C++).

~~~
steveklabnik

      > (and is nowhere near the speed of optimized C/C++).
    

Please file bugs! We consider them as such.

