Thread: question on consts.

It's more part of the design process. You should mark variables that should not change as const partly to prevent mistakes of your own.

Originally Posted by Elysia

It's more part of the design process. You should mark variables that should not change as const partly to prevent mistakes of your own.

I think the question was more about whether there is a tool that can automatically analyze the code and determine where "const" can be added.

There are such tools but I don't know of any free ones, and the commercial ones do not come cheap. Coverity is one popular tool for static source analysis. It starts at $30,000.

That was my intended point, though. Kind of. Yes.
A simple tool might detect variables that aren't modified and change them to const.
But are there tools that can detect which variables really should be const? That's the question, and probably is more of a design issue rather than a tool issue.

Detecting functions that are not implemented.

The linker will do that. Only when they're used, of course.

Detecting unused variables?

Try enabling all warnings (-Wall -Wextra) and optimization (-O1 or higher) in GCC.

Detecting unused includes is pretty easy, unless the project is enormous, by experimenting - just remove the include and compile - if compiles without warnings & errors, then it's not needed. It gets a bit harder if you have many different configuration options, but it's usually doable. Start with files that have a large proportion of include vs. actual code (where you have the biggest gain!).

I don't know of any tool that actually does this for you, however.

A cross-referencing tool can also help you with all manner of things - however, classes and pointers to classes can lead to interesting effects, e.g.

Code:

class A
{
   public
      virtual void foo();
};

cass B: public A
{
   public:
      virtual void foo();
};

void func(A *ptr)
{
   ptr->foo();
}

The linker will probably complain if you don't implement B::foo(), but if you never actually call func() with a pointer to B - because of the way that func is being used - then it's very difficult to discover - I don't think coverity can do that either (I have used coverity a little bit - but not a whole lot).


--
Mats

Originally Posted by matsp

Detecting unused includes is pretty easy, unless the project is enormous, by experimenting - just remove the include and compile - if compiles without warnings & errors, then it's not needed. It gets a bit harder if you have many different configuration options, but it's usually doable. Start with files that have a large proportion of include vs. actual code (where you have the biggest gain!).

There's only one problem with that, though.
Since header X may include header Y, you will find that the code may compile without header Y and you may deem it unnecessary, remove it, and thus, the code will fail to compile on other compilers.
Beware.

Originally Posted by Elysia

There's only one problem with that, though.
Since header X may include header Y, you will find that the code may compile without header Y and you may deem it unnecessary, remove it, and thus, the code will fail to compile on other compilers.
Beware.

That's what I meant by "but it gets harder if you have many configurations" (as the different configurations will mean many compiles with either different compilers or different settings).

Beware of differences between debug and release builds too - release builds may not use the logging code, which is produced in a debug build. So when you remove say, stdio.h, then the code will build in release form, but not in debug form.

--
Mats

We use a version of "linux cross reference", which is used on this site:
http://lxr.linux.no/

It's not perfect, but it's pretty good. Source code for that site is available via link on the above page.

--
Mats

> or program that can add const modifiers to parameters that aren't changed withing a function..
Lint will do a lot of that, and at around $400 (oh man, it's gone up!) for a single-user licence, it pays for itself with the first bug it finds that you no longer have to spend a day looking for the old fashioned way.

They're the same product (with different names) for different markets.