Re: Why people use "new" & "delete" too much?!!
On Jul 8, 2:52 pm, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article
<bc6c98b2-b72a-420f-bdc0-15ecd55e2...@d45g2000hsc.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:
[...]
Where garbage collection is always a win is in development time
and program security and robustness.
You know, that's the funny thing: When I write C++, a very
rarely feel that a garbage collector would help me write code
faster or result in more secure and robust code.
The security issue is clear: garbage collection reduces the risk
of a dangling pointer actually pointing to some other object
(which can be a security leak, much like buffer overflow), and
more generally, allows reliable checking for dangling pointers.
The win in development time depends largely on what you're
doing; it's true that there are many cases in C++ where it isn't
that relevant. But there are still a few cases where you'll
prefer pointers to dynamically allocated objects to pure value
semantics:
-- when the objects are big enough to make the cost of copying
an issue,
-- when the object is used in an exception, and copying isn't
guaranteed no throw (if an object is to be thrown, you'll
use std::string*, rather than std::string), and
-- when the object must be polymorphic, although otherwise
value semantics apply.
Now it's true that tr1::shared_ptr can be used in the first two,
but that does mean extra effort on your part, albeit minimal.
In the third case, you may have to worry about cycles as well.
And in all cases, it means thinking about it, rather than just
using a pointer and being done with it.
(There are also special cases. I recently had to deal with a
case where I needed a complex data structure which could be
statically initialized. But wasn't always. Because of the
requirement of static initialization, the elements in the
structure couldn't have constructors of destructors, which meant
that in the case of dynamic management, I had to visit the
structure manually to do the deletes. Getting the code
exception safe was a real pain, whereas with garbage collection,
it would have represented 0 effort.)
STL containers are used extensively. I rarely use "new",
when I do it it's generally inside object and managed using
RAII or ownership is clear anyway. The few cases left are
rare enough that I don't find it a burden nor a security risk.
Even with the said GUI application, to me there's a clear
ownership relationship between a window and a button on that
window so lifetime management is simple.
The security risk is still there, as soon as you have objects
with arbitrary lifetimes. (Like buffer overflow, it can only
occur as a result of a programming error. But programming
errors exist, and the fact remains that using a dangling pointer
which points to a new object can result in your code being
compromized.) For the rest, it's certain that you don't need
garbage collection in the way that Java needs it; that it's
impossible to write correct code without it. But there are
enough cases where it does help that one or the other will
inevitably show up in most applications.
However, when I write C. I do find it problematic. The
absence of both garbage collection and RAII makes memory
management a constant pain, slows development and create
risks.
Yes. Without RAII, garbage collection is an absolute necessity.
Unfortunately, when I look at some other code that is meant to
be compiled with a C++ compiler, things are not always as
nice. Innapropriate habits (maybe imported from C, Java or
simply never learnt better) can introduce poor memory
management patterns which leads to slow development and
security and robustness issues.
So a couple of possible solutions:
- Training: teach peoples to write good code. Writing good code
doesn't take longer than writing poor code, it just requires more
skill.
I'd say different skills, rather than more skill. It actually
takes more skill to write correct C, but if you apply those
skills to C++, the results aren't going to be very good.
- Garbage collection: has clear advantages in some situations.
But is it a substitute for poor skills?
No. You need both (and the correct skills is the more important
issue).
- Remove flexibility from the C++ language: Is one of the
weakness of C++ its great flexibility? It brings as cost, the
capability of writing poor code which is somewhat limited in a
less flexible language. (witness for example python's
attempts to enforce "nice" formatting by making formatting and
whitespaces part of the syntax)
The reason C++ is widespread is not its elegance and its
simplicity. Nor even its safety, per se. The reason C++ is
widespread is its flexibility. And the fact that as the global
knowledge base expands, we learn new and better ways of doing
things. So that, correctly written, C++ is considerably more
robust and secure than Java, despite Java's having been designed
with those issues in mind. Java cast in stone the established
concepts of robustness and security at the time it was
developed; since then, we know more, and can do better. At
least in C++, because nothing has been cast in stone.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34