[Development] Question about QCoreApplicationData::*_libpaths
charleyb123 at gmail.com
Fri Jan 15 16:08:52 CET 2016
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
<snip, std::vector (and other std:: stuff) technically "leads" in
implementation, language advances, and capabilities over some Qt
Notable quote (Marc):
This is why we need to stop duplicating std API. It's not Qt's core
> 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
> the poor-man's std::optional for the next few decades.
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:
> 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++
*- 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.
(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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development