Oh, and I forgot to mention, this could of course happen in the case where you 
already had multiple overloads:

foo(const char *);
foo(Foo);
...
then later add
foo(int);


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> On Behalf Of Tony Van Eerd
> Sent: Thursday, February 27, 2014 3:06 PM
> To: [email protected]
> Subject: [Development] Binary Compatibility question (KDE)
> 
> 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 *).
> 
> 
> Anyone care?  Where should I forward this email to?
> 
> Thanks,
> Tony
> 
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to