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