Archived

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

VS2012 C++11 Compiler Error on ICE 3.5b with auto-generated code

Hi all,

I am trying to upgrade my compiler and my existing project, but I keep encountering this:
1>C:\Program Files (x86)\ZeroC\Ice-3.5b\include\Ice/Proxy.h(867): error C2664: 'IceInternal::Cpp11FnOnewayCallbackNC::Cpp11FnOnewayCallbackNC(const std::function<_Fty> &,const std::function<void (const Ice::Exception &)> &,const std::function<void (bool)> &)' : cannot convert parameter 1 from 'nullptr' to 'const std::function<_Fty> &'
1>          with
1>          [
1>              _Fty=void (void)
1>          ]
1>          nullptr can only be converted to pointer or handle types

And the code that is generating it is here:
#ifdef ICE_CPP11
    ::Ice::AsyncResultPtr begin_ice_flushBatchRequests(
                                    const ::IceInternal::Function<void (const ::Ice::Exception&)>& exception, 
                                    const ::IceInternal::Function<void (bool)>& sent = ::IceInternal::Function<void (bool)>())
    {
        return begin_ice_flushBatchRequestsInternal(new ::IceInternal::Cpp11FnOnewayCallbackNC(nullptr, exception, sent), 0);
    }
#endif

Any suggestions?

I tried Googling and was unsuccessful; apologize for poor Google-fu if I missed something obvious.

Comments

  • I think this is a minor "bug"[1] in ICE.

    ZeroC ICE used to compile in C++/CLI and work perfectly. Now that C++11 is around and has introduced nullptr, what's happening is that the ZeroC #ifdef ICE_CPP11 blocks are not checking whether the code is managed (/clr) or not. Thus, what's happening is that the compiler is opting for the C++/CLI nullptr and not '__nullptr'[2], which is supposed to be the native language version in use.

    Since your product has never had any issues in .NET with C++/CLI, I'd prefer to have it this way as a user :-). In the mean time, I can add the necessary preprocessor defines to make it work. I can see other clients running into this issue and remaining somewhat puzzled about what to do on the new compiler.

    [1] I use the term loosely, because the product is still fine in the native non CLR version.
    [2] See discussion here: http://stackoverflow.com/questions/7978006/nullptr-vs-nullptr
  • I corrected the issue with this hack and the problem went away:

    #ifdef ICE_CPP11
    ::Ice::AsyncResultPtr begin_ice_flushBatchRequests(
    const ::IceInternal::Function<void (const ::Ice::Exception&)>& exception,
    const ::IceInternal::Function<void (bool)>& sent = ::IceInternal::Function<void (bool)>())
    {
    #ifndef __cplusplus_cli
    return begin_ice_flushBatchRequestsInternal(new ::IceInternal::Cpp11FnOnewayCallbackNC(nullptr, exception, sent), 0);
    #else
    return begin_ice_flushBatchRequestsInternal(new ::IceInternal::Cpp11FnOnewayCallbackNC(__nullptr, exception, sent), 0);
    #endif
    }
    #endif


    (So my request is to please make the code /clr aware and to use the proper __nullptr when C++/CLI is in use.)