James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|>  efrem@dti.net (Efrem J. Sternbach) writes:
>|>
>|>  >This note is to call attention to a serious problem with current STL
>|>  >implementations (including the ANSI C++ draft versions).
>|>
>|>  The ANSI C++ draft doesn't specify the implementation.
>|>
>|>  The problem you note may well exist, but it is a problem in the current
>|>  STL implementations, not in the draft ANSI/ISO C++ standard.
>
>This may be true for the specific problem he mentions, but what does the
>draft say should happen if, in "vector< T > v( 5 )", the copy
>constructor for T throws an exception when constructing the third
>element in the vector?
>
>My understanding is that if the standard doesn't say anything, it is
>undefined behavior.  In which case, the standard STL is practically only
>usable for the basic types, pointers, PODS and very basic classes like
>complex.

What you say is entirely correct (of the current draft), but I don't
see the relation with my post.  Efrem J. Sternbach pointed out a
supposed problem in the draft.  I pointed out that the problem was
really with some current implementations, not the draft.  You raised an
entirely different problem.  Sure, it's a problem.  I never claimed
the current draft didn't have any problems!

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

This note is to call attention to a serious problem with current STL
implementations (including the ANSI C++ draft versions). This concerns the
treatment of memory. Specifically, containers such as deque, and the
associative containers use internal buffers to avoid constant allocation
and deallocation of memory off the heap. The problem is that all the
implementations I have seen "hardware" this buffer to be at least 4K bytes of
memory.

In my own work I typically have containers containing up to 50 or 100
elements of small size. These elements might be pointers or perhaps a date
class expressed as a julian date(unsigned long). In any case the size of
each element will not be much more than 4 bytes. Doing the math can
demonstrate that if a buffer is at least 4K bytes, then 90% or more of the
memory allocation is wasted! Having a large number of containers only
compounds this problem.

The original HP implementation of the allocator class had a method
init_page_size() that was used to set the buffer size. This allowed one to
at least specialize an allocator to use a smaller buffer. Since this
allocator method did not make it into the ANSI C++ draft this "fix" is not
available in all cases.

For those who have not personally encountered the same problems I have
just described, I refer you to the article "STL Gotcha's" by Jack Reeves
in the January 1997 issue of C++ Report.

In current implementations, STL code reflects the experience and perhaps
prejudices of the original designers.  If STL is to fulfill its promise as
a general and efficient code for containers then changes need to be made.
I am open to any ideas that allow the efficient use of memory.  Personally
I would be happy to see a "reserve" function such as vector already has
added to all the container classes to indicate the expected maximum number
of elements.  In any case, if nothing is done then STL style containers will
be unusable for a wide variety of applications.

--
Dr. Efrem J. Sternbach
Insight Risk Management Consulting
12 East 22nd Street, Apt. 10F
New York, NY 10010
212-982-9704     fax : 212-780-0533
email: efrem@dti.net
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

efrem@dti.net (Efrem J. Sternbach) writes:

> This note is to call attention to a serious problem with current STL
> implementations (including the ANSI C++ draft versions). This concerns the
> treatment of memory. Specifically, containers such as deque, and the
> associative containers use internal buffers to avoid constant allocation
> and deallocation of memory off the heap. The problem is that all the
> implementations I have seen "hardware" this buffer to be at least 4K bytes of
> memory.

This is a problem, yes.  The first piece of good news: it isn't a
problem with the standard.  There is nothing in the draft C++ standard
that requires that containers maintain their own free lists, let alone
anything that requires a particular free list size.  This is a
"quality of implementation".

The second piece of good news: the original HP STL was rather lavish
in its use of memory (you would, indeed, waste 4K bytes if you
inserted a single element into an empty vector), but more recent
implementations do not have this problem.  The implementation that I'm
most familiar with, the SGI STL (http://www.sgi.com/Technology/STL)
does not waste memory this way.

(Incidentally, deque is a special case: deque does sometime allocate
more memory then you ask for.  This is inherent in the nature of the
data structure.  Deques are rather specialized, though, and you
probably shouldn't use them unless you have a specific reason.)


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

efrem@dti.net (Efrem J. Sternbach) writes:

>This note is to call attention to a serious problem with current STL
>implementations (including the ANSI C++ draft versions).

The ANSI C++ draft doesn't specify the implementation.

The problem you note may well exist, but it is a problem in the current
STL implementations, not in the draft ANSI/ISO C++ standard.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

|>  efrem@dti.net (Efrem J. Sternbach) writes:
|>
|>  >This note is to call attention to a serious problem with current STL
|>  >implementations (including the ANSI C++ draft versions).
|>
|>  The ANSI C++ draft doesn't specify the implementation.
|>
|>  The problem you note may well exist, but it is a problem in the current
|>  STL implementations, not in the draft ANSI/ISO C++ standard.

This may be true for the specific problem he mentions, but what does the
draft say should happen if, in "vector< T > v( 5 )", the copy
constructor for T throws an exception when constructing the third
element in the vector?

My understanding is that if the standard doesn't say anything, it is
undefined behavior.  In which case, the standard STL is practically only
usable for the basic types, pointers, PODS and very basic classes like
complex.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]