This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++/16612, empty basic_strings can't live in shared memory
- From: Phil Edwards <phil at codesourcery dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Wed, 4 Aug 2004 09:48:21 -0400
- Subject: Re: libstdc++/16612, empty basic_strings can't live in shared memory
- References: <20040804111757.GB905@tofu.dreamhost.com>
- Reply-to: libstdc++ at gcc dot gnu dot org
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.
Ya know, as fond as I am of good ol' 14882, this is one requirement I
wouldn't mind just blowing off.
Real character arrays don't work like this portably, so I don't see what
basic_string is trying to mimic by doing this.
Smart programmers don't access off-the-end values for any other data type
and expect to get a meaningful (i.e., non-singular, non-crashing) result.
This isn't returning an iterator, even. Why would they do so here?
And at the expense of performance, no less.
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.
--
<The_Vulture> evilgeek: actually it's <: and :>, <% and %>
<evilgeek> oh, right. digraphs are always happy