I was reading through the FAQ in the section labeled:

 "When I assign a shorter string to an existing string which contained a
longer string originally the assignment corrupts the heap. How do I fix
this problem?"

It shows the following example which causes the heap to get corrupted when
the last line is executed:

        string  str, str2;
        str = "abcdefghijklmnopqrstuvwxyzabcdefghij" ;
        str2 = str;
                //Workaround, uncomment the following line
                //str.erase() ;
        str = "zyxw" ;

I found the suggested fix rather weak (use xxx.erase()). I poked around in
xstring and found the root cause of this problem in _Copy (copying too
much). This problem could be encountered in other circumstances than the
example shown above so I corrected it in xstring.

This problem is very fundamental and makes the use of strings unreliable.
Certainly others have corrected this problem and presumedly other problems
as well. Could someone be so kind as to direct me to fixes to problems in
this version of the STL.

John Keenan

Well, I would probably have to start that consultancy I dream about.

So I sit and wait for Bill to fix his code for me :(

The STL files supplied with Visual C++ 5.0 show a copyright of 1995... so
we are not dealing with a hot-off-the-press package here. The particular
problem I originally noted is very fundamental and can crop up in numerous
situations. The bug is in _Copy, which is used by _Grow, which is used by
append, assign, insert, erase, replace, reserve, and _Freeze, which in turn
are used by... identifying all the specific cases which will activate this
bug would be difficult (but admittedly not insurmountable). The point is
there *may* be many. Many user must have stumbled across this problem in
the past several years and I am interested in knowing what action was
taken. I have thought of the following cases:

  1) Everyone knows there is a more recent P.J. Plauger STL implementation.
It is at ?????
  2) Use a different STL implementation with Visual C++ 5.0
  3) Fix the root problem in the Visual C++ 5.0 supplied implementation
  4) Add workarounds in user code on a case by case basis
  5) Don't use STL with Visual C++ 5.0
  6) This is a none-issue, I've made a mountain out of a mole hill, stop
whining

 Actually I am extremelly new to STL (one week) and am trying to figure out
how to proceed. I would appreciate any user's guidance.

John Keenan

I would like to echo John Keenan's query about what to do with Microsoft
code which is buggy and / or not very well implemented, especially as this
relates to the standard c++ classes.  There are a number of problems
I have come across and I too have wondered what other people have done to work
with them.  This xstring problem seems to be the worst of the bunch as it is
a real bug and will trash memory.

In response to John, I would suggest checking out other implementations of
the STL classes, especially one called STLport which is based on the SGI
implementation of the standard containers and algorithms of c++.  I also
think fixing the supplied code is workable, but that depends on the
environment you are in.

I do not know of a later Plauger STL implementation (which is really the HP
implementation just modified somewhat I believe) for MSVC.

I definitely don't think this is a non issue.  If more people complained
about these things, Microsoft might respond a bit more quickly.  I'm still
waiting for a compiler implementation that produces correct floating point
optimized code reliably, for instance.  Even after three iterations (SP3)
there are still problems.

-Eric Twietmeyer

There is a later PJP version, but it's not free - check out
www.dinkumware.com for details.

HTH

: I do not know of a later Plauger STL implementation (which is really the HP
: implementation just modified somewhat I believe) for MSVC.

--
/*  Andrew  */
WWW: http://www.halcyon.com/ast        

The reason why this distinction is important to the thread is that looking
for another STL implementation (such as SGI's) will not help solve the
problem John Keenan is talking about.  std::string is not supplied in SGI's
STL implementation.

I have used a version of SGI's STL implementation at home, and I must say
that it is pretty nice.  Although one doesn't typically read library source
code, when the need arises the SGI code is--gasp--readable.  Compared to the
source that MS ships with VC++ there is no contest.  Also, SGI has paid more
attention to exception and thread safety.

The version I use can be found at:  http://www.sirius.com/~ouchida/

It's not the most recent version, but it is the easiest to use with VC++.

John, could you elaborate on the bug fix that you made in xstring.h, I'm
considering implementing it here.

Thanks,

    Chris Hines
    The sooner you start coding, the longer it will take you to finish.

<snip>

        void _Copy(size_type _N)

// ?????????????????????
// Modified the following to correctly use the minimum size

//              {size_type _Ns = _N | _MIN_SIZE;

                {size_type _Ns = _N;
                if ( _Ns < _MIN_SIZE ) _Ns = _MIN_SIZE;

// End of modification

                if (max_size() < _Ns)
                        _Ns = _N;
                _E *_S;
                _TRY_BEGIN
                        _S = allocator.allocate(_Ns + 2, (void *)0);
                _CATCH_ALL
                        _Ns = _N;
                        _S = allocator.allocate(_Ns + 2, (void *)0);
                _CATCH_END

// ?????????????????????
// Modified the following to copy the correct amount.
// This problem was identified in the Microsoft STL FAQ. Search for:
// "When I assign a shorter string to an existing string ..." in the FAQ
// for more information.

//              if (0 < _Len)
//                      _Tr::copy(_S + 1, _Ptr, _Len);

                if (0 < _Len) {
                        size_type number_to_copy = _N;
                        if ( number_to_copy > _Len ) {
                                number_to_copy = _Len; }

                        _Tr::copy(_S + 1, _Ptr, number_to_copy); }

// End of modification

//              size_type _Olen = _Len; // This line removed... variable _Olen not
used... see below
                _Tidy(true);
                _Ptr = _S + 1;
                _Refcnt(_Ptr) = 0;
                _Res = _Ns;

// ?????????????????????
// Modified the following to set the end of string correctly.

//              _Eos(_Olen); }

                _Eos(_N); }

// End of modification

The problem is that this method is not completely responsible for making a
copy (as its name implies). The caller of this method is doing part of the
work by calculating the new desired size which is passed in as argument _N.
The allocation of _S is a function of this new size... however, the copying
into _S was a function of the original size. If the new size was smaller
than the original size, memory beyond the end of _S was corrupted. With the
changes shown above, the end of _S is respected.

HELP!

I am trying to use STL templates in a MFC 5.0 application under Win95. I
keep getting "Undeclared identifier" even if I #include the STL header
files.

I have previously used STL happily under MFC 5.0 (NT) without the need to
explicitly include STL header files but I am now on a different PC.

RS

perhaps you need to use one of the following?

std::whatever

or

using namespace std;

--
---
Andrew Osman
ViewSoft, Inc.
http://www.viewsoft.com
---

HELP!

I am trying to use STL templates in a MFC 5 application under Win95. The
compiler does not recognise any of the STL template classes even I #include
the STL header files.

I have previously used STL happily under MFC 5 (but under NT) even without
the need to explicitly include STL header files but I am now on a different
PC.

Any ideas?

Ravi Sikka

perhaps you need to use one of the following?

std::whatever

or

using namespace std;

--
---
Andrew Osman
ViewSoft, Inc.
http://www.viewsoft.com
---

STLPort (a port of SGI STL) has a rope class, which does what a string
class does and then some.

Check out the documentation found on SGI's STL home page.

Also, AFAIK, string is part of the new "draft" standard of C++, not
necessarily part of the STL (which is part of the "draft" standard).

tom

--
SPAM FILTER ON
remove no and spam from address to email me.

I don't believe the proposed fix will work.
I think both the allocate and _Tr::copy need an _Ns' which is big enough to accomodate
_Len.