I followed Microsoft's instructions in the STL "readme" file for Visual C++
4.0.  I also added helper code and documented solutions to common problems.

This code is unique in that it allows STL to work with CString.

The code has been tested extensively with MFC applications.

The files are available at:

FTP:  ftp.rahul.net/pub/terris/stl.zip
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <4c6lnb$8pe@hustle.rahul.net>, terris@rahul.net says...
>
>I followed Microsoft's instructions in the STL "readme" file for Visual C++
>4.0.  I also added helper code and documented solutions to common problems.
>
>This code is unique in that it allows STL to work with CString.
>
>The code has been tested extensively with MFC applications.
>
>The files are available at:
>
>FTP:  ftp.rahul.net/pub/terris/stl.zip

Hi, Terris. I grabbed your headers; thanks for the work, especially the
CString and Ptr stuff.

I'm having a minor problem with Iterators using the Ptr class for collections
containing pointers. I don't know if it's a VC 4.0 problem, or a
language/class problem. iterator::operator!= causes an error regarding
ambiguous operators during a compile. Reversing the sense, that is:
!(iter1==foo.end()), works fine. For example:

  #include <list.h>
  #include <ptr.h>

  class foo { };
  typedef std::list<Ptr<foo> > FooCollection;
  typedef FooCollection::const_iterator FooConstList;
  ....
  extern FooCollection & rFoo;
  for (FooConstList p(rFoo.begin());
        p != rFoo.end();    // compile error here, ambiguous operator==
        p++)
    ;

  for (FooConstList p(rFoo.begin());
        !(p == rFoo.end()); // compiles fine, works fine
        p++)
    ;

The workaround is not very horrible, and allows work to continue. Have you any
thoughts on what the problem might be? The obvious "fix" of defining
iterator::operator!= has occured to me. This would appear to be a very
intrusive change on the STL collection classes, and somewhat undesireable.

Mike.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]