The following conventions are used throughout the C++ source code:

• Put all your code inside the mmx namespace. New namespaces can be nested inside the mmx namespace. Only exception: the principal glue definition routine define_name for a package name should be put unmangled in the global namespace.

• Use the following naming and case conventions:

  • Lowercase for types (string, vector, etc.).
  • Short names with first letter in uppercase for template arguments (C, V, Op, etc.).
  • Short lowercase names for variables. When possible, use the first letter of the type when possible, i.e. string s, int i1, etc.
  • Fully uppercase names for macros (INDIRECT_PROTO, ARITH_INT_SUGAR, etc.).
  • Exception to the above rule when the macro is an abbreviation for a type or a value, in which case only the first letter uses uppercase (Vector, Matrix, Pi, etc.).
• Don't use STL, but rather build upon the common datatypes provided by basix (i.e. string, array, list, table, function, iterator, symbol, pair, triple). Also notice that nat stands for unsigned int.

• When defining a data type my_type which is really a pointer to the representation class my_type_rep, use the standard mechanism for defining reference counted pointer classes. In the case of a simple class my_type, this is done using the following kind of code:

  In the case of template classes, one should use similar macros INDIRECT_PROTO_1, etc.

• To increase conciseness, we systematically abbreviate template definitions and template type names when defining new template classes. For instance, the code of the list<C> class is enclosed in a block of the form:

• Please let every file start and finish by one blank line. Please don't indent code inside namespace directives which span over a whole file.

There are probably more convention; please follow the style of existing code when writing new packages.

1.Important recommendations

• Static variables. The use of static variables in C++ can lead to weird effects within memory initialization and destruction. Their use is thus depreciated. For a local usage nesting a static variable inside a function that returns a read/write reference to the variable is often a good solution, for instance:

2.Debugging

In case you run into a “segmentation fault” within the mmx-light shell, you can use gdb as follows, assuming that you are in development mode:

In this way you will find the location of the crash inside the C++ source code. In order to obtain more information you must recompile the package involved with the –enable-debug option:

An other convient way to launch the debugger just after an mmx-light session has crashed is as follows: