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

List:       koffice-devel
Subject:    Re: Portable Code (am I dreaming? :))
From:       Clarence Dang <CTRL_CD () bigpond ! com>
Date:       2002-01-21 10:41:29
[Download RAW message or body]

On Wed, 16 Jan 2002 07:13, Nicolas Goutte wrote:
[snipped]
> On Tuesday 15 January 2002 01:25, Clarence Dang wrote:
> > I don't think it's ISO C++ but it's GNU so should work everywhere?
> > I notice that you have:
> > #ifndef __GNUC__
> > #define __attribute__(a)
> > #pragma pack(1)
> > #endif
> > So what do I, if I they're not using GNU (is anyone not?)?
>
> Use the old portability trick: read byte per byte and calculate the
> variables yourself.
>
But, isn't this a little slow?

> Please also note that with pack==1, you are generating unaligned accesses
> everytime you would access your structure. The structure must be packed
> like the CPU want it. You read one time from the file, but you access each
> variable many times (typically.)
>
Does this mean that I have to manually align variables at certain addresses 
or the filter will cause a CPU exception?  Because, it hasn't happened yet...
I thought that all #pragma pack(1) did was make sure that sizeof() gave the 
right answer because it doesn't pad data structures (please correct me if I'm 
wrong).

> > Also, is this portable:?
>
> No! Size of int is unknown (could be 64 bits). Packing is unknown (the int
> could be aligned at addresses that can divide by 8.)
>
> > FILE *filepointer;
> >
> > struct
> > {
> > 	int a;
> > 	int b;
> > } mystruct;
> >
> > fread (&mystruct, sizeof (int), 2, filepointer);
> > if (mystruct.a == some_magic_number)
> > 	do_something ();
> >
> > Will bit order affect the "mystruct.a == some_magic_number" test?
>
> If you have bit order problems, you would have very big problems! I
> therefore suppose that you mean byte.
>
Surely there is at least one platform (that KOffice runs on) that has a 
different bit order to Intel?  This could affect << and >> (shift) operations.

> Yes, your test will be affected. (For example: 0x5300 could become 0x0053.)
>
This could turn out to be bit of a nightmare...
Does anyone mind if I delay making the filter portable?

> If you want fully portable (non-QT) code, you would need something like
> reading four bytes and then calculate the two variables from them.
>
> Something like:
>
>  FILE *filepointer;
>
>  struct
>  {
>  	int a;
>  	int b;
>  } mystruct;
>
>  Q_INT8 helper[3];
>
>  fread (&helper, 1, 4, filepointer);
>  mystruct.a=helper[0]+256*helper[1];
>  mystruct.b=helper[2]+256*helper[3];
>  if (mystruct.a == some_magic_number)
>  	do_something ();
>
> Better use QT's QDataStream, like for example (not tested):
>
The problem is this: the mswrite import filter is sort of separate from the 
MSWriteLib library and this modularity enables me to write other filters for 
mswrite, instead of just KWord (e.g. mswrite->HTML).  MSWriteLib is written 
purely in standard C++ and I don't want to "contaminate" it with QT.  Does 
anyone have a way around this?

> I hope that I was able to help you a little.
It did!

Thanks!
Clarence

_______________________________________________
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]