[keyple-dev] Keyple C++ Headers

[Charles HUET <charles.huet@xxxxxxxxxxxxxxxx>]

Hi,

I just found out there are multiple headers with the exact same name in the Keyple C++ hierarchy.

Setting aside the difficulties this can cause for code reading when multiple classes have the same name, this causes a specific issue in C++ given the way the projects are structured.

For instance, the line #include "CardIOException.h"​ can refer to two completely different files, and which one is included depends on the order in which the includes are passed to the compiler.

In modern CMake this means the order in which the targets are passed to the target_link_libraries​ instruction.

This means that if my previous proposal of using dependencies transitively is accepted, specifying which CardIOException.h we want to include becomes much more difficult.

While in Java this is solved by using an import with the full package name, in C++ this is usually solved by having headers in folders whose name reflects the library, and using these in the #include​ directive, e.g. #include <keyple-plugin-cpp-api/CardIOException.h>​ or #include <calypsonet-terminal-calypso-cpp-api/CardIOException.h>​

This requires a reorganisation of the source files to avoid having a very verbose include like #include <keyple-plugin-cpp-api/src/main/CardIOException.h>




Should I reorganize the files this way along with the CMake targets refactor ?




Thanks


Charles HUET

Architecte, Design Authority

RATP SMART SYSTEMS

8, Avenue Ariane

33700 Mérignac

 ratpsmartsystems.com

ratpgroup.com

 

Si vous n'êtes pas destinataires de ce message, merci d'avertir l'expéditeur de l'erreur de distribution et de le détruire immédiatement. Ce message contient des informations confidentielles ou appartenant à RATP Smart Systems. Il est établi a l'intention exclusive de ses destinataires. Toute divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce message ou des informations qu'il contient, doit être préalablement autorisée par RATP Smart Systems. Tout message électronique est susceptible d'altération et son intégrité ne peut être assurée. RATP Smart Systems décline toute responsabilité au titre de ce message s'il a été modifié ou falsifié.