Rants

December 11, 2015 ยท View on GitHub

Use structs for plain-old-data types (POD), classes for OOP (which you should use sparingly). Prefer PODs.

Re the Google C++ style guide: handy starting point, but don't have to drink all the koolaid.

Unicode: http://utf8everywhere.org/, Unicode in C++ (CppCon 2014)

Potential Tools

Dynamic Analysis

  • Coveralls.io - code coverage analysis using gcov
    • Projects seem to be shared across users who have access, so sign in with your own account and create projects as needed.
    • Currently unpaid, so only OSS projects
  • Clang static analysis and dynamic sanitizer tools? These are still under development, and not sufficiently broadly available to make part of CI tooling

STL debug support in GDB

cling - an interactive C++ interpreter

Libraries

Selection Criteria

  • Builds without warnings in Clang and GCC, including -Wextra
  • Doesn't peg itself to an outdated version of Boost
  • Unicode support, if it needs to interact with strings
  • Is under active development. When was the last release? How often is there a new release? How often do we expect to need the new release?
  • Supports building on Windows with MinGW-w64
  • The security track record. Does upstream have a security mailing list?
  • License requirements. With C++ based stuff, beyond the normal license concerns, we'd like to be able to statically link libraries in (or at least have that flexibility). That means no GPL (v2 or v3) if we can help it. Prefer BSD, MIT, or ASL 2.0.

Release Engineering requests all new libraries be screened through the New Third-Party Library Request Process.

Using libraries in a project

How to include libraries in a project is a work-in-progress. Currently projects use CMake's find_package to find previously built/installed packages. On POSIX systems this works well for development with package managers, but a system for local dependency installation would be desirable (bundle vs gem). On Windows most packages don't have pre-compiled MinGW packages to host on Chocolatey, and Chocolatey is still a young project (timely package updates aren't always available). We should also make a distinction between OS functionality that simply may not be available on all installations - such as Windows SDKs and libblkid (Linux) - and other libraries.

Most large C++ presences end up with a monolithic repository for dependencies and interdependent projects. We would like to avoid this and keep our project environment more modular.

Interesting Candidates

  • Okasaki - functional data structures
  • docopt - nice command-line parsing
  • coroutines - go-style coroutines and channels
  • HAMT - hash array-mapped trie
  • Mach7 - fast pattern-matching (often faster than the Visitor pattern)
  • RapidCheck - generative property-based testing for C++