> On 22 Aug 2019, at 15:11, Mutz, Marc via Development > <development@qt-project.org> wrote: > > We need to collectively understand that implementing a library is different > from the library's API and from use of the API. Anyone who thinks otherwise > is invited to have a look at qmetatype.h or qtypeinfo.h. All users see from > this is Q_DECLARE_METATYPE, and we don't really care whether they use > Q_DECLARE_TYPEINFO. But a Qt developer mustn't forget to add > Q_DECLARE_TYPEINFO, because it's a BiC change to add it afterwards, and there > are tons of Qt optimisations hinging on getting that correct. Qt developers > are under very different constraints than Qt users, and we can't go on > pretending that it's ok to develop Qt as if we were developing a throw-away > Qt app and that profiling will show us where to optimise.
The notion that developing a generic library is “harder” than application development is no excuse for not having good APIs for our own internal use. Nor is it an excuse for micro optimising every code path “just in case”. A lot of the “library” development in Qt are features and convenience, where the availability and ease of use of the feature is itself more important to our users than whether or not it performs optimally in every single use-case. As long as the API is not painting us into a corner the code can in many cases be optimised incrementally when and if it turns out to be a problem. Qt is a large project, with a wide range of areas. If the mental model for developing Qt requires you to take into account every single corner case or micro-optimisation possible you’ll end up with 10 perfect string classes and nothing that uses them because the feature development will grind to a halt. This also goes for increasing std-ization of Qt, where the use of the std-library ends up obfuscating what the code is actually doing. Tor Arne _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
