On 2016-11-18 20:37, Marc Mutz wrote:
On Friday 18 November 2016 09:30:03 Lars Knoll wrote:
On 17/11/16 23:03, Thiago Macieira wrote:
[...]
> But GSL is another story. If it is sensibly developed, with a promise
> to binary compatibility for extended periods of time and no nonsense
> stuff like inline namespaces, we could accept it. Especially the
> header-only parts of it.
[...]
Let's wait a bit how this develops, and whether they are even
interested in
keeping compatibility between versions. But it would be another
dependency, something I don't want to introduce without getting enough
benefit out of it.
The GSL is header-only. There are no BC guarantees, and, "worse", there
are
different implementations. All the compiler, or a static checker, cares
about
is the name of type: ::gsl::owner, ::gsl::non_null, ::gsl::string_span.
It
does not care about the implementation.
To see how simple gsl::owner markup is to incorporate into Qt, I sat
down, added it to QtGlobal and marked up QScopedPointer (incl. docs)
with gsl::owner.
https://codereview.qt-project.org/178107
Anything other than gsl::owner is hitting the incompatibility wall, but,
given some form of reliable detection of GSL alternatives, could be used
with a Qt implementation as a fallback. In that case, Qt would only give
BC guarantees for the version compiled with its own version of the GSL.
This is a stop-gap measure to enable the use of more of GSL in Qt while
still being bound by the current restrictive API rules. Personally, I
wouldn't bother with anything but gsl::owner until those rules are
relaxed to allow upstream GSL's types in the ABI.
The use of gsl::owner now also marks places where we might want to use
unique_ptr in the future, reducing this amount of conceptual work when
moving to Qt 6.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
