Apologies for "hijacking" the thread, but two points were raised that IMHO would be helpful if they were answered directly:
(1) Future of Qt binary compatibility (2) Use of std:: containers (especially in context of (1)). We can take this to another thread as-needed. However, quick "recap": ===>PART (1), Future of Qt binary compatibility Marc sayeth: <snip, std::vector (and other std:: stuff) technically "leads" in implementation, language advances, and capabilities over some Qt equivalents> Notable quote (Marc): > <snip>, This is why we need to stop duplicating std API. It's not Qt's core > competency > to meddle with things we only have a half-interest in. It's fun to write > QOptional. Until it isn't anymore. And then the (Qt) world needs to live > with > the poor-man's std::optional for the next few decades. > </rant> In further support of (1), ... Иван Комиссаров sayeth: > >> I've already heard those arguments, however we _can't_ use std::vector in >> API, because it's implementation may differ between compliers (gcc and >> clang stdlibs, for example). > > Giuseppe D'Angelo respondeth: > We might reopen the case about why we should care at preserving binary > compatibility amongs different standard libraries. Or preserving binary > compatibility at all... > IMHO, "something is different" now that C++17 will provide features like "Modules". While "phase 1" might merely be something like a glorified "precompiled-header" bundle to speed compile-time, it's clear that "phase 2" is intended to approximate an ABI whereby a compiler could resolve these implementation-mappings across compiled-lib boundaries. This begs the question: Past Qt design decisions providing binary compatibility through *code* decisions (e.g., d-ptr and wrapper classes) might in the (not-too-distant-future) be otherwise resolved with new C++ language features. If this were true, how would Qt like to position itself? Specifically, IMHO Qt remains the best-in-class cross-platform framework. In part, this value came from its strong adherence to managing what nobody else was managing -- its interface binary compatibility. Going forward, Qt's value proposition might more appropriately focus on what it *is*: A rich cross-platform framework (whereby it might continue its ABI stability through C++ language advances, not through library conventions). ===>PART (2), Use of std:: containers This is a big topic, discussed on other Qt threads. However, from this thread: Bo sayeth: > <snip>, > However, my customers have developers that are a lot less experienced than > us. And it's my observation that using the Qt classes over the std classes > lead to fewer mistakes and faster applications. It seems much easier to > shoot yourself in the foot with std. I don't know why this is, it's only > what I observe when I look at code written by others. Agree. Completely. IMHO, this is because: std:: and friends: *- GOOD: ...are mathematically elegant, and complete, and fast (e.g., Stepanov's work, iterators, API and implementation evolves with C++ language advances). *- BAD: ...have really poor APIs that are error-prone, are often inconsistent, and incomplete, and dangerous, and unlike how most programmers "think" and designs "work", and are painfully volatile across C++ Language Standards versions. In our codebase, we've "wrapped" the std:: containers for stable-and-safe interfaces. Huge dividends. You can get (unsafe) direct access to the embedded std:: entity if you want. This is another option/mechanism for how we might evolve stable Qt interfaces, and work with std:: and friends. <===END THREAD HIJACK IMHO, the Qt community likely requires a long-term strategy for how it wants to address ABI and std:: in the face of very active advances in C++ Language Standards, libraries, and STL idioms. Also IMHO, these are big things that we can leverage to great Qt advantage. Specifically: (a) There is a reason programmers want to use std:: (b) There is a reason programmers have a hard time using std:: in any codebase (Qt can help with this) --charley
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development