@@ -4,6 +4,37 @@ The new version of pls uses a more complicated/less user friendly
API in favor of performance and memory guarantees.
For the old version refer to the second half of this document.
# 18.03.2020 - Coding Standard/C++ Standard
We previously stuck to strict 'static' allocation in global static
storage or on the stack for most memory we need. However, we found
this to be very restrictive and making our code overly complicated
and not at all 'modern C++'.
After some research we found that this restrictive style is common
in very restrictive embedded domains. However, we target multi and many
core systems that run many applications on a shared operating system in
a more traditional 'PC-like' manner. The model best fitting this application
style is the adaptive autosar standard. It models the system as a posix
compliant os running specialized software for application deployment and management.
Under this stack there is usually a normal OS scheduler, like e.g. a
linux image tuned for low latencies. The target platform for such systems
are intel and arm processors with 2 to 16 cores, making it ideal for
our framework.
Following this logic, we decide to orient ourselfs at the
[C++ 14 guidlines of autosar](https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf).
Specificially, they encourage the use of dynamic memory allocation and
modern C++, as long as some restrictions are hold.
The memory usage of an app must be bounded and best practice is to
allocate resources 'outside of real-time sections, e.g. startup',
making it, again, a good fit for our concept. We do not plan
to follow all these rules, but we see them as an example for where
our research can be applied later on. As the autosar standard is
[moving towards C++ 17 and integrated into misra C++](https://www.autosar.org/news-events/details/misra-consortium-announce-integration-of-autosar-c-coding-guidelines-into-updated-industry-standar/)
we decide to go for C++ 17 in our project. These facts make develpoment
a lot more convenient and are enough to test our profe of concept prototype.
# 13.03.2020 - Coroutines and 'Nice API'
Before Christmas we finished the 'ugly' inline/object based API.
