[Interest] Interest Digest, Vol 79, Issue 19

[Reinhardt Behm]

On Wednesday 25 April 2018 08:53:26 Roland Hughes wrote:
> On 04/25/2018 08:24 AM, Thiago Macieira wrote:
> > Another issue is that QDataStream tries to store all integers in big
> > endian, unless you tell it otherwise. Since most machines are
> > little-endian, that's a waste of CPU cycles, as you're doing the endian
> > conversion twice, for little gain, however fast it is.
> 
> Be gentle and tread lightly here. Don't just take an x86 view of the
> world when considering this change. Having gray in the hair and a long
> time in the field has me recalling a reason behind that. Many embedded
> Qt projects were creating devices which fed data via hook or crook back
> to IBM, Amdahl, Prime, PowerPC based, etc. While Amdahl and Prime have
> ceased production they are still in the field and still being fed.
> 
> https://www.indeed.com/viewjob?jk=f0ccbd43e9217ed2&q=amdahl&tk=1cbugjg1f1a4o
> 2lk&from=web&vjs=3
> 
> Unisys was little-endian but the COBOL compiler had USAGE IS COMP
> clauses which would import/use big-endian format. One of the few which
> had that. Most everyone else had to use FORTRAN or role their own
> special COBOL libraries. Yes, most of the systems catching the output
> were COBOL. It still is the largest "production" language in the world
> by application size and base.
> 
> What I'm trying to tell you is there was and still is a legitimate
> reason to have a QDataStream which can write big-endian. Don't just rip
> it out. Make it some kind of settable boolean flag in the class. There
> is no way to know just how many of these things are still out there and
> are still being developed. Most were in the world of defense
> contractor/military

It is not only that big iron. There many small controllers to which e.g. my 
Qt-applications are talking. Here I have both endian types.

-- 
Best Regards

Reinhardt Behm