[omniORB] -Woverloaded-virtual compiler warning

Duncan Grisby duncan at grisby.org
Mon Feb 23 12:39:15 GMT 2015


On Mon, 2015-02-23 at 09:34 +0100, Michael Teske wrote:

[...]
> In file included from /Users/mteske/build/trader/OSX_64/GCC421/Debug-static-mthr/include/omniORB4/CORBA.h:285:
> /Users/mteske/build/trader/OSX_64/GCC421/Debug-static-mthr/include/omniORB4/messaging.hh:252:18: warning: 'Messaging::Poller::_PR_copy_state' hides overloaded virtual function [-Woverloaded-virtual]
>     virtual void _PR_copy_state(Poller*);
>                  ^
> /Users/mteske/build/trader/OSX_64/GCC421/Debug-static-mthr/include/omniORB4/pollable_defs.hh:96:16: note: hidden overloaded virtual function 'CORBA::Pollable::_PR_copy_state' declared here: type
>       mismatch at 1st parameter ('CORBA::Pollable *' vs 'Messaging::Poller *')
>   virtual void _PR_copy_state(Pollable*);
> 
> I'd really like to shut that off. One could add a 
> using DIIPollable::_PR_copy_state;
> directive so that both methods are available
>  or disable the compiler warning if the hiding was intended. 
> 
> So... what _was_ intended?

The hiding is intended, so it's unfortunate that it provokes the
compiler warning. It doesn't warn with the versions of GCC I've tried.

To avoid the warning, the best approach might be to stop declaring
_PR_copy_state() as virtual. It's only virtual to provide a hypothetical
extension point, but it's omniORB proprietary and not documented so I
doubt anyone has used it.

_PR_copy_state() is used in the default implementation of the standard
valuetype _copy_value() method, generated by the IDL compiler. That
method creates an "empty" object with the valuefactory's
create_for_unmarshal() method, then copies the state into it using
_PR_copy_state(). The default implementation of _PR_copy_state() just
simply copies the members, but it's declared virtual so the concrete
valuetype implementation class could override it if it wanted to. Each
valuetype class needs its own function to copy its state, so it's
correct that it hides the function with the same name in the base class.

This is really fall-out from the over-complicated inheritance structure
used in the C++ valuetype mapping.

This small patch to the IDL compiler back-end stops declaring the
function as virtual, so it will remove the warning. At the moment,
omniORB trunk is still used for the 4.2.x series, so I can't check this
change in, because it will break binary compatibility even if nobody is
using the ability to override it. 

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --

-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy_state.patch
Type: text/x-patch
Size: 526 bytes
Desc: not available
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20150223/e5f50ee3/attachment.bin>


More information about the omniORB-list mailing list