Re: basic_string causes crash in _vsnprintf???

As someone said both StlPort and CString took great pains to support this
functionality so while it was not a standard STL implementation it was an
implementation specific functionality that could be relied upon from those
vendors.

So the code is not proper to the STL standard baseline implementation but it
is valid for the vendor specific implementations that chose to support it.
It is surprising microsoft's implementation does not given stlport chose to.

I agree with the point it is not proper STL usage as per spec of the STL
standard, just we have a lot of code that relied on a specific implementation
that did work well with the ms crt libraries.

The problem with migrating the code is that anywhere a basic_string was used
we have to make sure there are no calls to ANY variable argument methods
which include any printf family of functions. Even closely examining all the
code would not likely guarantee nothing was missed so I'd like to find a way
to make the basic_string work like it used to.

The options I'm considering to have a better guarantee of success:
1. Checking with MS to see if they encountered this and have an option for
their STL to do this (slim chance but worth a check)
2. Go back to using STL port instead of the MS version of STL
3. create an enhanced CString with stl functionality such that any code
using stl like syntax will work and will support the behavior some code
relied upon.

The last option would be to go through every line of code and examine it to
see if c_str() needs to be called, that seems VERY error prone, so seems like
it is not a good option at this point. I need something that will most
definately work and in the shortest time possible (Usual software development
schedules you know :) )







"Stephen Howe" wrote:

> > Thanks. Was just doing internet searches and found the same thing, that
> does
> > in fact work. The problem is we have a half million lines of code that
> was
> > using stlport and that worked in stlport.
>
> You should _NEVER_ code because it sort of ..."works".
> You should code because it is "correct". Correct according to C++ standard.
> No "undefined behaviour" - a technical term according to the standard.
>
> Correct code is more maintainable. You shift compiler vendor it should still
> work even if the vendors implementation is different under the hood.
>
> Even if you 500,000 lines of code that "work" but it turns out that it is
> just an accident that "work", you should make an effort to correct the lines
> of code. It is an error to write code in C++ that relies on some aspect of
> "undefined behaviour" working the way you expect. I regard this as so severe
> that I would correct it immediately, even 500,000 lines of code. And I would
> fire programmers that write "undefined behaviour" code, particularly if it
> turns out there is a decent alternative which works with _ALL_ compilers.
>
> In the case of std::string, getting a pointer to the internal buffer of
> characters means that member function c_str() should be called. And note
> this is constant so you should never attempt to write to that buffer - it is
> read-only.
>
> > So the question is how to avoid
> > having to do that for every string everywhere in the code. Not sure all
> code
> > would be compatible if a changed everything to a CString instead of a
> > tstring... anyone run into this before?
>
> CString allows you to do that operation.
> But these days, implicit conversion operators are frowned on for classes.
> Better to have explicit named conversions - like std::string - less
> unexpected nasty surprises
>
> Stephen Howe
>
>
>
.

Relevant Pages

  • Re: basic_string causes crash in _vsnprintf???
    ... and any other output string sets used. ... want or revert back to the old stl. ... >> this functionality so while it was not a standard STL implementation ... > In STLport it's just luck that it "works". ...
    (microsoft.public.vc.stl)
  • Re: basic_string causes crash in _vsnprintf???
    ... > this functionality so while it was not a standard STL implementation ... In STLport it's just luck that it "works". ... The first pointer points to the start of the string, ... > So the code is not proper to the STL standard baseline implementation ...
    (microsoft.public.vc.stl)
  • Re: C++ Standard Library
    ... Surprisingly, not only does my customer base not want STL, they don't usually want ... 8-bit and 16-bit characters under std::string, and how to move them in and out of CString. ...
    (microsoft.public.vc.mfc)
  • Using STLport with Microsoft Visual C++ 6
    ... Using STLport with Microsoft Visual C++ 6 ... Effective STL. ... was adopted into the draft standard at the July 14, ... Any better C++ template links? ...
    (microsoft.public.vc.stl)
  • Re: C++ Standard Library
    ... Unicode. ... CStrings and 8-bit CStrings, as well as the generic CString which is based on the the ... I use MFC classes from habit, and largely because my customer base doesn't want STL. ... that wouldn't work under a shared MFC DLL scenario. ...
    (microsoft.public.vc.mfc)
Loading