Warp wrote:

>   It may be a standard way in Java. In C++ it's a standard way of getting
> sure that you will get a high chance of a memory leak (specially if
> there's more than one person using the library which does that). (And no,
> the way Java handles object allocation and freeing is not always good.)
> 
>   As I already said in another article, one of the basic principles of
> modularity is that if a module (class, whatever) allocates a resource, the
> same module takes care that the resource gets freed (and gets freed only
> once).
>   Making a module which allocates a resource, returns a handle to this
> resource outside and hopes that someone else will hopefully free it
> somewhere, is a *really* bad module design (and OO design).
> 
>   The whole class hierarchy should be designed so that this kind of
>   copying
> is not needed (ie. not in this way). This usually can be done much better
> and much more nicely (and specially much more safely).
>   Making efforts for a good design now can save you a lot of trouble
>   later.
> 

Well, the whole thing about garbage collection, reference counting, etc. 
etc. is just meant for NOT bothering about these details. I am working in 
Java since 2000 (and in C++ since 1990..) and I find myself 10 times more 
productive by just calling clone() on an object to create a copy than 
messing around with templetazied smart pointers, idioms to ensure correct 
destruction etc. etc.

ANY modern language (Java, C#, Perl, Python) and some not so modern 
(LISP...) have AT L:EAST reference counting.

Bye!!!
        Alessandro Coppo
        a.c### [at] REMOVE_MEiolit

Post a reply to this message