[Development] Binary Compatibility question (KDE)

Thiago Macieira thiago.macieira at intel.com
Thu Feb 27 22:50:25 CET 2014


Em qui 27 fev 2014, às 20:06:04, Tony Van Eerd escreveu:
> Sorry, there is probably a KDE email list or something that I should post
> this to, but I know it is very closely related to Qt:
> 
> On http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
> there is:
> 
> You cannot...
> 
> - For existing functions of any type:
> 	- add an overload (BC, but not SC: makes &func ambiguous), adding 
overloads
> to already overloaded functions is ok (any use of &func already needed a
> cast).
> 
> There is another issue - implicit casting. ie
> 
> Foo.hpp // old
> 	int foo(const char * ptr);
> 
> MyCode.cpp
> 	#include <Foo.hpp>
> 	int x = foo(NULL);
> 
> 
> Foo.hpp // NEW (1)
> 	int foo(const char * ptr);
> 	int foo(Bar *);
> 
> MyCode (same as above) now has SC break - "ambiguous function call"
> 
> Foo.hpp  // NEW(2) - WORSE
> 	int foo(const char * ptr);
> 	int foo(int);
> 
> MyCode.cpp now still compiles, *but calls a different function!* - 
> foo(int), as NULL is 0 is an int, and that is a closer match that foo(const
> char *).

That technically depends on what NULL is. If NULL is actually nullptr, it will 
bind to the pointer, not the integer. If it's C++98 and it's a literal zero, 
it will bind to the int.

That doesn't lessen the problem, though.

> Anyone care?  Where should I forward this email to?

I'm the maintainer of that page. But it's a wiki, just edit it with your 
additional case.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list