backstro@silver.bacs.indiana.edu (02/02/88)
After wading through several C books, and feeling completely
lost, a book entitled "LEARNING C programming GRAPHICS on the AMIGA and
ATARI ST" really caught my eye. Here was a book that got into
the interesting stuff right in the begining - to keep the readers
interest, while still being simple enough for someone who in
the past has basically just spoken several dialects of basic to understand
whats going on (yes, I know I should have learned PASCAL or something
of the sort before leaping into C...a bit late for that now...).
After typing in the program "machine.c" (the machine specific program
which allows you to run the programs in the book on the ST or Amiga simply
by linking the program to the end of any of your programs), I attempted
to compile it. I was surprised that very few erros were encountered.
After about 10 minutes all but one of these errors was fixed (typos..the
program in the book is HOPEFULLY fine). Then ensued my 6 hour long
battle with that ONE line! For some reason I just couldn't figure
out what is wrong with it. The line is 95, and it is a "{"...its in
the function "exit_graphics". I tried all kinds of things - including
checking the syntax of the entire program a couple times. I searched
out every occurance of the "exit_graphics" function, and all seemed fine.
Although I can't remember the exact error, it was something
to do with "external object mismatch error".
I somehow got the idea of replacing every occurance of "exit_graphics"
with "quit_graphics", and strangly enough the program compiled correctly.
Unfortunatly it still would not work...
Anyway, I am going to send off my $16.00 to get the programs in the book
on a disk tommorow, but I would really like to continue learning C....
Is there ANY chance someone could mail me the Amiga version
of "machine.c" in the above mentioned book - published by Compute?
The book won't be here for 4-5 weeks, and I really want to dig into the
C! I also have Rob Peck's book, but I am planning on using that
once I have finished this book...(and I WILL send my money in for the
disk for Peck's book...I just don't need it yet, and I'm real short on
cash...)
Thanks!!
My dreams, they are as empty
as my conscience seems to be... -The Whocmcmanis%pepper@Sun.COM (Chuck McManis) (02/03/88)
In article <18700021@silver> backstro@silver.bacs.indiana.edu writes: > ... Then ensued my 6 hour long >battle with that ONE line! For some reason I just couldn't figure >out what is wrong with it. The line is 95, and it is a "{"...its in >the function "exit_graphics"... >Although I can't remember the exact error, it was something >to do with "external object mismatch error". Ok, a little bit of C lore, and then the answer to your question/problem. When C was written, it was considered a neat feature that if you didn't declare a variable or a function it was *automatically* assumed to be either an int or a function returning an int. Unfortunately, that does not allow for very many optimizations. And it makes the compiler jump through hoops when you really meant it to return a pointer to structure or whatever. In either event the way Lattice works, is that the first occurrence of the function name 'types' it and subsequent uses of the function are compared against that type. When the declaration of the function appears and it has a different type than what the compiler was assuming was the type, you get the error External Attribute Mismatch. The solution is to make sure that the function is declared correctly the first time the compiler sees it. You can do this by either making the function declaration come before the first use of the function or you can 'forward' declare it. For example void main() { some_funtion(); exit(0); } void some_function() { printf("This is some function!\n"); return; } Will return External Attribute mismatch because some_function() was assumed to return an int, and when the declaration was found it turns out not to return anything at all. Two solutions are possible, the first is to use a type declaration for some_function as follows : void some_function(); /* This declares this function has a type of void */ void main() { some_function(); exit(0); } void some_function() { ... } Or you could re-order the source code to look like this : void some_function() /* first occurence types it. */ { ... } void main() { some_function(); exit(0); } The other common error you will be informed about by the Lattice compiler is the 'return value mismatch'. This occurs when the return value does not match the type of the function. For instance if you declared some_function() as having a type of void and return 0 then you have a return item mismatch. Similarly if you type the function to return a pointer to an int and you return an int, the same thing happens. Note that return with no argument is equivalent to return (void) and your function should be typed as void if you don't return anything. Ok, that's the C lesson for today, --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.