Erik Steffl <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>.. [. . .] > I forgot to add that Stroustrap says that lot lot of memory > management problems can be avoided by simply using variables on the > stack and not dynamically allocate it using new (so you're not alone:-), > I don't have reference but I guess you'll be able to find it if you want > to... If you use STL (or something similar) you can have the containers > in the stack and let the containers (better debugged than your code) > handle the allocation of the data (that way you get advantage of using > heap for large data plus the advantage of stack - code is > cleaner/shorter, data are automatically freed without you having to take > care of it and you can handle the out of memory error). [. . .]
I also remember Stroustrup said something along the lines. Since I read quite a bit of what he wrote and I did it a long time ago, I don't remember exactly where he said that. What I've dug up is: section 2.4 of "The Design and Evolution of C++" (Stroustrup, 1995, Addison Wesley). Here he discusses why he specifically decided to allow allocation of user-defined objects on stack. You find a similar discussion in his "The C++ Programming Language", 3rd ed., where he emphasises the usefulness of "concrete" types, which can be used in the same manner as the intrinsic types. This is an interesting design decision. In "mainstream" object-oriented languages such as Java and Ruby (please notice that I quoted "mainstream" :-), user-defined objects are (almost?) always allocated on the heap. As I like Ruby very much, I also did suffer from the inefficiency of that approach. In passing, yes, I miss the STL. I use only Fortran 95 these days. The other day, I had to hand-craft a linked list in F95. It wasn't a big deal, but I had to use my mental energy not to make mistakes. If there had been a generic container, I would have definetely used it. In short, I wished I had something like the STL in Fortran 95. Someday. . . . Cheers, Ryo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
