Quoting [Thilo Kielmann] (Aug 01 2006):
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.)
Ok, assume we define the async methods to return pointers to tasks, not task instances (you cannnot use 'new()' to create a task): ---------------------------------------------- saga::task_container tc; for (i = 1; i < 1000; i++) { saga::file * f = new saga::file (url[i]); saga::task * t = f->copy saga::Task ("/tmp/"); tc.add (t); } tc.run (); tc.wait (); ---------------------------------------------- The the code is valid, but, again the user needs to keep track of the instances as they are used _internally_ in saga.
Yes, with C++ you have to do life cycle management of object references.
Of course - but that does not mean you cannot do it IN the library. For example QT, which is regarded as a poster child and easy-to-use C++ library, object life time is managed in the libqt, not in the application (the application CAN manage the lifetime explicitely though). WT uses following mechanisms: - shared pointer (QPointer) - special slots (delate_later, destroyed) to signal internal object destruction - object dependencies (if parent gets destroyed, children get destroyed). There is no reason to put that burdon to application level. I don't see that as an language issue BTW - I know that can be done in C (hence in also in Fortran bindings), Python and Perl, and I am rather positive for Java, too.
I know, by keeping SAGA out of the memory management business, the price for this clarity is manual destroying of objects.
I think we differ in what clarity means. You propose a clear definition, and simple rules. I would argue that clear and simple application code is more important.
But: we should stop arguing over artificial examples that are only designed for proving a certain argument.
I'd be happy to see code proving the opposite :-) But really, all what should matter is the end is what the application programmer will see, and use, and that is code. It does not help us to define simple rules etc, if the resulting SAGA code is cumbersome to use...
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.
Maybe. But that is definitely note the case for tasks and other object dependencies.
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.
Can you explain why?
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.
No, thats not a language issue - see above. Andre. -- "So much time, so little to do..." -- Garfield