The class declarations of the LEDA data types are contained in header files. To be able to use a certain data type, we must include the appropriate header file. In general, the header file belonging to the LEDA type X is called X.h, though there are exceptions to this rule.^[2] If the LEDA type X is to be used, it must be prefixed with the directory name LEDA/ in the include statement.

	Note
	This prefix has become more complicated as of LEDA 5.0. If you use LEDA version 5.0 or higher, and want to compile and run the programs of this tutorial, please read Section “Structure of include directories as of LEDA 5.0” below. This tutorial is based on the old include structure.

In every case, the manual page belonging to a data type gives information about the header file to be included: The “Definition” section the manual page quotes the exact include statement that has to be used.

According to the conventions for LEDA versions prior to 5.0, we include the file string.h here as follows:

#include<LEDA/string.h>

LEDA defines all identifiers of types, functions, constants, etc., in the namespace leda.^[3] Thereby LEDA data types can be used together with types from other libraries like ABACUS, CGAL, and primarily the C++ standard library (and the former STL now merged into the latter one).

There are three possibilities of using identifiers from the namespace leda for application programs:

Another possibility is therefore the following one:

#include <LEDA/string.h>
#include <iostream>

using leda::string;
using std::cout;

int main() 
{
  string msg = "Hello LEDA world!";

  cout << msg << "\n";
}

Which of these possibilities we should choose differs from program to program. The use of using directives is generally regarded as bad style because the programmer loses the overview on which identifiers he makes available (in the case of a using namespace leda these are quite a lot) and because the danger of name collisions is increased thereby. using directives make sense primarily when old LEDA programs in which identifiers are not yet specified qualified shall be linked against LEDA versions with a release number as of 4.4.

In the following, we will usually make clear explicitly by using declarations at the beginning of a program which identifiers we make available. In doing so we also highlight with which identifiers of LEDA we mainly deal in the section in question. We usually use identifiers from other namespaces, such as std::cout, fully qualified unless they occur very frequently in the program text so that a using declaration saves paperwork.

Warning

Both of the C++ standard library and LEDA contain a class string. A mistake that is made particularly often when adapting old code that does not yet use namespaces to new code that is working with namespaces is the following: Two using directives lead to an ambiguity (name collision) of the identifier string, such as in the following code fragment: using namespace leda; using namespace std; //... string msg; // ambiguous: std::string or leda::string? Since we use identifiers from the standard library only occasionally in the following programs, we will almost always specify them fully qualified or make them available by a using declaration.

The rest of the program should be self-explanatory. A LEDA string can be initialized with a constant C++ string literal and written to standard output by means of the operator <<.

There you are! This was already almost the most important thing to say about LEDA. Now we must only make it run and look at the other data types thereafter.

During the last years, LEDA's main include directory grew to more than 400 include files. As a result, the include directory has become very complex. To tidy LEDA's include structure, modules were introduced in LEDA 5.0.

Starting from version 5.0, LEDA partitions its types into several modules. The most important module is the core module. It contains all simple data types and simple container types, all associative container types, all priority queues, and basic algorithms such as sorting algorithms.

Each type belongs to exactly one module. For example, the type string belongs to the module core. To use a LEDA type X contained in module M, it has to be prefixed with LEDA/M/ in the include statement. So to use the type string, the include statement must read

#include <LEDA/core/string.h>

The following program is a LEDA 5.0 version of Hello world!.

#include <LEDA/core/string.h>
#include <iostream>

using namespace std;

int main() 
{
  leda::string msg = "Hello core module!";

  cout << msg << endl;
}

Users of LEDA version 5.0 or higher can still use the old include structure (and thus the old include statements) by additionally specifying $LEDAROOT/incl_old in the compiler's include search path. (More about LEDAROOT and compiling will follow in Section 1.3.)

Details about LEDA's modules and the structure of include directories can be found on the corresponding manual page about modules.