Re: Is Linux Unix?
Erik Steffl <email@example.com> wrote in message news:<2qwt0-7TLfirstname.lastname@example.org>..
[. . .]
> 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. . . .