Maintaining the ETL can take a lot of man-hours of work, but unfortunately it doesn't pay the bills. When I have to take on paying work, the ETL gets a lot less attention. So if you have found the library is an important component in your work and you would like to help out, then please consider by sponsoring the project through GitHub.
Many thanks.
John.

Any help porting the library to work under different platforms and compilers would be gratefully received.
I am especially interested in people who are using Keil, IAR, Green Hills, TI Code Composer etc, bare metal
or RTOS, and DSPs.

Motivation

C++ is a great language to use for embedded applications and templates are a powerful aspect of it. The standard library can offer a great deal of well tested functionality, but there are some parts that do not fit well with deterministic behaviour and limited resource requirements. These limitations usually preclude the use of dynamically allocated memory which means that the STL containers are unusable.

What is needed is a template library where the user can declare the size, or maximum size of any object upfront. As most embedded compilers do not currently support the standard beyond C++ 03, it would also be nice to have access to some of the features introduced in the later library.

Summary

The ETL is not designed to completely replace the STL, but to complement it. Its design objective covers the following areas.

• Create a set of containers where the size or maximum size is determined at compile-time.
• These containers should be largely equivalent to those supplied in the STL, with a compatible API.
• Be compatible with C++98 but implement as many of the later C++11/14/17 additions as possible.
• Have deterministic behaviour.
• Add other useful components that are not present in the standard library.
• The embedded template library has been designed for lower resource embedded applications. It defines a
   set of containers, algorithms, and utilities, some of which emulate parts of the STL. There is no dynamic memory
   allocation.
• The library makes no use of the heap. All the containers (apart from intrusive types) have a fixed capacity
   allowing all memory allocation to be determined at compile-time. The library is intended for any compiler that
   supports C++03 or greater.

Help on integrating the ETL with your project may be found here.

Main features

• MIT licence
• No reliance on the STL (see here)
• No dynamic memory allocation. All storage is declared either at compile time or on the stack.
• No RTTI required
• Very little use of virtual functions. They are used only when they are absolutely necessary for the required
functionality.
• All header. No cpp files to compile.
• A set of fixed capacity containers that mirror those supplied in the STL, plus a few non-standard extensions.
• As the storage for the container types is allocated as a contiguous block, they are extremely cache friendly.
• Reduced container code size through use of base classes dependant on type only.
• Templated compile time constants.
• Templated design pattern base classes (Visitor, Observer).
• Frameworks for message routing, finite state machines and task scheduling.
• Reverse engineered C++ 0x11 features (type traits, algorithms, containers etc.)
• Type-safe smart enumerations.
• Type-safe typedefs + constants.
• 8, 16, 32 & 64 bit CRC calculations.
• Checksums & hash functions.
• Variants (a type-safe union).
• Choice of asserts, exceptions, error handler or no checks on errors (see here).
• Many utilities for template support.
• Unit tested (currently over 6480 tests), using VS2019, GCC 8.1.0, , GCC 9.3.0, Clang 9.0.0 & 10.0.0
• Easy to read and documented source.
• Free email support.
• Continuous integration testing on GitHub, Appveyor and CircleCI using VS2019, GCC and Clang.
• A copy of the ETL is stored in the Artic Code Vault.

7 Sponsors : 2% of target sponsorship.
Why sponsor the ETL?

Arctic Code Vault