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 
 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 
 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,

Technical Consultant, Professional Services
GridGain Systems

> On Apr 16, 2018, at 9:02 AM, Igor Sapego <isap...@apache.org> 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 <dma...@apache.org> 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 <isap...@apache.org> 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 <
>>> valentin.kuliche...@gmail.com> wrote:
>>>> Is there a ticket? Let's create one if not.
>>>> -Val
>>>> On Tue, Apr 10, 2018 at 6:17 AM, Vladimir Ozerov <voze...@gridgain.com
>>>> 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 <
>>>>> valentin.kuliche...@gmail.com> 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

Reply via email to