MISSING FEATURES
****************************
tipi con < > non vengono gestiti (solo le classi
base, ma senza annidamenti)

gestire i reference &

gestire i metodi const
****************************

i branch dovrebbero essere possibili solo quando si sta esaminando una classe
(testare il controllo all'interno di prog elems)

occhio alle inheritance cicliche: devono essere evitate!

Controllare che il tipo di un multimetodo sia un puntatore e non un
tipo di base

Controllare che ogni multimetodo sia differente (per parametro)
da un altro dello stesso ramo

togliere generate da ProgElems?

La differenza sul parametro su cui viene fatto il double dispatch non
deve essere per un const o per un puntatore invece di un riferimento.
Questo deve essere controlato?  O lo lasciamo fare al compilatore?
Inoltre si deve avere che il tipo puntatore o riferimento deve
essere lo stesso, e se e' const uno lo devono essere tutti quelli
dello stesso branch.

le varie stringhe create per gli IDE rimangono allocate...
meglio passare alle string invece di usare i char *

con l'opzione di test continua a generare .h invece di .h_test
con l'opzione invade-target...

invadere anche i .cpp anche questi circondandoli con un //begin
comment che poi puo' essere ignorato durante il preprocessing?

aggiungere un commento agli .hpp dei non soli target dicendo che
si tratta di un file generato automaticamente e che non deve essere
modificato e di modificare invece il sorgente vero.

fine di un metodo }; dovrebbe contemplare anche lo spazio o e'
rischioso?

-------
INCLUDE
-------

visto che adesso l'include viene gestito, si deve riconoscere anche
template<class T, ...>

Rivedere IncludeModifier, in modo che capisca quali file sono stati
effettivamente modificati.
Provare anche con una classe base di partenza che non definisce nessun
multimetodo.

Nella documentazione dire che se non si aggiunge nessun nuovo ramo,
ma si ridefinisce e basta uno esistente, non importa usare branches.

-------
VIRTUAL
-------

controllare che i path nel file name vengano gestiti correttamente

analyse_header puo' essere ottimizzato in modo tale da controllare
prima se il file e' gia' stato esaminato e poi proseguendo (vedendo
se il file effettivamente esiste).

testare e documentare sourcepath ed excludeheaders

----------
Generazione files
----------

provare a non dover cambiare l'estensione del file, basandosi per le
estensioni di input su quella specificata a riga di comando.

----------
NUOVO ALG
----------

Il generate_using andrebbe spostato in branch analyser?

Anche intorno ai dispatch_m si deve rimettere le linee corrette?

Dire almeno che i metodi const e i ref non sono ancora gestiti.

deve riconoscere anche il namespace nelle classi derivate
class C : public std::list

Controllare perche' in

class T {};

class A
{
 public:
  branches m
    void (T *) {};
  endbranches
};

class B {
 public:
  branches m
    void (T *) {};
  endbranches
};

class C {
 public:
  branches m
    void (T *) {};
  endbranches
};

class AB : public A, public B {
 public:
  branches m
    void (T *) {};
  endbranches
};

class BC : public B, public C {
 public:
  branches m
    void (T *) {};
  endbranches
};

class AC : public A, public C {
 public:
  branches m
    void (T *) {};
  endbranches
};

class ABC : public AB, public BC, public AC {
 public:
  branches m
    void (T *) {};
  endbranches
};

viene aggiunto anche m_DB in ABC (mentre l'algoritmo non
lo aggiungerebbe).

nel caso di

branches m
  void ()
endbranches

da' segmentation fault!

--------------
FEATURES
--------------

gli altri parametri non devono essere puntantori.
Ad es. ostream.
visitando un header file capire quando un nome e' un typedef
e per quello generare un #include (ad es. per ostream).

riconoscere classi base della forma
: public std::map<ExpressionType, std::string>



check gnulib usage of include files

You may need to add #include directives for the following .h files.
  #include <getopt.h>
  #include <string.h>

You may need to use the following Makefile variables when linking.
Use them in <program>_LDADD when linking a program, or
in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.
  $(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise

Don't forget to
  - add "lib/Makefile" to AC_CONFIG_FILES in ./configure.ac,
  - mention "lib" in SUBDIRS in Makefile.am,
  - mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am,
  - mention m4/gnulib-cache.m4 in EXTRA_DIST in Makefile.am.
  - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC,
  - invoke gl_INIT in ./configure.ac.
