Get rid of boost dependency

The title says it all … don't use boost.

Meanwhile the C++ standard support most of the stuff we currently use from boost, so lets switch to that.

added priority::medium silecs-communication-cpp labels

mentioned in merge request !27 (merged)

I checked the code and it seems boost is used for some pointers (which we can replace with std), the other use is the boost filesystem which is only available from C++17 on in std. Also should we add the 2.5.0 milestone to these new issues?

the other use is the boost filesystem which is only available from C++17 on in std

On the asl we have gcc 11.3, which should have full C++17 support, so should be fine (While we actually don't need to be OS-agnostic here at all :D)

For yocto it as well seems to be fine. The following gcc seems to be used:

[schwinn@asl754 bin]$ pwd
/common/usr/embedded/yocto/sdk/sysroots/core2-64-ffos-linux/bin
[schwinn@asl754 bin]$ x86_64-ffos-linux-gcc --version
x86_64-ffos-linux-gcc (GCC) 12.2.0
...

Also should we add the 2.5.0 milestone to these new issues?

If you could as well take care of this issue, that would be great! In case we can extend your work package accordingly (ping @a.debenjak). Probably would make sense before going for the cmake port.

So... snap7 library typdefs an unit8 to btye which causes a collision with std::byte in C++17. This could probably be solved by wrapping the snap7.h include in a specific Snap7 namespace, which does compile. However this would need to be tested to make sure that everything is really ok. Do you use any PLC available for testing?

One other note which is very important. With the transition to C++17 we must be careful since FESA relies on the cpp-communication library, while internally FESA still uses auto_ptr which was removed in C++17, so the communication library must not have any C++17 features in it's interface to make sure that the FESA classes could still be compiled with C++11. (auto_ptr just being one example it's possible there are other such cases)

One other option is only get rid of boost from the diagnostic and cli-client and for now leave it in the communication part. Which is a partial solution but gets us in the right direction.

Do you use any PLC available for testing?

There is tsts7001 (more info here https://www-acc.gsi.de/wiki/Frontend/FEC_PLC), though currently I don't have a WinPC available to install TIA. If you can access it via some tunnel, you could use it.

One other note which is very important. With the transition to C++17 we must be careful since FESA relies on the cpp-communication library, while internally FESA still uses auto_ptr which was removed in C++17, so the communication library must not have any C++17 features in it's interface to make sure that the FESA classes could still be compiled with C++11. (auto_ptr just being one example it's possible there are other such cases)

Uh, a good point .. I did not think in that direction. I think we don't really need boost::filesystem. The only method which uses it, is getBinaryFolderPath, which just returns the path where the binary is located. Can be done without boost, e.g. like this.

So I suppose like this we could completely get rid of boost, and only use C++11 features (if I am not mistaken?)

(So let's postpone that C++17 port with its collision with std::byte for a different day ... would be great to have a separate issue for it)

Yes I agree. I think this is the safest way to do it currently.

I created a separate issue #85 (moved)

Thanks ! Added some more info to the issue.

changed milestone to %2.5.0

changed title from Get rif of boost dependency to Get rid of boost dependency

mentioned in issue #85 (moved)

mentioned in merge request !32 (merged)

closed with commit 18d0b898

mentioned in commit 18d0b898