Efficency and the standard library

[Malcolm McLean]

(1) I am not qualified to read assembler (note that that's how a
gentlemen speaks when he is not qualified to read code: he doesn't
call the code unreadable)

That would imply that there is an esoteric or highly professional body
of knowledge called "assembler" which requires a logn apprenticeship
to learn.
"I can't read assembler" or, more likely, "I'm unfamiliar with this
particular assembler" is the better response.

 

[spinoza1111]

I make them more than most people.  As a compensating tactic, I can be pretty
careful about working things out and testing them...  But I tend not to when
posting to Usenet (although I always check my facts before posting nonsense
to Usenet!).


In general, no.  Someone pointed that one out, and I concede cheerfully that,
yes, that's a pretty stupid mistake.  I make stupid mistakes a *lot*, so I'm
used to that.  Note that I make them a lot less often on much more
complicated things than on simpler things; a neat quirk of brain chemistry
or something.  And I don't just mean "less often, compared to other people"; I
mean less often in absolute terms.  I'm much more likely to get something
trivial wrong than something interesting and challenging.


I disagree.  The problem is not the lack of an errata list; it's that he
still doesn't even *understand* how feof() works.  He's written a series
of Pascal books which have been cleverly relabeled "C" and had some of the
punctuation altered, in effect.  He got several of the "easy" mistakes that
were, say, posted on my page, fixed for the 4th edition.  He didn't fix the
much more serious logic flaws introduced by his unwillingness to comprehend
how end-of-file conditions are handled in C.

And that's the thing.  Errata would be one thing.  But if every example I
read using feof() used it incorrectly, and multiple examples of how to do

In Herb's defense, I'd say that intelligent people find it hard to
treat mistakes (such as the design of feof) with respect, and enough
to remember the deviant implementation that feof is. Herb's failure to
recall to mind a massive boner means he's an intelligent person.
Whereas nasty little clerks (who as we saw this morning make their own
stupid mistakes, but expect to be forgiven) take a sour delight in
"learning" clap trap.

This isn't programming, Seebach. It's Trainspotting.

An intelligent programmer, when confronted with the incredibly poor
design of feof, turns right around and changes feof into a simple
macro:

#define READ(f) (attemptToRead(f), feof(f)) ? 0 : -1 // Change
attemptToRead to fgetc, fgets, etc.

He then can forget the design error, which is normalized deviance from
hell, since it forces the program to try to read SOMETHING to detect
IO. On any number of environments, this can change the state of the
underlying hardware in unpredictable ways. Even if the hardware can
signal to the runtime "don't you dare try to read from me, I have
nothing for you now", the C runtime HAS TO READ, which can easily
throw off auditing software or firmware, recording in all cases one
extra read.

Someone late at night has then to remember, while nodding weak and
weary, that oh yeah, this is a C program.

How many ruined marriages, late nights, alcoholic benders, and
suicides has this caused? How many little, stunted, substance abusing
and creepy personalities has this caused? And why do people think that
knowing these coding horrors is anything but an expense of spirit in a
waste of shame?

Herb should have done a better job, but the error is so common among
good programmers and intelligent people so as to cast the aspersion on
C and standards committee members too cowardly and incompetent to fix
it.

In case you hadn't noticed, the only reason for using a programming
language is to make programming intellectually manageable. The blame
lies upon the designers of C, and you had NO STANDING in pretending to
be more qualified than Herb Schildt, and advance your career without
suitable academic preparation thereby. You should have been taking
evening classes in comp sci. You especially have NO STANDING in light
of your own frequent errors.

The intended meaning of "C: The Complete Nonsense" was "look at me, I
am more qualified than Herb Schildt". But your errors in this thread,
and your failure to post decent code, means that you are far LESS
qualified.

You blame Herb for not publishing errata. New editions trump errata.
Sure, he should have fixed the bug: but what about the refusal of the
C standardizers to reform the numerous errors in C? I'd say this is
the greater crime, because again, the only reason for using a high
level language is to make problems intellectually manageable.

I've shown that this is possible in C with the replace() example this
week. My solution (and only my solution) showed aspects of the
problem which other solutions concealed. Had I been Herb, I would have
addressed the feof() issue head-on, but I'm not, and it may be that he
didn't want to confuse his readers.

