Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Programming / CodeWarrior / July 2003



Tip: Looking for answers? Try searching our database.

Problem with std::basic_string::c_str()

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Arvan Pritchard - 09 Jul 2003 16:24 GMT
The standard [section 21.3.6 of ISO/IEC 14882:1998] says this returns
a pointer to a zero-terminated array, but it does not in CodeWarrior
8.3 - for example this sample code

#include <iostream>
int main()
{
    using namespace std;
   
    std::string a=std::string("ab");
    std::string b(a.begin(), a.end());
    const char *c=b.c_str();
   
    cout << c[0] << c[1] << int(c[2]) << endl;
   
    return 0;
}

Prints "ab53" not "ab0".

I suspect that c_str() is just returning data(), and that it's usually
OK because the controlled string is null-terminated. Can anyone tell
me whether this problem is restricted to strings constructed from
iterator pairs?

[I submitted this to Metrowerks a couple of days ago via
http://codewarrior.com/MW/Support/Contact+Support/bug.htm but have not
had an acknowledgement so I don't know if that is working]
Howard Hinnant - 09 Jul 2003 17:48 GMT
| The standard [section 21.3.6 of ISO/IEC 14882:1998] says this returns
| a pointer to a zero-terminated array, but it does not in CodeWarrior
[quoted text clipped - 20 lines]
| me whether this problem is restricted to strings constructed from
| iterator pairs?

Yes, this bug is restricted to strings constructed from iterator pairs.
My apologies for the time this bug has cost you.  And thank you for
reporting it.

Fortunately there are several ways to proceed from here:

1.  You can fix the bug:

Open <string> and go to line 1994.

Change:

        traits::assign(*(data_ + n), charT());

to:

        traits::assign(*(data_ + size_), charT());

Recompile your MSL libraries.

2.  This bug is only present in the non-refcounted version of string.
You could comment out _MSL_NO_REFCOUNT_STRING in <mslconfig> and
recompile the MSL libraries.  string will now be refcounted.

3.  There is a new <string> in the Thrill Seekers Folder of the
Reference CD.  This is actually a preview of the Pro 9 <string>.  It is
not refcounted, and implements the "short string optimization".  I
recommend it.

Rename your string to string.bak.  Copy the string from Thrill Seekers
into your MSL_C++/MSL_Common/Include/ and recompile your MSL libraries.

| [I submitted this to Metrowerks a couple of days ago via
| http://codewarrior.com/MW/Support/Contact+Support/bug.htm but have not
| had an acknowledgement so I don't know if that is working]

My apologies again.  The Austin offices are in the middle of a move,
and our service is not up to our usual standards this week.  Thanks
again for submitting the bug, and for following it up here.

If for some reason none of the above alternatives are viable for you,
or if you have further problems, please post back here, or feel free to
contact me directly.

Signature

Howard Hinnant
Metrowerks

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.