Ok, I will not resist! Thinking twice, QTransmogrifier avoids promising too
much and the length is not a problem since it only appears as
QTransmogrifier full specializations.
It is just *one* way to transform C++ data to an abstract structured value,
that will then be disguised as Cbor, Xml...
-Original Message-
From: Jason H
> > My only remaining comment is QBind is rather ambiguous.
> > We already have "bind" used as for SQL parameters. Bind is also used for IP
> > ports, Boost uses "bind" for connections. "Data binding" is another thing
> > as well usually to bind data to
-Original Message-
> From: Bogdan Vatra
>
> It will be great if we can find a way to use it any (de)serialization
> mechanism (e.g. proto buff, flat buffers, etc.) not only with only one (qt
> specific).
As explained in the answer to Simon, QBind replaces .proto files with C++
functio
uate data format according to the
requirements: binary for performance, explicit text-format for interoperability
with other languages, XML for the toolset, what else?
Hope it helps thinking about the various pros/cons involved...
Cheers,
Arnaud
From: Simon Hausmann mailto:simon.hausm...@qt.io
Thank you,
I will then submit a patch with the core of QBind and ask for reviewers.
Arnaud
-Original Message-
From: Edward Welbourne
Sent: jeudi 29 août 2019 17:39
To: Arnaud Clere
Subject: Re: Proposal for an efficient and robust (de)serialization mechanism
working with Qt-supported
Hi all,
I only received feedback from users in private, so I guess this is not the
right mailing list to ask for feedback on new features... Would
inter...@qt-project.org be a better place?
I thought about the developers mailing list because my proposal may allow
answering some needs expressed
Hi all,
Qt handles a broad spectrum of data both in and out of RAM and Qt users
routinely need to read/write such data from/to their domain-specific C++ types.
But doing so can feel much more complicated than it should be: e.g. unexpected
QVariant conversions, unknown QDataStream versions, compl
-Original Message-
> From: Konstantin Tokarev
> > The creeping STLization of Qt (deprecating some classes for STL
> > alternatives, using STL classes in some APIs, etc.) is also part of
> > this disturbing trend. It typically regresses both ease of use and API
> > consistency in the na
Hi all,
So, do I understand correctly that:
1. QUtf8String may be required in Qt7 to solve problems due to C++2x char8_t
2. QByteArray methods currently operating on latin1 may be restricted to ascii
in Qt6 to avoid problems when const char* input really is utf8
3. QLatin1String may become QLatin
> -Original Message-
> From: Thiago Macieira
> > On Monday, 8 July 2019 12:42:51 -03 Arnaud Clere wrote:
> > > -Original Message-
> > > From: Thiago Macieira
> > >
> > > I am not completely convinced of the benefit of adding of an
-Original Message-
From: Thiago Macieira
>
> I am not completely convinced of the benefit of adding of an owning UTF-8
> string class, though I very much agree with a view over UTF-8 strings.
> The reason is not the string class itself (alone it is definitely useful),
> but the fact t
Hi all,
> -Original Message-
> From: Thiago Macieira
>
> But QByteArray is encoding-indeterminate since it can carry any type.
> Arguably, toUpper() and toLower() should be removed, since
> QByteArray(u8"Résumé").toLower() is mojibake.
...
> Are we willing to add ubegin() and begin8()
12 matches
Mail list logo