But in light of how frequent feof() errors are (see the first Google
hit for "feof C" at http://www.cplusplus.com/reference/clibrary/cstdio/feof/:
it warns about the behavior of this turkey and then has a code sample
with the classic error), it was in fact libel for you to try to make
this global and normalized deviance stick to Schildt.

You have TWICE in the past week posted trivial code snippets with
errors (%s and off by one strlen). You had NO STANDING ten years ago,
and you have NO STANDING now in talking about other people's errors,
especially because with regards to McGraw Hill and here, you act like
an infant, refusing to work collaboratively and compassionately with
others while expecting us to have compassion for your oh-so-precious
and oh-so-unique personality disorders.

You need to WITHDRAW and APOLOGIZE FOR the "C: The Complete Nonsense".
NOW.

input loops used feof() incorrectly, that suggests to me that these are not
merely "stupid mistakes" (fencepost errors, typos, etcetera), but a genuine
failure to comprehend something which I think can be reasonably regarded as
fairly basic.

This is your self-serving interpretation. However,

* Posting a solution that is supposed to replace %s and replaces
instead all percents and the character following them, which may cause
a memory fault,

* Posting a strlen replacement which managed to be off by one in a
few short lines of code,

* Claiming that "the 'Heap' is a DOS term",

* Consistently asking forgiveness for errors whilst uncharitably
withholding it from colleagues,

* Being ignorant of the use of concrete memory layouts of stacks and
heaps in classrooms to explain how runtimes work,

* Throwing away email from Apress colleagues unread, and calling them
"morons" and impugning their credibility and sanity online

indicates a far more troubling personality.

 

[spinoza1111]

Paraphrasing again?
"You talk like a fag, and your shit's all retarded" - Idiocracy,
Mike Judge, 2006

Yes, correction accepted. I also screwed up the grammar. Your, not
you're.

 

[Seebs]

I certainly hope that I am never able to crank out that
level of code, regardless of the time it takes.

And I certainly hope I never reach a point where a ten-minute project
takes two hours to write and maybe 8-10 hours thereafter to produce an
elaborate, complicated, inefficient, version which we still aren't totally
sure works.

-s

 

[websnarf]

Yeah fantastic -- because you are using C strings, you are forced to
execute this in two passes, one to figure out how much space to
allocation and the second to do the copies.

Both are using C strings and suffer from the stupidity of not being
able to use lengths to accelerate the performance of any portion of
this algorithm. "Efficiency and the standard library" is an
oxymoron. Compare this to the implementation in the Better String
Library.

For a standard library, the *most* important thing is correctness.

How can one implement gets() correctly?

[...] IOW, a bsearch() function that is blazing fast but fails if there are
more than 2 billion items is not as good as one that is only half as fast
but works with anything up to size_t (-1) number of elements.

Assuming correctness, then efficiency should be the next decider.

And what if the specification of the C library does not allow the
algorithm to be implemented efficiently?

[...] An
interesting project would be to take a collection of all public C
libraries and do the following:
1. Exhaustively test for correctness

How would you test gets() for correctness.

The Better String Library, on the other hand *COMES WITH* a unit test
that does a reasonable amount of testing. *Correctness* is also a
more usefully defined concept in the Better String Library (every
function must support all possible parametric inputs so long as each
of the contents of the parameters are independently valid with respect
to their own type.)

If the ANSI C language committee were forced to ship a unit test for
the C standard library, it would probably be a very different
language.

2. Analyze for efficiency

Even if it doesn't make any sense to do so? qsort(), for example, is
*NEVER* efficient in any circumstance. Nearly the full complement of
string functions are easily beat by the portable "Better String
Library" implementation (note that the latest hand optimized x86
assembly language libraries for the Intel/Microsoft have managed to
catch up to the Better String Library in a few cases, but only by
using esoteric instructions.)

3. Choose best of breed from the above analysis.  It could also be a
hybrid (e.g. a decider function chooses the best algorithm based on
conditions).

If the libraries are written in assembly language (which in Intel and
Microsoft's case is true) does that make sense in your comparison?
You could only say that a library was good on a particular platform.

 

[Chris M. Thomasson]

Yeah fantastic -- because you are using C strings, you are forced to
execute this in two passes, one to figure out how much space to
allocation and the second to do the copies.

Well, you are not necessarily "forced" to loop on `strstr()' in two phases.
One can cache the results such that a second round of `strstr()' calls can
be completely eliminated. I created a crude little program that does this:


http://groups.google.com/group/comp.lang.c/msg/2ebbf412549f3300


This has to improve things a little bit...

;^)

