Re: ? about C++
Lo, on Thursday, March 7, Dimitri Maziuk did write:
> * Craig Dickson (crdic@yahoo.com) spake thusly:
> > begin Dimitri Maziuk quotation:
> >
> > > Does anyone know about a school that teaches people to use
> > > vector<>, auto_ptr<>, basic_string and references?
> >
> > I have no idea what they teach in school these days, but I should think
> > they would have to teach references if they teach operator overloading.
>
> Not according to the code I get to play with.
>
> [ snip ]
> > The standard auto_ptr<> is an abomination.
> [ snip ]
>
> Well, there's that... I'd argue that garbage collection is very
> hard to get 100% right anyway
In C and C++, this is basically correct, although it depends on exactly
what you mean by `right'. In advanced languages which actually provide
type safety, I disagree. Correct GCs have been pretty well understood
since, oh, about the mid '70s. (I want to say '74, but I don't recall
exactly when the mark-and-sweep algorithm was developed.) Most of the
research in this area since then has been concerned with performance
improvements, rather than correctness issues.
This is pretty irrelevant when you're talking about auto_ptr; it's not a
full GC. IMO, most of auto_ptr's bad reputation comes from people
trying to use it as though it single-handedly solved all memory
allocation problems. It doesn't, and it was most specifically not
designed for that in the first place. It does, however, do a wonderful
job at what it *was* designed for: it prevents memory leaks in the face
of exceptions.
> and there are other ways to detect memory leaks...
Yes, although this is not really one of the main benefits of using a
GC. For my money, one of the primary benefits of GC is that I don't
have to worry about a lot of really annoying bugs, especially dangling
pointers or heap corruptions through incorrect deletions.
> Anyhow, my point was, name 4 problem areas in C.
>
> 1. No array bounds checking (Fix: use vector<> or equivalent)
Agreed.
> 2. Pointers (Fix: use references, iterators etc.).
Pointers are not the problem; the fact that they're not safe is the
problem. Solution: get rid of void*, and prevent all typecasts
involving pointers except those between different classes in an
inheritance hierarchy. Oh, and check pointer arithmetic, too, but
that's basically equivalent to point #1.
Referencs a la C++ have their own problems; they allow variable
aliasing, which causes all kinds of grief during optimization.
> 3. Forgetting to free() malloc()'ed memory (Fix: use auto_ptr<>,
> destructors etc.)
auto_ptr and destructors are a step in the right direction, but I don't
find that they're completely general. This may be due to the fact that
I'm used to the freedom and flexibility that comes with a GC language.
> 4. Using pointers to (hopefully array) (hopefully allocated) (hopefully
> null-terminated) of char as string data type (see also 1, 2, & 3)
> (Fix: use std::string)
Oh, absolutely. This is basically related to the other three points.
Richard
Reply to: