Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #265

Re: Defect Report: Wordings on basic_string::data() disallow small-string optimization

Show all headers | View raw

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                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Find similar

Thread

Re: Defect Report: Wordings on basic_string::data() disallow small-string optimization Kazutoshi Satoda <k_satoda@f2.dion.ne.jp> - 2011-08-28 08:42 -0700
  Re: Defect Report: Wordings on basic_string::data() disallow small-string optimization Daniel Krügler<daniel.kruegler@googlemail.com> - 2011-08-28 11:07 -0700

csiph-web