Hi, I have in the past fixed #include mistakes such as #include <qsharedpointer.h> for QSharedDataPointer, and even though each time the issue came up that this is a SiC change (but only for users that unduly rely on indirect includes), so far they were always accepted.
When splitting off qHash() from qhash.h into qhashfunctions.h, I have come across many files that included qhash.h without using it, and likewise some for which qhashfunctions.h would suffice. One of them now got a -1 for being SiC. Can we please decide once and for all whether #include cleanups that are technically SiC are ok or not, if they only affect users that rely on indirect includes? My vote obviously goes to allowing them. Rationale: We're also allowing adding new overloads of functions, which is SiC for code that takes the address of a functions. We allow it, because there's an easy fix that is both forward and backwards-compatible: explcitly cast pointers to these functions. Something that should probably have been done defensively to begin with. So is #include'ing all required headers yourself. It makes no sense to allow one and forbit the other. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
