"no unique final overrider" appears in 3.0.1-3.4.1 move

in Help Center
Hi.
I'm trying to move some C++ projects on RHEL 5 (GCC 4.1.2) from Ice 3.0.1 to Ice 3.4.1. We have slice/C++ interface/class hierarchies that compiled fine with 3.0.1 but break on 3.4.1, and I'm trying to figure out why.
The errors I'm getting say things like this:
"SegCertify.h:22: error: no unique final overrider for `virtual const std::string& SPData::BaseSegIF::ice_id(const Ice::Current&) cons' in `SegCertify'."
I'm no C++ expert, but it seems like maybe we have the problem described here:
http://www.zeroc.com/forums/help-center/4869-implementing-multiple-interfaces-single-c-class.html
What strikes me as odd is the fact that this problem suddenly appeared with Ice 3.4.1. Does that seem seem possible, Ice developers, or do I have some other build problem?
I'm trying to move some C++ projects on RHEL 5 (GCC 4.1.2) from Ice 3.0.1 to Ice 3.4.1. We have slice/C++ interface/class hierarchies that compiled fine with 3.0.1 but break on 3.4.1, and I'm trying to figure out why.
The errors I'm getting say things like this:
"SegCertify.h:22: error: no unique final overrider for `virtual const std::string& SPData::BaseSegIF::ice_id(const Ice::Current&) cons' in `SegCertify'."
I'm no C++ expert, but it seems like maybe we have the problem described here:
http://www.zeroc.com/forums/help-center/4869-implementing-multiple-interfaces-single-c-class.html
What strikes me as odd is the fact that this problem suddenly appeared with Ice 3.4.1. Does that seem seem possible, Ice developers, or do I have some other build problem?
0
Comments
It would be helpful to include the declaration of your class, together with the Slice definitions of the interfaces (classes, structs...) it refers to.
This error would indeed occur if you're implementing directly multiple generated classes. It's surprising but not impossible that this code compiled with 3.0.1.
Cheers,
Bernard
Then, if you really like multiple inheritance and know what you're doing, have a look at the "cpp:virtual" metadata in http://www.zeroc.com/doc/Ice-3.4.1-IceTouch/manual/Metadata.48.3.html. This could explain the difference you're seeing between Ice 3.0.1 and Ice 3.4.1, as this "cpp:virtual" used to be the default.
Cheers,
Bernard
slice2cpp produces this:
I'm curious why the IceInternal::GCShared is private and non-virtual. I ask, not because I know enough to expect otherwise, but because I can get rid of a build error by making it public and virtual. Here's the error:
Sorry for asking reverse-engineered questions; I'm just stuck and hoping for another insight like ["cpp:virtual"].