
Additional C/C++ Tooling - ScottWRobinson
http://nickdesaulniers.github.io/blog/2015/07/23/additional-c-slash-c-plus-plus-tooling/
======
nnethercote
Calling Valgrind a "memory leak detector" totally underplays its usefulness.
But for some reason I've never worked out, a lot of people think this is all
it does.

The main things that Memcheck, the default Valgrind tool, do are:

1\. Detect accesses to inaccessible memory.

2\. Detect dangerous uses of undefined values.

3\. Detect memory leaks.

Memory leaks are arguably the least interesting of these three things.

ASAN can do 1 and 3, but cannot do 2. That's why Mozilla runs both Valgrind
and ASAN on Firefox test automation.

There's a tool related to ASAN called MSAN that attempts to do 2, but 2 is
really hard to do with static instrumentation so MSAN doesn't get much real-
world use.

~~~
glandium
And then there are the valgrind tools other than memcheck: cachegrind (cache
and branch-prediction profiler), callgrind (call-graph profiler), helgrind
(thread error detector), massif (heap profiler), and probably more I forget.

------
mden
Our team has had a decent compile time improvement by switching to ninja[1]
from gmake.

[1]
[https://martine.github.io/ninja/manual.html](https://martine.github.io/ninja/manual.html)

~~~
Joky
My experience has been very positive for incremental build (you have built
once a large software and change one file and need to rebuild) but no
difference on fresh build.

~~~
mahyarm
After a certain point, you can't get over compiler processing time.

~~~
mden
Ninja's magic happens before the compiler in deciding what needs to be
compiled quicker than gmake.

~~~
mahyarm
That's what I meant. If you have to rebuild everything, then ninja or gmake
doesn't make anything faster, since it's the compiler's speed at that point.

~~~
Joky
Well there is still the amount of parallelism that can be exposed. It just
seems that CMake exposes it as well for make than for ninja I guess.

------
antirez
While simple, osx "leaks" is truly formidable because you can call it while a
program that was compiled without any special flag is running. For example the
Redis testing framework runs "leaks" every time an unit was executed
completely, warning the user if a leak is found. When this happens I resort to
valgrind to find the cause, but to call "leaks" every time you want during
development and having it running in a few seconds is a killer feature. I miss
it when I develop using Linux.

~~~
enedil
Here you are:
[http://www.opensource.apple.com/source/SecurityTool/Security...](http://www.opensource.apple.com/source/SecurityTool/SecurityTool-7/leaks.c)
[http://www.opensource.apple.com/source/SecurityTool/Security...](http://www.opensource.apple.com/source/SecurityTool/SecurityTool-55109.1/leaks.h)

After reading the source, I think that you must put the binary in
`/usr/bin/leaks`.

------
apaprocki
If you work at a company that can afford Coverity (static analyzer), it is
great. Super simple to integrate into a standard gcc build.

~~~
TwoBit
I'd love to see a comparison of Coverity vs. Clang sanitizers.

I wish we could buy just a couple Coverity licenses, but they want to license
the entire organization for something like $200,000.

~~~
slacka
When Daniel Hax ran Coverity and Clang against the curl source code, he found
that the each "tool detected several issues the other didn’t spot."

Coverity – very accurate reports and few false positives

clang-analyzer – awesome reports, missed slightly too many issues and reported
slightly too many false positives [1]

You'll find similar results in PVS Studio vs clang[2] and PVS Studio vs
Coverity.[3] If code quality is important to your organization, than one tool
is probably not enough. If it's vital, you may want to consider another
language such as Haskell or OCaml.

[1] [http://daniel.haxx.se/blog/2012/07/12/three-static-code-
anal...](http://daniel.haxx.se/blog/2012/07/12/three-static-code-analyzers-
compared/)

[2] [http://www.viva64.com/en/b/0272/](http://www.viva64.com/en/b/0272/)

[3] [http://www.viva64.com/en/a/0076/](http://www.viva64.com/en/a/0076/)

------
angry_octet
You lost me when you suggested cmake as a build tool. Its principal killer
feature seems to be that it abstracts cross platform building. Unfortunately
the price you pay for that is eventual insanity, an unreasoning desire to
DESTROY EVERYTHING.

Stay away from cmake.

~~~
TwoBit
The thing I hate about CMake is that it can't generate relative directory
structure projects. That's stupid and no other build system of significance
has this limitation.

~~~
fit2rule
I don't know what you mean - can you explain this further? Because I've seen
it do what I think you mean, but I guess I don't understand.

------
Omnus
People often take it as common knowledge that Visual Studio barely supports C.
As of VS2015 almost all of the C99 standard is implemented, with a few corners
missing, like tgmath. I am interested to see if this allows more C libraries
to be built with VS rather than relying on MinGW and other Unix based
alternatives.

~~~
santaclaus
Doesn't Visual Studio support Clang as an official alternative to MS'
compilers, now?

~~~
TwoBit
I think the answer is yes and no. You can get clang to compile standard C/C++,
but not any Windows code, as Microsoft has many compiler extensions and quirks
they depend on.

------
amelius
> What did I miss?

Perhaps a tool to generate header files, so we don't have to write every
function declaration twice?

~~~
nulltype
I use makeheaders:
[http://www.hwaci.com/sw/mkhdr/](http://www.hwaci.com/sw/mkhdr/)

It's pretty amazing.

If you can't use makeheaders, I prefer the Plan 9 include style where header
files are not allowed to include header files:
[http://doc.cat-v.org/bell_labs/pikestyle](http://doc.cat-v.org/bell_labs/pikestyle)

~~~
amelius
Interesting. Do you know if it works with C++14?

~~~
kazinator
My educated guess: not a chance. It's probably not going to grok C++ member
declaration syntax, templates, namespaces, and so on.

------
andrewchambers
Someone should make a cargo clone for building C/C++ code. I don't care if it
makes everything statically linked, that is good for me. :)

~~~
ndesaulniers
I was playing around with this idea [0], much to the dismay of colleagues,
until I discovered that CMake's ExternalProject module could do everything my
"package manager" could do. I was pretty close to making the package manager
self hosting, too...

I think it doesn't actually matter if dependencies are statically linked or
dynamically linked, just as long as they are not installed globally, and
shared between non homogenous processes.

[0]
[https://github.com/nickdesaulniers/picodeps](https://github.com/nickdesaulniers/picodeps)

------
plorkyeran
Note that valgrind trunk now supports OS X 10.10 and 10.11 and it's completely
trivial to build.

~~~
ndesaulniers
Right, should have tried that! I bent over backwards building some of the
other tools from source!

See also:
[https://www.reddit.com/r/programming/comments/3egclc/additio...](https://www.reddit.com/r/programming/comments/3egclc/additional_cc_tooling/ctf4565)

------
banachtarski
Death to cmake. Long live premake (5)

~~~
jschwartzi
Death to cmake. Long live make.

~~~
banachtarski
You're kidding me. Have you tried to manage a cross platform build using make?

------
je42
Gradle also supports C/C++

------
toolslive
getting your code pass valgrind's exam is pretty essential. The only problem I
have with it is that it doesn't support all syscalls.

------
ilurk
Are there any comparisons of:

1) bazel VS. gradle

2) cmake+ninja VS. tup VS. redo

------
MichaelCrawford
The term "C/C++" is a Tool of the Devil. Each has its many endearing qualities
but it is inappropriate to put them together like that.

I often see job board posts and get mail from recruiters seeking coders with
experience in "C/C++". Consider that Linus Torvalds and Richard Stallman would
be unqualified for C++ work. I myself have done so much C++ that I am not
particularly good at C anymore.

If you use C++ as "A Better C" or "C With Objects" you will never get the bugs
out of your code. C++ wants to be written a certain way which is quite alien
to most C practices.

~~~
jasode
_> The term "C/C++" is a Tool of the Devil. Each has its many endearing
qualities but it is inappropriate to put them together like that._

I do understand the common complaint about that but in the author's type of
article, it's fine to lump them together. He's talking about "tools" for
runtime analysis, formatters, etc. The tools he's talking about handle both
languages.

His current url for the article is:

.../blog/2015/07/23/additional-c-slash-c-plus-plus-tooling/

What would be a solution to satisfy purists and _always_ separate C from C++?
Should the author create 2 separate urls?

C tooling url would be:

.../blog/2015/07/23/additional-c-tooling/

C++ tooling url would be:

.../blog/2015/07/23/additional-c-plus-plus-tooling/

And both webpages would be 99% the same and running a diff only shows that
string "C language" is replaced with "C++ language". Instead of that
convoluted redundancy, it's quite reasonable in this specific type of article
to lump "C/C++" together.

~~~
gherazta
But the tools _do_ change. E.g.

\- Development Environments

High-Level C++ is rather verbose so it is often developed in connection with
an IDE, e.g. to jump to a class definition. C works way better with
established tools like grep and co, as it does not do function overloading.

\- Debugging

C++ is for me the most hard language to debug, as their is so much stuff you
have to keep in your head. Due to name-wrangling symbols get also weird names
in debuggin areas.

\- FFI

C is the established high-quality FFI approach and popular languages have very
good _C_ FFI support: Python, Haskell, etc. In particular it is simpler for
language designers to support C.

It is similar to the Java/JavaScript debate, where one might argue that both
are interpreted languages.

~~~
jasode
_> But the tools _do_ change._

Yes but that's not relevant in this thread. Please try to follow the limited
context of this discussion. We are not talking about the set of ALL tools of
which some might be specific for C and others might be specific to C++.

Instead, we were discussing Nick Desaulniers' _specific article_ and the
_particular tools_ he's describing in _his article._

