[ charter | policy | FAQ ]
Quoting from the charter: comp.std.c++ is for technical announcements and discussion of the ANSI/ISO C++ standardization process and the C++ standard, and for discussion of the design and standardization of the C++ language and libraries. Other discussion that is directly related to the C++ standard (not related merely to C++ programming techniques) is also welcome. Posts should be cogent and free from personal attacks.
RFC 1855 (Netiquette Guidelines, by Sally Hambridge) describes generally accepted standards that apply to comp.std.c++ as well as to other Usenet newsgroups.
Further information about moderation policy can be found at http://www.comeaucomputing.com/csc/policy.html.
If you're talking specifically about the C++ standard, or about how the C++ language itself is designed, or about recent changes to the language, then your post probably belongs in comp.std.c++. If you're talking about how to write C++ programs (if you want to know how to do something in C++, for example), then your post probably belongs in comp.lang.c++.moderated or comp.lang.c++. If you're talking about general issues that aren't unique to C++ (algorithms, for example, or object-oriented design), then you might want to consider comp.programming, comp.lang.misc, or comp.object.
Finally, most of the popular platforms (Unix, OS/2, MS-Windows, Macintosh, and so on) have their own groups. Topics that apply to some particular platform, rather than to C++ in general, should go to one of those groups.
You should be able to use your ordinary newsreading software: if things are set up properly, an article that you "post" to comp.std.c++ will automatically get forwarded to one of the moderators. If that doesn't work, though, you can mail your article to firstname.lastname@example.org; this is less convenient than using your newsreader, but probably more reliable.
Because of differences in time zones, and other factors, it can take 24 hours for your article to finish its travels and appear at your news site. If your article is not accepted (which will occur only if it doesn't meet the fairly loose criteria described here and in the document describing our moderation policy) your article will be returned directly to you by the moderator with an explanation. If you submit an article and it isn't rejected and it doesn't appear in comp.std.c++ after two days, please send mail to the contact address email@example.com asking if it was received. Please do not just resubmit the article. Please also realize that if you don't provide a valid email address, the moderators cannot notify you if the article is rejected!
Note that crossposted articles often take longer to appear, largely because they involve more work for the moderators. This is especially true of articles that are crossposted to more than one moderated newsgroup.
Cancelling an article doesn't work for moderated newsgroups. If you accidently hit "send" before you are finished composing the article, immediately send email to the contact address firstname.lastname@example.org with a copy of what you want cancelled, so the moderators can match the cancel request with the article. If you realize you made a mistake some time after sending the article, then you should wait for the article to appear and then post a followup containing the correction.
Comp.std.c++ is moderated by panel: an article sent to email@example.com is automatically mailed to one of the moderators. If you want to get in touch with the moderators (if you want to discuss moderation policy, for example), you should send mail to firstname.lastname@example.org. Mail sent to that address will be forwarded to all of the moderators.
At present, there are five moderators:
Is there an archive of comp.std.c++ postings?
We (the moderators of comp.std.c++) don't maintain such an archive, and we don't know of anyone who does. Google Groups, however, does save articles from comp.std.c++. (as well as all other newsgroups.)
comp.lang.c++ is for general discussion about C++ programming, and comp.lang.c++.moderated is a moderated newsgroup for general discussion about C++ programming. You should probably read the comp.lang.c++ FAQ list, available in HTML form on Marshall Cline's WWW site and in plain text form on rtfm.mit.edu. Bjarne Stroustrup also maintains a list of C++ resources online. See also question B.1.
The comp.std.c++ FAQ is currently maintained by James Dennett, one of the newsgroup's moderation panel. He can be contacted at email@example.com. Corrections and suggestions are welcomed.
To get a copy from ANSI, visit the ANSI web store.
For a paper copy, go to http://www.ansi.org. Choose Catalogs/Standards Information, then "ANSI-ISO-IEC Online Catalog". Search for "14882".
Designation: ISO/IEC 14882-1998
Title: Information Technology - Programming Languages - C++
Price per copy (US dollars): $175.00
To download an electronic copy, go to http://webstore.ansi.org/ansidocstore/default.asp. The document is in PDF format, 2794Kb in size, readable by the free Adobe Acrobat reader. The price (US dollars) is $18.00.
The current (2003) version of the C++ Standard is also available in book form, from John Wiley and Sons Ltd; its ISBN is 0470846747. The cost of this book is lower than the cost of a paper copy from ANSI, and it is widely available in bookstores.
You can view the earlier public-comment version (December 1996) at http://www.open-std.org/jtc1/sc22/open/n2356/.
The public-comment version is similar to the 1998 standard, but differs in many details. The current standard is different again in that it includes many corrections to the 1998 standard. You should not rely on the public-comment version for detailed answers to C++ questions.
I'm looking for a more recent free version of the draft standard than the public comment version. Why can't I find any copies online?
The public comment versions are the only ones that are supposed to be publicly circulated; interim working papers contain editorial comments, portions that are known to be unstable, and so on.
From a legal (copyright) perspective, the C++ committee is not authorized to distribute any versions except the public-comment versions, and Committee members have been asked not to make other versions publicly available.
If you want to follow the standardization process, you may either get information from a colleague who is on the committee, or else join the committee yourself. Membership is open to all.
As Bjarne Stroustrup wrote:
I guess that everything good ought to be free. However, it costs quite a bit to run a standards organization, to create a standard, and to produce and/or distribute copies. Therefore, the question becomes "who pays?"
The standards organizations cleverly finance the actual creation of standards by having them written by volunteers who are charged for the privilege of doing the work. That works reasonably well.
This leaves the problem of maintaining a standards organization, production of standards documents (for people who prefer paper), and distribution. It may seem a good idea for governments to finance this. However, people don't like to pay taxes, so governments have been increasingly unwilling to subsidize ISO, ANSI, BSI, AFNOR, etc. This leads the stadards organizations to look for sources of income to cover their costs.
Given that, I think the US$18 that ANSI charges for the pdf version of the C++ standard is reasonably cheap. If that's too much, get the free slightly-out-of date draft that the C++ standards committee issued for public comment (you can find links to both on my home pages).
One thing to bear in mind is that a standard is not a tutorial. Most people (including all novices) are better off with a good textbook. Experts who really need a standard are (by the standards organizations) assumed to be able to afford it.
The "C++ Committee" is really two committees in one: a United States committee, and an international committee.
The Information Technology Industry Council in the US sponsors InterNational Committee for Information Technology Standards (INCITS) (formerly called X3), a standards body accredited to the American National Standards Institute (ANSI). None of these bodies are part of the government, but their members come from academia, industry, and individual government agencies. INCITS charters individual committees to create and maintain standards documents. Each member of a committee represents some organization, but not a country. A self-employed person can represent self. Each organization gets one vote.
For C++, that committee is J16. (Formerly called X3J16.) The J means "programming languages", and the 16 means it is the 16th J committee to receive a charter.
The International Organization for Standardization (ISO) is an independent body composed of member nations. Each member of an ISO technical committee attends on behalf of his or her nation, each nation getting one vote. Each nation determines for itself how its members are selected. For C++, the technical committee is SC22/WG21 (Steering Committee 22, Working Group 21), under JTC1 (Joint Technical Committee 1). The US representative to WG21 is a member of J16, and casts the US WG21 vote according to the majority vote of J16. In effect, the technical representatives of the US to WG21 comprise the entire J16 committee. (It is actually not that simple, but it is a reasonable approximation.)
The C standard was created by J11 (formerly X3J11). After it was complete, an ISO committee (SC22/WG14) was formed to create the ISO C standard. At the time, document format requirements of ANSI and ISO were different, so there were for a time two standards. ANSI worked with ISO to find a way to avoid in the future creating two "standards". For C, ANSI adopted the ISO version of the C standard, and now publishes that as the ANSI standard; there is only one C standard now.
For C++, the INCITS and ISO committees meet together and published a single standard.
That depends on the procedures of your country. In the US you would join J16, in Britain you would contact BSI, in France you would contact AFNOR, DIN in Germany, and so on.
Two kinds of membership in the committee are possible: Principal member and Advisor. ("Advisor" was formerly known as "Observer".) Both kinds of members have the same privileges in their access to the committee documents and any information related to the committee work and distributed by the committee or by the InterNational Committee for Information Technology Standards (INCITS) Secretariat. (INCITS was formerly known as X3). As of 2008, both kinds of members pay $1200 membership fee per year, which includes an unlimited number of alternate members.
Committee documents are made available before and after each of the meetings. Currently there are 2 or 3 meetings per year. Documents submitted in electronic format (PDF, HTML, or plain ASCII) are posted on a controlled web site.
After consultation, INCITS have now withdrawn the option of having paper copies of all documents mailed for an additional fee.
The Principal member is expected to take work assignments and cannot miss more than one out of any three consecutive meetings. In exchange, the Principal member has voting rights and is allowed an alternate (no additional fee is charged for the first alternate) who can replace the Principal at some meetings or participate together with him/her. Only one Principal member can represent any organization or individual. The Advisor has no obligations except for membership fees and can attend or skip any or all meetings. All documents are available to the Advisor regardless of his/her presence at meetings.
ANSI supports an "open door policy", which means that any person from the international community and any non-US organization can also join the technical committee as a Principal member or an Advisor.
To apply, send an application form with information about you and/or your company and how your business depends on C++ standardization. Indicate the name of the ANSI C++ standard committee (J16) and what kind of membership you are applying for. The form is available at http://www.incits.org/membership/membership.pdf or in HTML format at http://www.incits.org/membership/mem_app.htm.
Address this letter to:
1250 Eye Street, NW
Washington, DC 20005
Please also send copies of this letter to the J16 chair and vice-chair:
Stephen D. Clamage
You can contact individual members or officers of WG21 or J16. You can submit comments during public-comment periods via the announced procedures. (They have been announced in comp.std.c++; also see INCITS's press release) You can post comments and questions to comp.std.c++.
The table below describes the schedule from before approval of the FCD.
The ISO side of the C++ committee is WG21, which is under SC22, which is under ISO/IEC JTC1. "CD" means Committee Draft, the draft standard which is voted on. When a Final CD (FCD) is accepted, it becomes a Final Draft International Standard (FDIS).
After final approval, the FDIS becomes an International Standard (IS). Once the standard has reached FDIS stage, it may be cited publically as the "Final Draft International Standard for C++."
In November 1997, the C++ Committee voted to approve the draft dated December 1997 as the "Final Draft International Standard" (FDIS), and forwarded it to ISO to be sent to member nations for a final vote. The first C++ standard (ISO/IEC 14882:1998, Programming Language -- C++) was approved on July 9 by a unanimous 20-0 vote. Formal publication occurred Sept 1, 1998.
Between 1998 and 2003, the work of the C++ Committee involved evaluating Defect Reports (reports from any source of possible errors and requests for clarification), and publishing corrections, resulting in the updated C++ Standard ISO/IEC 14882:2003.
The C++ committee has formally registered its intention to update the C++ standard, adding significant new library and language functionality, and has a current target of releasing an updated standard in 2009.
In 2006 the Library Working Group published a Technical Report (informally, TR1) including a number of new library components. While not formally a Standard, this TR is expected to provide experience with the proposed features, many of which have been incorporated into the latest versions of the Working Paper.
|03/96||Santa Cruz, CA||WG21||Meeting #15.|
|07/96||Stockholm, Sweden||WG21||Meeting #16. Resolve technical issues in FCD draft.|
|11/96||Kona, HI||WG21||Meeting #17. Complete FCD draft.|
|12/96||SC22||FCD ballot, and ANSI public-comment period.|
|03/97||Nashua, NH||WG21||Meeting #18, ANSI public-comment period ends.|
|06/97||WG21||FCD balloting ends.|
|07/97||London, England||WG21||Meeting #19, Begin resolving FCD comments|
|11/97||Morristown, NJ||WG21||Meeting #20. Complete FDIS draft.|
|03/98||Sophia Antipolis, France||WG21||Meeting #21.|
|04/98||JTC1||FDIS ballot 2 months.|
|09/98||WG21||Publication of IS.|
|10/98||Santa Cruz, CA||WG21||Meeting #22. Begin evaluating Defect Reports.|
|04/99||Dublin, Ireland||WG21||Meeting #23.|
|10/99||Kona, HI||WG21||Meeting #24.|
|04/00||Tokyo, Japan||WG21||Meeting #25.|
|10/00||Toronto, Ontario||WG21||Meeting #26.|
|04/01||Copenhagen, Denmark||WG21||Meeting #27.|
|10/01||Seattle, Washington, USA||WG21||Meeting #28.|
|04/02||Curaçao, Netherlands Antilles||WG21||Meeting #29|
|10/02||Santa Cruz, CA, USA||WG21||Meeting #30|
|04/03||Oxford, England||WG21||Meeting #31|
|10/03||Kona, HI, USA||WG21||Meeting #32|
|04/04||Sydney, Australia||WG21||Meeting #33|
|10/04||Redmond, WA, USA||WG21||Meeting #34|
|04/05||Lillehammer, Norway||WG21||Meeting #35|
|10/05||Mont Tremblant, Quebec, Canada||WG21||Meeting #36|
|4/06||Berlin, Germany||WG21||Meeting #37|
|10/06||Portland, OR, USA||WG21||Meeting #38|
|04/07||Oxford, England||WG21||Meeting #39|
|09/07-10/07||Kona, HI, USA||WG21||Meeting #40|
The Annotated C++ Reference Manual (usually referred to as the ARM), by Ellis and Stroustrup, essentially covers what C++ was before WG21/J16 convened. It consists of a formal reference manual interspersed with explanatory comments, and is very valuable even though it is somewhat out of date. The Design and Evolution of C++ (usually referred to as D&E), by Stroustrup, is less technical and more historical. It is also more up to date: it includes many of the changes in C++ since the ARM was published. D&E is useful because it discusses language design decisions in detail, including ideas that were ultimately rejected. Both books are published by Addison-Wesley.
Finally, The Draft Standard C++ Library, by Plauger (published by Prentice Hall), is also useful: it is the basis for some of the text in the working paper. There were major changes just after the book was published, unfortunately, and the C++ standard library in the IS no longer bears much resemblance to the one Plauger describes.
You should probably read the ARM and D&E before posting to this group.
See the discussion in D&E: it's possible that your idea has already been considered and rejected, or that a similar proposal is being considered. D&E also has some comments about extension proposals in general.
Work towards the next C++ standard, intended for release in 2009, is well underway, and its major features have been established by this time. The Library Working Group is still accepting proposals, but they are not expected to form part of C++09, but rather to form part of future Technical Reports.
At the moment the committee's time is split between handling reported defects in the standard and considering proposals for changes and extensions.
Some of the first proposals to go before the committee have come from the Boost group, see http://www.boost.org/.
Informally, most members "have a little list" of pet topics they plan to bring up. Many good ideas have also been posted to comp.std.c++, and many committee members read and participate in those discussions.
If you have some feature in mind, you should post it to comp.std.c++. It will get some discussion and refining without the need to wait for the committee to be ready to review it. If some vendor, or g++ contributor, likes the idea, it might even get implemented, and have the advantage of being "existing practice."
You should submit a defect report to the standardization committee; see Question B13 for details.
ISO (the International Organization for Standardization), which is ultimately responsible for the C++ standard) has a single mechanism called Defect Reports for reporting problems and asking for interpretations.
A DR is not a request for an extension or a suggestion for a change. A DR is not an opportunity to have someone teach you C++. A DR reports an apparent error, inconsistency, ambiguity, or omission in the published final standard (ISO/IEC IS 14882:1998, Programming Languages -- C++). Examples: The standard
If a submitted DR is accepted, the C++ Committee eventually prepares a formal response. The response might be that no defect exists. If the Committee agrees that a defect has been identified, it will eventually adopt a formal resolution. The resolution might be to ignore the defect, or to correct it and publish the correction in a Technical Corrigendum (TC). The first TC to the 1998 Standard was issued in 2003. (The standard itself can comes up for review in 2003. At most 2 TCs to any version of the standard can be published.)
As a procedural matter, a submission is known inside the Committee as
an "issue", until it is either closed or elevated to DR status. Two lists
of issues and DRs currently before the Committee are now available on two
public Web sites:
The open-std site is the official public web page for the C++ committee.
The "core language" issues concern primarily clauses 1-16 of the C++ standard. The "library" issues concern primarily clauses 17-27 of the standard. There is some overlap, and some of the Annexes are covered by both lists. The lists are updated several times per year.
The lists include proposed resolutions. A "proposed resolution" reflects the best judgement of the C++ Committee as of the last revision date of the issue. It has no official weight, and does not override the contents of the standard. It provides guidance as to how the issue is likely to be officially resolved in a TC.
If you believe you have found a defect in the latest publically available draft of the standard, first review the lists on the web site to be sure it has not already been submitted. It wastes everyone's time (including yours) to process duplicate reports.
Assuming your defect is not already in the lists, the simplest way to submit a DR is via the moderated Usenet newsgroup comp.std.c++. The moderators of that newsgroup have agreed to act as a preliminary filter, and forward reasonable-looking DRs to the C++ Committee for consideration. Post your submission to that newsgroup, or send it by email to firstname.lastname@example.org.
Prepare your submission following these guidelines:
No particular format is required, as long as the guidelines above are followed.
The submission should be plain ASCII text, not html, not anything formatted
for a word processing program. The language should be English. (Your English
writing need only be understandable. No DR will be rejected because of
incorrect grammar or spelling.)
"How can I create and use a stack of strings? I can't figure it out from the material in clauses 21 and 23."
Not a DR. The standard is not meant to be a tutorial, and is not suitable for trying to learn the language. You can ask the question in a usenet C++ newsgroup, or send it to a C++ magazine that offers a Q&A column, or read a C++ textbook.
"The standard is defective because the library does not contain a hash table template."
Not a DR. Despite the clever use of "defective", it suggests a substantial addition.
"The stuff about errno isn't clear."
Not a valid submission. It doesn't say what isn't clear, and doesn't identify the parts of the standard that aren't clear.
"In Section 188.8.131.52 [lib.headers] and 19.3 [lib.errno] it is unclear whether errno must be a macro."
A valid submission, although more detail would be better. (A more elaborate DR has already been submitted on this subject.)
"Section X.Y.Z [foo.bar] paragraph 18 says 'time flies.' Is that a statement about time, or a requirement to measure the flight of insects?"
Probably a valid submission. You should first check to see whether the explanation already exists elsewhere in the standard. Check the document index, or search the document if you have an electronic version. In addition, it is common for the introductory paragraphs of a clause to be imprecise (to provide an overview) with detailed explanations appearing later.
The moderators of comp.std.c++ will verify that the guidelines have been followed. If they find that the guidelines have not been followed, the submission will be returned to you with an explanation. You can submit a corrected version if you wish.
If the moderators agree that the submission follows the guidelines, they will forward it to the C++ committee, where it will be processed as explained above. The moderators will also post your submission in the comp.std.c++ newsgroup. That posting will serve as your acknowledgement. (If accepted by the C++ Committee, your submission will also eventually appear in one of the issues lists.)
If you feel that your submission has been unfairly rejected by the newsgroup moderators, you can submit it directly to the ISO National Body for your country. In the US it is ANSI; in the UK it is BSI; in France it is AFNOR; in Germany it is DIN. Try the ISO home page for contact information.
If you cannot locate an appropriate National Body, the UK delegation to the C++ Committee has volunteered to act as ombudsman. If all else has failed and you still think you have a valid DR, you can submit it to them via Francis Glassborow.
The rules for qualification conversions (standard conversions that add const or volatile specifiers) are given in section 4.4 of the draft standard. T** to const T** is not a qualification conversion; this is not an oversight, but is necessary to preserve const safety. Consider the following. (This example was provided by James Kanze, but the general idea behind it is well known.)
const char c = 'a'; char* p; char** pp = &p; const char** ppc = pp; // Supposing that this were not illegal. *ppc = &c; // Oops: where does p point? *p = 'b'; // And what is wrong here?The rules in section 4.4 of the draft standard prohibit this sort of error.
There have been at least three different versions of auto_ptr in various drafts of the C++ standard; the differences all have to do with transfer of ownership. (The original auto_ptr proposal avoid all of this complexity by forbidding transfer of ownership.)
There is a discussion of auto_ptr on Scott Meyers's More Effective C++ Web site. This discussion includes the final proposal for auto_ptr as defined in the C++ standard.
The committee considered proposals for a range of smart pointer semantics, including garbage collection and reference counting. Garbage collection was considered too ambitious, and indeed the state of the art has already moved past the proposals then before the committee. Reference counting elicited heated disagreements: some thought it useful, others disagreed as to what semantics it should have, and still others thought it inefficient. In the end only auto_ptr was accepted.
Many of the changes are summarized in Appendix A of Stroustrup's book The C++ Programming Language (second edition or later). If you have an older printing of that book, you can get an updated version of the appendix from ftp://ftp.std.com/AW/stroustrup2e/new_iso.ps. Also, many of these changes are discussed in Sean Corfield's C++ Beyond the ARM site.
Here are a few of the changes. Templates and exceptions are no longer "experimental". Templates may be used for non-virtual member functions, as well as for functions and classes. Templates may be partially specialized---that is, a template specialization may itself be templatized. Class template parameters may have defaults. Function template parameters are still deduced from argument types, but it is now also permitted to specify the parameters explicitly. The binding of names in template functions has been clarified, and a new keyword, typename, may be used to resolve some cases that would otherwise be ambiguous. Member functions of derived classes may have covariant return types. Run-time type identification (RTTI) has been added to the language. There is no longer any reason to use C-style casts: you should use static_cast, dynamic_cast, const_cast, or reinterpret_cast instead. A namespace mechanism has been added to the language; the keywords using and namespace deal with that mechanism. The use of file-scope static functions is deprecated in favor of functions declared within an unnamed namespace. It is possible to declare variables in the test expression of if, for, while, and switch statements. (But not do statements.) The scope of variables declared in a for loop no longer extends past the end the end of the loop. C++ now has a boolean type, bool, with manifest constants true and false; the built-in relational operators have been redefined to return bool instead of int. You can restrict the application of single-argument constructors with the explicit keyword, and you can use the mutable keyword in class definitions to declare that members in otherwise const objects can actually be changed. The language now has an extensive standard class library; the STL, or Standard Template Library (a container, iterator, and algorithm library) is integrated into the standard C++ class library.
The following Web sites contain STL information.
You might also want to look at one or more of these books:
The SGI implementation is available from http://www.sgi.com/tech/stl/, and the original HP implementation is available from ftp://butler.hpl.hp.com/stl and ftp://ftp.cs.rpi.edu/pub/stl.
A widely ported implementation based on the HP/SGI STL and supporting extensive debugging facilities as well as versions optimized for speed is available from the STLPort project.
Also, versions 2.7 and later of libg++ (the GNU C++ library) include a version of the STL that works with GNU C++. GNU C++ version 3.0 and later includes GNU's libstdc++ v3, which conforms much more closely to the C++ Standard.
Note that several companies, including Modena, Rogue Wave, Plum Hall, Dinkumware, and ObjectSpace, also sell commercial implementations.
Daveed Vandevoorde has written a partial implementation of the valarray templates; you can get it from ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray. Modena has written a partial implementation of the string template and made it freely available; it is called bstring.h, and you can get it as part of the source code for David Musser's and Atul Saini's book.
The most recent version of libstdc++ (the C++ library supplied with gcc) implements much of the standard library. Most of the commercial library vendors also sell implementations.
STLport is an Open Source free implementation of the complete C++ standard library. It is available for download at http://www.stlport.org.
The first compilers which support all of the features of modern C++ have appeared during 2002. Most compilers implement most, but not all, of the post-ARM changes.
Version 4.3 of Comeau Computing's C++ compiler, based on the EDG frontend, claims full support for the language, and when used in conjunction with Dinkumware's library supports the whole of standard C++. Most leading compilers have fairly complete support, although some features such as partial ordering of function templates and export support are often lacking.
Since the C++ standard has been finalized, many books about standard C++ have appeared. Two such books are the third edition of C++ Primer, by Stanley Lippman and Josée LaJoie (Addison-Wesley, 1998), and the third edition of The C++ Programming Language, by Bjarne Stroustrup (Addison-Wesley, 1997). The C++ Programming Language is now in its sixteenth printing; if you have an earlier printing, you may wish to see the list of errata. One book that describes the entire standard library (but not the core language) is The C++ Standard Library - A Tutorial and Reference by Nicolai M. Josuttis (Addison-Wesley, 1999). (Formerly available as Die C++-Standardbibliothek)
Automatic type conversions are dangerous in general, since the compiler can apply them even when you don't intend for a conversion to occur. The conversions can result in ambiguities, or can turn invalid code into legal code that does the wrong thing.
In the specific case of an automatic char* conversion from string, you could wind up unexpectedly with a pointer to the internals of a string object. Such a pointer could easily become a dangling (invalid) pointer when the contents of the string were reallocated, or if the lifetime of the string object ended while the pointer still existed.
Worse, it is intended to be allowed by the standard for strings to use a reference-counting implementation. If you could change the contents of a string, you might unknowingly change the contents of other strings that shared the data.
You can get a conversion to const char*, but you must ask for it explicitly by calling member function c_str(). The explicit function call reminds you to be careful about lifetimes. You can copy the string contents to your own char array and then do anything you want with it.