libstdc++/16612, empty basic_strings can't live in shared memory

[Nathan Myers]

On Wed, Aug 04, 2004 at 09:48:21AM -0400, Phil Edwards wrote:
> On Wed, Aug 04, 2004 at 04:17:57AM -0700, Nathan Myers wrote:
> > Now that nothing modifies the empty-string rep object, it would almost 
> > be possible to use NULL as the address.  The fly in the ointment is 
> > the recent extension (grrr!) requiring that s.operator[](s.length()) 
> > actually yield a zero.
> 
> ... 
> I can't recall ever hearing a good explanation for this requirement.
> If somebody can provide one, I'll change my stance, otherwise I'll go out
> on a limb and suggest we just ignore it.  (And document that we do so.)
> If we do, I will wager $5000ZWD that no real-world programmer will notice
> the omission, nor care.

There can be no good explanation.  It was added while I was called 
away.  The LWG was always fooling around with ways to damage string; 
it was pretty badly messed up before I joined.  (The original proposal 
that added it was almost OK.)

It occurs to me that the same solution for c_str() would work for []:
Declare the data member of basic_string<> as:

  union { _CharT* _M_data; _CharT _M_nul };

and define

  inline _CharT* c_str()
    { return (this->data() ? this->data() : &this->_M_nul); }

  inline _CharT& operator[](size_t i)
    { return this->c_str()[i]; }

One can hope that the optimizer might hoist the test out of loops.
(Fat chance.)  

Nathan Myers
ncm-nospam@cantrip.org