Namespaces and Interaction with other Libraries

If users want to use other software packages like ABACUS, CGAL, or STL together with LEDA in one project avoiding naming conflicts is an issue. As name spaces are not yet generally available LEDA offers a new prefixing mechanism to avoid name conflicts. The libraries from all object code packages as well as the ones produced from the source code package contain class name symbols with the common prefix leda_. A macroing package allows users to use unprefixed class names as used in the manual pages in chapters Simple Data Types to 14.

All unprefixed type names are transfered to prefixed ones at compile time by the macros provided automatically by the inclusion of any LEDA header file. There's two consequences to this.

• if you debug your code you'll always see prefixed symbols from within debuggers like gdb.

• if you use other libraries like STL in the same project you have to avoid LEDA's automatic prefixing being valid in the general program scope. You can disable automatic prefixing by compiling your program including the flag -DLEDA_PREFIX, e.g.

  CC -DLEDA_PREFIX prog.c -lP -lG -lL -lm

  But then of course you have to use explicitly prefixed class names in your code like:

    leda_list<int> L;
    L.append(3);
    leda_graph G; 
    ...
  

Remember that you have to prefix all LEDA class types yourself if you use -DLEDA_PREFIX.

The second issue of interaction concerns the data type bool which is part of the new C++ standard. However not all compilers currently support a bool type. LEDA offers bool either compiler provided or defined within LEDA if the compiler lacks the support. Some STL packages follow a similar scheme. To solve the existance conflict of two different bool type definitions we suggest to use LEDA's bool as STL is a pure template library only provided by header files and its defined bool type can be easily replaced.