[...]

Both are using C strings and suffer from the stupidity of not being
able to use lengths to accelerate the performance of any portion of
this algorithm.

Humm... Of course one can use C strings in conjunction with a length.
Perhaps something like this crap:
_________________________________________________________________
#include <stdio.h>


struct string
{
size_t length;
char* buffer;
};


#define STRING(mp_name, mp_len, mp_content) \
char mp_name ## _temp mp_len = mp_content; \
struct string mp_name = \
{ \
sizeof(mp_name ## _temp) - 1, \
mp_name ## _temp \
}


#define STRING_CONST_FROM_CSTR(mp_name, mp_str) \
struct string const mp_name = \
{ \
sizeof(mp_str) - 1, \
mp_str \
}


int main()
{
STRING(mutable_string, [], "Hello World! (mutable)");

STRING_CONST_FROM_CSTR(inmutable_string, "Hello World! (inmutable)");

printf("mutable_string(%lu) = %s\n"
"inmutable_string(%lu) = %s\n",
(unsigned long)mutable_string.length,
mutable_string.buffer,
(unsigned long)inmutable_string.length,
inmutable_string.buffer);

return 0;
}
_________________________________________________________________


BTW, how are you handling this in your Better String Library? I see that you
have a function called `cstr2bstr()', but AFAICT it uses dynamic memory
allocation.

"Efficiency and the standard library" is an
oxymoron. Compare this to the implementation in the Better String
Library.

[...]

 

[spinoza1111]

And I certainly hope I never reach a point where a ten-minute project
takes two hours to write and maybe 8-10 hours thereafter to produce an
elaborate, complicated, inefficient, version which we still aren't totally
sure works.

But dear Peter, you haven't written a working solution to the problem
(replace() without string.h) in a week, nor have you given any
evidence of being able to do so. Quite the opposite, Mister Off By
One.

Part of the myth is that software is easy and a truly reusable and
efficient library routine such as this can be written by one magical
person in an hour: Kernighan contributes to this myth-making in the
O'Reilly anthology Beautiful Code with his story-telling about Rob
Pike writing a regex (which wasn't a real regex) by himself in an
hour.

The software that is written in five minutes or an hour is almost
always delivered with smartass remarks such as yours, such as "you'd
be better test it" or "I didn't actually check for %s", accompanied by
anti-intellectual and sexist remarks, generally to the effect that
anyone who worries about marginal conditions in the deliverer's code
isn't being "practical", is "academic", or a queer.

Real development can be done solitary but this takes even longer than
collaborative development of truly reusable routines, which takes time
owing to the need to coordinate people, here in different time zones,
and to get rid of disruptive individuals such as you.

 

[spinoza1111]

On Feb 14, 7:05=A0am, (e-mail address removed) (Richard Harter) wrote: [snip]

At some point in the distant past, Harter, you were able to
write competent code, for I saw an old 1990 program of yours
that was competent.  I think you are now some sort of
manager

Chortle.  Excuse me while I go whip some slaves, er,
admonish the programming staff.

who is today unable, unlike me, to crank this level
of code in the time I took...about two hours for the first
version, and a total of 8..10 hours thereafter.

I certainly hope that I am never able to crank out that
level of code, regardless of the time it takes.

I don't know what you mean. Do you mean you never hope to become as
truly competent as I am, since in programming (which is now a cost
center in which creative and intelligent people are now merely
disruptive) such great code merely attracts envy and infantile rage,
such as we see in Seebach?

[snip]

You don't know what you're talking about, and you have not diligently
or adequately studied the code.  strNew is needed to index through the
new string, whereas we need to return strNewStart.

You are right.  Mea culpa.

Fine. Please study the code before emitting judgements next time.

Well, no, it's not.  In the C standard "defined" has a very
specific, parochial meaning.   More generally, however, the
definition of a variable is a description of its usage in the
code.  A comprehensive definition includes such things as the
invariants and constraints associated with the variable, and the
kind of things it represents.

There seldom is a need for elaborate definitions.  Often none is
wanted.  Often, however, the presence of an explicit definition
makes a lot of difference, both in reading the code and writing.
The absence of explicit definitions can lead to nasty, obscure
bugs.

I think what's best, then, would be to rename them retaining my great
pre-Syzmonyi Hungarian and index followed by a trailer as in
ptrIndex3match.

It occurs to me that you did not recognize "Index variables" as
shorthand for the variables named ptrIndex0, etc.  If that is
what you were on about, that was what was meant.

But: you recognized them as index variables.

Bear in mind one simple fact. Nobody else in this thread has been able
to solve the assigned problem. I do not think that this is because
nobody else is able to! "Writing a replace() without using string.h in
some reasonably efficient way" is nothing more than a basic university
assignment.

I think instead that owing to the domination of these threads by thugs
and twerps like Heathfield and Seebach, most posters are afraid to,
since any code, in any style, at any level of quality, will be mocked
by people who themselves are not very competent, such as Heathfield,
who believed at least in 2000 that it's acceptable to shove arbitrary
data into the nodes of a linked list, or Mr. Off By One Seebach. The
mockery and falsehoods to which they would be exposed can threaten
their positions.

But since I am not employed as a programmer or in computing, nor seek
work in those fields, I decided to expose how these newsgroups are
being abused.

Rob Pike or any other great programmer could post here *incognito*,
and since great programmers almost always have idiomatic relationships
to code and markers of style, they would be flamed for those markers,
as well as for any and all bugs. I do not know of any great programmer
who also writes code free of bugs the first time: in fact, given
Knuth's free confession of the mistake he always makes when coding
binary search, I'd guess that great programmers are so fecund, with a
higher volume of output, that their code has a higher level of
bugs...which they, as great programmers, are far more eager to fix
than Peter Seebach was anxious to fix his famous %s bug.

 

[spinoza1111]

Yeah fantastic -- because you are using C strings, you are forced to
execute this in two passes, one to figure out how much space to
allocation and the second to do the copies.





Both are using C strings and suffer from the stupidity of not being
able to use lengths to accelerate the performance of any portion of
this algorithm.  "Efficiency and the standard library" is an
oxymoron.  Compare this to the implementation in the Better String
Library.

For a standard library, the *most* important thing is correctness.

How can one implement gets() correctly?

[...] IOW, a bsearch() function that is blazing fast but fails if there are
more than 2 billion items is not as good as one that is only half as fast
but works with anything up to size_t (-1) number of elements.

Assuming correctness, then efficiency should be the next decider.

And what if the specification of the C library does not allow the
algorithm to be implemented efficiently?

[...] An
interesting project would be to take a collection of all public C
libraries and do the following:
1. Exhaustively test for correctness

How would you test gets() for correctness.

The Better String Library, on the other hand *COMES WITH* a unit test
that does a reasonable amount of testing.  *Correctness* is also a
more usefully defined concept in the Better String Library (every
function must support all possible parametric inputs so long as each
of the contents of the parameters are independently valid with respect
to their own type.)

If the ANSI C language committee were forced to ship a unit test for
the C standard library, it would probably be a very different
language.

2. Analyze for efficiency

Even if it doesn't make any sense to do so?  qsort(), for example, is
*NEVER* efficient in any circumstance.  Nearly the full complement of
string functions are easily beat by the portable "Better String
Library" implementation (note that the latest hand optimized x86
assembly language libraries for the Intel/Microsoft have managed to
catch up to the Better String Library in a few cases, but only by
using esoteric instructions.)

3. Choose best of breed from the above analysis.  It could also be a
hybrid (e.g. a decider function chooses the best algorithm based on
conditions).

If the libraries are written in assembly language (which in Intel and
Microsoft's case is true) does that make sense in your comparison?
You could only say that a library was good on a particular platform.

Is the Better String Library based on a linked list representation of
strings?

 

[Chris M. Thomasson]

[...]

Both are using C strings and suffer from the stupidity of not being
able to use lengths to accelerate the performance of any portion of
this algorithm. "Efficiency and the standard library" is an
oxymoron. Compare this to the implementation in the Better String
Library.

[...]

Is the Better String Library based on a linked list representation of
strings?

I don't think so. BTW, have you taken a look at this:

http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf

 

[Malcolm McLean]

Part of the myth is that software is easy and a truly reusable and
efficient library routine such as this can be written by one magical
person in an hour: Kernighan contributes to this myth-making in the
O'Reilly anthology Beautiful Code with his story-telling about Rob
Pike writing a regex (which wasn't a real regex) by himself in an
hour.

As I told my students, don't confuse doing the planning with the time
it takes to write down the plan.

Once you've decided on the specifications and behaviour of a string
library, writing the code should be trivial - almost certainly all you
will be doing is copying, concatenation, and a few simple searches.
However getting the specifications right is hard.

 

[Nick Keighley]

On 13/02/2010 10:30, spinoza1111 wrote:

Then it's shitty code, pure and simple.

if was hard to write then it should be hard to understand

 

[Nick Keighley]

spinoza1111 wrote:

Simpler, and slightly more informative to the caller:

long strLength(const char *s)
{
   long len = 0;
   while(*s++) ++len;
   return len;

}

isn't strLength in the implementaion namespace?



<snip>

 

[websnarf]

Well, you are not necessarily "forced" to loop on `strstr()' in two phases.
One can cache the results such that a second round of `strstr()' calls can
be completely eliminated. I created a crude little program that does this:

http://groups.google.com/group/comp.lang.c/msg/2ebbf412549f3300

This has to improve things a little bit...

;^)

Right, but then you are mixing line length delimiting with C strings.
And you are basically solving the problem from scratch rather than
using the semantics implied by the C library.

Of course the Better String Library has what you suggest above as an
obviously available technique since lengths are always available.

Here's a hunk of another one:

[...]

Both are using C strings and suffer from the stupidity of not being
able to use lengths to accelerate the performance of any portion of
this algorithm.

Humm... Of course one can use C strings in conjunction with a length.
Perhaps something like this crap:
_________________________________________________________________
#include <stdio.h>

struct string
{
    size_t length;
    char* buffer;

};

#define STRING(mp_name, mp_len, mp_content) \
    char mp_name ## _temp mp_len = mp_content; \
    struct string mp_name = \
    { \
        sizeof(mp_name ## _temp) - 1, \
        mp_name ## _temp \
    }

#define STRING_CONST_FROM_CSTR(mp_name, mp_str) \
    struct string const mp_name = \
    { \
        sizeof(mp_str) - 1, \
        mp_str \
    }

int main()
{
    STRING(mutable_string, [], "Hello World! (mutable)");

    STRING_CONST_FROM_CSTR(inmutable_string, "Hello World! (inmutable)");

    printf("mutable_string(%lu) = %s\n"
           "inmutable_string(%lu) = %s\n",
           (unsigned long)mutable_string.length,
           mutable_string.buffer,
           (unsigned long)inmutable_string.length,
           inmutable_string.buffer);

    return 0;}

_________________________________________________________________

BTW, how are you handling this in your Better String Library? I see that you
have a function called `cstr2bstr()', but AFAICT it uses dynamic memory
allocation.

Look up the bsStatic() and bsStaticBlkParms() macros to see how I
handle that.

(Note that if you pass non-string literal values to your macros you
will get strange results.)

 

[Malcolm McLean]

isn't strLength in the implementaion namespace?

<snip>- Hide quoted text -

So are things like strength, island, isobars, strip_spaces, today,
meme, delta_t.

Most compilers won't warn you by default and it is a complete nuisance
to remember.

 

[websnarf]

Both are using C strings and suffer from the stupidity of not being
able to use lengths to accelerate the performance of any portion of
this algorithm. "Efficiency and the standard library" is an
oxymoron. Compare this to the implementation in the Better String
Library.

[...]

Is the Better String Library based on a linked list representation of
strings?

No it is based on exponential realloc() lengths for the backing
memory, and otherwise defining the string as length limited, not '\0'
limited.

I don't think so. BTW, have you taken a look at this:

http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf

Yes, Ropes -- as far as I understand it, they have never finished
implementing it. The VStr library is probably the closest thing to it
that at least is fully implemented. But IMHO, it trades off a lot of
complexity that you will end up paying for in practical cases in order
to achieve good results in atypical cases.

 

[Richard Tobin]

isn't strLength in the implementaion namespace?

No. "str" followed by a lowercase letter. (7.26.11)

-- Richard

 

[spinoza1111]

Yes, I've come across others with that view in the past (others besides
Spinny, that is). In one egregious instance the writer declined to do
any doccy for his code, for just the reason you cite. He was too
impressed by his own cleverness, the offering was "neat", to use his
words. Asked to write some code to take a text file and convert it to
another form, he'd written a "compiler", so instead of a small piece of
code to do the job, it was humongous - with the attendant issues of
maintainability and modifiability.

