By removing `etl/` from include paths (in `#include` statements), the path to the directory `include/` doesn't need to be provided to the preprocessor as an include path if the files in `include/etl/` are included by other means.
This has no disadvantages.
Actually the form `#include "..."` is intended to be used for relative paths in the first place.
This is relevant if one wants to include the source files from `include/etl` only indirectly.
For example we use special generated header files which wrap the include statement of the vanilla header files with diagnostic commands.
Those commands allow to disable diagnostic for ETL's files and re-enable them after the file inclusion.
Wrapper files are generated for every non-private header file.
We provide the directory with the wrapper files as include path to the preprocessor instead of the normal `include/` directory.
Thus include statements like `#include "etl/private/..."` are invalid in that case.
The const variables "left" and "right" are const default initialized.
The C++ standard states the following:
"A class type T is const-default-constructible if default-initialization
of T would invoke a user-provided constructor of T."
Since the "left_soec" and "right_spec" structs are PODs they are not
initialized per default. Due to the "constness" the variable can not be
modified later one, therefore the POD is in a state in which it is not
useful at all.
Since the mentioned structs are empty there would be no problem
in this case. This is an issue in the C++ standard (CWG Issue 253).
Some compilers already handle this issue with their own solution
despite the fact, that the standard did not provide a solution yet.
For some exotic compilers (e.g. Tasking for TriCore) the include of
the "string_stream" header caused compilation errors:
"const variable "etl::left" requires an initializer -- class "etl::private_basic_format_spec::left_spec" has no user-provided default constructor"
References:
https://en.cppreference.com/w/cpp/language/default_initializationhttps://cplusplus.github.io/CWG/issues/253.htmlhttps://stackoverflow.com/questions/7411515/why-does-c-require-a-user-provided-default-constructor-to-default-construct-ahttps://stackoverflow.com/questions/24943665/why-is-a-constructor-necessary-in-a-const-member-struct
* #850 Fixed names according to Arduino's guidelines
* #850 Fixed names according to Arduino's guidelines
* Add support for in-place instantiation of a shared message in the message pool
---------
Co-authored-by: John Wellbelove <john.wellbelove@etlcpp.com>
Co-authored-by: John Wellbelove <jwellbelove@users.noreply.github.com>
Utilized a spell checking tool to identify and correct spelling
throughout all files in the code base.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
* In subspan function, add static checks on extents
* Change to ETL_STATIC_ASSERT. Add static assert for first and last functions
* Add static assert to pre c++11 subspan
* Change extent to Extent to better match existing code
