Xref: utzoo comp.lang.c:27820 comp.lang.c++:7178 comp.lang.misc:4856
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!sp20.csrd.uiuc.edu!davies
From: davies@sp20.csrd.uiuc.edu (James R. B. Davies)
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.misc
Subject: Re: what is c++, c, ansi c etc...
Message-ID: <1990Apr12.214718.18545@ux1.cso.uiuc.edu>
Date: 12 Apr 90 21:47:18 GMT
References: <DAVIS.90Apr6151002@muscle.pacific.mps.ohio-state.edu> <6000:Apr720:31:1490@stealth.acf.nyu.edu> <28742@cup.portal.com> <539@tmiuv0.uucp>
Sender: usenet@ux1.cso.uiuc.edu (News)
Reply-To: davies@uicsrd.csrd.uiuc.edu
Distribution: usa
Organization: University of Illinois Center for Supercomputing Research and Development
Lines: 68


In article <539@tmiuv0.uucp>, rick@tmiuv0.uucp writes:

|> The best "thumbnail" sketch of OOPS (Object Oriented Programming Systems) I
|> can offer is that your programming style (well, actually your problem
solving
|> style) changes.  Currently, C causes you to think "procedure-wise". 
In other
|> words, you think about _how_ to solve the problem, writing a list of
procedures
|> that will accomplish the task.  This involves how to manipulate the data
|> objects you're playing with at each step of the way.
|> 
|> In C++, the OOPS version of C, you think "solution-wise".  You simply write
|> code which treats your data objects as though they were standard C variable
|> types.  You don't have to worry about "Gee, now, if I want to add these two
|> structures, I have to add each member of one to the corresponding member of
|> the other" and write the code to do that each time.  Instead, you simply say
|> "c = a + b", where a, b, and c are the structures you are playing
with.  Later
|> on, you write a "data abstraction" which defines what the structures
look like,
|> a set of functions and operators which perform the operations on the
data, and
|> which parts of the structures are visible to the outside world.  Once that's
|> done, your code is much more readable, since you're not writing "c.mem1 =
|> a.mem1 + b.mem1;", just "c = a + b".
|> 
|> That's simplifying it a bit, but the general idea is correct.
|> 
|> C++ can really make some nasty and complex code a heck of a lot
easier to deal
|> with.
|> 

Well, I for one don't always write the absolute lowest-level inline-est
code possible when using ANY language.  My first impulse when I want to
copy one string to another isn't to think "Gee, now, if I want to copy
one string to another, I have to move each byte of the first string to
the corresponding byte of the second string" and then write

   register char *cp1,*cp2; 
   for (cp1=string1,cp2=string2;*cp1;cp1++,cp2++) *cp2 = *cp1;
   *cp2 = '\0';

Instead I write

   strcpy(string2,string1);

Admittedly, it might be nice to just write

   string2 = string1;

but I'm comfortable with function calls instead of operator overloading.

What you're describing used to be called "information hiding" and
"modularity" and "reusability" and maybe "functional decomposition"
and probably "structured programming".

The argument about "C makes you think of methods" versus "C++ makes you
think of objects" is a rehash of an old claim by the function-language
crowd.  I've seen little evidence that it has any validity among trained,
experienced programmers - they can write in any language successfully.
And, as it has oft been stated, it is possible to write bad code in
any language (even C++).

All in all, I tend to agree with Mr.  Bernstein - the same old
stuff using some new words.