Facebook Flint: Public domain C++ lint

By Felix Petriconi | Dec 1, 2014 02:02 AM | Tags: intermediate

Some months ago Facebook brought their C/C++ Facebook-Lint (Flint) analyzer into public domain and made it available on github.com/facebook/flint. Flint provides a lint framework and a number of C++11/14 style rules that we have found useful in our company.

This static code analyzer is not based on a C++ parser, but works with a tokenizer, completely written in D. (The previous C++ version of the program is still part of the repository.) 

Andrei Alexandescu gives detailed information in his blog entry:

Under the Hood: Building and open-sourcing flint

by Andrei Alexandrescu

... Writing a C++ linter in particular is not for the faint of heart because of C++'s high barrier to entry for parsing. That said, there are now dozens of C++ lint programs with a variety of features, some open sourced. So the natural question is why we chose to write our own instead of using a pre-existing one.

When we started this project, the lint programs we tried were too slow and most didn't support the C++11 features that our codebase had already started to use. Clang, which today would be logical starting point for a C++ analysis tool, offered too little support back then...

The distributed makefile is designed to work on Mac OS and Linux. But it is pretty easy to build a working flint.exe for Windows with Visual Studio and an installed D compiler and the corresponding plugin.

We prefer in our company either pairing or code reviews to ensure a high code quality. But we decided to use Flint as an additional safety-net and since the speed of the analyzer is so amazingly high, we were able to integrate it into the pre-commit hook of our Mercurial repository without any noticable performance drawbacks. So all to be committed C++ files are checked against a subset of all rules, that Flint supports.

(We disabled some Flint rules in the source code, because of missing C++11 capabilities of Visual Studio 2012/2013 and certain checks that does not make sence in our context.)

Consider automatically applying a lint tool in your project build. Whether you pick this or another one, it's worth checking out.

Quick Q: Are "++a" and "a = a.load() + 1" equivalent if 'a' is "atomic<int>"?--StackOverflow

By Jared Mulconry | Dec 1, 2014 01:57 AM | Tags: intermediate c++11

Quick A: No. Between a.load() and the addition and store to a is a window in which other threads can change the value of a, causing updates to be lost.

Recently on SO:

c++ atomic read/write misunderstanding

Why program with this code sometimes prints "2"?

int main() {
    std::atomic<int> a;
    a = 0;

    std::thread t1([&]{++a;});
    std::thread t2([&]{a++;});
    std::thread t3([&]{
        a = a.load() + 1;
    });

    t1.join();
    t2.join();
    t3.join();

    if (a != 3) {
        std::cout << "a: " << a << std::endl;
    }
}

I've thought std::atomic guarantees that all operations will be done atomically so writing here(incrementing) will use a memory barrier and we will have always "3" at the end of threads work. I've explored the code and found out that the problem thread is t3 but I can't understand why it is wrong.

ODE simulations with Boost.odeint and Boost.SIMD

By Meeting C++ | Nov 30, 2014 08:36 AM | Tags: intermediate boost advanced

A very nice article on how to use boost::odeint and SIMD:

Boosting ODE simulations with Boost.odeint and Boost.SIMD

by Mario Mulansky

From the article:

Ordinary Differential Equations appear in numerous applications and finding their solution is a fundamental problem in science and engineering. Often one has to rely on numerical methods to approximate such solutions as in the presence of nonlinearities, no analytic solution can be found. Being such a frequent problem...

Design Patterns Revisited -- Bob Nystrom

By Mantosh Kumar | Nov 28, 2014 10:01 AM | Tags: intermediate

Walk through (with practical examples) a handful of the original patterns the Gang of Four documented in C++.

Design Patterns Revisited

Design Patterns: Elements of Reusable Object-Oriented Software is nearly twenty years old by my watch. Unless you’re looking over my shoulder, there’s a good chance Design Patterns will be old enough to drink by the time you read this. For an industry as quickly moving as software, that’s practically ancient. The enduring popularity of the book says something about how timeless design is compared to many frameworks and methodologies.

While I think Design Patterns is still relevant, we’ve learned a lot in the past couple of decades. In this section, we’ll walk through a handful of the original patterns the Gang of Four documented. For each pattern, I hope to have something useful or interesting to say.

