On Dec 24, 6:14 pm, atucker <agjf.tuc...@googlemail.com> wrote: > I am also curious about this. Apologies, possibly naive question > ahead :) > > My background is in C++. By choosing to work with immutable values > (i.e. with a lot of consts), I found that I was able to avoid most of > explicit memory management, pointers etc. Exceptions were: > > (a) when interfacing with other people's code, and > (b) when making optimisations, e.g. to save a needless copy-on-return. > > Otherwise everything happened behind the scenes as variables with > "automatic" lifespan, passing into and out of scope, had their memory > allocated and deallocated on the stack. > > Surely this is the most performant approach to memory management where > it is possible? And doesn't Clojure's pure-functional ethos make it > possible? > > Alistair >
It's great until you want to have more than one reference to a particular piece of data. Then you have two options: a) Copy b) Make another pointer to it Option a) is often good enough. But if it's a huge object (like sound or picture data) you probably can't afford copying it. Option b) means that you now have lost the ability to manage the memory through scope alone. You will need manual management or some kind of GC mechanism. In C++ you often use boost::shared_ptr<> but that can't handle circular references so there is still a manual management component to it. When option a) is too expensive and option b) is too complicated, that's when you need a real GC. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
