Errors: Compiling

In general it is usually not too difficult to figure out what the compiler is complaining about as it points to the line at fault. Problems can be hard to understand if the error you have made has a knock-on effect. The following compilation problems are covered:-

Compiling rootcint dictionaries
Missing member function definitions
Conflicting member function definitions
Conflicting return types
Syntax errors involving < and >
General errors

Compiling rootcint dictionaries

If rootcint dictionaries (code generated by rootcint that contain dictionaries of user classes) fail to compile, check that:-

the LinkDef.h file has been properly updated and is the last file passed to rootcint. If it contains templated classes, they should come before any non-templated ones. Strictly speaking they only need to precede any that use them. Failure to do this can lead to strange errors such as:-
Specialization of template-class::ShowMembers(...) after instantiation
rootcint did not generate any errors.
You are running the right version of rootcint i.e. the version:-
```
  $ROOTSYS/bin/rootcint
```
is the same as:-
```
  where  rootcint
```
and not some other version located earlier in your PATH.

Missing member function definitions

Make sure you have included the class's header file rather than just an incomplete class definition i.e. you have e.g.:-

   #include "MyClass.h"

instead of just:-

   class MyClass;

Conflicting member function definitions

Definitions in the header and implementation files must be identical, and that includes any const keywards. For example:-

   Int_t GetInt() const;

does not match:-

   Int_t MyClass::GetInt() {return fInt;}

It has to be:-

   Int_t MyClass::GetInt() const {return fInt;}

Conflicting return types

One problem that catch the unwary is that if const member functions return pointers to themselves or internal components, then these pointers must also be const. Its logical really: const member functions are the only functions allowed to access objects in read-only memory, and of course any pointers into such objects must be read-only too.

Syntax errors involving < and >

If you get syntax errors and the code looks a bit like this:- > <<<<<<< <filename> > > ... > ======= > > ... > >>>>>>> 1.18 then this is a CVS conflict. CVS has found that it cannot merge a repository update into you local file system because a change made locally conflicts with an official change. This can happen if, for example, you accidentally modify local code. If you really didn't mean to make a local change then the simplest course of action is to delete the local code and restore from CVS:- cd <problem directory> rm <problem file> cvs update <problem file> If you did mean to make a change then the conflict has to be understood and resolved.

General errors

If you cannot see what is wrong:-

Comment out the problem statement using // at the start of line. Does the error go away? If it does then at least the compiler hasn't got confused as to the source; try breaking up complicated statements.
If the error still occurs but has moved down then look back to the lines above, the problem lies there. Check particularly for a missing semi-colon (a popular mistake for FORTRAN programmers).
Check for mismatched braces - an editor like emacs can help here as it can highlight the opening bracket that matches a closing one.
As with FORTRAN, if you get multiple errors, fix those you understand and try again. Others may not be genuine.

Contact: Nick West (n.west1@physics.oxford.ac.uk>)