proj-plbook-plChCtmLangs

Table of Contents for Programming Languages: a survey

C

Because it is so well-known and well-liked, C gets its own chapter.

See chapter on chapter on C.

C++

"In C++’s case, the Big Idea was high level object orientation without loss of performance compared to C." [1] (my note: and backwards compatibility with C; and close-to-the-metal low-level operation)

• Backwards-compatible with C.
  • However C's longjmp interacts poorly with C++ destructors: http://en.cppreference.com/w/cpp/utility/program/longjmp
• A combination of performance, abstraction, and portability (e.g. https://news.ycombinator.com/item?id=6417859 )

" C++ is a general-purpose programming language with a bias towards systems programming that

    is a better C
    supports data abstraction
    supports object-oriented programming
    supports generic programming " -- http://www.stroustrup.com/C++11FAQ.html#aims

" ...C++’s fundamental strengths:

• A direct map to hardware (initially from C)
• Zero-overhead abstraction (initially from Simula) " -- Thoughts about C++17 by Bjarne Stroustrup

Attributes:

• Imperative
• Compiled
• Low-level
• OOP

Pros:

• Backwards-compatible with C.
• "You only pay for what you use"; that is, although the language does provide optional abstractions which require more time or memory overhead than C, these are always optional.
• "support for object-oriented programming, generic programming, traditional procedural programming, and multi-paradigm programing combining elements of those." -- A rationale for semantically enhanced library languages
• "Classes plus templates plus overloading is the basis of expressiveness and performance." -- A rationale for semantically enhanced library languages

Cons:

• Big language
• Many of the most obvious ways to do things are antipatterns. Must learn best practices to avoid writing buggy code. Cite e.g. http://bartoszmilewski.com/2013/09/19/edward-chands/ , https://news.ycombinator.com/item?id=6418165
• Build time with many header files
  • "How did we get here? Well, C++ and its stupid O(n^2) compilation complexity. As an application grows, the number of header files grows because, as any sane and far-thinking programmer would do, we split the complexity up over multiple header files, factor it into modules, and try to create encapsulation with getter/setters. However, to actually have the C++ compiler do inlining at compile time (LTO be damned), we have to put the definitions of inline functions into header files, which greatly increases their size and processing time. Moreover, because the C++ compiler needs to see full class definitions to, e.g., know the size of an object and its inheritance relationships, we have to put the main meat of every class definition into a header file! Don't even get me started on templates. Oh, and at the end of the day, the linker has to clean up the whole mess, discarding the vast majority of the compiler's output due to so many duplicated functions. And this blowup can be huge. A debug build of V8, which is just a small subsystem of Chrome, will generate about 1.4GB of .o files which link to a 75MB .so file and 1.2MB startup executable--that's a 18x blowup." [2]

Good for:

• low-level code (for systems programming or for performance) when more abstraction is desired than C can provide
• simulations; simulations are generally CPU-bound programs that take a long time to run and hence demand efficiency. The OOP paradigm is generally a good fit; types of domain objects are usually represented by object-oriented classes.

Best practices and style guides:

• http://www.stroustrup.com/Tour.html (rec. by [3])
• C++ Primer, 5th Edition (rec. by [4])
• http://bartoszmilewski.com/2013/09/19/edward-chands/
• Effective modern C++ (recc. by [5], [6] but counter-recommended by [7] and 2 others in that thread, for the reason that it goes into detail about gotchas)
• https://google.github.io/styleguide/cppguide.html
  • old URL? http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• "Modern C++ can be safe by making use of:
  • type safe enums (enum class)
  • STL collections instead of plain C like types
  • references for out parameters
  • RAII
  • smart pointers
  • values types over heap allocations everywhere
  • warnings as errors
• "-- [8]
• C++ Core Guidelines edited by Bjarne Stroustrup and Herb Sutter
• http://google.github.io/styleguide/cppguide.html
• http://www.stroustrup.com/resource-model.pdf
• https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637
• http://clang.llvm.org/extra/clang-tidy/ "the clang tidy linter has a way of checking your code against the C++ core guidelines [2], which is a set of modern best practices for the language" [9]