[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Portable Code (am I dreaming? :))
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-01-23 22:34:25
[Download RAW message or body]

On Wednesday 23 January 2002 22:53, shaheed wrote:
> Nicolas,
>
> > > 1. Write all your code in terms of Q_{U,}INT{8,16,32} to maximise
> > > portability on all Qt supported platforms. In your header file, do
> > > something like this:
> > >
> > > #ifndef Q_UINT8
> > >
> > > ...as many platform-specific defs enclose in platform #ifdef guards
> > >
> > > #endif
> > >
> > > to maximise portability on non Qt supported platforms. Or vice versa.
> >
> > I do not think that you need it.
> >
> > The MS Write import filter does define its base types (BYTE, WORD,
> > DWORD...) correctly (apart perhaps from the comment I made about
> > signess).
>
> No, the mswrite filter does it *wrong* for DWORD on any modern 64 bit
> machine. Basically, most 32 bit machines (e.g. "modern" x86) uses the
> so-called "ILP32" model where Integers Longs and Pointers are all 32 bit.
> However, AFAIK, all the major 64 bit platforms use "LP64" (once you get
> over the crappy transitional compiler environments that certain Unixes used
> to "help" application porters migrate) so that where mswritelib.h says:
>
> typedef signed long DWORD;                      // 4 bytes
>
> it will break on Digital UNIX, Solaris 8 and Irix in their 64 bit clean
> compilation environments. Note that these have always been, or are
> becoming, the defaults for those platforms. I suspect, but don't have
> proof, that Qt is more likely to get this right on a range of platforms
> than me, for example

Well then define DWORD/UDWORD as int instead of long! Then you would exactly 
have what QT does. QT does not do anything more!

However, I say that it is not necessary if you read it byte per byte, because 
all you need is at least 32 bits. So you can leave the "long" and you still 
even have compatibility with 16 bits environments (I do not know if it is 
wanted or not by Clarence Dang.)

>
> :-), and I was taking the liberty of extrapolating to others too!
>
> Note how mswordgenerated.h carefully uses "unsigned int" for the DWORD
> thing in the hope that few people are still on "int => 16 bits" - using a
> Qt type would most likely get me the same advantages there!
>
> > QT defines its base types quite the same way. So you do not need to
> > depend on QT, because it does not bring you something new or better (not
> > even additional portability.)
>
> I'd be amazed if this was true since.

Well, I looked in global.h (in QT's directory src/tools)!

The basic types are only defined one time and I do not see where these 
definitions would be over-ruled.

(However: yes, I was surprised too that QT define them like that!)

>
> > And if you read the values byte by byte, you do not really care about the
> > real size (as long as it is not smaller).
> >
> > > 2. Use functions (and/or macros) as Nicolas suggested for reading 8,
> > > 16, 32 bit signed/unsigneds.
> > >
> > > 3. Don't worry about the direction of bit shifts for the reason Nicolas
> > > gave, and don't worry about the performance of bit shifts since the
> > > compiler will almost certainly put the original value in a register.
> > > The current msword code does some of this, and a typical routine looks
> > > like this:
> > >
> > > unsigned MsWordGenerated::read(const U8 *in, __UNAL SHD *out, unsigned
> > > count) {
> > >     U32 shifterU32;
> > >     U16 shifterU16;
> > >     U8 shifterU8;
> > >     U8 *ptr;
> > >     unsigned bytes = 0;
> > >
> > >     ptr = (U8 *)out;
> > >     shifterU32 = shifterU16 = shifterU8 = 0;
> > >     for (unsigned i = 0; i < count; i++)
> > >     {
> > >         bytes += read(in + bytes, &shifterU16);
> > >         out->icoFore = shifterU16;
> > >         shifterU16 >>= 5;
> > >         out->icoBack = shifterU16;
> > >         shifterU16 >>= 5;
> > >         out->ipat = shifterU16;
> > >         shifterU16 >>= 6;
> > >         out++;
> > >     }
> > >     return bytes;
> > > } // SHD
> >
> > I must admit that I have some problems to understand this function. I
> > especially do not understand why you use shifts not divisible by 4 and
> > why you do not use AND ( & ).
>
> The shifts not divisible by 4 are because MS Word defines these odd-sized
> bitfields. Did I misunderstand your question?

No, I was the person that misunderstood something. (See my other mail!)

>
> And I don't need a "&" mask step because in C/C++, a right shift on an
> unsigned quantity is guaranteed to shift in zeros from the top. Note how
> the intermediate storage is carefully always an unsigned!
>
> > > Note that the _UNAL will disappear as soon as I get round to
> > > eliminating a
> >
> > I suppose that _UNAL is something like __unaligned, isn't it?
> >
> > > few sizeof()s used by the current code. In the example, I have an
> > > overloaded read() function for the different primitive types.
> >
> > Just a comment on what I told previously: instead of struct you can also
> > use class and have a method (named for example readFromFile) for each
> > structure instead of an independant function for each structure.
>
> Hehe. I had a loooong argument with Werner about this, and in the end
> Werner went ahead and used the class (and/or namespace) techniques in wv2.
> I am waiting for him to finish so that I will be able to smugly point out
> how bloated his code seems (:-). Werner will probably reply that I am
> simply a reactionary oldie that doesn't appreciate that OO is good for
> everything.
>
> I elected to use a much simpler model of a highly overloaded read()
> function for everything. Had I done writes, I would have done the same with
> write(). Much simpler IMHO.

Well, as here everything is public, both ways are possible.

However, my point was something else. I had started my examples like in C, 
using different function names like readWord, readDWord and so on. I was just 
telling that if you really use C++, you have other possibilities (Your way is 
another possibilty.)

>
> > You could even extend the idea to have BYTE, WORD, DWORD... as classes.
>
> I get the feeling that you are on Werner's side in all this.

Well, your idea works better with simple types, because it is hard to make 
good classes out of them.

>
> Thanks, Shaheed (40 in 7 days time, and still looking for a better language
> than Ada 95).

Have a nice day/evening/night!

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]