The anthropological lessons of these myths is "don't be too smart." Or
as we say in China, "the tallest stalk of rice is cut down".

This particular myth often appears both in break rooms in programming
"shops", and here. It is told in ceremonious whispers and is a post-
Enlightenment myth.

In it, "there used to be this guy who thought he was better than us",
and in it, he is whip't and scorn'd and driven away in humiliation.

His humiliation is of course what the tellers and hearers fear, and
the anthropological function is to assert membership in a tribe of
regular (Chomsky 3) guys who would never do what the Chosen One did in
the Dreamtime, such as write a compiler to solve a simple problem.

[Interesting solution, one which I recommend, but of course for only
"hard" problems with frequent requirements changes, in my book, "Build
Your Own .Net Language and Compiler" (Apress 2004). One I've in fact
used.]

In some cases in my (30 year) programming career, I've overrated the
intelligence and work ethic of my mates, and I may have unleashed some
surprises like the one you describe.

But: the point of mythologizing the story is "never, ever, do that,
lest you be exposed, lest what Adorno called the 'secret contour of
your weakness' be out there, you naked in the face of the raging mob
of programmers who have to maintain your crap".

The mythical admonition has the effect of making acceptable solutions
over-simplified with obvious bugs (such as Seebach's famous %s, and
percent bugger all, replacer which started this thread) that are in
many cases, even acknowledged by the developers with a self-satisfied
smirk, and no plan whatsoever to fix these "issues". Objections are
"academic" in the incantation.

