Although the majority of the library has been written by me, I'm always open to contributions from other people.
There are always a number of features and enhancements that either I'd like to see, or have been suggested by other
users, but I only have a finite amount of time to give.
I accept contributions both big and small; If you have an idea for a funky non-standard container that you think would
complement the library, then let me know. If you just want to add an enhancement to an existing class, tell me about
This is a very friendly project and I'm not going to start shouting abuse at you if I see issues with your idea or code. If
there is a problem we can have a dialog about what I think should change. Feel free to argue your case.
I am the dictator of what goes in to the ETL, but I see myself as a very benevolent dictator. ;-)
There are a number of jobs outstanding at the time of writing that could usefully be taken up whole, or in part, by
1. Add C++03 compatible C++11 'emplace' functions to the rest of the ETL containers.
2. Add C++11 variadic 'emplace' functions to all containers, selected by a pre-processor switch for ETL_CPP11
3. Add a 'fast clear' option for all containers of types with trivial destructors.
I don't want to be any sort of style Nazi, but there are a few conditions that I ask you to try to adhere to.
1. The style of the public API of the class should mirror that of the STL.
Lower case class and function names, separated by an underscore.
2. Use the same naming convention as the STL.
If appropriate for the class, a set of typedefs should often be present to define types such as...
If a function does something similar to that in a standard class in the STL then use the same terminology.
3. All ETL classes are to be within the etl namespace.
4. All classes private to the ETL shoud reside in a nested namespace prefixed with __private_
5. Use descriptive names for internal variables and functions.
6. Use comments to summarise or explain blocks of code that may be difficult to quickly understand.
7. Never use int8_t or uint8_t. Some processors such as DSPs do not support 8 bit values. Use int_least_8_t and
uint_least8_t in their place.
8. Never assume the bit length of a type. If the bit length is important then either use a type from stdint.h or
interrogate the type for its size.
9. In a similar vein to 7, Never assume the minimum or maximum values for a type. Use type traits to look them up.
10. Where ever possible, add static asserts to catch errors at compile time, rather than runtime.
11. Use the ETL macros to report runtime errors. This will ensure that the correct code is generated for the user
selected error reporting method.
ETL errors are packaged in exception structures. Do not get confused with this terminology, it does not mean that it
will always be thrown as an exception. It may just be passed as a parameter to an error handler.
class stack_exception : public exception
stack_exception(string_type reason_, string_type file_name_, numeric_type line_number_)
: exception(reason_, file_name_, line_number_)
class stack_full : public stack_exception
stack_full(string_type file_name_, numeric_type line_number_)
: stack_exception(ETL_ERROR_TEXT("stack:full", ETL_FILE"A"), file_name_, line_number_)
12. Define ETL_FILE in your class header file.
#define ETL_FILE "33"
// Define your class here
The list of file numbers may be found in file_error_numbers.txt
Every class or function that is in the library should be unit tested. Do not submit your code unless you have a full set
of tests that exercise as much of the functionality as you can possibly think of. Make sure that you cover all of the
corner cases. There is not such thing as too many tests. There are such things as useless tests. Don't test the
completely trivial though if it's fully exercised in more complex tests later.