I is my understanding that an ANSI (WP) complient string class
must support strings with imbedded NUL characters.  If I am
wrong on this count, somebody please correct me, and skip
the rest.
If my understanding is correct, allow me to relate an
experience that I had with the only implementation I have
of a string class that purports to be ANSI complient, and
tell me if I observed appropriate behaviour.

First, I had to jump through hoops to construct a string
with imbedded NULs.  Any constructor that took a char*
treated it as NUL terminated.  Well, that seems reasonable.
string(const char*, size_t)
also terminated on the first NUL char.  Is this appropriate?
I had to create the string with
string(unsigned char, size_t) // char repeated size_t times
then, using the operator[], put the characters in one-by-one.
If it had been a char*, I could've used memcpy().
Next, I wanted to store the strings (actually a descendant) on
a tree container class (same vendor).  The items stored on
the tree must have operators == and <.  The string class does,
so I didn't bother overloading them, until I found out that
they didn't work.  Wading through the string class hierarchy,
I found that, ultimately, it called strcmp(), which of course
terminates at the first NUL char.  Is this appropriate?  I
had to overload the operators to use memcmp() to make it
function.  So, basically, I had to overload virtually every
method of the string class that I actually used.
BTW, string::length() returned the length (not NUL terminated).

Please comment on what should be the appropriate behaviour
of an ANSI (WP) or ISO complient string class WRT imbedded
NUL chars.
regards,
chris
---
. OLX 2.2 . I tryed to draw a picture of my shadow but it kept moving

chris.smith@ftl.mese.com (Chris Smith)  writes:
>I is my understanding that an ANSI (WP) complient string class
>must support strings with imbedded NUL characters.  If I am
>wrong on this count, somebody please correct me, and skip
>the rest.
>
That is correct.

>If my understanding is correct, allow me to relate an
>experience that I had with the only implementation I have
>of a string class that purports to be ANSI complient, and
>tell me if I observed appropriate behaviour.

>First, I had to jump through hoops to construct a string
>with imbedded NULs.  Any constructor that took a char*
>treated it as NUL terminated.  Well, that seems reasonable.
>
Well, not quite. According to my reading of the January 94 draft,
you should be able to do what you want with the constructor from
char *:

 string(const char *, size_t n = NPOS);

If you don't supply a length, this constructor will use strlen(s),
which will indeed cause it to stop at the NUL. If you do supply a
length, it should copy that many characters, regardless of NULs.

>Next, I wanted to store the strings (actually a descendant) on
>a tree container class (same vendor).  The items stored on
>the tree must have operators == and <.  The string class does,
>so I didn't bother overloading them, until I found out that
>they didn't work.  Wading through the string class hierarchy,
>I found that, ultimately, it called strcmp(), which of course
>terminates at the first NUL char.  Is this appropriate?
>
No. String::compare() is defined in terms of memcmp, and so "does the
right thing" with NULs. I would expect all of the relational operators
to behave as if they were based on String::compare().

Steve.
--
UUCP:  ...!uknet!warwick!steve Internet: steve@maths.warwick.ac.uk
JANET:  steve@uk.ac.warwick.maths PHONE:  +44 203 524657