Certain types of problems, as your coworker may have known, are solved
less by a hard-coded solution than by a language for expressing the
set of possible solutions. This is in fact an old and useful problem
solver in the real world; in The Psychology of Computer Programming,
Gerald Weinberg describes the solution of a difficult problem of
properly configuring automobile features in the form of tables
constituting a language. However, it flies in the face of management's
search for the dumb and dumber solution.

Sure, the guy may have gone overboard. But the effect of the myth is
to bias programmers to a "simplicity" which permits them to make silly
mistakes.

"No use goin' on; de dam willains will keep a scougin' and slappin'
each
oder, Massa Stubb; dey don't hear one word; no use a-preaching to
such dam g'uttons as you call 'em, till dare bellies is full, and dare
bellies is bottomless; and when dey do get 'em full, dey wont hear you
den; for den dey sink in the sea, go fast to sleep on de coral, and
can't hear noting at all, no more, for eber and eber."

- Herman Melville, Moby Dick, or The Whale

It was beneath his dignity, you see, to consider others, just as it's
beneath Spinny's dignity to consider others or to bother understanding
feof() or whatever it was. Well, **** to the lot of them, is what I say.

Or whatever. Yes, I had to refresh my memory (you might also consider
doing your homework on what's what before posting: there's really no
excuse not to since so much information is online).

