> <\body> The following conventions are used throughout the C++ source code: <\itemize> Put all your code inside the namespace. New namespaces can be nested inside the namespace. Only exception: the principal glue definition routine >> for a package >> should be put in the global namespace. Use the following naming and case conventions: <\itemize> Lowercase for types (, , etc.). Short names with first letter in uppercase for template arguments (, , , etc.). Short lowercase names for variables. When possible, use the first letter of the type when possible, , , etc. Fully uppercase names for macros (, , 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 (, , , etc.). Don't use , but rather build upon the common datatypes provided by ( , , , , , , , , ). Also notice that stands for . When defining a data type which is really a pointer to the representation class , use the standard mechanism for defining reference counted pointer classes. In the case of a simple class , this is done using the following kind of code: <\cpp-code> class string { \ \ INDIRECT_PROTO (string, string_rep) \ \ ... }; INDIRECT_IMPL (string, string_rep) In the case of template classes, one should use similar macros , etc. To increase conciseness, we systematically abbreviate template definitions and template type names when defining new template classes. For instance, the code of the C\> class is enclosed in a block of the form: <\cpp-code> 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. <\itemize-dot> 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: <\cpp-code> inline C& my_static_variable () { \ \ static C x = ...; \ \ return x; } In case you run into a ``segmentation fault'' within the shell, you can use as follows, assuming that you are in development mode: <\shell-code> 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 source code. In order to obtain more information you must recompile the package involved with the option: <\shell-code> ./configure ... --enable-debug An other convient way to launch the debugger just after an session has crashed is as follows: <\shell-code> gdb mmxlight/build/.libs/mmx-light run --replay [Crash information] bt . If you don't have this file, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.> <\initial> <\collection>