🚀 go-pugleaf

In rmit.comp.sys.mac Hamish Moffatt <hamish@moffatt.nu> wrote:
: anyway (to help with the GUI design on Windows) but need to get this thing
: running on the Mac eventually anyway. Can someone convince me to "hang in 
: there" with CW, or suggest another compiler?

  I've been using Symantec C/C++ v8.0 for a couple of years, just
writing small programs, and I haven't had major problems, except
sometimes the project files get corrupted and I get lots of linker
errors.  Also, when I write bytes to a file using iostream functions
(as opposed to stdio), it seems to forget to write the type / creator
information into the file, so that I have to edit these with ResEdit in
order for a text editor to read my output.  I'm not sure if Symantec
still produce compilers for Mac, they may have given up.
  Another option you could investigate is Apple's MPW (Macintosh
Programmer's Workshop), which apparently has a UNIX-style shell
interface, with makefiles etc. and highly optimised compilers MrC and
MrC++, which are supposed to generate faster code than CodeWarrior.
  Here's a URL you might find useful:

    http://developer.apple.com/dev/tools/tools.shtml

  There's other good stuff besides MPW here such as MacApp, which is a
C++ class library used as the basis for applications such as Photoshop.
Happy hacking!

	Vaughan :-)

hamish@moffatt.nu (Hamish Moffatt) writes:

>I've been doing quite a lot of CodeWarrior development lately (on my PC,
>because the Mac is too slow and not on my desk). And in the process I've
>found quite a few bugs/errors/etc (confirmed by MetroWerks). Here's
>the short list:

>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.

>2. Compiler/template library problems where you have to use
>__MSL_FIX_ITERATORS__ to work around compiler bugs. Otherwise
>some STL classes, like priority_queue in <queue.h>, won't compile.

>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. 

>unsigned char a[4];

change this to char a[4];

>int i, j;
>for (i = 0; i < 4; i++) {
>    stream.get(a[i]);  // should be stream >> a[i] but see above!
>}
>j = (a[0] << 24) | (a[1] << 16) | (a[2] << 8) | a[3];

Logical OR will work the same with signed/unsigned types.

>does not seem to work properly (j ends up with 0 instead of the correct
>value). MetroWerks suggestion was to change it to a char array and turn on
>"Use unsigned chars" in the options instead. This seems to fix this particular
>problem, but still my code does not run properly -- but the exact same
>source runs fine on GNU g++ and Solaris CC.

>4. Right now, my program gets a lot further in the debugger than it
>does in a non-debug build. The latter seems to hang in one place and chew
>a LOT of CPU time.

Can't help you, could be anything. 

>I find all this to be incredible because as I understand it, CW Pro 3 is
>something like the 14th version of the compiler? Even if it's only version
>3, how can it contain missing library functions and buggy ones too?

CW Pro 3 x86 is a good compiler.  I can't really tell you anything
about the C++ library.  I don't use it. (to buggy).     

>I'm at a loss as to what do. I have Visual C++ 5.0 here waiting to be installed
>anyway (to help with the GUI design on Windows) but need to get this thing
>running on the Mac eventually anyway. Can someone convince me to "hang in 
>there" with CW, or suggest another compiler?

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

>thanks,
>Hamish

Luke.

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.

>>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.


Hamish
-- 
Hamish Moffatt, StudIEAust              hamish@debian.org, hamish@moffatt.nu
Student, computer science & computer systems engineering.    4th year, RMIT.
http://hamish.home.ml.org/ (PGP key here)             CPOM: [*******   ] 71%
Nondeterminism means never having to say you are wrong.

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.

In rmit.comp.sys.mac Luke Walshe <lw@yallara.cs.rmit.edu.au> wrote:
>>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.

I think it's defined to always by 8 bits; I assume that it could
be signed though, which is why you can explicitly state it. The CW option
"chars are always unsigned" is a confusing one, then.

> 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.  

I will try this.


thanks,
Hamish
-- 
Hamish Moffatt, StudIEAust              hamish@debian.org, hamish@moffatt.nu
Student, computer science & computer systems engineering.    4th year, RMIT.
http://hamish.home.ml.org/ (PGP key here)             CPOM: [*******   ] 71%
Nondeterminism means never having to say you are wrong.

In rmit.comp.sys.mac Hamish Moffatt <hamish@moffatt.nu> wrote:
>> 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.  

> I will try this.

I changed the PC code to use C I/O (fgetc, fread etc) and it works perfectly.
Unbelievable.


Hamish
-- 
Hamish Moffatt, StudIEAust              hamish@debian.org, hamish@moffatt.nu
Student, computer science & computer systems engineering.    4th year, RMIT.
http://hamish.home.ml.org/ (PGP key here)             CPOM: [*******   ] 71%
Nondeterminism means never having to say you are wrong.

hamish@moffatt.nu (Hamish Moffatt) writes:

>In rmit.comp.sys.mac Luke Walshe <lw@yallara.cs.rmit.edu.au> wrote:
>>>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.

>I think it's defined to always by 8 bits; I assume that it could
>be signed though, which is why you can explicitly state it. The CW option
>"chars are always unsigned" is a confusing one, then.

I thought the ANSI C standard defined sizeof char == 1 'byte'
and the number of bits in 1 'byte' to be equal the number of bits
need for a char.


--
Hartley's Second Law:
        Never sleep with anyone crazier than yourself.

hamish@moffatt.nu (Hamish Moffatt) writes:

>In rmit.comp.sys.mac Hamish Moffatt <hamish@moffatt.nu> wrote:
>>> 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.  

>> I will try this.

>I changed the PC code to use C I/O (fgetc, fread etc) and it works perfectly.
>Unbelievable.

I believe it.

Also don't forget that Mac is bigended.  So when you are internalising 
PC shorts,ints and longs you have to swap bytes.

>Hamish

Luke.

In rmit.comp.sys.mac Luke Walshe <lw@yallara.cs.rmit.edu.au> wrote:
> Also don't forget that Mac is bigended.  So when you are internalising 
> PC shorts,ints and longs you have to swap bytes.

That's ok, the files I am having trouble with are byte-oriented anyway.
They even use variable-length numbers by only using 7 bits and using the
8th to indicate whether it is the final byte or not.


Hamish
-- 
Hamish Moffatt, StudIEAust              hamish@debian.org, hamish@moffatt.nu
Student, computer science & computer systems engineering.    4th year, RMIT.
http://hamish.home.ml.org/ (PGP key here)             CPOM: [*******   ] 71%
Matter cannot be created or destroyed, nor returned without a receipt.