Re: c++ documentation
From: Daniel James (wastebasket_at_nospam.aaisp.org)
Date: 05/18/05
- Next message: Russell Shaw: "Re: c++ documentation"
- Previous message: gold+ares+REMOVE-IT_at_gmail.com.invalid: "how to use specific context before thread switch"
- In reply to: Last2Know: "Re: c++ documentation"
- Next in thread: Russell Shaw: "Re: c++ documentation"
- Reply: Russell Shaw: "Re: c++ documentation"
- Reply: Last2Know: "Re: c++ documentation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 18 May 2005 13:22:44 +0100
In article news:<pan.2005.05.17.14.41.56.524642@yahoo.com>, Last2Know
wrote:
> In this thread I'm explicitly asking about the existence
> of complete alternatives.
Alternatives to understanding how the language maps onto the metal? The
alternative is not knowing, and being a less good programmer. Many people
get through their professional lives this way (and it sometimes makes me
weep).
I've agreed with you all along that knowing the metal-interface is
important for an advanced understanding of the language. I just don't
think it needs to be understood by beginners.
> Several aspects of C++ feel like they were designed by someone
> who hardly even thought about linkers.
I'm sure Bjarne says something about linking in /Designand Evolution/ (I
don't have it with me right now) ... probably just that when designing C++
he wanted to be able to use existing linkers and so shoehorned the
compiler's operation into the mould of the existing linker technology.
You're right that C++ could take advantage of a smarter linker, but that
would mean writing a new linker for every platform ... which is a price
many vendors would not be able to pay. I can certainly understand the
language committee not wanting to mandate an entirely new linker for every
implementation (they have a hard enough time persuading vendors to support
things like 2-phase lookup and export).
I think it's something we're going to have to continue to live with for a
good while yet.
> > Using things like std::vector and std::string
[snip]
> I merely pointed out that it doesn't free one from understanding
> the concept of a pointer ...
One can do a lot with C++ without ever using a raw pointer directly if one
adopts the "modern" style, and uses (for example) string and vector
extensively. There will certainly come a time when one needs to implement
some construct that does cry out for a raw pointer ... but beginners need
not encounter them. I believe /Accelerated C++/ manages to avoid raw
pointers in all its examples and exercises.
This seems to me to be the application code vs. library code discussion,
again. Beginners use libraries, they don't write them. They should
probably be aware that somewhere inside the libraries there are these
scary things called pointers, but they don't have to deal with them
directly.
> In addition it adds additional burdens in the form of understanding
> template syntax and semantics.
.. And some damned impenetrable error messages ... but that's a fault of
the tools not of the language.
> Without disagreeing directly with any of the above, I don't think
> you are responding to my actual point, which is that getting the
> algorithmic design correct is surely one of the most challenging
> and common aspects of programming, but the plethora of books and
> columns written on C++ are not teach
There are books about designing algorithms, but the ones I've seen are
mostly language-neutral. The reader is expected to be sufficiently clueful
to be able to apply the concepts of the book in his preferred language.
You seem to wnt me to say that C++ is in some way "superior" for algorithm
design, but I'm not sure that it is. I don't think it's in any way
"inferior" for that task -- and the tools one knows are always more
attractive than the tools one doesn't -- but I can't claim that it is
superior.
In short, I'm not sure that there is (or needs to be) a response to your
point. Designing good algorithms is hard in itself, use any language you
are happy with (just don't ask ME to use LISP!).
> Please tell me which smart pointer you think will work well for all
> "the cases that [the novice] will encounter in training".
I could suggest the Boost shared pointer ... there are others.
> > Exceptions are core to C++. The standard library throws them.
>
> In very unusual circumstances that most programs won't
> be able to do anything about.
Exceptions are, however, the standard error reporting mechanism used by
the library. It's often possible to respond to an exception in an orderly
fashion even if it isn't possible to correct the condition that caused it
and continue. Code that is not exception safe impedes this.
> >User code can throw them.
>
> And should normally only do so as a last resort.
I disagree. Throwing an exception is a perfectly valid way to report an
error that cannot be handled locally, and programmers should have no
compunction about doing so. I do agree that some programmers overuse the
exception mechanism horribly, but that's another matter.
> I actually like the Java model of exception signatures,
> but that isn't the way C++ works. Which is a pity.
C++ has exception specifications, but they're often ignored. That's
fortunate as checking exception specifications at compile time (which is
where it would bring the greatest benefit) is much harder in C++ than in a
relatively small and restricted language like Java. The real problem in
C++ is that the exception specification isn't part of the type of a
function, and so exception specs aren't associated with funtion pointers
and template arguments. IOW there are too many places in the syntax of the
language where exception spec information isn't reorded to allow effective
compile-time checking. The runtime checking that the language specifies
instead is horrible, and has unacceptable implications for performance.
Even Java's exception signatures don't really help as well as they might -
unchecked exceptions are a hack to prevent the exception signature
mechanism from becoming unmanageable ... but the thing a programmer really
wants to know is "can this function throw" and because unchecked
exceptions never have to be declared there is nothing in the language to
make that guarantee.
It's a nice idea, but not specified well (in either language).
> I agree if by "break" we mean break a program that is otherwise
> not broken.
Of course ...
> I tried to explain in my earlier post why exception
> safety is unimportant for more than 99% of C++ code written,
> and you didn't really respond to my points.
> Even if production code (we we have already agreed is a tiny, tiny
> fraction of the code that is written) the overwhelming majority of
> applications that consist of a single process terminate after an
> exception is thrown, and if they are terminating then a "memory leak"
> at that point is not a bug.
No, we do not agree.
Exception safety is VITAL for ALL C++ code, except in limited cases where
exceptions aren't used at all (I've used C++ in some embedded projects in
which exceptions weren't used by the application and weren't thrown by the
libraries, for example).
I would say that at least 25% and probably more than 33% of all the code
written in all the commercial projects I've worked on was "production
code" in that it was destined, one day, to be shipped to a customer as a
working program or library, or embedded in some device. Most of these
projects did use exceptions and so all that code had to be exception safe.
Much of the rest of the code was test code, and as there's no point in
trying to test poduction code for correctness using tests that are
themselves incorrect that all had to be written to the same high standard.
The rest of the code was a mixture of prototypes, demos, and discardrd
"first passes" ... and, of course, at least the demos and "first passes"
had to be written to production quality (there's nothing better for giving
a bad impression of a product than a demo that crashes).
None of these applications (apart, maybe, from a few trivial test cases)
was "a single process that terminated after an exception was thrown". Many
of them were, for example, GUI apps that would abort a single command and
return the user to a main menu after an exception was throuwn, or server
apps that would drop a single connection (on a single thread) aftern an
exception was thrown and return to the "listening" state. Exception safety
mattered in the greater part of all the code written.
> If you agree with it, but still feel
> that all C++ code written should have exception safety as
> a priority just in case it will eventually be used in one
> of those production contexts where it is relevant, then
> please tell me why you don't think that wastefully inefficient
> advice to programmers that significantly slows down their
> productivity.
As I've said, I don't agree.
I also don't believe that training programmers to write in an exception
safe style -- even when exception safety isn't going to be an issue -- is
wasteful or inefficient. It required very little work and the payoff is
huge. There is certainly no "significant slowdown".
I want programmers working on my projects to be *incapable* of writing
code that wouldn't pass muster in a production environment. I want them to
have the mindset that does not allow them to write sloppy code in any
circumstances. I want them to take pride in every line being correct. It's
always cheaper by far to get it right the first time than to have to fix
it later.
Cheers,
Daniel.
- Next message: Russell Shaw: "Re: c++ documentation"
- Previous message: gold+ares+REMOVE-IT_at_gmail.com.invalid: "how to use specific context before thread switch"
- In reply to: Last2Know: "Re: c++ documentation"
- Next in thread: Russell Shaw: "Re: c++ documentation"
- Reply: Russell Shaw: "Re: c++ documentation"
- Reply: Last2Know: "Re: c++ documentation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
