Our favourite bulk file copy code snippet would, for example, cease to work:
----------------------------------------------- saga::task_container tc;
for (i = 1; i < 1000; i++) { saga::file f (url[i]); saga::task t = f.copy saga::Task ("/tmp/"); tc.add (t); }
tc.run (); tc.wait (); -----------------------------------------------
Its not only the file object which goes out of scope here, its also the task!
Indeed, this code is broken. It might artificially be made to work by all the fancies that you guys have put into the implementation. In proper code, objects would be created on the heap (with new). You better do that anyway as you don't know how big your stack is and how big the objects are that some 3rd-party library creates. (Esp. if you have multiple threads, you cannot assume stacks to grow infinitely.) Yes, with C++ you have to do life cycle management of object references. I know, by keeping SAGA out of the memory management business, the price for this clarity is manual destroying of objects. But: we should stop arguing over artificial examples that are only designed for proving a certain argument. Sessions are by definition rather static; in a real application I can not see a session to be destroyed before the end of the program anyway.
All that is simple to do in the SAGA implementation, which _knows_ where it is inherited, and which will do ref counting anyway...
No way. SAGA needs to stay away from object lifecycle management.
Again, I think your proposal is simple and it works, so its an valid option -- but IMHO it makes programming SAGA applications an ugly business.
Yes, in less advanced languages there is some price to pay. But there is no single reason to spoil the language-independent spec, just because C++ doesn't have proper memory management. Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/