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 _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
