Re: Replacement for MS STL?
Garry W wrote:
Here's another STL bug I found -
#2: Instance of illegal "pointer" usage (or non-usage).
I am doing something unusual: I'm providing my own definitions for
allocator::pointer and allocator::const_pointer. (I have a persistent - i.e,
memory-mapped - database to store that "huge" amount of data I have. The
persistent database requires the unusual pointers.) Doing something unusual
always provides excellent opportunities for interesting bugs.
Specifically -
In the file "xstring" near line 2045 occurs this definition of std::string
character storage:
union _Bxty
{ // storage for small buffer or pointer to larger one
_Elem _Buf[_BUF_SIZE];
_Elem * _Ptr;
} _Bx;
First error is that the intrinsic-pointer usage "_Elem *" is obviously wrong
- it has to be rebind<_Elem>::pointer or something. There shouldn't be any
naked pointers to elements in stored STL data.
More subtle error is that even with that change the program would still be
wrong: the arbitrary type "pointer" =may= have constructors (or destructors
or assignment ops.) Mine do. And types that have any of those things are
illegal within C++ unions.
The implementation is allowed to assume that allocator::pointer ==
allocator::value_type* (see 20.1.5/4). Certainly, STLport makes that
assumption AFAIK, though Dinkumware comes quite close to avoiding making it.
I only know of one implementation that works with completely custom
pointer/reference types, and that's the one in the boost shared memory
library, which hasn't been released yet (see
http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/shmem/quick_guide.html#shmem.qg_shmem_container)
To achieve the equivalent effect of constructor-in-union, you might instead
do a bit of fancy footwork with alignment guarantees, manual
construction/destruction at the proper moments, and accessors that do
reference casts. At least, that's what I did in my quick work-around, except
for putting in the alignment guarantee (my own pointers didn't need it.)
Right. Dinkumware should perhaps investigate what changes (or "fixes")
they need to make to allow their containers to work with Boost::shmem.
You've reported a lot of non-bugs! Other STL implementations have all
the problems you mention, and more (e.g. STLport can't mix debugging and
non-debugging iterators either).
Tom