As I said, this is because intelligent people prefer learning and
remembering elegant things, and feof() is coyote ugly, and, as I said,
a bug waiting to happen when a C program has to do an extra read
merely to check EOF from a device.

Intelligent people also prefer the company of the enlightened, and
that's why they leave many programming jobs after the company passes
the point of no return, where innovation gives way to computing as a
cost center staffed by eunuchs.

 

[spinoza1111]

Both are using C strings and suffer from the stupidity of not being
able to use lengths to accelerate the performance of any portion of
this algorithm. "Efficiency and the standard library" is an
oxymoron. Compare this to the implementation in the Better String
Library.

[...]

Is the Better String Library based on a linked list representation of
strings?

No it is based on exponential realloc() lengths for the backing
memory, and otherwise defining the string as length limited, not '\0'
limited.

Exponential? You mean you double each request? Sounds kind of like Las
Vegas to me. Might make sense.

Until very recently, I thought that bit length was an unacceptable
restriction on string length, but if one ponders the scale of long
long, it is more than enough.

However, for easy modification, I don't think a doubly linked list
representation of strings with a length code could be beat.

When I implemented something vaguely like this using long and not long
long in 1990, I discovered my concept of "inspect" which I later used
in OO code, for IF the string data structure contains a length and a
linked list, the total lengths of the list entries should never not
match the length code, UNLESS you allow the length code to be an
Unknown value (-1?) until its value is needed just-in-time.

