🚀 go-pugleaf

In article <4f81p2$j2u@bmtlh10.bnr.ca> "john (j.d.) hickin"
<hickin@bnr.ca> writes:

|> The following was taken from a copy of the DWP:

|>   basic_string<charT,traits,Allocator>&
|>       operator=(const basic_string<charT,traits,Allocator>& str);

|>   Effects:
|>     If *this and str are not the same object, modifies *this such that:

|>                       Table 7--operator=(str) effects

|>              +-------------------------------------------------+
|>              | Element                    Value                |
|>              +-------------------------------------------------+
|>              |data()       points at the first element  of  an |
|>              |             allocated  copy  of  the  the array |
|>              |             whose first element is  pointed  at |
|>              |             by str.size()                       |
|>              |size()       str.size()                          |
|>              |capacity()   a value at least as large as size() |
|>              +-------------------------------------------------+
|>     If *this and str are the same object, the member has no effect.
|>   Returns:
|>     *this

|> Aside from a seeming typographical error in the Value column for Element data()
|> (... by str.data() ?) the wording of this seems to rule out a counted pointer
|> representation.

|> Is my interpretation correct?

Well, it says `allocated copy', not `newly allocated copy', so
strictly speaking...:-).  Still, what you are saying would seem to be
the intent.

Note that in any case, the basic template cannot use a countedd
pointer representation, or only with extreme difficulty, because of
the allocator arguments to the constructors.  (Different instances may
be allocated from different memory pools.)  I believe, however, that
the intent is that the implementation provide optimized
specializations for the `standard' cases (char and wchar_t, default
traits and allocator).  The standard guarantees that all instances of
the default allocator are, in effect, the same; this provides the
necessary loop-hole for reference counting with regards to the
allocator.

In many ways, calling the allocator is a side issue (although it is an
observable side effect when a user defined allocator is used); what is
important is the validity of addresses obtained from c_str, data, and
expressions like &s[ i ].  I feel that these are really separate
issues, at least from a standards point of view.  (From the
implementation point of view, of course, I cannot imagine a case where
I reallocate but do not invalidate the addresses.  The reverse is
*not* necessarily true, however.)

The current wording of the standard in fact guarantees nothing.  For
example, consider the following:

    string              s( "abc" ) ;
    s.reserve( 100 ) ;              //  should be enough
    char const*         ps( s.data() ) ;
    s.remove( 0 , 1 ) ;
    assert( *ps == 'b' ) ;

Is the assert guaranteed.  According to the present wording, all that
is guaranteed is that s.remove did not reallocate; I seen nothing in
the draft standard which would preclude the implementation from simply
playing tricks with the start pointer, however, leaving ps pointing to
the `a' (that is no longer in the string).

I do not know whether this is intended or not.  Personally, I have no
problem with the above being undefined, as long as it is explicitly
stated that it is undefined (e.g.: all non-const functions may
invalidate any previously returned pointers, whether reallocation
occurs or not).
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]