[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