Re: c++ documentation
From: Last2Know (grokkalot_at_yahoo.com)
Date: 05/17/05
- Next message: loic-dev_at_gmx.net: "Re: how to explain the thread3 from the Bengining Linux Programming 3rd edition."
- Previous message: Dennis-Bendert Schramm: "Re: Error while compiling fontconfig"
- In reply to: Daniel James: "Re: c++ documentation"
- Next in thread: Daniel James: "Re: c++ documentation"
- Reply: Daniel James: "Re: c++ documentation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 17 May 2005 09:41:57 -0500
On Tue, 17 May 2005 11:44:18 +0100, Daniel James wrote:
>> ... C is describe as a portable assembly language ...
>
> I've occasionally said that if C is a portable assembler then C++ is a
> portable macro assembler (or maybe a meta-assembler).
>
>> ... and traditional courses in C often began with a description of the
>> mapping of the language onto assembly for some architecture.
>
> That's certainly something you need to know about to use C as a systems
> programming language ... but I wouldn't have thought it could ever be a
> good place to start.
It's important to have some sort of mechanical model of how the
program works. It isn't necessary for that model to extend
down to the level of machine instructions, but having that
extra knowledge is sometimes helpful and it insures that the
model is sufficiently complete to make correct predictions
about behavior and check them when there is doubts.
In this thread I'm explicitly asking about the existence
of complete alternatives.
>> > Having said that, the committee are only human, and there may well
>> > be places in the standard that are easier to understand if you
>> > already know what they're trying to say <smile> -- that applies to
>> > a foreknowledge of C++ as well as of C.
>>
>> Yes. The parts that people didn't already know about, like exported
>> templates took many years to be implemented by compilers.
>
> New language features -- especially things ike export that are new in C++
> and noit quite like anything that any other language has -- are much
> harder to learn to implement than they are to explain to the user. Indeed,
> the comment that is often made about export is that people are surprised
> that it is needed at all: they expect it to happen by magic without the
> need for a new keyword.
Several aspects of C++ feel like they were designed by someone
who hardly even thought about linkers. For instance, it's simply a design
bug for information like how to find a particular function in a shared
library to be some sort of implementation-defined black magic, because
doing that is a basic example of how the language product is to be used,
and that was known at the time of its creation.
But you are right that exported templates was not the best example
of the point I was trying to make - let me replace it with something
like 'getting multiple correct in the presence of template classes
and virtual base classes'.
>> Using good libraries to do something is always easier than
>> coding it all by hand. The standard C++ library is quite
>> good in many respects.
>
> Yes, that's the point. Using things like std::vector and std::string
> rather than raw C-style pointers to data buffers is easier, once you get
> into the habit, and leads to more reliable and more maitainable code.
We agree about that. I don't recall writing anything that should
give the impression that I'm against that practice or teaching it.
I merely pointed out that it doesn't free one from understanding
the concept of a pointer and it doesn't necessarily avoid the
catastrophes that come from pointer misuse: invalid dereferences,
addressing errors, stack corruption, invalid deletes, etc can
all still be merrily accomplished with STL code. In addition
it adds additional burdens in the form of understanding template
syntax and semantics.
>> Surely using the STL is pretty daunting to the novice, and you or I
>> would would have a hard time imagining the multiplicity of ways that a
>> novice can screw up badly trying to use and debug STL-based code.
>
> Yes, STL can be daunting, but I think that's partly because it's seldom
> explained well -- that's one reason I recommend the Musser, Derge &
> Saini book; which I found really very good. I found I understood the
> /point/ of STL much more after reading that, even though I thought I got
> it beforehand.
I haven't read that book, but would note that the STL concept of
iterators, begin, end, etc. can also be used to make ordinary
code with C style arrays and pointers better and safer.
Of course anything can always be taught better, but there is
a lot of inherent complexity in understanding templates that
will be there for the novice no matter how well it is taught.
>> ... where are the C++ gurus who say that C++ is not a good tool for
>> designing algorithms?
>
> I've never heard any of them say that ... but I suspect that that's
> because they don't think it worth saying. C++ is a perfectly good tool
> for designing algorithms and if you're a "C++ guru" it's probably the
> tool you'd use. There are other things one can use -- I mentioned
> Python, which I quite like -- and if you're a "Pthon guru" you'd do
> perfectly well to use that; that's not to say that C++ isn't good for
> the task or that Python is better.
>
> If a "C++ guru" thinks Python (or anything else) is better suited for a
> task than C++ then it probably wouldn't occur to him to say so, he'd
> think it was too obvious to mention.
>
> Note that "designing algorithms" isn't (necessarily) the same thing as
> "prototyping".
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 teaching effective ways to use
C++ as a primary tool for that task. They rather emphasize a
lot of focus on issues that orthogonal to the task and often
distract from it. I'm not taking sides in a debate about
whether it would be better to do prototyping and algorithmic
design in another language or in C++ itself. I'm saying that
in either case there a lot of issues about what are the effective
practices that are not being addressed, and their absence leaves
people with misleading impressions about how to go about writing
programs that are to be ultimately implemented in C++.
>> Smart pointers, hallelujah! <sarcasm> Nothing improves productivity
>> like tinkering with code trying to figure out exactly which of the many
>> types of smart pointer to use and which behavior it should have.
>> </sarcasm>
>
> Your sarcasm is misplaced. That's *just* the sort of thing a competent
> C++ programmer *knows*.
The set of people who *know* this is incredibly small because the
issues are very complex. Heuristics that say things like
"use a copy-on-write pointer for a class member and reference
pointer outside a class" are so simplified that they do more
harm than good. I'm comfortable with the generalization that
novices using smart pointers are going to confront mystifying
bugs in their programs that are directly traceable to smart
pointer misuse.
>It's one of the things novices have to learn,
> but they can be introduced to it gently by giving them one single smart
> pointer that works well in the cases that they will encounter in
> training.
>
> (and no, that isn't std::auto_ptr!)
Which only complicates the issue further. Please tell me
which smart pointer you think will work well for all
"the cases that [the novice] will encounter in training"
and what the comprehensive training actually consists of.
>> As for "exception safety" ...
>
> 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.
>User code
> can throw them.
And should normally only do so as a last resort. I
actually like the Java model of exception signatures,
but that isn't the way C++ works. Which is a pity.
>Every bit of code that calls anything (drectly or
> indirectly) that can throw an exception has to be written so that it
> won't break if something it calls does so.
I agree if by "break" we mean break a program that is otherwise
not broken.
That doesn't mean it has to
> handle -- or even know about --- the exception itself, just that it has
> to operate correctly if an exception is thrown and propagates through
> it. Usually (but not always) this means no more than that it must not
> leak memory or leave objects in undefined/illegal states when the stack
> unwinds during exception propagation. It's not rocket science, but
> requires a little thought and a little care
I understand all the concepts and don't need any additional
tutorials on this topic. My disagreement is about the priority
this should have on the list of practical programmer concerns.
> This is important in 99% of all C++ code written,
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. So let me
reiterate what I said earlier in a more direct way:
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. Preventing memory leaks in case an
exception is thrown is only important in application code where
significant additional memory allocations will occur after the
exception is thrown. If you disagree with my previous sentence,
then please tell me why. 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.
- Next message: loic-dev_at_gmx.net: "Re: how to explain the thread3 from the Bengining Linux Programming 3rd edition."
- Previous message: Dennis-Bendert Schramm: "Re: Error while compiling fontconfig"
- In reply to: Daniel James: "Re: c++ documentation"
- Next in thread: Daniel James: "Re: c++ documentation"
- Reply: Daniel James: "Re: c++ documentation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
