> Meson is, as far as I can tell (I had already looked at it a couple
times),
> mostly a CMake clone written in Python. I fail to see how it is
conceptually
> any different from (let alone better than) CMake. It is mainly pushed by
> GNOME developers who are fed up of stone-age autotools, but appar
>
> > Non-owning QString can be created with special static QString method. It
> > stays non-owning only while being passed through const &. Code that cares
> > about keeping QString in view mode, must stick to const QString & all the
> > time. Copy assignment on non-owning QString results in ownin
Thiago described Qt6 QString as { QArrayData *d; ushort* b; qsize size }.
That is pretty close to QStringView, just extra *d makes it slightly bigger.
This is how I understand this class:
QString will have (typical) case when b points into d. QString own one
reference in d in this case.
QString wi
What about removing the hard dependency of type safe replicas on the
rep language and rep compiler? Can we extend moc compiler?
When we write the server objects, we already have the QObject with all
the signals and slots visible for moc. Moc could generate the type
safe replica objects based on th
> Cache format: binary json
You use json internally as cache. What is the motivation to introduce
new classes with similar API like QJson classes?
Is the implicit shared semantics not suitable for this use case? Can
it be addressed in QJson classes directly?
If Qt gets some type safe wrappers ab
Hi all
I am very interested to discuss and contribute to this project.
Our motivation:
Our qt application is split to modules written in qt and every module
runs in its own process. This gives us robustness but our calls become
IPC. All modules are updated at once, so there is no need for stable
> As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
> measured the difference between the current approach and using atomics using
> Olivier's initial benchmark, it's about 4-5x slower for checking if there's a
> callback set. Since this is affecting every Qt application on
>
> > The idea was to silently return a default-constructed type.
>
> I'm not keen on that. Aside from adding extra restrictions to the
> types that the class can be used with as you mention,
> it runs the much more severe risk of masking serious bugs.
>
Returning default-constructed value is heav