Common Adapter Documentation/HecksNotepad
This is just a personal notepad of heck.
This is just a collection of drafts to be exported into well structured documentation.
Adapter standardization
libpEpAdapter
The idea is to have a C++ layer on top of the engine, to be used by adapters written in C++. The current idea is to use and extend libpEpAdapter for that matter.
Move all possible redundancies (common code) across adapters in to libpEpAdapter.
Everything that makes sense should be Code generated (e.g types, see engine branch gen_samples)
Portable C++
Adapter will use different C++ versions. The C++ version must be part of the build def of an adapter. The whole software stack has to be built using the native default system toolchain of the target env.
Therefore, libraries and code which is used on different target environemts, must guarantee identical behaviour, even when compiled using different C/C++ standard and compilers. So, for libpEpAdapter, the core problem is to define C++ coding standards and patterns that are portable across several different standards of C++.
Default C++ Standard
Today, we’ve at least C++ 11 on all platforms (z/OS has it). So versions before are not needed any more. When Windows has to be supported then CL.EXE sets the limit. When many different platforms have to be supported then there MAY be platforms with older compilers only.
Hence we’re basing on C++ 14 today for most projects.
Default system toolchain
The system default toolchain means, that we use only natively supported tools to build our projects. But we may have explicit version depencies (e.g. for a compiler) but it must be a natively supported version/implementation.
Portable C++
Identified portability problems:
- Temporary object lifetime
- Static init order (and resulting problems in concurrency)
- POD-types (Plain-Old-Data)
Findings:
- auto_ptr are bad - shared_ptr are good
- copy semantics are good
p≡p Engine
Here is a collection of notes about “The Engine” from the perspective of an Adapter dev. (heck)
Crytotech concept
The Engine has a variable backend concept using the driver pattern. Is implemented using dynamic binding. dynamic binding -> switching of drivers (backends) at runtime
dynamic linking -> no switching at runtime possible
String encoding
IN: UTF-8 NFC normalized
OUT: UTF-8
No unicode in engine
Memory management
you cant be guaranteed to just deallocate memory on a pointer using delete/free(), therefore:
pEp_free() is guaranteed to work always.
CodeGen
Here is a collection of notes about code generation from the perspective of an Adapter dev. (heck)
Version Control
Version control on DSL input files.
No version control on generated files.
Projects/Branches relevant for Code Gen
Engine Branches:
- generate_api - nana neue DSL
- gen_sample - sample for generating list types in C99 (linked list)
- The same can be done for list types in C++
- inspiration for codegen for C++ engine layer (libpEpAdapter)
- z.B. c++ liste als iterable im C++ libpEpAdapter