Re: [Development] On Removing Public Undocumented/\internal APIs

[Shawn Rutledge via Development]

On Mar 13, 2024, at 12:30 AM, Marc Mutz via Development 
 wrote:

TL;DR: Make qdoc openly document \internal members of documented
classes/namespaces or defined in public headers as "Internal. Subject to
change without notice. If you feel this function should be public, file
a bug report with your use-case."?

We have internal docs at https://contribute.qt-project.org/doc/

They are rather bulky (so probably it’s best that we don’t bloat the Qt 
installation with internal docs); and this way we maintain a clear and 
unambiguous division between public API (what you can see in the help docs that 
we do ship) and those that are meant only for Qt contributors, or for 
unsupported application hack-arounds.

Doxygen has a lot of useful features for this purpose.  (qdoc also has strong 
points, especially its QML support, and low-impedance customizability.  It’s 
fine to keep using it for the public API docs IMO.)

I’ll keep working on improving those internal docs as a background task over 
time, and would encourage everyone else who can help.  Hopefully every class 
and function already shows up there somehow (albeit not yet all submodules); 
and we have some \internal doc comments that explain some dark corners, 
implementation details that would otherwise be hard to understand just by 
reading the code.  Often some diagrams are helpful; and this is where doxygen 
really shines.  You get a standard set of UML diagrams for free, and you can 
use PlantUML syntax or graphviz syntax for custom diagrams.

