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

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

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

Show all headers | View raw

On 2011-08-24 03:56, Kazutoshi Satoda wrote:
>  In N3290 (2011 FDIS), C.2.11 [diff.cpp03.strings] says:
>>    21.4.1
>>    Change: Loosen basic_string invalidation rules
>>    Rationale: Allow small-string optimization.
>
>  Here is an existing implementation (STLport) with such optimization.
>  http://stlport.git.sourceforge.net/git/gitweb.cgi?p=stlport/stlport;a=blob;f=stlport/stl/_string_base.h;hb=af309b7a853f95ae8d4546ac79525d6a2e1fa450#l55
>
>  Then, 21.4.2 [string.cons] Table 71 says:
>>    Table 71 — operator=(const basic_string<charT, traits, Allocator>&&) effects
>>
>>      data(): points at the array whose first element was pointed at by str.data()
>
>  I read the above wording of effect on data() as it mandates the
>  following assertion to always succeed.
>
>      void f(std::string&    x, std::string&&    str)
>      {
>        char const* const was_pointed = str.data();
>        x = std::move(str);
>        assert(x.data() == was_pointed);
>      }
>
>  But it can fail if small-string optimization is implemented and str
>  was short enough.

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."

>  Additionally, but less obviously, many tables in 21.4.2 says that data()
>  should point at the first element of "an allocated copy". I think
>  "allocated" should be dropped not to imply a probable call to
>  Allocator::allocate() which can be optional with small-string
>  optimization.

I agree, this will be forwarded to LWG.

>  I think these wordings of effects on data() are unintentionally
>  over-constraining, and should be relaxed to keep the rationale for
>  C.2.11 "Allow small-string optimization" really valid.

I have not yet seen an example which proves this. Your above given
example is invalid.

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

Defect Report: Wordings on basic_string::data() disallow small-string Kazutoshi Satoda<k_satoda@f2.dion.ne.jp> - 2011-08-23 18:56 -0700
  Re: Defect Report: Wordings on basic_string::data() disallow small-string Daniel Krügler<daniel.kruegler@googlemail.com> - 2011-08-24 17:38 -0700

csiph-web