It was hard to get my doubly linked list working, but I did. It would
have been nice to have a separate tool for linked lists. Richard
Heathfield appears to have published such a tool in 2000, in C
Unleashed, but as far as I can determine (see elsethread), the
Dickiemaster copies the actual values into the list. This would have
blown me to Kingdom Come. I THINK the Heathman wanted to avoid using
pointer to void (he is welcome to comment here).

However, preprocessor macro implementation of linked list would avoid
both copying entries and pointer to void. But it would be at that
point in which I would ask myself, like Ross Perot's running mate VAdm
Jim Stockdale in 1992, "Who am I? Why am I here? And why am I not
coding in C Sharp, or getting laid?"
Very nice. I pulled a copy a few months ago while researching string.H
replacement.

 

[spinoza1111]

As I told my students, don't confuse doing the planning with the time
it takes to write down the plan.

Once you've decided on the specifications and behaviour of a string
library, writing the code should be trivial - almost certainly all you
will be doing is copying, concatenation, and a few simple searches.
However getting the specifications right is hard.

Malcolm, hi. I don't agree with you at all. "Find all strings AND
replace them" is as we've seen two problems, and the specifications
may only seem precise. Remember the gotchas I mentioned? Right to left
as opposed to left to right? Overlapping strings?

Any specification will contain aporias because specifications are in
natural language. Sure, you could write the algorithm or even hard
code inside the spec, but then it's no longer a spec, is it?

Over thirty years, primarily but not exclusively in business data
processing, I saw again and again the bad consequences of expanding
spec time and contracting code time, despite the fact that to do this
is conventional wisdom. Sure, if the Specifiers were Platonic
Guardians (Plato's philosopher kings who are implicitly knowledgeable
about the trades of the Artisans and themselves Warriors as well as
Guardians, and as virtuous as Boy Scouts on salt petre) then they
would know exactly what the "mere coders", the scribes, the slaves
needed.

There are two objections to this applied Platonism (apart from the
fact that Plato's sole value was starting a dialogue with posterity in
which the first response was a Bronx cheer from his star student
Aristotle).

The first is that if the specification is perfect we could merely
write a specification compiler and compile it, or, if labor is cheap
or as in a slave society free, we could merely tell the programmers to
mindlessly "code the spec". Or die.

If the specification is in any way imperfect, however, the slaves have
to bring this to the attention, whether directly or indirectly to the
Guardians. Of course, in this ideal state, one of absolute Perfection
and top-down authority, any Slave would have to be nucking futz to do
this. No, instead, he will quietly code the right way (or the wrong
way), trying to repair the spec rather than get his nuts chopped off
for being uppity.

But since, as I've demonstrated using Socrates' own dialectical form
of argument, the Platonic vision of perfect specs and mindless code is
utterly unsustainable malarkey, what really obtains in the real world?

It ain't pretty. Using the rhetoric, that "we mustn't code too early",
the favored or senior "analysts" buy themselves several months or even
years of "requirements analysis". During these happy times, they go to
a lot of meetings, talk in a lot of circles, write a lot of unreadable
and indeed unread documents, and do a lot of Facebooking and Youtubing
on the sly.

When Coding day finally dawns, a couple of hapless junior people,
often the ladies, along with a few misfits hired as "consultants", are
handed beautiful "requirements documents" filled with malarkey, tripe,
horse feathers, buggery, sodomy, clap trap, logical contradictions,
paradoxes, and quibbles.

When they are unable, often through a form of low level Lutheran ich
kann nicht anders intellectual integrity, to code anything that runs
without catching fire using the clap trap and Higher Sodomy given unto
them from On High, they are said to be "incompetent programmers" and
are shown the door. The analysts then are given megabucks to retain a
Triad or Mafia dominated consulting firm, in many cases more than
once, and finally some rough beast of a System slouches towards
Bethlehem to be born, and to start misrouting trucks, losing baggage,
stopping pacemakers, and debiting the accounts of the wretched of the
earth.

The answer? Extreme programming. The comments are the spec. I deliver
you something by 5:00 EACH DAY that does something and then I go home,
you dig? I work side by side with a copilot, or as his copilot. I
bathe regularly so he don't throw up.