Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: =?UTF-8?B?RGFuaWVsIEtyw7xnbGVy?= Newsgroups: comp.std.c++ Subject: Re: Defect Report: Wordings on basic_string::data() disallow small-string optimization Date: Sun, 28 Aug 2011 11:07:42 -0700 (PDT) Organization: A noiseless patient Spider Lines: 82 Sender: std-cpp-request@vandevoorde.com Approved: stephen.clamage@oracle.com Message-ID: References: <4E591721.2020208@f2.dion.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: news.albasani.net lSDDljXYYZZVpjwmN3bup0UZhpEC8XkSSLwekY8gc2FkhLhD2OoV81h92PaehdHl069Fhirs9NafBbLoAPPitg== NNTP-Posting-Date: Sun, 28 Aug 2011 18:07:44 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="2tqMNA6CkJ8gYaIqE7k3vPlC586LD3POu5rfeKrHfpyJ9kki46ene3zt8IqbZhLzoh64Um7n3jXER+gCEvBceohLM8gaNIy2dIx7C9WBeFanhF6eT7m7LiFDjbeCzWdZ"; mail-complaints-to="abuse@albasani.net" X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:J/RAfU0s27x/zGR3O0yaqGC7zzI= X-Original-Date: Sun, 28 Aug 2011 18:21:18 +0200 Xref: x330-a1.tempe.blueboxinc.net comp.std.c++:265 Am 28.08.2011 17:42, schrieb Kazutoshi Satoda: >> You cannot make normative conclusions from this code, because it invokes >> undefined behaviour. This is so, because the expression >> >> x = std::move(str) >> >> calls a function that (potentially) invalidates the pointer returned >> fromstr.data(), based on 21.4.1 [string.require] p6: >> >> "References, pointers, and iterators referring to the elements of a >> basic_string sequence may be invalidated by the following uses of that >> basic_string object: >> � as an argument to any standard library function taking a reference to >> non-const basic_string as an argument.(footnote) >> � Calling non-const member functions, except operator[], at, front, >> back, begin, rbegin, end, and rend." > > In the previous reply, I took "standard library function taking a > reference to ..." as std::move() in the above expression. Yes. > But if you are referring operator=(basic_string&&) itself as the > trigger of invalidation, I did. > it seems impossible to show the problem with a > valid C++ code example, because comparison of pointers is the only way > in C++ to examine the effect on data(). >> >> data(): points at the array whose first element was pointed at by >> str.data() > > Returning to the original DR; > It is not possible to confirm the above effect of data() if small-string > optimization is implemented, because data() may point an small array > which is distinct for each basic_string instance to decrease the number > of allocation. What I'm trying to say is that you cannot prove a defect unless you still try to induce conclusions about the standard or implications on implementations by providing code examples that invoke undefined behaviour. And your examples did always induce undefined behaviour yet, so there is nothing they can really point out. Note that "undefined behaviour" does not require that crude things might happen on a machine, undefined behaviour can in fact be a very defined behaviour for some specific platforms. There is another way of looking at the wording state for std::basic_string: The standard says that the invalidation happens such to *ensure* that the short-string optimization is possible, it does not *require* an invalidation in the sense of requiring the production of an invalid pointer value. For the same reason the quoted wording is written such that a call of a swap function for basic_string (member and non-member) potentially invalidates any pointer, reference, and iterator taken before. If the wording state wouldn't be as written, you could construct another example like this one void g(std::string& x, std::string& y) { char const* const was_pointed = y.data(); x.swap(y); assert(x.data() == was_pointed); } and you could now assert that this example also demonstrates that the standard disallows the short-string optimization. But this example is also invalid as any of your examples shown so far. HTH& Greetings from Bremen, Daniel Krügler -- [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]