optimization
Organization: unknown
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Original-Date: Wed, 10 Aug 2011 04:25:20 +0900
X-Submission-Address: std-cpp-submit@vandevoorde.com


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.

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 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'm sorry not coming with proposed resolutions.
--
k_satoda


[ 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                      ]