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:

  class string { INDIRECT_PROTO (string, string_rep) … }; INDIRECT_IMPL (string, string_rep)

  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:

  namespace mmx { #define TMPL_DEF template<typename C> #define TMPL template<typename C> #define List list<C> #define List_rep list_rep<C> … #undef TMPL_DEF #undef TMPL #undef List #undef List_rep } // namespace mmx

• 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:

  inline C& my_static_variable () { static C x = …; return x; }

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:

gdb mmxlight/build/.libs/mmx-light
[Enter the script]
[Crash information]
bt

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:

./configure … --enable-debug

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

gdb mmxlight/build/.libs/mmx-light
run --replay
[Crash information]
bt