[ale] C programming books

[Benjamin Scherrey]

Joseph Rattz Jr wrote:
> 
> > I recommend that you buy a C++ book instead and
> > learn that. There is
> > absolutely no reason to learn plain old C any more
> 
> I just have to make an issue out of this statement.  I
> am a C and C++ programmer and I am going to take a
> public stand and say that I think C is suprerior to
> C++ for most work, with the possible exception of GUI.

	Funny but I generally recommend people use Java, WEB, or some design
tool for a GUI. You're certainly welcome to your opinion but to make
an issue it helps to make a substantive claim in your point.

>  And that exception is only due to the nice class
> libraries that have been provided for free that could
> have easily existed for C, but didn't for some reason.

	Sure there are. Bunches of them. GNOME is based on a more recent one
and I've been using others since 1989.

> I have heard people say that C was bad because it was
> too complex due to the pointers and memory management
> required.  Well...C++ inproves on this?!?  Please!

	This is a straw tiger. I never said C was bad, just not appropriate
for most application development. Its purpose was to be a very
portable assembly language for writing system level code, something
which it excels at and is why linux and most gnu code uses C. Why
wasn't EMAC's scripting language C? Would have been easier than
writing the lisp interpreter at the time. Simply wasn't the
appropriate choice. It isn't in standard business applications either.

> I feel that in all the places I have worked only about
> 10% of the C programmers should have been allowed to
> touch the code.  The other 90% should have been
> fetching soft drinks or coffee.  

	Possibly true but definitely irrelevant to the subject at hand.

> And, make no mistake, C++ is far more complex.

	Only as complex as you need it to be. Certainly doesn't have to be
more complex than C and is often less so.

> Right now, I have inherited a C++ application that
> compiles clean, and runs.  The first time it runs, it
> core dumps.  The second time it runs, it produces
> output that is accepted as usable.  However, if I try
> to debug it, it causes a sig10 and core dumps the
> debugger (dbx) on program load.  So, I can't debug it.
>  BTW, we are talking Solaris 2.5.1, their C++ 4.2
> compiler, and something like version 11s of rogue wave
> I think.  The rogue wave seems to only be used for its
> stl. 

	So you've got a junk project with badly written code. Wow, *that*
never happens with C! :-) You're also using old compilers and a poorly
designed library. STL for RougeWave was an afterthought developed on
top of their own proprietary container classes which were never any
good to begin with. Sounds like you have tool problems not language
problems.

<more tool complaints snipped>

> Some syntax errors in my code cause the compiler to
> core dump.  Never had that happen in C on any platform
> I have used.

	Oh??? Try several versions of the M$oft C compiler as well as other
less popular ones. Many legal C constructs could break them.
 
> I have two books covering STL and they aren't the
> same.  The same basic example in the books has
> different syntax and slightly different methods, as I
> racall.  One works with my compiler, and the other
> doesn't.

	..now he complains about books..

	Since you don't give any examples I cannot be definitive but there
*are* many valid syntactical constructs in the STL thanx to its heavy
templating and generic/functional programming paradigm. Probably old
books or, more likely, old tools.
 
> A friend of mine was having a memory violation on an
> NT Server app written with VC++ 5.0.  I debugged it to
> a bug in the xstring header file.  There is a HUGE bug
> if you are using the string template where if you
> assign a smaller string literal to a stirng tamplate
> that once contained a larger string literal, it will
> violate memory.  I can;t believe a bug like this could
> exist in such a basic class that is used by so many.
> When I found the bug, my friend contacted customer
> support, and they had no official code fix.  Their
> official work-around was to assign an empty string to
> the template before assinging it to a bigger string.
> You had to do this every time you reassigned a value
> to the string!!!  However, he was dissatisfied with
> this and begged till they gave him an unofficial code
> fix.  When he got off the phone, he found it wouldn't
> even compile!  They actually called him bact to tell
> him they forgot to give him part of it.  Once he got
> it to compile, it still didn't fix the problem!  In
> the meantime, I had notice that PJ Plauger was listed
> as the author and had found his web site.  I
> corresponded with him through e-mail to find out that
> he was aware of the bug and had a corrected header
> file.  And, it worked!!!  Odd that MS didn't have it
> available!?

	Microsoft has never produced anything resembling an ANSI compliant
C++ compiler (much less C). Why do you insist on selecting the worst
development tools available? Jeepers - you're on a LINUX email list
claiming that C++ is bad because of a MICROSOFT compiler. I sorta
doubt this argument carries much credibility here.

	<more ranting snipped>

> Now, to bring this to an on topic point.  I am glad
> that at this point, most of Unix/Linux is C based, and
> I personally hope it stays that way.  It will be
> faster and more stable that way.

	C was the correct language to use at the time and probably still is.
Once the C++ standard grows more mature (and gets a standard ABI) then
you'll be hard pressed to find a C compiler that doesn't also happen
to be a C++ compiler. BTW... every major Linux vendor either has or is
switching to the egcs compiler which happens to be one of the most
ANSI compliant C++ compilers on the market. Perhaps you should upgrade
your tools as well because you failed to even claim a substantive
problem with the C++ language in your entire post. Just tool FUD.

	regards & later,

		Ben Scherrey