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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
