Skip to content
New MINOR release 00.29.00

Changes since 00.28.00:

Important note: This release does significant changes to the internal structure. Although no changes to the public (non-experimental) API has been introduced, some corner use-cases could be affected. Please check your application/library carefully against this version before releasing it into production!

* Major bug fix for the TransferGroup and readAsync() logic. This commit involves slight behavioral changes of the TransferGroup (only corner cases with previously undefined/strange behaviour) as well as a change of the internal backend interface (only those backends not based on the NumericAddressedBackend).
  Notable changes are:

  - preRead(), postRead(), preWrite() and postWrite() are now protected against multiple calls. To achieve this, the function implemented by the backends has been renamed into doPostRead() etc.
  - TransferGroup logic was completely reworked. Copies are now properly done where necessary, so user buffers will never be shared after merging identical registers into the same TransferGroup.
  - TransferGroups are now set to read-only if copies will be made - in which case writing would result in undefined behaviour.

* Interface change in experimental feature: readAsync() no longer returns a reference to a TransferFuture. Instead the TransferFuture is now copyable and no longer polymorphic.

* Introduced a base class for decorators of NDRegisterAccessor - NDRegisterAccessorDecorator - and use it in various places

* Introduced a doReadTransferAsync() and doWriteTransfer() similar to the other doReadTransfer...() functions. This affects any implementations of NDRegisterAccessor (read documentation of the functions)!

* Split the TransferElement base class into TransferElement and TransferElementAbstractor, to properly seperate the two parts of the bridge coding pattern. Along side with this change goes a rename of NDRegisterAccessorBridge into NDRegisterAccessorAbstractor. Users should mostly not see this change, since they should only use concrete implementations of the classes, which were effectively not changed.

* Extended the tests

* Some improvements to the build environment and removal of warnings etc.