Re: C++ Frequently Questioned Answers
* Yossi Kreinin:
On Oct 29, 3:22 am, "Alf P. Steinbach" <al...@start.no> wrote:
A Frequently Questioned Answers is a very good idea, and I commend
the
effort you've put into this.
Thanks!
One thing I'm definitely interested in is whether I got
any facts wrong, and if I did, which ones.
Well, most of it. ;-)
Well, I meant "facts" :) My definition of "facts" in this context is
here (together with the first factual correction submitted by a
reader):
http://yosefk.com/c++fqa/web-vs-fqa.html
Why not quote that definition: ?I mean statements which can be proved
wrong or refuted by a practically feasible test.?
Starting with the first sentence of the first FQA item, numbered 6.1,
?C++ is not "mature" in the sense that different compilers will
interpret it differently, and C++ modules built by different vendors
will not work with each other"?. If the latter part of the sentence
is meant to be existentially qualified, that it's possible to write
modules that will not work with each other, then it's meaningless. If
on the other hand it is meant to be universally quantified, that it's
impossible that different vendors write modules that work with each
other, then that's demonstrably false. So as it stands it's either
meaningless or false. It is however not difficult to understand what
is probably meant, that C++ lacks an official (e.g. ISO) standard for
compiled code (an ABI). As it is, one must rely on de facto
standards. But this best-meaning interpretation doesn't help the fact
that the FAQ's statement as it stands is either meaningless or plain
false.
Next sentence, ?C++ is not "well-supported" in the sense that
development tools for C++ lack features and are unreliable compared to
other languages.? I would tend to agree with the features
(functionality that requires parsing of C++ code is generally lacking,
due to the complexity of a C++ parser) but not with reliability (on
the contrary). However, this is just opinion that cannot be proven or
disproven. It may be that the author has only used low quality tools.
Third sentence, ?These things make one ask "Am I the first one trying
to do this?" all the time.? If this sentence is about the author's
experience then it is presumably true, but not falsifiable. :-) If it
correctly relates the author's experience, rest assured that you're
not the first, and that there are also good tools for C++.
And so on: of the first three sentences, one was either meaningless or
false, and two were not falsifiable.
One main high level issue that the FAQ gets wrong is the purpose of a
programming language. In general it's a good idea to use the most
appropriate language for a task, but your FQA seems to assume that
somehow everything has to be done in C++.
The FQA doesn't say that everything has to be done in one language
anywhere, and I use several languages myself. The FQA says that /
nothing/ should be done in C++. This does not imply that "if C++ were
good, you'd have to do anything in it" or anything like that.
Garbage collectors such as the Boehm collector work well.
One problem is that several libraries may be built to use different
garbage collectors. Garbage collectors are not entirely non-intrusive;
they may ask the user to provide some kind of layout information or
finalization functions, for example. Having many of them in one
program is thus problematic.
I wouldn't know because I haven't used garbage collection with C++.
The only person I know who does use garbage collection in C++ is James
Kanze. And he has not reported any such problems, instead
recommending garbage collection to newbies.
Non-intrusive garbage collectors have false positives (some things
look like pointers, but aren't), and fail when people use formally
illegal, but normally working techniques like int* one_based_vector =
(int*)malloc(sz)-1;
I hope James will answer that.
One thing C++ garbage collectors can't do is heap compaction. AFAIK
this increases the upper bound on the memory consumed by a program
with the peak sum of allocated object sizes equal to M from M to
M*log(max_block_size), which is a huge difference for realistic values
of max_block_size.
There is nary a computer science problem that can't be solved by
adding a level of indirection. Modern computers typically have built-
in memory management that adds just such a level of indirection. In
the old days before that hardware became commonplace on PC's we had to
use handles to memory (instead of direct pointers), in order to allow
compaction.
With extreme fragmentation and large underlying page size it would be
possible to consume a lot of memory, as opposed to address space.
However, I don't think that's something that a language solves for you.
However, for
many C++ programmers garbage collection is not desirable, because
while
it can ensure that memory is always reclaimed, it leads to other
problems.
If you refer to /hard/ real time applications (most large ones are
really /soft/ real time), than AFAIK operator new has the same
problems in terms of worst case performance. If you refer to resource
leaks when resources!=memory, then I have to point out that the vast
majority of resources /is/ memory, and very basic language constructs
(such as new) depend on being able to acquire memory, and not having a
simple solution for memory management is likely the single biggest
problem with "low-level" languages when you try to do "high-level"
work in them (but C++ is promoted as a pretty high-level language).
IMO not acknowledging the difference between "memory" and "resource"
is a manifestation of perfectionism ("solutions that only solve 95% of
the problem are worthless"), and there's plenty of such things in C++.
Unpredictable and jerky response time is one consideration, yes. But
I was mainly thinking of the impact on design when objects hold
references to non-memory resources. In e.g. Java this leads to
"destroy" methods all over the place, where a call to such a method
zombifies the object. This in turns leads to checks of whether the
object is a zombie, resulting in complication, and undetected invalid
usage of the zombified object.
C# helps a little with its "using" statement, but that's mostly
cosmetic.
My ideal garbage collector for C++ would be one that addressed one
problem only, that of doing actual memory reclamation at idle times.
Such a garbage collector would not invoke destructors. Instead,
memory freed by operator delete or C free would by default be passed
(constant time) to a list, traversed by the garbage collector at
suitable times.
From the FQA:
And what if you make a mistake, one single mistake with all these
deletions?
with proper RAII, if an object is still alive, then its class
invariant
still holds.
RAII does not at all prevent problems with dangling references. If you
keep a pointer into an object in an STL container, which acquires
memory in the constructor and deallocates its memory in the destructor
(which is what RAII means), and the container dies, you have a
dangling reference. Which is why C++ programs will frequently make
themselves private copies of objects - pointing to something you don't
"own" is dangerous.
You're right that RAII does not prevent problems, it just helps solve
them. Garbage collection doesn't prevent problems either (in
particular early versions of Java's Swing library tended to leak
memory by keeping references to old objects in singletons, garbage
collection didn't prevent that). The solution is in general not to
copy data. Since you assert that that's a common solution it seems
you have been exposed to some really bad programming practices. But
that's not a feature of a language: incompetence is a feature of
programmers.
You can implement reference counting on top of RAII, making all your
pointers "smart" (and having the usual trouble when integrating with
other libraries of equally smart though different, or, most often,
dumb bare pointers). Then you'll have the problem with cyclic
references (which, by the way, is AFAIK the single case when a GC
could leave "zombie objects" around - and note that it took us way
less work to get to this stage).
Curiously, I've never had a problem with cyclic references in C++. On
the other hand, it is true that blind application of unsuitable
reference counted smart pointers runs a good chance of creating such a
problem. And I've helped resolve such problems created with reference
counting in other languages, mainly Visual Basic. Again it's not the
language's fault, but generally incompetence on the part of the
programmer.
And no, GC doesn't create zombie objects (programmers do), and no, it
doesn't have anything to do with cyclic references.
A zombie object results from manual logical destruction (in order to
release non-memory resources), leaving an existing, zombie, object.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]