[comp.sys.mac.programmer] ANSI vs. THINK. Help!

swynne@decoy.uoregon.edu (Stephen Wynne) (02/10/91)

As a beginning self-taught C programming student, can anyone tell me
the difference between K&R C, ANSI C and, C++; and how that relates to
THINK C.  I --uhhhhh-- THINK it's not compatible with ANSI. is that
true? Any details would be helpful!

REPLY TO: swynne@oregon.uoregon.edu 
(Stephen Wynne, Consulting Reception)  

perry@key.COM (Perry The Cynic) (02/12/91)

In article <SWYNNE.91Feb9230636@decoy.uoregon.edu> swynne@decoy.uoregon.edu (Stephen Wynne) writes:
> As a beginning self-taught C programming student, can anyone tell me
> the difference between K&R C, ANSI C and, C++; and how that relates to
> THINK C.  I --uhhhhh-- THINK it's not compatible with ANSI. is that
> true? Any details would be helpful!

Okay, very briefly. K&R (Kernigham & Richie) C is the original article. The
K&R term usually refers to the book "The C Programming Language" by those
two luminaries, which includes a "new features" appendix that should be
considered part of the language. This is the C language that used to be
(more or less) standard on UNIX. Any real UNIX system (no flames please)
out there is (or can be made) compatible to this. Today, K&R C forms the
"least common denominator" language for C compilers, if you're just a bit
careful about how you write your code.

ANSI C is the C language standard. It's the result of trying to clean up K&R C
without causing too many compatibility problems. You can read the ANSI standard
document. CAUTION: reading ANSI standard documents may cause disorientation
and/or nausea. The major enhancements of ANSI C over K&R are:
  - Prototypes (strong type checking of arguments)
  - "const" and "volatile" qualifiers
  - a cleaned-up and standardized C library with corresponding header files
  - (IMnsHO) questionable international support
ANSI C is "almost" upward compatible from K&R C. That means that there is a
set of "questionable usages" in K&R C that are not guaranteed to work in
ANSI C. Quite often they work anyway, since compiler writers are not total
idiots. (Usually. No guarantees.)

C++ is Bjarne Stroustroup's extension of the C language into the realms of
object orientation, stronger typing, and many other goodies. It's an attempt
to remedy the weaknesses of C without abandonning compatibility. C++ is
currently effectively defined by the book "The Annotated C++ Reference Manual"
by Ellis & Stroustroup (usually called the ARM). The C++ standard is "evolving",
which means they are still changing it and adding goodies. The core language
is pretty stable though. Some highlights are (this is NOT complete):
  - "class" types to implement object orientation
  - polymorphism, including multiple inheritance
  - function and operator overloading
  - implicit user-defined conversions
  - implicit programmer-controlled initialization and termination
	of class variables, and of variable memory allocation
  and, currently being added and debated,
  - exception handling
  - templates (meta-types)
C++ is "almost" upward compatible from ANSI C (does this start to sound
familiar?). The "learning gap" from ANSI C to C++ is considerable. I think
it's worth while.

THINK C is a sort-of almost ANSI-C compatible compiler with proprietary object
features reminiscent of Object Pascal, trying to look superficially like C++.
Missing from the ANSI C standard are mainly the "const" and "volatile" features,
for no reason I can see. You can fix most of that problem by #defining
these words to nothing; the compiler is not good enough to need "volatile"
anyway.
Don't think for a moment that THINK C (V 4.x) is C++; it isn't, and I have
it on good authority (people from Symantec) that its creators despise the
C++ language and don't intend to implement it until the market (us) force
them to. They have their own object system and library that is Macintosh
specific. In short, they do their own thing.

From my (personal, subjective, unofficial... okay?) point of view, ANSI C
is the language to use for "current" C programming. K&R C makes it very easy
to write bug-riddled programs that just happen to run until the day after
shipment; ANSI C's prototypes help a lot there. Properly used, "const" can
add a lot of meaning (and compiler checking) to a C program. It's also a lot
more portable, because ANSI C defines header files and library interfaces.
Almost everybody has an ANSI C compiler by now, and there are (public domain)
converters that can turn an ANSI C source file into a K&R digestible form.

I love C++. Other people hate it. It's hard to get an objective discussion
going on that, and I'd rather not start a flame war. For better or worse,
C++ is beginning to catch on, both in the UNIX world (AT&T System V.4 has
parts written in it) and on Micros (MacApp is currently being rewritten
in C++, and there's a good "Turbo C++" for the IBM PC).
The "learning curve" from ANSI C to C++ is considerable. In fact, I could
make a point that the programmer's mindset needed is substantially different
for the two languages. While most ANSI C programs *are* valid C++ programs,
it usually requires redesign to make use of the salient C++ features.
In my (hopeful) opinion, C++ is the language of the "near future" (2-5 years).
ANSI C is "here right now, to stay."

Did that help? Well, I tried. Feel free to add information. Constrain flames
to mail, please. Thanks a lot
  -- perry
-- 
--------------------------------------------------------------------------
Perry The Cynic (Peter Kiehtreiber)		       perry@arkon.key.com
** What good signature isn't taken yet? **  {amdahl,sgi,pacbell}!key!perry

rxcjm@minyos.xx.rmit.oz.au (John Mazzocchi) (02/12/91)

swynne@decoy.uoregon.edu (Stephen Wynne) writes:

>As a beginning self-taught C programming student, can anyone tell me
>the difference between K&R C, ANSI C and, C++; and how that relates to
>THINK C.  I --uhhhhh-- THINK it's not compatible with ANSI. is that
>true? Any details would be helpful!

Think C 4.0 IS ANSI-compatible, Think C 3.0 isn't.
-- 
+ John Mazzocchi              +   "The mind is not a vessel to be filled, +  
+ Melbourne, Victoria         +    but a fire to be lighted" - Plutarch   +
+ Australia                   +                                      
+ rxcjm@minyos.xx.rmit.oz.au  +