[Development] format-like tr()

Ivan Solovev ivan.solovev at qt.io
Fri Oct 25 10:40:12 CEST 2024


> Here's another one: formatting of floating point types.
>
> That's a hard pass on the Standard Library implementations. We already carry
> code for this in the form of libdoubleconversion, so unless we can ditch that
> in favour of the Standard Library content, we shouldn't use both, which would
> increase QtCore code size and possibly introduce differences in behaviour.

Fair point. We definitely do not want current tr() and new trFormat() produce
different results.
But then, I'm questioning the need for trFormat(), at least for now.

If we implement the entire (or most of) formatting and parsing on our own, then
we'll need to support two custom solutions instead of one. And the new one
would anyway diverge from what the standard provides.

> And we really can't use the the Standard Library ones until sometime in the
> 2030s, can we?

Yeah, not until we unconditionally switch to C++20. So, maybe we should
postpone the new solution until that time, and then create something which is
standard-compatible?

------------------------------

Ivan

________________________________________
From: Development <development-bounces at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Thursday, October 24, 2024 7:58 PM
To: development at qt-project.org
Subject: Re: [Development] format-like tr()

On Thursday 24 October 2024 10:12:35 Pacific Daylight Time Thiago Macieira
wrote:
> > IMO, we could benefit from the new syntax, if we could build our
> > implementation on top of what the standard provides for us. But I see
> > little benefit in reimplementing the standard from scratch.
>
> I'm hoping we don't have to do it all. But I don't know yet how far we can
> go. Especially since we mean to do a mixed encoding solution:

Here's another one: formatting of floating point types.

That's a hard pass on the Standard Library implementations. We already carry
code for this in the form of libdoubleconversion, so unless we can ditch that
in favour of the Standard Library content, we shouldn't use both, which would
increase QtCore code size and possibly introduce differences in behaviour.

And we really can't use the the Standard Library ones until sometime in the
2030s, can we?

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Platform & System Engineering


More information about the Development mailing list