Hi Guys, Having (very unfortunately) done a boatload of C++ programming while I was at university, there are some issues to consider here. One of the biggest is compiler name mangling <https://en.wikipedia.org/wiki/Name_mangling#Real-world_effects_of_C++_name_mangling>. Now, I’m guessing you’ve heard about this, but it’s a lot nastier than people think it is. For example, you can’t link an object built with GCC on Linux to one built with LLVM on Linux (though this may be changing with the introduction of a “standard” Linux ABI and name mangling scheme, c.f. this Oracle TechNet article <http://www.oracle.com/technetwork/articles/servers-storage-dev/stablecplusplusabi-333927.html>). Essentially, C++ object code built with different compilers—or even different versions of the same compiler—have totally different name mangling schemes and ABIs. So we’d need to pick one and stick with it. The Wikipedia article linked-to above explains this problem better than I can.
So we’d have to standardize on one compiler ABI, then build the native code portions of our C++-to-JVM bridge with that compiler, such that object code loaded from the client side during a compute invocation could be dynamically linked to our native code interface on the server side, since code built with different name mangling schemes and different ABIs can’t be linked together. The most obvious choice is the GCC/Linux ABI, since most of our users deploy on Linux and GCC comes as the standard compiler suite on most distros. What’s more, IIRC, it’s possible to force Visual Studio on Windows and LLVM on the Mac to output GCC Linux ABI-compliant code. This way, we’d give our users the capability to run unit tests in CppUnit, etc. on their development laptops and then have that same compiled object be able to work seamlessly when our server side code loads it and links it into the server C++ runtime. Hope that all makes sense. I’m happy to contribute to this effort. Take care, Lucas -- Lucas BEELER Technical Consultant, Professional Services GridGain Systems www.gridgain.com > On Apr 16, 2018, at 9:02 AM, Igor Sapego <[email protected]> wrote: > > It depends on which functionality is needed, as there are > several versions of those methods. Some would require > implementing of Cluster API, which is not present in C++ also. > > Best Regards, > Igor > > On Mon, Apr 16, 2018 at 6:41 PM, Denis Magda <[email protected]> wrote: > >> Do we target it for 2.6 release? It shouldn't be time-consuming to support >> it, right? >> >> -- >> Denis >> >> On Mon, Apr 16, 2018 at 2:48 AM, Igor Sapego <[email protected]> wrote: >> >>> Guys, >>> >>> I've created a ticket: [1] >>> >>> [1] - https://issues.apache.org/jira/browse/IGNITE-8273 >>> >>> Best Regards, >>> Igor >>> >>> On Wed, Apr 11, 2018 at 2:44 AM, Valentin Kulichenko < >>> [email protected]> wrote: >>> >>>> Is there a ticket? Let's create one if not. >>>> >>>> -Val >>>> >>>> On Tue, Apr 10, 2018 at 6:17 AM, Vladimir Ozerov <[email protected] >>> >>>> wrote: >>>> >>>>> Val, >>>>> >>>>> They are simply not implemented yet. I am not aware of concrete plans >>> to >>>>> support them. >>>>> >>>>> On Mon, Apr 9, 2018 at 11:33 PM, Valentin Kulichenko < >>>>> [email protected]> wrote: >>>>> >>>>>> Guys, >>>>>> >>>>>> Is there a way to run collocated compute job in C++? I can't find >>>>>> affinityRun and affinityCall method in C++ compute API, am I >> missing >>>>>> something? If we really don't have them, is there any particular >>> reason >>>>> for >>>>>> this and/or plans to add them? >>>>>> >>>>>> -Val >>>>>> >>>>> >>>> >>> >>
