easier to make you own classes, and types defined in the standard
library work well with tclap. I'll try to write up some documenation
of how to achieve this as-well.
major problems. 1) There where static functions and variables that could cause
link errors if tclap where used in different files (e.g. file1.cc and file2.cc
included tclap then compiling both files would give hard symbols for some
variables which would produce multiple definition when linking) 2) The
dependencies of tclap was a bit strange (CmdLine depends on Args and Args
depends on CmdLine for instance)
The first problem I solved by removing all static variables putting them in
static member functions (which are weak-symbols). So for instance every where
there previously was something like x = _delimiter there now is x = delimiter()
or in case of write acces delimiterRef() = x instead of _delimiter = x (I had
to append the Ref because there where already functions with the same name as
the variables). To solve the problem with static functions I simply inlined
them. This causes the compiler to produce a weak symbol or inline if
appropriate. We can put the functions inside the class declaration later to
make the code look better. This worked fine in all but two cases. In the
ValueArg and MultiArg classes I had to do a "hack" to work around the
specialization template for extractValue<std::string>. The code for this is
very simple but it might look strange an stupid at first but it is only to
resolve the specialisation to a weak symbol. What I did was I put the
implementations of extractValue in a helper class and I could then create a
specialized class instead of function and everything worked out. I think now in
retrospect there might be better solutions to this but I'll think a bit more on
it (maybe some type of inlining on the specialized version would suffice but
I'm not sure).
To handle the dependencies I had to do some rewriting. The first step was to
introduce a new class CmdLineInterface that is a purely abstract base of
CmdLine that specifies the functions needed by Arg and friends. Thus Arg
classes now takes an CmdLineInterface object as input instead (however only
CmdLine can ever be instantiated of-course). With this extra class cleaning up
the dependencies was quite simple, I've attached a dependency graph to the mail
(depgraph.png). I also cleaned up the #includes so now only what actually needs
inclusion is included. A nice side effect of this is that the impl. of CmdLine
is now put back into CmdLine.h (where I guess you wanted it) which (recursivly)
includes everything else needed.
Just to make things clear for myself regarding the class dependencies I made a
class TCLAP::Exception that inherits from std::exception and is a base of
ArgException (Exception does nothing currently). If we don't want the Exception
class it can be removed, however I think it could be a nice logic to have a
base Exception class that every exception inherits from, but we can discuss
that when we decide how to handle exceptions.
