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;
  }

  Otherwise, for variables that are global to a module, initialization and termination must be done by defining a my_package_instance class, whose constructor is the initialization routine and whose destructor is the termination routine (see for instance basix_instance in basix/src/basix.cpp.)

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