NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/alt/msdos/programm/3018

Internet Message Format | 1992-12-26 | 5.6 KB

Xref: sparky alt.msdos.programmer:3018 comp.os.msdos.programmer:11632 comp.sys.ibm.pc.programmer:680 comp.lang.c++:18437 comp.lang.c:18906
Path: sparky!uunet!wupost!emory!ogicse!sequent!muncher.sequent.com!furballs
From: [e-mail] (Paul Penrod)
Newsgroups: alt.msdos.programmer,comp.os.msdos.programmer,comp.sys.ibm.pc.programmer,comp.lang.c++,comp.lang.c
Subject: Re: Newbie Wants Advice on C-Programming
Message-ID: <[e-mail]>
Date: 27 Dec 92 01:25:36 GMT
Article-I.D.: sequent.1992Dec27.012536.7173
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (usenet )
Organization: Sequent Computer Systems, Inc.
Lines: 105
Nntp-Posting-Host: crg8.sequent.com

In article <[e-mail]> [e-mail] (Michael Malak) writes:
>In article <[e-mail]> [e-mail] (Wayne A. Christopher) writes:
>>In article <[e-mail]> [e-mail] (Michael Malak) writes:
>>> In my opinion, there is no fast track to either C or C++.  I feel the
>>> following must be learned in order:
>>>   1) Pascal, with two semesters experience
>>
>>IMHO, Pascal has nothing useful that C doesn't have, except for array
>>bounds checking.  You you use C++ you can use a vector class that
>>gives you that.
>
>Pascal has the following advantages over C:
>
>   1) It has structured syntactic blocks for constants, types and
>      variables.
>
>   2) It has nested procedures.
>
>   3) Most importantly, the good structured programming professors
>      wouldn't be caught dead teaching C (biggotry in my opinion).
>

Most of the structured programming professors I have had to suffer
with can't program. That's one of the reasons they wouldn't be
caught dead using C. C Presumes you already know what your doing.

>>
>>>   2) Assembly, learned anywhere, with tinkering on your own
>>
>>I'm not sure it's so important to really program in assembly.  You
>>should understand basic machine architecture, and have some idea of
>>what an instruction set looks like, but writing real code, especially
>>for a RISC, doesn't teach you all that much.
>
>It depends on what you mean by "writing real [assembly] code".  I think
>to learn anything you need to try it at least once.  The programming
>assignments in an assembly class would be sufficient, as would be
>trying a couple of exercises out of a tutorial book if one were
>learning it on his own.
>

Assembly gives one a very detailed view of things. It does not
matter what machine architecture you use. If you decide you really
want to undertand the basic inner workings of your machine and by
extension, how C deals with the underlying details, then by all
means learn assembly.

>>
>>>   3) C, 2-3 years min. anywhere (college, real world, or tinkering)
>>> After that you can learn and appreciate C++.  You need to first learn
>>> structured programming and algorithms, most importantly, linked lists
>>> and trees.  Since C is tightly coupled to assembly in many ways (C is a
>>> shorthand for assembly, and C integrates easily with assembly modules),
>>
>>Two point here.  First, you can start with a subset of C++ that is
>>close to C, but includes important things such as mandatory function
>>prototypes and flexible declaration positioning, and add classes and
>>other OO features gradually.  You don't have to jump into multiple
>>inheritance the first day.  There are plenty of ways that C++ improved
>>on C that don't add much conceptual complexity.
>
>Good point.
>

That depends. OOP is not for everyone, and especially if you are
trying to understand your machine architecture. Systems people have
very little use for container classes that are nothing more than
reusable code for disposable programmers. Applications people will
find more usuability out of OOP. However, understand that OOP can
be done just as effectively in C as in C++. The trick is proper use
of structures and the understanding of data manipulation under C.
C++ hides much of the dirty work of how this is accomplished. While
it might make for pretty code, I consider it a serious detriment to
the development of a programmer's skills towards their peak
ability.

Also C++ suffers from mulitple inheritance and polymorphism, which
causes undue replication of code, from a compiler point of view.

>>
>>Second, it's not right to call C "shorthand for assembly".  One thing
>>you can say about C and C++ is that it discourages language features
>>that can't be implemented at compile time, but that doesn't make it
>>any closer to assembly than any other compiled language.  And most
>>languages "integrate easily with assembly modules", simply because
>>that's what compilers produce.
>
>BASIC, LISP, and all the other interpretive languages do not integrate
>with assembly.  And on many platforms other than MS-DOS you cannot mix
>(link) outputs from different compilers.  All in all, most languages on
>most platforms do not mix well with assembly.  I know of no C compiler
>that cannot link in assembly modules; I cannot say the same for any
>other language.
>

If your going to be in the MS-DOS environment. Learn your C first.
Then worry about integrating assembly calls. Almost all languages I
am aware of under MS-DOS allow for this. Learn the basics first.
The rest will be there when you are ready for it.

--
--------------------------------------------------------------------
            Bureaucracy: noun, plural - Bureaucracies.
         The process of turning energy into solid waste.
---------------------------------------------------------------------