[QGIS-Developer] To Qt or not to Qt? This is the question.

[Alessandro Pasotti]

Hi,

please have a look to https://github.com/qgis/QGIS/pull/9832

I think it's a good opportunity to start (or re-start in case i missed it)
a discussion about:

1. introducing new libraries where QT already provides an implementation
when there is a good reason to
2. using STL and other "modern C++" idioms and deviate from QT when there
is a good reason to

In the particular case of this PR I started from the consideration that
generating json "manually" by string concatenation was not a good idea
because it is error prone and not particularly efficient.
So i started by using QJson* from QT but it was not only very slow but also
it used an ugly syntax.

Moreover, json is becoming the preferred format especially for OGC API
(wfs3) and it is therefore important that we have a solid, efficient and
easy to use library for our json operations.

But, the library that IMO suited best the needs is not from the QT
ecosystem, for example, it uses std::string instead of QString, this is not
a problem for QGIS server because it already has overrides that take C
strings through QIODevive (note that despite the small overhead for the
conversion to/from QString, the new json implementation is still faster
than QJson).
To avoid unnecessary QString<->srd::string conversions, there will probably
be more server-specific overrides in the future.

Even if I started this work with the server in mind, similar considerations
will probably apply to some extent to the desktop as well.

The STL discussion is somewhat related (deviating from QT) but it is an
independent topic, I think we already started to deviate from QT when we
introduced std::unique_ptr, but I'd really like to go further and see more
automatic memory management and more usage of something like (a bit verbose
without typedefs):

std::unique_ptr<std::vector<std::unique_ptr<QgsSomeCoreClass>>>

This of course introduce problems with SIP bindings but this is another
story and we could start by using those idioms for internal implementation
and not for the API.

I'd be interested in what you guys think about these topics, I'm pretty
sure you have also thought about it some times.

Thanks in advance for your feedback!

-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190506/0ec3a3a9/attachment-0001.html>