🚀 go-pugleaf

hamish@moffatt.nu (Hamish Moffatt) writes:

>In rmit.comp.sys.mac Luke Walshe <lw@yallara.cs.rmit.edu.au> wrote:
>> hamish@moffatt.nu (Hamish Moffatt) writes:
>>>1. Missing library functions
>>>unsigned char x;
>>>stream >> x;

>>>This won't link; >> operator is missing for unsigned char.
>> I know you have read into a char then assign to uchar.

>Confirmed by MW to be a library bug.

>>>3. Weird character problems; for example, something like
>> Support for the character type has always been ify in c++.
>> If you want chars treated like chars by iostream you have
>> to use char.  It will sometimes think uchar is a 8 bit int. 

>That's the effect I want -- "unsigned char" should be a byte;
>char might not be.

I don't know any implementation where char is > 8 bits.

>>>unsigned char a[4];
>> change this to char a[4];

>That helps, but doesn't fix it, and should work as is IMHO.

>> Hang in there with CW.  A few minor C++ lib quirks are nothing to get
>> excited about.

>They are basic library functions -- I don't think it is unreasonable
>to expect them to work out of the box :-( And minor they might be,
>but how else can I read free-format binary files? Streams are a nice
>interface because I should be able to use the same function to read
>both files and Windows resources (and hopefully Mac resources too);
>C I/O won't do that.

I agree this sort of thing is a major piss-off.

Anyway C++ iostream objects are too inefficient for binary files.
You could use block mode read/write calls like fread & fwrite straight 
to/from a uchar array.  

You have to use MacOS Resource Manager calls to read/write resources.  
But they are very easy too use. All this is done transparently for
UI objects like Windows/Dialogs/Scroll Bars etc.  

>Hamish

Luke.