[Development] Question about QCoreApplicationData::*_libpaths

[charleyb123 .]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160115/5bfb68c7/attachment.html>