|[33 earlier articles]|
|Re: Internal Representation of Strings email@example.com (Marco van de Voort) (2009-02-27)|
|Re: Internal Representation of Strings firstname.lastname@example.org (Tony) (2009-02-28)|
|Re: Internal Representation of Strings email@example.com (cr88192) (2009-03-03)|
|Re: Internal Representation of Strings firstname.lastname@example.org (Armel) (2009-03-02)|
|Re: Internal Representation of Strings email@example.com (Tony) (2009-03-03)|
|Re: Internal Representation of Strings firstname.lastname@example.org (Waldek Hebisch) (2009-03-05)|
|Re: Internal Representation of Strings email@example.com (cr88192) (2009-03-06)|
|Date:||Fri, 6 Mar 2009 18:17:52 +1000|
|References:||09-02-051 09-02-068 09-02-078 09-02-120 09-02-125 09-02-134 09-03-001 09-03-009 09-03-018|
|Posted-Date:||06 Mar 2009 06:41:06 EST|
"Tony" <firstname.lastname@example.org> wrote
> "cr88192" <email@example.com> wrote
>> "Tony" <firstname.lastname@example.org> wrote
>>> "Armel" <email@example.com> wrote in message
>>> My goal is to get away from all the APIs that use null-terminated
>>> so I will be replacing all of that. Not needing that null terminator
>>> be an indication of success of a string implementation that wished to
>>> depart from that paradigm.
>> what is the problem with NULL-terminated strings anyways?
>> my code uses them all the time with no real ill-effect...
> But if you were doing it from scratch, would you implement strings as
probably, and I even did NULL-terminated arrays (although, I would
probably change this as one can soon discover that NULL is a useful
value to be able to put into an array, but at the same time,
initially, I had used a different value to represent NULL as well,
if I were designing them clean, I would probably use a hybrid
approach, sort of like I eventually did with arrays...
>> so, maybe the big question that can be asked is:
>> really, why do you so much dislike the NULL-terminated strings?...
> Many reasons. Not the least of which are that they are bad and the
> implementation is ugly. ;) (Read: I don't feel like retyping
> everything already said a thousand times that is is bad about
> null-terminated strings).
I don't remember a specific deficiency being specified, nor can I seem
to find one in the thread. it is repeatedly stated that you don't
like them, but there is no clear reason for this sentiment from what I
(so, I can't say where this was actually said, I can't find it...).
I see both pros and cons to null-terminated strings, and as I see it, for
the most part the pros outweigh the cons (and the few cases there are cons
are fairly rare in practice, such as finding the length of a very long
likewise, as a general rule, the algos are generally simpler for working
with null-terminated strings than with length-terminated strings, ...
so, as I see it, personally, disliking them so much does not seem
although, granted, I guess one could find it useful to equate strings and
string-buffers, and a length could be useful for this (or, if one
supports/uses indexing operations into strings, a length allows faster
bounds checking). all this, however, would more seem to opt for a hybrid
approach than pure length-based approach (since for other kinds of
operations the terminator would still be useful, ...).
but, oh well, I also like lists and CONS cells, as for many things they are
so much more convinient than arrays (for many tasks I use CONS-based
structures more than arrays, ...).
Return to the
Search the comp.compilers archives again.