#New C Programer
14 messages in this thread
All,
Hello,
I'm going to start teaching myself how to program in C on the Amiga and I'm
hoping to get some good pointers from ya all. I'm in process of getting SAS C
used or new if I can not get it used. I already have a place to get SAS C
shrink wrapped if I'm willing to spend $120.00. Which I am, but I'd rather go
the used route< cheapness:) > What books can you recommend? I'm really at
home with the Amiga OS, at least from a user's point of view.:) I know about
the need to have the .include files and I'm sure to get them. Just some basic
information would be nice.
Dwayne J. Bathke
>> I'm going to start teaching myself how to program in C…
>> .. and I'm hoping to get some good pointers…
Gosh, allow me a quite chuckle on the wording. A good part of getting used
to the C language is learning how to cope with pointers; pointers to data,
pointers to strings, pointers to other pointers… Indeed, I often think that
many beginners throw up their hands when they meet a pointer to an array of
pointers, each of which points to a structure contining pointers. It takes a
certain type of mind to keep track of how many levels you need to track to get
the to actual stuff you want. 🙂
The C language takes a certain mindset, which is hard for some. In general,
what you're writing is a subroutine which is called in by a mess of canned code
attached to your program. Except we don't call it a subroutine in C, it's
really a procedure, except that it returns a value (the return code status),
which might make it a function. And that doesn't really matter much, since
procedures are really the same as functions, even if they return nothing
("void"). And they tend to use LOTS of pointers. <g>
Please don't let the last paragraph scare you off. You'll just need to get
your mind around some new concepts.
Thought: C IS REALLY TWO DISTINCT LANGUAGES.
Language 1: "Traditional C" is something that you'll find described in lots
of books. (I like "C PRIMER PLUS", by the Waite Group). Like any traditional
computer system, you do input/output with traditional devices (the console),
and handle files with standard fopen() type commands. Programs written in
language 1 are highly portanble, since they don't tap any of the unique
features of the Amiga operating system.
Language 2: "Targeted C" goes for the whole rich paraphenalia of the Amiga:
the windows, screens, gadgets, requesters; the whole bag. Today, it's much
easier to code this for 2.0 systems because of the new libraries (ASL and
GADTOOLS) and also because of extensions to existing libs. But it's not easy
to find books dealing with thing style of C. Suggestions, anyone?
–Jim
>A good part of getting used to the C language is learning how to cope with
>pointers
Very true. And something every C programmer should master.
Equally though, I rather tend to not consider it a "good part" but just
another part of the deal. Surely, vast quantities of C code can be
written w/o any (explicit) pointers at all (this is less a suggestion than
letting people stick with the current corners of the language that are
known to them, appropriate, etc expecting the rest to subsequently
materialize when applicable). IOW, I consider C, or any language,
a package to deal with. Yes, though, each does have their set of
gotchas and wackos, and in C, many problems do surround pointers.
Anyway, on another frame of reference: the thought process, approach,
insights, etc, of the problem, and its solutions, is often lost in
language, OS, editor, problem and issues. It is this I always try
to instill into folks when I teach or write.
>It takes a certain type of mind to keep track of how many levels you
>need to track to get the to actual stuff you want. 🙂
Yes, this is the killer kind of issue from above. Figure the danged thing
out first. Far to many get (artificially) bottlenecked with the notation
(this is not to say it isn't a genuine issue, but is something that should
be besides the point).
>The C language takes a certain mindset, which is hard for some. In general,
>what you're writing is a subroutine which is called in by a mess of canned code
>attached to your program.
If I understand what you mean, this is not anything specific just to C.
> Thought: C IS REALLY TWO DISTINCT LANGUAGES.
> Language 1: "Traditional C" is something that you'll find described in lots
>of books…
> Language 2: "Targeted C" goes for the whole rich paraphenalia of the Amiga:
That's not two distinct languages. It's the exact same language being used
in different contexts. In the latter case we're simply talking about the
same C using API's et al for the Amiga. Nothing in C changes.
(BTW, "Traditional C" usually connotates "K&R C". It's better to keep it
that way to distinguish it from "Standard C", the ISO/ANSI C.)
Greg,
Hello,
I am learning a lot of GOOD "Building Blocks" from following the flow of
words between you and Jim!
What language would you suggest a New Programmer start to learn? The choices
are really almost endless.
IMHO, the language of choice for the Amiga platform is "C". I understand what
you give up by using "C", I.E., speed, size of executable file, learning the
"quirks" of each different compiler, to name a few.
But the advantages of "C" are not bad at all, I.E., large base of code,
libraries, portable, and the most important to me, the large amount of people
to gain insights/pitfalls, maybe?
Dwayne J. Bathke
>> I understand what you give up by using C, i.e., speed, size of executable
file …
You don't give up that much. C is quite efficient, and compiles into fast
code. There are also ways of arraging to trim out much of the "canned code"
(I'm referring to c.o and some of the stuff it invokes) if you're familiar with
your C compiler's environment.
Assembler coding is always faster and more compact .. IF YOU'RE AN EXCELLENT
PROGRAMMER. But some optimizing C compilers can put out code that's as compact
and efficient as many (not all) programmers would write.
–Jim
> You don't give up that much. C is quite efficient, and compiles into fast
>code. There are also ways of arraging to trim out much of the "canned code"
>(I'm referring to c.o and some of the stuff it invokes) if you're familiar with
>your C compiler's environment.
For instance, Jim is referring to code that might do behind the scenes
start-up stuff, for instance, command argument processing.
There are also other things that can be done with the canned stuff
(for instance, bringing in a printf that doesn't use floating point, etc).
Equally, I think it is important to agree that in general, the "expense" of
things like start-up code, or printf, is quickly insignificant for any
non-trivial application. And when say bloat is a concern, say when ROMing,
or trying to squeeze a product onto a floppy or something, options are
available.
>Assembler coding is always faster and more compact .. IF YOU'RE AN EXCELLENT
>PROGRAMMER. But some optimizing C compilers can put out code that's as compact
>and efficient as many (not all) programmers would write.
I think that's an overstatement. I'd rather just say that most compilers,
even the non-optimizing ones, can put out good enough code. In case where
it matters, yes, the optimizer can help. In cases where it cannot, it is
still up to the programmer. Perhaps the programmer was just sloppy in
allocating too many arrays, and their respective sizes, for instance
(and hence many opt for dynamic allocation with the known size, etc).
As well, instead of second guessing, the programmers should obtain a
profiler and check out where their app might be being bottlenecked and work
from there. Etc.
>What language would you suggest a New Programmer start to learn? The choices
>are really almost endless.
Frankly, I think the choices are endless. I'm much more concerned about a
new programmer learning/knowing how to think, weight, consider, research,
sweat, etc, than what size paintbrush or hammer they have. Too much common
wisdom recommends Pascal as "the teaching language", and although I
understand why this is said, I think it is somewhat a misguide.
Although Pascal is a small enough and safe enough language, as per above,
the real issue at hand is in designing and thinking properly.
There are also real world issues like where the market is, what the
persons interests and goals might be, etc. It is also more important to me
that folks turn to the better training material and mechanisms.
>IMHO, the language of choice for the Amiga platform is "C".
No doubt.
>I understand what you give up by using "C", I.E., speed, size of executable
>file, learning the "quirks" of each different compiler, to name a few.
No sure what you mean re giving these things up. Sure, certain feature or
library routines have associated costs, but don't they all in most HLLs?
What C-based language give you re these things is that in C, you don't pay
for what you don't use, you can get low level when you want, etc, hence,
there is no great speed or size disadvantage to using C. And in fact, since
C is so popular, compilers (albeit with quirks, just like for any language)
are reasonable about avoiding silly code bloat and such things.
>But the advantages of "C" are not bad at all, I.E., large base of code,
>libraries, portable, and the most important to me, the large amount of people
>to gain insights/pitfalls, maybe?
Don't get me wrong, I'm very much into C and C++. I have no problem
recommending C as a first language. As with everything, be wise.
>> "Traditional C" usually connotes K&R C ..
OK, would you go for "generic C"?
I was trying to address the original question, "What's a good book from which
to learn C?". The problem as I see it is that most books stay strictly with
"generic" code: level 2 file commands such as fopen(), fclose(); ANSI
functions such as malloc() to allocate memory without distinguishing between
chip and fast memory, or the whole printf() puts() getchar() style of
input/output.
So .. the user buys one of these books and then tries to use it to read some
of the C source code posted on the Fish disks. Much of that code never touches
the above-named functions; instead it dives directly into Amiga library
functions, which are unlikely to be documented in the C compiler manual. Seems
to me the user needs a broad hint that open() and Open() are completely
different calls. The first is a level 1 file open function that was adopted
from Unix usage; the second is an Amiga DOS library call, not covered by the "I
Learned C In 30 Days" book.
I had thought it would be useful to point out that the language is used in
two radically different styles, so as to help the user when he encounters
unfamiliar code. Perhaps you disagree.
Perhpas you might like to adress the original question, about a good book
from which to learn C? I'm certainly hard put to name a text that will take
you gently into the Amiga's environment.
–Jim
Hi Guys.
I'm new here, too, but have a suggestion.
>> Perhpas you might like to adress the original question, about a good book
from which to learn C? I'm certainly hard put to name a text that will
take you gently into the Amiga's environment.
I've been trying to lear C myself – just not enough time. Anyway, I've been
going through Abacus' book _Amiga C for Beginners_. I also have the _Amiga C
for Advanced Programmers_ but haven't gotten that far, yet.
They're both circa 1990 – just a little out of date – but have specific
examples and explanations, including the "Hello" program that EVERYONE writes
on EVERY platform. They also include the compiling and linking commands for
Lattice (told you they were old) and Aztec compilers.
There may be updated printings for these, but I haven't had time to check. Good
luck to (I can't remember the originator of this thread).
Wolf Pup
<<There may be updated printings for these, but I haven't had time to check.>>
These were the lastest book published by Abacus. The only cover 1.2 and 1.3 of
the os and have NO material on os 2.0 and above.
Stew
> These were the lastest book published by Abacus. The only cover 1.2
and 1.3 of the os and have NO material on os 2.0 and above.
That's what I thought, but they are good _Starter_ books. They teach the
basics of variables, includes, pointers, functions, etc. And they have decent
tutorials and examples. I figured using these was the best way to start.
Thanks for the info…
/\
: >
/ :
/ /::
/ / ::
/ / ::
—-==== ::
>> "Traditional C" usually connotes K&R C ..
>OK, would you go for "generic C"?
No, that has different connotations, and believe it is also a product name
:-(.
>I was trying to address the original question, "What's a good book from which
>to learn C?". The problem as I see it is that most books stay strictly with
>"generic" code:
Yes, agreed.
A book on C should stay compiler and OS neutral.
A book on C for X (say where X is AmigaDOS) should be where any
variations, APIs, etc, are delved into.
> level 2 file commands such as fopen(), fclose(); ANSI
>functions such as malloc() to allocate memory without distinguishing between
>chip and fast memory, or the whole printf() puts() getchar() style of
>input/output.
Right (though the heritage varies, they're all ANSI functions now BTW)
>So .. the user buys one of these books and then tries to use it to read some
>of the C source code posted on the Fish disks.
Right, and is completely lost _on the calls_. C remains exactly the same,
it the AmigaDOS API's and library calls that are the difference.
Struct and switch statements and everything remains the same though.
Yes though too, extensive use of Amiga specific calls also has its
idioms and conventions and such, and so it is good to know about this too.
Ditto for say using C with MS-Windows, etc. And respective literature on
those things that transend the language are great when available.
>Much of that code never touches the above-named functions;
No doubt.
> instead it dives directly into Amiga library
>functions, which are unlikely to be documented in the C compiler manual.
True, but they are documented in the respective Amiga manuals.
> Seems
>to me the user needs a broad hint that open() and Open() are completely
>different calls.
This is where the OS and compiler vendor are supposed to come into play
and I think have.
> The first is a level 1 file open function that was adopted
>from Unix usage; the second is an Amiga DOS library call,
>not covered by the "I Learned C In 30 Days" book.
True. And I don't trust learning any language in 30 days! 😉
>I had thought it would be useful to point out that the language is used in
>two radically different styles, so as to help the user when he encounters
>unfamiliar code. Perhaps you disagree.
I was just disagreeing with a technical idiosyncrasy.
I very much agree with your elaboration and your gestures to help.
>Perhpas you might like to adress the original question, about a good book
>from which to learn C?
Sure:
(1) "The C Programming Language", 2nd ed, Kernighan and Ritchie
(2) "Learning to Program in C" by Thomas Plum.
(3) "Programming in ANSI C" by Steve Kochan
(4) "Waite Groups New C Primer Plus" by Stephen Prata
There are others, but these are reasonable starting points.
Note: I recommend them all, not just one.
>I'm certainly hard put to name a text that will take
>you gently into the Amiga's environment.
I don't pretend to be an Amiga expert, so will waive this one.
Seems to me though that Cybex has some C books, which when I last looked
(5 years ago) seems quite poor. Nonetheless, isn't this what the RKM's are
about?
>>I'm certainly hard put to name a text that will take >>you gently into the
Amiga's environment.
Try "Mastering Amiga C" by Paul Overaa, Bruce Smith Books. It isn't too bad,
and starts at a fairly low level.
The key is here, to concentrate on "C" first. Learn ANSI C with ANSI C
funstions, and get to know them well, before you plunge into Amiga C. At that
point I think the RKMs can be very helpful. They are not written just for the
advanced programmer, you just have to know C first before you dive in.
Another note: ANSI, UNIX funtions are all small letters. If there is a
capital letter in the function it is AmigaDOS (or one you made up.).
>The key is here, to concentrate on "C" first. Learn ANSI C with ANSI C
>funstions, and get to know them well, before you plunge into Amiga C.
I couldn't agree more.