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.
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.
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.
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.
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.
I have not tried this yet, but Coverity provides a free online tool for open source projects. It will be a nice complement to travis/coveralls and other CI tools available for free to open source projects.
I'll definitely try it out once I get some time to work on infrastructure things on my own open source projects.
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.
Just out of curiosity, how big is your org? I've been tempted to suggest Coverity a few times but I always balk at buying tools where the price is listed as $CallSalesAndNegotiate.
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.
Seven years ago I helped move a fairly complicated commercial codebase from automake to cmake. In the process, I wrote thousands of lines of complicated cmake macros to interface with the packaging system, etc.
The end result was a love/hate relationship with cmake.
Clearly, the weakness is its hokey scripting language. The shame is that if they'd just started with something halfway reasonable like lua it would have been easier to build the tool and it would be far more powerful. Instead, they couldn't resist writing their own DSL where everything you need to do is possible but just barely. I've done so many zany hacks over the years to force it to do what I needed.
Granted, I did the major porting work to cmake 2.4. The newer versions are certainly better (no more duplicating the expression in IF()/ELSE()/ENDIF() statements!) but it's still pretty painful to write something non-trivial compared to any modern scripting language.
However, the results of cmake are fantastic. Once you've got your CMakeLists.txt's working you can largely forget about it -- it'll just work, completely cross platform. If you need to target both UNIX compilers and the Visual Studio world it's probably the best solution.
Having spent moderate to significant time with bjam, waf, qmake, make and cmake, I more or less settled on cmake because:
A. It's what everyone else is using.
B. It's simple to do common things.
C. It's pretty darn fast with the Ninja backend.
The only downside seems to be that the cmake language is ugly and limited. Fortunately, I only need to write a tiny amount of cmake code to build most of my projects, since find_package is so good. (Though, it probably sucks to be the guys making that work.)
To be honest, every tool I've tried has kind of sucked. cmake just sucks the least. One day I'd like to investigate tup and shake, though.
I have to agree honestly. I've tried many of the build systems out there, and I have settled on tup[1] as being one of the greatest creations ever. The Tupfiles are incredibly simple, the execution time is bloody fast, and it is more capable of creating easily-reproducible builds than anything else I've seen so far. I'd recommend you give it a look if you're not familiar with it.
CMake works well if you're building typical user space applications or libraries with dependencies to popular and typical libraries that CMake can find or follow typical conventions. It completely falls apart if you need to do something unusual or automate non-build tasks with it. E.g. building bootable kernel images (where you need a linker script, etc) with CMake is quite painful (I've done it, will not do it again).
The best feature of CMake for me has been easy cross compiling so I can develop and remote debug Windows apps on my Linux box.
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.
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.
Indeed, on my post about "Designated Initialization With Compound Literals in C" [0], someone commented "cool, but I use MSVC so..." [1]. Note: that was two years ago, I'm sure that's not the case.
I'm sure IDE's have great features; I wanted to avoid them in the article; they are simply not for me.
It may increase a bit. In fact the recently started C-based project Handmade Hero is done within Visual Studio so maybe that will spark some interest. The real advantage of mingw and other opensource tools is that you can use the same compiler on both Windows and Linux. With something like msys you can even get away with using a single Makefile. Also because C is a small language many professional C developers are unlikely to use an IDE and so would more likely use the windows sdk (assuming that still ships with the command line compiler which I'm not sure about).
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.
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
As annoying as it is, especially when updating function signatures, I kinda enjoy having separate header files. It clearly defines the public vs. private interface(s), it's a place to put your docstring comments in and a single file that can provide a quick glance to how a module works.
Although it is much less practical in C++ than in plain C, when you have to put the whole class definitions (including private member functions) in a header.
A good editor/tags system/ide should support jumping between definition and declaration quickly, this definitely makes it a bit less painful (e.g. vim + ctags + cscope work fine).
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.
Apparently that's a build tool that uses lua rather than some bastardized config language (like CMake does), and otherwise is somewhat inspired by CMake?:
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.
>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.
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.
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.
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.
The OP is about tools to build, develop and debug C and C++. None of the mentioned tools apply to one and not the other. Why would you want the title not to mention both?
I agree, C and C++ despite many similarities and close ties in their family trees are quite different. I did not make that point in the article, as it's irrelevant to a piece on tooling that works for both.
You can use a C++ compiler to do "C with objects" fine. Lots of people successfully do that. There's specification for doing this in fact which is adhered to by embedded developers. It's better to use C++ more fully, of course.
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.