[ale] C programming books

[Benjamin Scherrey]

Joseph Rattz Jr wrote:
> 
> > 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.
> 
> But, Ben that is THE problem.  I don't have the
> authority to change the tools at every company I do
> work for.  I am a contractor, and I have to use what
> they provide and are willing to pay for.  And, for the
> most part, they are what I have told you about.

	Reexamine your premise sir! :-) As a contractor (which I have been),
you have much greater authority than almost all the employees at that
company. The authority to say "No thanx" and go work somewhere else.
If you're a competent C++ developer, there's no end of high paying
contract work out there on just about every platform imaginable. I did
one contract where Visual C++ was the standard compiler. I simply
developed test cases for the bugs I found, submitted them to Microsoft
(where they were ignored, denied, or promised fixes in the next
release next year), demonstrated the problems didn't exist in another
available compiler (in this case Borland's) and told the company if
they wanted me to work on their product that they should invest in the
Borland compiler unless they preferred to subsidize my debugging
efforts for Microsoft. Given that the Borland compiler costs (way)
less than half a days work, they switched. If they hadn't I would have
has my resume available and been picked up by someone else within a
couple of weeks.

>  Part of the problem is that ANSI took too long deciding the
> standard, and now everyone had been doing their own
> thing for soooo long.  No, my STL books are both
> recently published.

	There are many who think the standard went too far too quickly. I
think they made decisions in some areas where there wasn't enough
practical experience and ignored some areas (the ABI) where a
leadership role clearly needed to be taken. STL differences between
what was originally proposed are minimal and all my early STL code
builds and runs correctly under the standard today. Recall how long it
took to get an ANSI C. C++ was much quicker in time scale.

> > not appropriate
> > for most application development. Its purpose was to
> > be a portable assembly language...
> 
> I feel exactly opposite.  I feel that C is better for
> most development, and that C++ is only better for
> things that the class libraries highly leverage and
> are not performance sensitive. 

	Well then you disagree with the K&R boys because that's their exact
stated intent.

> And again, this is
> only due to the class libraries that could be written
> in C.  If you are going to recommend the language just
> due to the productivity you gain by using a class
> library, then you also have to consider the negative
> impact of the bad class libraries that are also out
> there.  And one place I worked had that sort of thing.
>  They had C libraries that had container code, even
> code to move data structures to dialog boxes and
> vice-versa.  I would hate to use a server that is
> developed in C++, it WILL be about 5-10 times slower.

	OKay more FUD. And we're way too offtopic. The fact is that you're
just wrong here and you still haven't provided any evidence or even
specific allegations. "C++ overhead" has been thoroughly debunked for
all but the most extreme non-portable C constructs which are then
solved by the C++ keyword "asm" (which, I believe the new ANSI C
update intends to take on as well). Indeed, many times, thanx to
templates and operator overloading, C++ redeveloped applications show
significant increases in speed. I've done this for many a fine
developed C application ranging from large UNIX applications to
embedded systems.

> I am just compiling the declaration of a map, and the
> debugger core dumps.  How can I make it less complex?
> At it's least complex, it is C complex.

	Then you did it wrong or your compiler's broken. Has absolutely
nothing whatsoever to do with the language. Understand that and you'll
do fine...

	regards,

		Ben Scherrey

PS: Further inquiries should be taken to comp.lang.c++.moderated.