ABI compatibility and separation of public interface and private implementation details on the API

[izonfreak]

Hello,

I am trying to compile the AdsLib as a shared library on windows and having a hard time dealing with this. There are some things that are missing like the export/import decorators but that is not really the reason why i made this ticket.

To maintain API and ABI compatibility implementation details should be hidden from the public API definition. Exposing internal data structures, class layouts, or implementation-specific types increases dependency between a specific version of AdsLib and the consumer application. This makes it so that any changes made to AdsLib are very likely to break existing code specially if you are compiling AdsLib as a shared library (in any platform).

My suggesting would be to only expose a stable public interfaces by using opaque types and/or the PIMPL pattern (whenever possible) and keeping implementation details private. This way the internals of AdsLib can change and be refactored without affecting users of the API and keeping both source compatibility and in the case of shared library keeping binary compatibility and avoid the need to recompile the application to get a bug fix.

I can help with these changes and we can try to keep as much of the source compatibility with the current interfaces as possible, but I cant guarantee that everything will just "stay the same" since this update will require multiple changes and multiple reviews. Long-term wise I think this will be better than the current approach.

[pbruenn]

If you need an opaque interface just go with the C API .
There is a reason why we never provided a shared library, because it's so ugly and hard to use for C++ applications.
You have the source, integrate it into your app. Ship updates with updates of your app. Simple!

In all the time I found only a single usecase valid to build AdsLib as a shared library: pyads. They need to decided at runtime if they have to link against the standalone version or the TwinCAT version. Yes, that's a valid usecase but as TwinCAT only provides the C API, all they can use is the C API. They can't make use of the convenient wrappers we build here.

So thanks again for making it easy for users like pyads to build a shared library version of AdsLib. But no I will not take patches to implement a COM interface.

[izonfreak]

The thing is that i want to do the same thing pyads is doing. I do not want a COM interface. I want my application to select whether to load the Standalone or TwinCAT version at runtime. However, unlike the pyads that requires that TcADSDll is always available if you want to use it on windows, I want to also be able to select standalone if TcADSDll is not available. Requiring the user to always installing TwinCAT runtime on the target PC just to have TcADSDll is something that I will like to avoid.
I suppose that for pyads is the same issue on linux as they always try to use the Standalone version on Linux regardless of whether TcADSDll is available on the system. If I remember correctly it is not recommended to use the Standalone version of TcADSDll is available.

Maybe the better way is to meet haft way and enable building a "standalone TcAdsDll" shared library using the functions that you have define. After all they are the same API anyways as you have duplicated the interface. What do you think of that idea?