I think some patterns are overused (Singleton), while others are underappreciated (Command). A couple are in here because I want to explore their relevance specifically to games (Flyweight and Observer). Finally, sometimes I just think it’s fun to see how patterns are enmeshed in the larger field of programming (Prototype and State).

Anti-IF idioms in C++ -- Marco Arena

By Marco Arena | Nov 28, 2014 09:46 AM | Tags: intermediate community c++14 c++11

I'm showing interactive examples of "anti-IF" idioms in C++, inspired by C# snippets which Claudio Pattarello proposed at the Italian Agile Day 2014.

Anti-IF idioms in C++

by Marco Arena

From the article:

In this post I’d like to show you how to rewrite these idioms in C++, starting from a C# snippet. And the resulting code is pretty much identical. [...] I'm not saying "this is the best thing you can do in C++". [...] Sure, we have specific idioms in our favorite language but I think it’s lovely that we are able to reuse the same code from other languages with a little effort. And this is also appealing for other programmers who want to experience C++, maybe by starting coding idioms they know. ...

Where will Evolution lead C++17?

By Meeting C++ | Nov 9, 2014 06:02 AM | Tags: intermediate experimental c++17 advanced

The third part of my series about the proposals for Urbana is about the subgroup evolution:

Where will Evolution lead C++17?

by Jens Weller

From the article:

This is the third part in my series about the proposals for the current C++ committee meeting in Urbana. This time its all about the subgroup Evolution, which has the most papers, so this is only the first part. The previous parts were about concurrency, and Part 2 about core, networking, models and undefined behavior.

Looking for C++17 - Urbana Proposals for Core, Modules, Networking, Reflection and UB

By Meeting C++ | Nov 1, 2014 09:24 AM | Tags: intermediate experimental c++17 advanced

The second part of my series on the C++ Proposals for the next Committee meeting in Urbana:

Looking for C++17 - Urbana Proposals for Core, Modules, Networking, Reflection and UB

by Jens Weller

From the Article:

The second part of my series about the proposals for Urbana, where the next C++ committee meeting will be held. The papers grand us a first view on a distant future - C++17...

C++ and Zombies: a moving question

By Meeting C++ | Oct 31, 2014 03:57 AM | Tags: performance intermediate efficiency c++14 c++11 boost advanced

One of the issues I was thinking about since C++Now: move and move-destruction

C++ and Zombies: a moving question

by Jens Weller

From the article:

This has been on my things to think about since C++Now. At C++Now, I realized, that we've might got zombies in the C++ standard. And that there are two fractions, one of them stating, that it is ok to have well defined zombies, while some people think that you'd better kill them.

Urbana Proposals - C++17 insight?

By Meeting C++ | Oct 25, 2014 01:59 AM | Tags: intermediate experimental c++17 c++ committee basics advanced

I've started with my series on the proposals for the next C++ Committee Meeting:

Urbana Proposals - C++17 insight?

by Jens Weller

From the article:

A short series to give you an overview over the Papers submitted in the latest mailing for the C++ Committee Meeting in Urbana-Champaign in Illinois. At the beginning of November the C++ Committee will have its 3rd Meeting this year. As C++14 is now finished, the focus is clearly on the upcoming C++17 standard.

Quick Q: Should I prefer non-member std::begin and std::end? -- StackOverflow

By Blog Staff | Oct 5, 2014 09:26 PM | Tags: intermediate

Quick A: Yes.

A classic on SO, just re-asked yesterday:

When to use std::begin and std::end instead of container specific versions

Are there any general preferences or rules that explain when container specific versions of begin and end should be used instead of free functions std::begin and std::end?

It is my understanding that if the function is a template whereby the container type is a template parameter then std::begin and std::end should be used, i.e.:

template<class T> void do_stuff( const T& t )
{
    std::for_each( std::begin(t), std::end(t), /* some stuff */ );
}

What about in other scenarios such as a standard / member function where the type of container is known? Is it still better practice to use std::begin(cont) and std::end(cont) or should the container's member functions cont.begin() and cont.end() be preferred?

Am I correct in assuming that there is no benefit in performance by calling cont.end() over std::end(cont)?