Carl Banks wrote:
> On Feb 21, 7:17 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>> Carl Banks wrote:
>>> On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>>>> There are other downsides to garbage collection, as the fact that it
>>>> makes it harder to implement the Resource Acquisition Is
>>>> Initialization idiom, due to the lack of deterministic destruction.
>>> That's not a downside: it's at least a wash.
>>> In C++ you manage memory and the language manages resources. In
>>> Python you manage resources and the language manages memory.
>>> RAII is merely one way of minimizing complexity. Garbage collection
>>> is another way.
>> If you've already got a generic, language-supported way to manage
>> resources (like RAII with deterministic destruction), then why bother
>> with garbage collection?
>
> Because now you have to manage memory? Did you read my post? You
> have to manage one thing or the other.
Yes, I read your post. You seem to be saying there's some kind of
trade-off between automatic management of dynamically allocated memory,
and automated management of other kinds of resources. I don't
understand why you believe that, so I asked.
If you have proper RAII and deterministic destruction, the management is
of resources is consistent, and mostly automated. Managing memory is
just not that difficult, especially if the vast majority of objects are
allocated on the stack or in static memory. A special language feature
for managing dynamically allocated memory robs the programmer of a
reliable way to clean up resources automatically, without bringing
anything of particular value to the table.
>> I'm not trying to knock it; it was a big step
>> up from C-style "who forgot to delete a pointer" games. It just seems
>> to me like a solution to something that's no longer a problem, at least
>> in well-written C++ code. I'll take destructors over GC any day.
>
> About 2% of the objects I creat have resources other than memory. I
> would rather manage resources of 2% of objects than manage memory of
> 100%.
That's not how it works. If I'm going to allocated a C++ object
dynamically, I have to assign it to some kind of handle, anyway, so I
might as well just use a smart pointer that will delete the object when
there are no more references to it. There is no extra effort involved.
The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the fstream
goes out of scope. CPython offers a similar feature, since you can
create a temporary object whose reference count will become zero at the
end of the statement where it is defined:
$ echo world >hello
$ python
>>> file('hello').read()
'world\n'
It's graceful, easy to write, and a million times better than having to
clean up the resource explicitly. A book on Python I was reading
recently (either Alex Martelli or Mark Lutz) used this idiom again and
again, and every time had to have a footnote about how it wouldn't work
right on (e.g.) JPython, because who knows if/when the resource-owning
object's finalizer will ever get called.
Admittedly, you have to know enough to use the right kinds of objects,
but that's something you have to learn anyway.
> YMMV, but I suspect mine is the more common opinion, if the
> recent (like, 10-year) trend in programming languages is any
> indication.
I agree that support for non-deterministic GC has grown very popular
over the past ten years or so. I don't think that is evidence of it
being a good idea though; I suspect that opinion of being the product of
widespread ignorance about alternatives to unpredictable GC.
--
http://mail.python.org/mailman/listinfo/python-list
