Re: [Development] Binary Compatibility question (KDE)
Tony Van Eerd schreef op 27-2-2014 21:06: 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). To me, it doesn't sound reasonable to expect an unqualified func to stay source compatible. If you want your code to be source compatible with future vesions and you use function pointers, I'd suggest to always use the longer, ugly cast version. I don't think it is unreasonable that in the future overloads are introduced for existing functions, especially for non-slots. BC is IMHO a big enough constraint. Lets not bind our hands even further... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
On Thursday 27 February 2014 17:09:59 Thiago Macieira wrote: Maybe techbase is deprecated and everything is moving to the newer wikis. It's not deprecated. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
On Thursday, 2014-02-27, 16:18:32, Thiago Macieira wrote: Em sex 28 fev 2014, às 00:39:05, Tomasz Olszak escreveu: 2014-02-28 0:24 GMT+01:00 Thiago Macieira thiago.macie...@intel.com: Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu: Thanks, but it seems I don't have permissions? :-( You can only edit after logging in. Now the big question is: where's the create account link? https://identity.kde.org/ It's not the same login. At least, I couldn't log in with my identity password on techbase. Login with OpenID, then select KDE Identity as the ID provider :) Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
Em sex 28 fev 2014, às 11:10:41, André Somers escreveu: To me, it doesn't sound reasonable to expect an unqualified func to stay source compatible. If you want your code to be source compatible with future vesions and you use function pointers, I'd suggest to always use the longer, ugly cast version. I don't think it is unreasonable that in the future overloads are introduced for existing functions, especially for non-slots. BC is IMHO a big enough constraint. Lets not bind our hands even further... For most functions, I agree. However, we need to be careful about signals. Since they are very, very often used in: connect(obj, Klass::somethingChanged, ...) We need to ensure that we aren't adding overloads to signals. -- 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
Re: [Development] Binary Compatibility question (KDE)
-Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Thiago Macieira Sent: Friday, February 28, 2014 11:26 AM To: development@qt-project.org Subject: Re: [Development] Binary Compatibility question (KDE) Em sex 28 fev 2014, às 11:10:41, André Somers escreveu: To me, it doesn't sound reasonable to expect an unqualified func to stay source compatible. If you want your code to be source compatible with future vesions and you use function pointers, I'd suggest to always use the longer, ugly cast version. I don't think it is unreasonable that in the future overloads are introduced for existing functions, especially for non-slots. BC is IMHO a big enough constraint. Lets not bind our hands even further... For most functions, I agree. However, we need to be careful about signals. Since they are very, very often used in: connect(obj, Klass::somethingChanged, ...) We need to ensure that we aren't adding overloads to signals. But in the end, it is only SC break. So the developer recompiles, and see ambiguous blah blah blah. Not too hard to fix. So I think that can be decided on a case by case basis - is it _really_ important to reuse the same function name, etc. (In most cases, a new name is just easier than trying to imagine all the ways an overload can fail. But in the odd case, I think overloads should be allowed. That's how I handle it for the BB10 APIs.) I think the implicit cast and potentially silently calling a different function, while less likely to happen, is much more serious. Anyhow, I signed in with OpenID, but still can't edit. Whatever. It is not quite important enough to me to keep trying. But I just wanted to bring it to people's attention in case someone thought it worthwhile. Tony ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
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: development-bounces+tvaneerd=blackberry@qt-project.org [mailto:development-bounces+tvaneerd=blackberry@qt-project.org] On Behalf Of Tony Van Eerd Sent: Thursday, February 27, 2014 3:06 PM To: development@qt-project.org 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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
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
Re: [Development] Binary Compatibility question (KDE)
Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu: Thanks, but it seems I don't have permissions? :-( You can only edit after logging in. Now the big question is: where's the create account link? -- 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
Re: [Development] Binary Compatibility question (KDE)
2014-02-28 0:24 GMT+01:00 Thiago Macieira thiago.macie...@intel.com: Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu: Thanks, but it seems I don't have permissions? :-( You can only edit after logging in. Now the big question is: where's the create account link? https://identity.kde.org/ -- regards, Tomasz Olszak Qt for Tizen | http://qt-project.org/wiki/Tizen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
Em sex 28 fev 2014, às 00:39:05, Tomasz Olszak escreveu: 2014-02-28 0:24 GMT+01:00 Thiago Macieira thiago.macie...@intel.com: Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu: Thanks, but it seems I don't have permissions? :-( You can only edit after logging in. Now the big question is: where's the create account link? https://identity.kde.org/ It's not the same login. At least, I couldn't log in with my identity password on techbase. -- 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
Re: [Development] Binary Compatibility question (KDE)
On 28 February 2014 08:18, Thiago Macieira thiago.macie...@intel.com wrote: Em sex 28 fev 2014, às 00:39:05, Tomasz Olszak escreveu: 2014-02-28 0:24 GMT+01:00 Thiago Macieira thiago.macie...@intel.com: Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu: Thanks, but it seems I don't have permissions? :-( You can only edit after logging in. Now the big question is: where's the create account link? https://identity.kde.org/ It's not the same login. At least, I couldn't log in with my identity password on techbase. It looks like you need admin rights in order to create an account: https://techbase.kde.org/index.php?title=Special:UserLogintype=signup Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary Compatibility question (KDE)
Em sex 28 fev 2014, às 08:46:09, Sze Howe Koh escreveu: On 28 February 2014 08:18, Thiago Macieira thiago.macie...@intel.com wrote: Em sex 28 fev 2014, às 00:39:05, Tomasz Olszak escreveu: 2014-02-28 0:24 GMT+01:00 Thiago Macieira thiago.macie...@intel.com: Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu: Thanks, but it seems I don't have permissions? :-( You can only edit after logging in. Now the big question is: where's the create account link? https://identity.kde.org/ It's not the same login. At least, I couldn't log in with my identity password on techbase. It looks like you need admin rights in order to create an account: https://techbase.kde.org/index.php?title=Special:UserLogintype=signup Maybe techbase is deprecated and everything is moving to the newer wikis. That's fine, but that would imply this page should have been moved too. -- 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
Re: [Development] Binary Compatibility question (KDE)
On Thursday 27 February 2014 17:09:59 Thiago Macieira wrote: Em sex 28 fev 2014, às 08:46:09, Sze Howe Koh escreveu: On 28 February 2014 08:18, Thiago Macieira thiago.macie...@intel.com wrote: Em sex 28 fev 2014, às 00:39:05, Tomasz Olszak escreveu: 2014-02-28 0:24 GMT+01:00 Thiago Macieira thiago.macie...@intel.com: Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu: Thanks, but it seems I don't have permissions? :-( You can only edit after logging in. Now the big question is: where's the create account link? https://identity.kde.org/ It's not the same login. At least, I couldn't log in with my identity password on techbase. It looks like you need admin rights in order to create an account: https://techbase.kde.org/index.php?title=Special:UserLogintype=signup Maybe techbase is deprecated and everything is moving to the newer wikis. That's fine, but that would imply this page should have been moved too. identity.kde.org account is a openid method. Using that it works for me. Mike -- Michael Jansen http://michael-jansen.biz ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