So especially, whenever your understanding of some algorithm or data structure 
in Qt seems particularly hard-won, I think you should write an \internal doc 
comment nearby, to describe those details of the class or method(s), while it’s 
fresh in your head.  Those comments will show up in the contributor docs (they 
should be built daily if nothing is going wrong; I’m not sure ATM).  (And if 
you want to check the rendering, you can run doxygen locally.  It takes more 
time and memory though, compared to a regular “ninja docs" build.)

I.e. if you understand what QDeferredDeleteEvent::loopLevel() is for, you can 
write a nice description for it right now, and also link to the places where we 
need it.  
https://contribute.qt-project.org/doc/db/deb/classQDeferredDeleteEvent.html 
doesn’t say much so far.

Otherwise, I think we should not constrain ourselves for even more 
compatibility than we already have.  It’s hard enough to keep the public API 
the same while we find better means of implementation.  Internal stuff is 
subject to change.

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Matthias Rauter for approval status

[Shawn Rutledge via Development]

On Jan 30, 2024, at 5:11 AM, Paul Tvete via Development 
 wrote:

Hi,

I would like to nominate Matthias Rauter as an approver for the Qt Project.

+1

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Marking the Tech Preview APIs as such

[Shawn Rutledge via Development]

On Jan 22, 2024, at 10:41 AM, Giuseppe D'Angelo via Development 
 wrote:

Hi,

A number of classes and functions that are going to be introduced in 6.7 are 
meant to be "tech preview", and thus they may pass the header review even if we 
are aware of some limitations or issues with their design.


I propose to introduce a macro, QT_TECH_PREVIEW_API (bikeshed please), that 
expands to nothing/`[[qt::tech_preview_api]]`/... (moar bikeshed) and it's used 
to mark APIs that are considered tech preview.

The first goal of this macro is to ensure that making an API officially 
supported (and out of TP) will require changing the header, and therefore be 
picked up in the next round of header reviews.

Otherwise, there is the chance that an API becomes official by simply adjusting 
the documentation, and one may not notice that this has happened during the 
next API review (and confirm that all the shortcomings have been addressed).


The second goal would be for qdoc to automatically document methods and classes 
marked by the macro as TP.

We have the qdoc \preliminary tag.  But we haven’t always used it consistently; 
some docs just have a \note instead.  
https://doc.qt.io/qt-6/16-qdoc-commands-status.html#preliminary If a whole 
class is considered to be Tech Preview, it’s easier to add one note than to 
mark every function as preliminary.  In the case of the TextDocument API, it 
was exposed only for C++ API before (as a middleman to provide access to the 
QTextDocument that a TextEdit is using), and now it’s gaining properties and 
invokables, so effectively the whole class is Tech Preview from a QML-API 
perspective.

I guess your goal is to be able to see it in the header rather than having to 
look up the docs in the cpp file or online?  (Alternatively we could write all 
docs in headers, but then the headers get to be large, take storage space 
alongside every installation of Qt binaries, and slow down everyone’s 
compilations, so I guess that’s why we don’t do it that way?  Or we could 
somehow include doc diffs in API review patches for whatever API the script has 
already decided is “interesting".)

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New assign() Functionality Added to Qt Containers

[Shawn Rutledge via Development]

Sounds efficient.

What is the meaning of the tilde the way you are using it here in operator=(~) ?

> On 6 Sep 2023, at 11:30, Dennis Oberst via Development 
>  wrote:
> 
> Hello everyone,
> 
> I would like to inform you that we've added assign(~) functionality to the 
> following
> Qt containers:
> 
> QVarLengthArray, QList, QByteArray, and QString. 
> It is now incorporated into certain non-sharing operator=(~) implementations.
> 
> As a quick heads up: assign() offers a convenient way to recycle allocated
> memory, potentially resulting in greater efficiency compared to its
> memory-allocating alternatives.
> 
> We observed that the efficiency of QString::operator=(~) could be boosted of 
> up
> to 30%! Here are some benchmarks to support this statement:
> 
> (x86_64-little_endian-lp64 shared (dynamic) release build (O3); bygcc 13.2.1, 
> endeavouros ; 13th Gen Intel(R) Core(TM) i9-13900K
> 
> benchmarks executed with -perf -iterations 100
> 
>   * The last value at the EOL represent the string size.
> 
> QString =(const QByteArray ) (current)
>   64.3  cycles/iter; 300  instructions/iter; 17   nsec/iter (5)
>   65.8  cycles/iter; 366  instructions/iter; 12   nsec/iter (10)
>   62.9  cycles/iter; 301  instructions/iter; 11.5 nsec/iter (20)
>   61.3  cycles/iter; 315  instructions/iter; 11.1 nsec/iter (50)
>   71.4  cycles/iter; 386  instructions/iter; 13   nsec/iter (100)
>   136.9 cycles/iter; 811  instructions/iter; 24.5 nsec/iter (500)
>   245.8 cycles/iter; 1394 instructions/iter; 42.5 nsec/iter (1'000)
> 
> QString =(const QByteArray ) (before)
>   78   cycles/iter; 399  instructions/iter; 15.3 nsec/iter (5)
>   82.3 cycles/iter; 465  instructions/iter; 15   nsec/iter (10)
>   76.7 cycles/iter; 400  instructions/iter; 14   nsec/iter (20)
>   79.5 cycles/iter; 414  instructions/iter; 14.5 nsec/iter (50)
>   91.4 cycles/iter; 485  instructions/iter; 16.7 nsec/iter (100)
>   189  cycles/iter; 910  instructions/iter; 34.4 nsec/iter (500)
>   320  cycles/iter; 1666 instructions/iter; 56   nsec/iter (1'000)
> 
> QString =(const char *ch) (current)
>   70  cycles/iter; 317  instructions/iter; 12   nsec/iter (5)
>   71  cycles/iter; 383  instructions/iter; 12.3 nsec/iter (10)
>   64  cycles/iter; 318  instructions/iter; 11.1 nsec/iter (20)
>   69  cycles/iter; 340  instructions/iter; 12   nsec/iter (50)
>   77  cycles/iter; 419  instructions/iter; 13.5 nsec/iter (100)
>   141 cycles/iter; 899  instructions/iter; 24.4 nsec/iter (500)
>   280 cycles/iter; 1518 instructions/iter; 48.4 nsec/iter (1'000)
> 
> QString =(const char *ch) (before)
>   86.7  cycles/iter; 416  instructions/iter; 15   nsec/iter (5)
>   87.8  cycles/iter; 482  instructions/iter; 15.7 nsec/iter (10)
>   82.4  cycles/iter; 417  instructions/iter; 14.3 nsec/iter (20)
>   90.2  cycles/iter; 443  instructions/iter; 15.6 nsec/iter (50)
>   101.4 cycles/iter; 518  instructions/iter; 17.7 nsec/iter (100)
>   204.4 cycles/iter; 994  instructions/iter; 36.5 nsec/iter (500)  337.9 
> cycles/iter; 1789 instructions/iter; 58.9 nsec/iter (1'000)
> 
> 
> 
> You can find the patch here: 
> https://codereview.qt-project.org/c/qt/qtbase/+/494280
> 
> Best,
> 
> 
> 
> Dennis Oberst
> Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> 12489 Berlin, Germany
> dennis.obe...@qt.io
> https://www.qt.io
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> 
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Santhosh Kumar Selvaraj for approver rights

[Shawn Rutledge via Development]

+1

On 20 Jun 2023, at 20:55, Jan-Arve Sæther via Development 
 wrote:

Hello all,

I would like to nominate Santhosh Kumar Selvaraj for approver rights in the Qt 
project.

Santhosh is a member of the UI Team, and has been working on improvement to our 
styles, dark mode support, palette handling both in qtbase and qtdeclarative.

You can see his merged changes here:
https://codereview.qt-project.org/q/owner:santhosh.kumar.selvaraj%2540qt.io+is:merged

and his reviews here:

https://codereview.qt-project.org/q/reviewer:santhosh.kumar.selvaraj%2540qt.io

cheers,
---
Jan Arve Sæther
Team Lead

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
jan-arve.saet...@qt.io
http://qt.io
---


--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer

[Shawn Rutledge via Development]

> On 4 May 2023, at 12:10, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> I'd like to nominate Eddy as the maintainer for the QLocale and 
> src/corelib/time QtCore subsystems. Eddy is filling that role de-facto 
> already; making it de-jure sounds only logical.
> 
> I asked, and he'd be on board, if we'd have him.
> 
> Anyone else in favour? (I'm not sure I have a vote, actually…)

+1
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] libQt6Core.so links against both libpcre.so.3 and libpcre2-16.so.0

[Shawn Rutledge via Development]

On 8 Mar 2023, at 11:42, Shawn Rutledge via Development 
 wrote:

My developer build:

$ lddtree /zhome/rutledge/dev/qt6-dbg/qtbase/lib/libQt6Core.so.6.2.0

Oops that was an old leftover; anyway it looks about the same in current dev 
branch:

/home/rutledge/dev/qt6-dbg/qtbase/lib/libQt6Core.so.6.6.0 (interpreter => 
/lib64/ld-linux-x86-64.so.2)
libicui18n.so.72 => /usr/lib/libicui18n.so.72
libicuuc.so.72 => /usr/lib/libicuuc.so.72
libicudata.so.72 => /usr/lib/libicudata.so.72
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0
libz.so.1 => /usr/lib/libz.so.1
libdouble-conversion.so.3 => /usr/lib/libdouble-conversion.so.3
libb2.so.1 => /usr/lib/libb2.so.1
libgomp.so.1 => /usr/lib/libgomp.so.1
libpcre2-16.so.0 => /usr/lib/libpcre2-16.so.0
libzstd.so.1 => /usr/lib/libzstd.so.1
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.6 => /usr/lib/libm.so.6
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.6 => /usr/lib/libc.so.6
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2

I guess it’s because QString uses 16-bit characters and libglib sticks with 
UTF8.  So how are Qt releases getting by without the 2-16 version then?  I 
guess those are built on RHEL 8.4 (?), which has available

/usr/lib64/libpcre16.so.0.2.10
/usr/lib64/libpcre2-8.so.0.7.1
/usr/lib64/libpcrecpp.so.0.0.1
/usr/lib64/libpcre2-16.so.0.7.1
/usr/lib64/libpcre2-posix.so.2.0.1
/usr/lib64/libpcreposix.so.0.0.6
/usr/lib64/libpcre2-32.so.0.7.1
/usr/lib64/libpcre32.so.0.0.10
/usr/lib64/libpcre.so.1.2.10

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] libQt6Core.so links against both libpcre.so.3 and libpcre2-16.so.0

[Shawn Rutledge via Development]

> On 8 Mar 2023, at 11:16, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> Did my first conscious ldd on QtCore todays and just found it curious 
> that it linked against pcre and pcre2-16.
> 
> Digging, I found that the pcre dep gets dragged in by glib-2.0:
> 
>   objdump -p /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 | grep NEEDED
> NEEDED   libpcre.so.3
> NEEDED   libpthread.so.0
> NEEDED   libc.so.6

Arch Linux package FWIW:

$ lddtree /usr/lib/libQt6Core.so.6.4.2
/usr/lib/libQt6Core.so.6.4.2 (interpreter => None)
libicui18n.so.72 => /usr/lib/libicui18n.so.72
libicuuc.so.72 => /usr/lib/libicuuc.so.72
libicudata.so.72 => /usr/lib/libicudata.so.72
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0
libz.so.1 => /usr/lib/libz.so.1
libsystemd.so.0 => /usr/lib/libsystemd.so.0
libcap.so.2 => /usr/lib/libcap.so.2
libgcrypt.so.20 => /usr/lib/libgcrypt.so.20
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0
liblzma.so.5 => /usr/lib/liblzma.so.5
liblz4.so.1 => /usr/lib/liblz4.so.1
libdouble-conversion.so.3 => /usr/lib/libdouble-conversion.so.3
libb2.so.1 => /usr/lib/libb2.so.1
libgomp.so.1 => /usr/lib/libgomp.so.1
libpcre2-16.so.0 => /usr/lib/libpcre2-16.so.0
libzstd.so.1 => /usr/lib/libzstd.so.1
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.6 => /usr/lib/libm.so.6
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.6 => /usr/lib/libc.so.6
ld-linux-x86-64.so.2 => /usr/lib/ld-linux-x86-64.so.2

6.5 beta from the installer:

$ lddtree /zhome/rutledge/Qt/6.5.0/gcc_64/lib/libQt6Core.so.6.5.0
/zhome/rutledge/Qt/6.5.0/gcc_64/lib/libQt6Core.so.6.5.0 (interpreter => 
/lib64/ld-linux-x86-64.so.2)
libicui18n.so.56 => /zhome/rutledge/Qt/6.5.0/gcc_64/lib/libicui18n.so.56
libicuuc.so.56 => /zhome/rutledge/Qt/6.5.0/gcc_64/lib/libicuuc.so.56
libicudata.so.56 => /zhome/rutledge/Qt/6.5.0/gcc_64/lib/libicudata.so.56
libdl.so.2 => /usr/lib/libdl.so.2
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0
libz.so.1 => /usr/lib/libz.so.1
libpthread.so.0 => /usr/lib/libpthread.so.0
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0
librt.so.1 => /usr/lib/librt.so.1
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.6 => /usr/lib/libm.so.6
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.6 => /usr/lib/libc.so.6
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2

My developer build:

$ lddtree /zhome/rutledge/dev/qt6-dbg/qtbase/lib/libQt6Core.so.6.2.0
/zhome/rutledge/dev/qt6-dbg/qtbase/lib/libQt6Core.so.6.2.0 (interpreter => 
/lib64/ld-linux-x86-64.so.2)
libicui18n.so.69 => None
libicuuc.so.69 => None
libicudata.so.69 => None
libzstd.so.1 => /usr/lib/libzstd.so.1
libdl.so.2 => /usr/lib/libdl.so.2
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0
libz.so.1 => /usr/lib/libz.so.1
libdouble-conversion.so.3 => /usr/lib/libdouble-conversion.so.3
libb2.so.1 => /usr/lib/libb2.so.1
libgomp.so.1 => /usr/lib/libgomp.so.1
libpcre2-16.so.0 => /usr/lib/libpcre2-16.so.0
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0
librt.so.1 => /usr/lib/librt.so.1
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.6 => /usr/lib/libm.so.6
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libpthread.so.0 => /usr/lib/libpthread.so.0
libc.so.6 => /usr/lib/libc.so.6
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt example development guideline and revamping examples

[Shawn Rutledge via Development]

On 3 Feb 2023, at 13:56, Tuukka Turunen via Development 
 wrote:

pdf/pdfviewer

Depends which one you mean.  They are all new and maintained at this point.  
There is some redundancy on purpose, because there are multiple PDF-viewing 
components.  So I wouldn’t delete any of them.

quick/delegatechooser

We need to make sure we are showing DelegateChooser somewhere; it’s quite 
useful.  I don’t see it in any other examples.

quick/pointerhandlers

I plan to give the pointerhandlers example some proper docs.  It only recently 
graduated from being a manual test.  It may not look like a “proper desktop 
application” but that’s not the point.

… many more I don’t remember so well, and then...
wayland/custom-extension
wayland/custom-extension/compositor
wayland/custom-extension/cpp-client
wayland/custom-extension/qml-client
wayland/custom-shell/client-plugin
wayland/custom-shell/compositor
wayland/hwlayer-compositor
wayland/minimal-cpp
wayland/server-buffer
wayland/server-buffer/compositor
wayland/server-buffer/cpp-client
widgets/itemviews/flattreeview
widgets/itemviews/storageview
...

As Kimmo mentioned, we should aim to check and move (or remove if not seen 
relevant as a manual test by the module maintainer) these during February.

You are talking about removing them from the manifest, not removing the code, I 
hope? Even so...

The point of examples is to show how to use Qt to do specific things.  Some of 
them are redundant? Well there is not only one way to do things; why should we 
hide something cool just because it’s only the second of several choices?

In the future I think we will hesitate to write new examples if the risk of 
deletion is so high.

Move them to manual tests?  Well that’s better than deleting, but users will 
not tend to find those, because we don’t ship them.

Snippets? I think those should be complete enough to actually run.  Otherwise 
it’s too much work to keep re-verifying that they still work.  And it is more 
useful to users to start with a complete, minimal example that already runs, 
and then add the extra functionality that they want, rather than just some 
stanza of code that got broken at some point along the way.  With QML that’s 
not too hard; so my rule is every QML snippet should be a complete standalone 
file that can run with the qml tool.  But with C++ snippets it’s not convenient 
to make them runnable; so when we convert C++ examples to snippets, we can 
expect them to rot, unless we come up with a way to auto-wrap them with 
boilerplate and test them automatically on a periodic basis (in CI, in 
pre-release testing or whatever).

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )

[Shawn Rutledge via Development]

> On 16 Jan 2023, at 13:49, Friedemann Kleint via Development 
>  wrote:
> 
> Hi,
> 
> I would like to propose considering making Qt suitable for CMake UNITY_BUILDs 
> ( https://bugreports.qt.io/browse/QTBUG-109394 , 
> https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html ) .
> 
> This has originally been proposed for Qt for Python  ( 
> https://bugreports.qt.io/browse/PYSIDE-2155 ). It has greatly benefited from 
> it; builds are much faster; particuarly for us in home-office where no 
> distributed build environment exists.
> 
> It is basically what webengine has been using for a long time: Source files 
> are concatenated to jumbo files which are then compiled.
> 
> For Qt for Python with its lots of generated files, the speed-up is drastic 
> (~10x); for an average module (qttools), less so, but still:
> 
> Initial build of qttools:
> 
> Standard (675 files): real 3m26,016s / user 19m4,352s / sys 1m48,346s
> Unity (203 files)   : real 2m2,557s  / user 9m40,147s / sys 0m47,144s 
> (CMAKE_UNITY_BUILD_BATCH_SIZE=16)
> 
> with CCACHE/warmed up:
> 
> Standard (675 files): real 1m50,605s / user 8m9,512s  / sys 1m9,187s
> Unity (203 files)   : real 1m30,990s / user 5m11,773s / sys 0m39,687s

Speaking of ccache, how stable is the selection of files that are concatenated? 
 I suppose small changes will tend to invalidate more of the cache? Where 
before you could make a change in one cpp, and only one smaller cache object 
was invalidated, now it will invalidate the whole jumbo file’s cache, and after 
all rebuilding the jumbo file should take longer and produce a larger object 
than the smaller file that was changed.  But I guess that’s the way it goes, 
since we are rebuilding Qt to test changes, not just rebuilding the same 
version over and over.  I wonder if the ccache hit rate will actually go down 
though, so incremental rebuilding when you are just changing a line at a time 
could be slower.

Any trouble with icecream after this?

Otherwise it sounds like a win, mostly.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Axel Spoerl as approver

[Shawn Rutledge via Development]

+1

I’m impressed with his lack of fear to dig into unfamiliar code to fix old and 
stubborn bugs, and optimistic attitude.

> On 5 Dec 2022, at 10:57, Volker Hilsheimer via Development 
>  wrote:
> 
> Hi,
> 
> 
> I’d like to nominate Axel Spoerl as an approver for the Qt project.
> 
> Axel has been working in The Qt Company since January, writing tests, 
> analysing and fixing bugs, participating in the port of Qt Speech to Qt 6, 
> investigating and stabilising flaky tests across all platforms, and most 
> recently implementing platform theme support for GTK3-based Linux desktop 
> environments.
> 
> I trust him to be a good approver. Links to gerrit dashboards:
> 
> Patches: https://codereview.qt-project.org/q/owner:axel.spoerl%2540qt.io
> Reviews: https://codereview.qt-project.org/q/reviewer:axel.spoerl%2540qt.io
> 
> Disclosure: I’m Axel’s indirect line manager at The Qt Company in Oslo.
> 
> 
> Volker
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Renaming quint128

[Shawn Rutledge via Development]

On 2022 Nov 18, at 03:13, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

I was working on extended integers and added qint128 and quint128 to qglobal.h

Interesting.  How far can we go with doubling bits?  quint512 in case you have 
AVX-512 registers?  (I must get a laptop with that feature, next time; since 
even Zen 3 doesn’t have it, I still don’t have any machine that does)

Variable-sized ints shouldn’t be a template though?

Maybe CBOR bignums would have a use for it?  Various kinds of hashes?  I’d 
really like it if cryptographic hashes often ended up being numeric again.

QUuid should have a use for it.

What else can we interoperate with? gmplib.org perhaps; 
maybe some C++ standard could be in the works?

What about having varints in Qt some day?  (Like the way protobuf stores ints)  
I wonder why CBOR doesn’t have them.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development