Subject: Re: Why Arc isn't especially OO From: Erik Naggum <erik@naggum.net> Date: Mon, 17 Dec 2001 06:36:14 GMT Newsgroups: comp.lang.lisp Message-ID: <3217559771425033@naggum.net> * Alexander Kjeldaas <astor-news@fast.no> | On the other hand, setting up a memory area that you allocate all objects | from (often called "areas" in the C/C++ world), and tearing it down when | you are finished with the request is a well known technique which is used | all over the place where server programming happens. It is an extremely | efficient way of handling this issue, and I think it would be nice to | have some language support for this. You need explicit allocation to make this work. Common Lisp does not have explicit allocation. C++ does, and therefore needs this dubious "feature". There is in fact _no_ language support in Common Lisp for _any_ form of allocation or deallocation. Think about it. In Common Lisps with a generational scavending garbage collector, such "areas" would amount to a "private" newspace, the GC'ing of which would copy live objects somewhere else before it got torn down. Because the whole language does allocation at will, the amount of control that would benefit from such areas being torn down as an inexpensive operation is simply not there. Whether you garbage collect a private newspace or the global newspace thus has no impact on performance (other than to copy any living objects once). | I would prefer a general solution that works for all allocation, for all | objects, also allocation done in a library not written with GC quirks in | mind. But I agree that resourcing is a good engineering solution that | overcomes GC problems. Resourcing is not about "overcoming GC problems". Their main use is to avoid allocating space that is usually freed immediately. In effect, resources are in Common Lisp what "areas" are in C++: privately managed allocation. Normally, however, allocated resources are discarded when GC happens, because they are maintained using weak pointers. This is a useful technique only when one expects allocating a lot of garbage of the exact same type. It appears that the desire to control memory allocation manually is almost a one-bit mental state. When I recently argued in a C group that calling free in short-lived or low-garbage applications was a waste of programmer brain cycles, one fairly irrational dude jumped on me and got nearly hysterical that I could even suggest such a thing. Explicit calls to free was to him the very mark of good programmer, and lack of which the mark of the devi. He argued that some broken version of Windows did not free memory allocated by a process unless expliciet calls to free were made all of the program, and has yet to realize that the goals of (manual) memory management may be obtained by automatic means. I, on the other hand, consider manual memory management to be _really_ stupid, and the desire to obtain control over this part of program development by forcing every allocation and deallocation to be manual as sheer lunacy. I have 15 years of experience writing C applications where manual memory allocation was never a problem. Now it is. My bit has been inverted. /// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.