Re: "The Elements of Programming Style"

jacob navia wrote:
CBFalconer a écrit :
jacob navia wrote:

.... snip ...

String S = "abc";

can be used the same with

String S = newStringFromchar("abc");

s[5] = 'a';

can be written

ReplaceAt(s,5,'a');

This is very cumbersome but is essentially the same.

What is wrong (in my suggestion) with:

s->guts[5] = 'a';

You can handle it with a macro if you wish. This will not have any
checking and auto expansion built in,

Strings do not have any auto expansion. Any index out of
bounds is an error. You can expand strings by Strcat, for instance, but
not by indexing anywhere.

The flaws with you approach
s->guts[5] = 'a';

1) The user needs to know the "guts" field. This is NOT desired
since this can be completely modified by the user to implement
read-only strings, strings all upper/lower case whatever. Your
approach fixes guts in the public interface forever.

but expansion is ridiculous
anyway (what do you put in the intermediary locations), so the
ReplaceAt() function should return an error status, and the s
parameter should be a pointer.

The parameter is the structure describing the string. That structure
contains a pointer to the data, not accessible by the user unless
he/she request a copy with a cast operation:

char *s = (char) String_my_string;

I contend that the ReplaceAt function is fundamentally flawed.
Building castles on quicksand is not productive.

Mmmm... can you explain the last sentence? Why it is flawed?

Because either it handles the attempt to extend the string, with no
reasonable strategy available, or it induces crashes. It has no
way of reporting the error. (I don't consider hanging on a use of
errno to be viable.)

For a good example of a system routine extension, look at the
genesis of strlcpy/strlcat. That crew didn't just release the
first thing that came into their heads. They stopped and looked at
the advantages and disadvantages, usage and misusage, of various
implementations. That genesis is included in my implementation,
available on my download site.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>


.

Relevant Pages

  • Re: Benchmarks: STLs string vs. C string
    ... without any extra strlen execution inside the sprintf. ... implementations, although all implementations I have tried have been very fast. ... In many programs you need to copy/format strings without actually doing a printf. ... I have noticed that most programmers dont care or know about the ...
    (comp.arch.embedded)
  • Re: Assembly string functions in i386 libc
    ... Definitely, for short strings, the ... I've tried statically linking all the test programs and this removes ... the libcstrlen/basestrlen differences. ... strlenimplementations behave better for longer strings. ...
    (freebsd-arch)
  • Re: std::string and refcounting
    ... > subject of our respective string implementations. ... > using the home-grown stringswere mainly refcounting and ... but I thought that these days almost all STL ... > implementations used refcounted strings and that the STL was available ...
    (comp.lang.cpp)
  • Re: Assembly string functions in i386 libc
    ... Definitely, for short strings, the ... indicates that your program is not able to accurately compare strlen() ... the libcstrlen/basestrlen differences. ... strlenimplementations behave better for longer strings. ...
    (freebsd-arch)