Archived

This forum has been archived. Please start a new discussion on GitHub.

Implications of C++11 build mismatch?

alexj
alexj
in Help Center
Hi,

I am working with a v3.5.1 of Ice which we have cross compiled for ARM and have been using for several months.

I have recently observed an issue with checkedCast() [subject of another thread] whereby it seemed to block rather then returning an error or throwing as expected. I tried to step into checkedCast() and noticed that Proxy.h has conditional compilation for isA() depending on whether ICE_CPP11 is defined or not. Our application is built with C+11 enabled but Ice does not have it enabled. I found details on another thread about how to to do this and have since created a version but it raises some questions:

1. Is it important that Ice is built with C++11 support if the application is?
2. What would be the problems we would be likely to see if not? Compilation? Loader? Non-deterministic behaviour?
3. What would the behavior be if there was a port clash? All of our clients/servers are on the same machine and we allocate ports starting at 10000 which we have already seen clash with gdb.
4. I notice IceUtil/Config.h sets ICE_CPP11 if the GNU compiler is at an appropriate level and that the output of slice2cpp has conditional compilation that uses it. Surely this will define the ICE_CPP11 if the compiler is capable of C+11 rather than if the application is being built with C++11 enabled? Doesn't this allow the application to be built with ICE_CPP11 defined when Ice itself was not? Does that matter?
5. Do we also need to make sure Ice dependencies (mcpp. expat, db53) are compiled with C++11 support too?

I should add that building Ice with C+11 did not solve the checkedCast() problem and that we also have our application running under 'native' 64-bit Linux (compiled with C++11) but with Ice libraries (built natively from sources WITHOUT C++11) and this works fine.

Thanks for any help,

Alex.

Comments

  • benoit
    benoit Rennes, France
    Hi Alex,

    I recommend to recompile Ice with C++11 enabled if your program is going to be compiled with C++11. See this note from the GNU GCC web site for information on why this is the safest: https://gcc.gnu.org/wiki/Cxx11AbiCompatibility. The Ice API uses std::map for instance. For BerkeleyDB, I don't think you need to-recompile it. The C++ BerkeleyDB API doesn't seem to be using any of the types whose ABI changed.

    Note that GCC C++11 support in Ice 3.5.1 isn't fully supported, at the time of the 3.5.1 release, GCC support for C++11 was still experimental. For GCC, we don't only check the GCC version, we also check for the presence of the __GXX_EXPERIMENTAL_CXX0X__ macro which is only defined if you compile the code with -std=c++0x. So if you compile your code with a GCC version >= 4.5 and -std=c++0x, Ice C++11 features should be enabled.

    If you start 2 servers that are listening on the same port, the object adapter creation of the 2nd server will raise an Ice::SocketException indicating that there's already a server listening on the port.

    Cheers,
    Benoit.
  • alexj
    alexj
    Hi Benoit,

    Thanks again for your reply. I had missed the bit about __GXX_EXPERIMENTAL_CXX0X__ in Config.h so that makes perfect sense now but I still have some questions:

    1. I used your reponses to another thread (http://www.zeroc.com/forums/help-center/6220-build-sources-ubuntu-13-04-a.html) to determine how to build with C++11 enabled and followed your example and used -std=C++11 rather than -std+C++0x. I've checked that __GXX_EXPERIMENTAL_CXX0X__ (and therefore ICE_CPP11) is still defined and it is. Is that the only concern or might there be other reasons for using C++0x as opposed to C++11?
    2. If you use a binary distribuition of Ice (e.g. from a yum repo) you don't know if C+11 has been used to compile it so it possible your app and Ice will be mismatched in this respect. Have you ever had any reports of faults that could be contributed to this situation.

    Thanks,

    Alex.

Categories