Hello,

I've been looking at Ignite C++, and in particular the C++ Thin Client, and 
while the code seems pretty ready for C++20 (or more recent), it still has 
pre-C++11 idioms/classes that makes it awkward to use when compiled with more 
recent compilers. (Please see P.S. for the details.)

Thus, my questions:

1 - Is the C++ thin client still actively maintained?

2 - Is there any plan to upgrade the C++ thin client and its dependencies to at 
least C++11? (e.g. replacing std::auto_ptr with std::unique_ptr, and 
SharedPointer with std::shared_ptr)

3 - If Pull Requests are provided to update the C++ code so it is more 
modern-friendly (i.e. compile with modern compilers without problems), under 
which conditions/constraints these PRs will be accepted? (e.g. the project must 
still successfully compile in C++98, source backward compatibility, etc.)

4 - Is there someone to be contacted beforehand to iron out the details?

Thanks,

-- Raoul B.

P.S.: For example, the usage of std::auto_ptr<T>, which is deprecated in C++11, 
and removed from the standard in C++17:
https://github.com/apache/ignite/blob/master/modules/platforms/cpp/binary/include/ignite/impl/binary/binary_type_impl.h#L154

There is also a massive usage of a std::shared_ptr-like class SharedPointer:
https://github.com/apache/ignite/blob/master/modules/platforms/cpp/common/include/ignite/common/concurrent.h#L135

The weird part is that the CMakeLists.txt sets, hardcoded inside, the C++ 
standard version as C++98, but it resolves as C++14 instead, in recent 
compilers like VS2022:
https://github.com/apache/ignite/blob/master/modules/platforms/cpp/CMakeLists.txt#L21
*******************************
This e-mail contains information for the intended recipient only. It may 
contain proprietary material or confidential information. Its content and any 
attachment hereto are strictly confidential and must not be disclosed to any 
unauthorized third party. If you are not the intended recipient, please delete 
this email and any attachment and notify us immediately. Murex cannot guarantee 
that it is virus free and accepts no responsibility for any loss or damage 
arising from its use. If you have received this e-mail in error please notify 
immediately the sender and delete the original email received, any attachments 
and all copies from your system.

Reply via email to