This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]