Eco Lab coding style

There is no particular Eco Lab coding style in terms of things like choice of identifier capitalisation, indentation, use of whitespace, naming schemes and the like. Non-syntactical information is always misleading, and I can well advise studying the output of doxygen to work what a particular identifier actually is. For singleton classes, I have a habit of following the Java convention of capitalising the class name, and using a lower case for the object. Similarly, for namespaces, I append a _ns.

Within header files, I tend to write more compactly, for instance placing an opening brace on the previous line, or putting several simple statements together on one line. In implementation files I tend to space things out a bit more. Obviously, the idea is to only place members with a few lines of definition in the interface file, otherwise migrate the definition to an implementation file.

More important is information that the compiler can use to enforce correctness and performance. The concept of const-correctness is very important in determining flows of data dependencies, similarly exception correctness is important for determining code flow. Use references instead of pointers whereever possible.

Of crucial importance is a concept known as “Resource Acquisition Is Initialisation”. If you need to access some resource such as memory, process or file, put the resource acquisition into the constructor of some object, and the corresponding resource release as the destructor. This has numerous benefits, ranging from eliminating resource leaks to ensuring exeception-correctness.

Much C++ code is written in a style I would call C/Java style. Objects are allocated on the heap using new, and users of class libraries must ensure that the corresponding delete is called to correctly clean up the opbject when it is destroyed. This style of programming leads to a whole host of subtle problems that RAII avoids.

Eco Lab code tends to assume that objects are default constructible, copiable, assignable and serialisable (DCAS). These concepts are heirarchical -- a class composed of members satisfying these criteria, also satisfies these criteria (or at least can be arranged to saisfy it through automated technques such as Classdesc). Unless absolutely necessary, try to ensure classes introduced in your Eco Lab model satisfy DCAS. Pointers are not DCAS, so if you need to use a pointer (eg to use a library having objects pointed to), then consider wrapping the pointer in an RAII style. Eco Lab provides the ref class, which is a DCAS type allowing shared references. ref is not suitable for polymorphic data, however Eco Lab provides poly{} type for handling polymorphic objects, that is DCAS. The Boost classes shared_ptr and intrusive_ptr (which are part of the TR1 standard addition to C++) are DCA, but unfortunately are not serialisable per se. Depending on your need, you may be better off using the Eco Lab ref and poly data types instead of the boost routines.