https://bugs.kde.org/show_bug.cgi?id=375195
--- Comment #10 from Kevin Funk <kf...@kde.org> --- I really don't like having to spend my time defending a change which actually helps us developers writing better code, but here we go... If there are some compiler switches that help us ensuring we're writing cross-platform code, then there are good reasons to use it. We've come across this problem: some Linux dev accidentally (freudian slip most of time) uses one of the operator keywords, and then just later we've noticed it broke the MSVC build. So this is addressing some real world issues. > Applications that use boost are not a theoretical concern, they exist. The > ECM are supposed to be a collection of convenience macros and modules, > allowing among others to write more readable CMake files that are easier to > maintain. > (...) Yes, and also to ensure we write proper C++ code, by enabling several compiler warnings, etc. pp. > To be very honest, I wasn't even aware that the C/C++ standard define named > logical operators. So I googled a bit and came across a number of good > arguments why one might prefer them. Not compelling enough to change my own > practice but I can very well understand why complex projects like boost use > them - and I doubt that boost has any anti-MSVC agenda (didn't check, though > :)). I just grepped the Boost source code (for 'not' and 'and') from the 15+ Boost libraries I have installed and it looks like there's indeed just occurrences of them in 'transitive_reduction.hpp', which looks to me like a freudian slip as well (all other files in that subdir use '!' and '&&' as usual). > What I think the ECM should do is set the options required to make software > compile on all supported/major platforms. Setting things up so that software > fails to build everywhere because there exists a platform where certain > practices cause build failure feels like caressing the proverbial cat against > its fur. Not really. If we can enable compiler warnings/error in a way it helps us writing cross-platform code, that's good. Please see this from a developer perspective. > Esp. if it happens in a minor release, possibly even without documentation > other than a commit message. And a review, and with a discussion on the review... > No matter how big MS Windows is compared to all other platforms it's still a > platform that's very different from KDE's main platform (Unix/Linux and > derivatives). And b/c it's different we shouldn't make it easier to develop for it? > It would be much more in line with the other ECM features to figure out how > to get all platforms to accept what they should be accepting in the first > place. Not sure what you mean here. > FWIW, should getting MSVC to accept named logical operators not be feasible, > isn't this something that should be implemented as a CMake policy? There's really no need to touch CMake here. There's an option to make MSVC adhere more to compiler standards (/Za) but I do not know the side effects of it. Please, let's not waste time discussing this change if there are no real world issues with it. The two or three individual problems with this patch have been sorted out, and since then no developer complained. We're really better off spending our time elsewhere. -- You are receiving this mail because: You are watching all bug changes.
