views:

958

answers:

8

I'm currently in the process of learning C++, and because I'm still learning, I keep making mistakes.
With a language as permissive as C++, it often takes a long time to figure out exactly what's wrong -- because the compiler lets me get away with a lot. I realize that this flexibility is one of C++'s major strengths, but it makes it difficult to learn the basic language.
Is there some tool I can use to analyze my code and make suggestions based on best practices or just sensible coding? Preferably as an Eclipse plugin or linux application.

+13  A: 

Enable maximum compiler warnings (that's the -Wall option if you're using the Gnu compiler).

'Lint' is the archetypical static analysis tool.

valgrind is a good run-time analyzer.

ChrisW
+1 for valgrind. It finds many newbie subtile errors like off by one.
ypnos
+1 for lint, such an amazing tool
JaredPar
Beware that most version of lint are written for C and are pretty useless for C++. Gimple PC-Lint is an exception.
Andy Brice
+2  A: 

lint - there are lots of versions but if you google for lint you should find one that works. The other thing to do is turn on your compiler warnings - if you are using gcc/g++ the option is -Wall.

You might find CppChecker helpful as a plugin for Eclipse that supports gcc/PC lint.

Nick Fortescue
+2  A: 

Tool support for C++ is quite bad compared to Java, C#, etc. because it does not have a context-free grammar. In fact, there are parts of the C++ grammar that are undecidable. Basically, that means that understanding C++ code at the syntactic level requires implementing pretty much a compiler front end with semantic analysis. C++ cannot be parsed into an AST independently of semantic analysis, and most code analysis tools in IDEs, etc. work at the AST level. This is part of the tradeoff you make in exchange for the flexibility and backwards compatibility of C++.

dsimcha
And this is exactly why I wanted to scream when I saw what new "features" the standards committee was going to add in C++0x!
c++ has a just-fine context-free grammar, and can be parsed just without semantic analysis if all you want is a syntax tree (and some ambiguities). You have to stop using weak parsing technology such as LALR (e.g., YACC). See GLR parsers, and especially see Elsa www.eecs.berkeley.edu/~smcpeak/elkhound/sources/elsa/ andthe DMS Software Reengineering Toolkitwww.semanticdesigns.com/Products/FrontEnds/CppFrontEnd.htmlBoth of these tools also provide full "semantic analysis" in the sense of determining the meaning of symbols and removing ambiguities from the parse tree, if asked.
Ira Baxter
Yes, but the some ambiguities part was the point I was trying to make.
dsimcha
+4  A: 

For g++, as well as turning on -Wall, turn on -pedantic too, and prepare to be suprised at the number of issues it finds!

anon
+1  A: 

I think that really what you need to learn here is how to debug outside of an IDE. This is a valuable skill in my opinion, since you will no longer require such a heavy toolset to develop software, and it will apply to the vast majority of languages you already know and will ever learn.

However, its a difficult one to get used to. You will have to write code just for debugging purposes, e.g. write checks after each line not yet debugged, to ensure that the result is as expected, or print the values to the console or in message boxes so that you can check them yourself. Its tedious but will enable you to pick up on your mistakes more easily, inside or outside of an IDE.

Download and try some of the free debugging tools like GDB too, they can help you to probe memory, etc, without having to write your own code.

jheriko
+1  A: 
Klaim
I second the comment re reading these books (+1).
Richard Corden
+1 for Meyer's Effective C++ books.
Andy Brice
+2  A: 

Turning on all compiler warnings (at least initially) and then understanding what they mean, how to fix the problems highlighted and which of the warnings represent genuine constructs that compiler writers might consider ambiguous is a good first step.

If you need something more heavy duty, you could try PC-Lint if you're on Windows, which is still one of the best lint tools for C++. Just keep in mind that you'll need to configure these tools to reflect your coding style, otherwise you'll get swamped with warnings and won't be able to see the wood for the trees. Yes, it costs money and it's probably a bit overkill if you're not doing C++ on a "getting paid for it" level, but I find it invaluable.

Timo Geusch
+3  A: 

There is as list of static code analysis tools at wikipedia.

But warnings are generally good but one problem with enabling all warnings with pedantic and Wall is the number of warnings you might get from including headers that you have no control over, this can create a lot of noise. I prefer to compile my own software with all warnings enabled though. As I program in linux I usually do like this:

Put the external headers I need to include in a separate file, and in the beginning of that file before the includes put:

#pragma GCC system_header

And then include this file from your code. This enables you to see all warnings from your own code without it being drowned in warnings from external code. The downside is that it's a gcc specific solution, I am not aware of any platform independent solution to this.

Zitrax