Re: [Opalvoip-devel] build broken

[<ada...@se...>]

Hi Robert,

"Robert Jongbloed" <ro...@vo...> wrote on 22/05/2009 
00:25:56:
> Re: [Opalvoip-devel] build broken
> 
> 
> > -----Original Message-----
> > From: Dave Allan [mailto:da...@re...]
> > Sent: Friday, 22 May 2009 2:37 AM
> ...
> > The opal build seems to be broken right now.  I don't have time to
> > troubleshoot it at all, but I've attached a log of the build output.
> 
> The error:
> 
> /ekiga/install/include/opal/opal/manager.h:1381: error:   overriding
> 'virtual ptlib_deprecation****** OpalManager::CreateCall()'
> 
> Indicates the function has been deprecated and should not be used in
> applications.
>
Personally I would avoid using the word 'deprecated' in this context as it 
implies that you can still use it but it is not supported.  This interface 
really is 'removed'.  I.e. you can no longer use it -- at all -- if you 
did your code wouldn't work.  The important thing is that, without 
something like this, nothing would tell the application developer that 
their virtual hook wouldn't be called -- they may just get strange 
behaviour from an apparently working build.

As an aside if your INTERFACE_REMOVED macro returned a pointer to function 
returning pointers to the fwd declared 'removed' class, you can get more 
stars in the output (woohoo):

        error: conflicting return type specified for 'virtual int 
Y::SomeFunc(int, float)'
        error:   overriding 'virtual removed (********** X::SomeFunc(int, 
float))(_**********)'

rather than:

        error: conflicting return type specified for 'virtual int 
Y::SomeFunc(int, float)'
        error:   overriding 'virtual removed********** X::SomeFunc(int, 
float)'

The former draws your attention more to the the base function signature -- 
well okay not much more but...

Also note that it is not really necessary to use prefixed name (like 
'ptlib_deprecation') for the fwd declared class.  Since the fwd declared 
'removed' class is declared within the body of another class it will be 
implicitly scoped by that, also any class member named 'removed' would 
still work since the macro would use 'class removed' or 'struct removed' 
to reference the class.  It even does not matter if you really have a 
nested class called 'removed' since you are only using a pointer to the 
type in some obfuscated function pointer.

I always think that:
 
    'virtual removed (********** ....

at the start of the error tells the developer "this virtual interface has 
been removed."


> Unfortunately the __attribute__((deprecated)) does not seem to work 
properly
> in GCC. So an alternative is used to indicate that if you do a virtual
> override of a function that is no longer used or, more often, had a
> parameter added to it, then the application must change it.
> 
Attribute deprecated only warns when you call a function marked in that 
way.  Overriding it is simply creating a new function at a higher tier 
that happens to be linked via vtable.  So you will get the deprecated 
warning when you try to call CreateCall() but not when you try to 
specialize it.  I don't see any other way but to force dependent 
applications to move to a the new api when the framework changes -- 
otherwise the dependent application's functions will not be called by the 
framework.  It should never simply be a warning, it should be an error -- 
i.e. notifying the programmer that the program won't work unless you move 
over.


> Yes, it would be nice to have 100% backward compatibility of the API for 
the
> next 50 years, but that is not going to happen.
> 
The important thing is not silently breaking behaviour.  Had the 
'interface removed' change not been added, Dave's build would likely have 
succeeded, but not worked at run-time (his override would not have been 
called).  Much better to catch these things at compile time.

Regards,
Adam

------------------------------------------------------------
This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein.  If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies.  It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose.

In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel.
SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Lambda House, Christopher Martin Rd, Basildon, SS14 3EL. England.