Efficency and the standard library

[spinoza1111]

Then it's shitty code, pure and simple.

He had bought a large map representing the sea,
Without the least vestige of land:
And the crew were much pleased when they found it to be
A map they could all understand.

"What's the good of Mercator's North Poles and Equators,
Tropics, Zones, and Meridian Lines?"
So the Bellman would cry: and the crew would reply
"They are merely conventional signs!

"Other maps are such shapes, with their islands and capes!
But we've got our brave Captain to thank:"
(So the crew would protest) "that he's bought us the best--
A perfect and absolute blank!"

(Lewis Carroll, The Hunting of the Snark)

 

[Seebs]

Then it's shitty code, pure and simple.

Pretty much. Why did multiple attempts at getting the Nilges string
replacement code debugged fail after hours of effort? Because it was hard
to read. Code which is hard to read is hard to maintain. Code which is
hard to maintain will start buggy. It will remain buggy despite debugging
efforts. It will become buggy whenever feature work needs to be done.

This ties in some to the debate about "software engineering". What would
people think of someone who claimed to be an "engineer", but who designed
bridges so elaborately complicated that no one could figure out which parts
were load-bearing?

This is why I don't take Nilges seriously when he rants about the design
of C. He's demonstrated conclusively that he has no clue about competent
design, and someone who can't build even simple programs correctly is not
qualified to comment on any programming language.

-s

 

[spinoza1111]

Pretty much.  Why did multiple attempts at getting the Nilges string
replacement code debugged fail after hours of effort?  Because it was hard

You're lying: the console output from the current version is at the
end of this response. Also, the next time you start a thread using the
word "efficiency", use a dictionary.

You and Richard Heathfield need to LEAVE. This is because you both
have a track record of LYING in this and other newsgroups because you
are using them DISHONESTLY to advance yourself in a profession for
which you are not qualified.

to read.  Code which is hard to read is hard to maintain.  Code which is
hard to maintain will start buggy.  It will remain buggy despite debugging
efforts.  It will become buggy whenever feature work needs to be done.

This ties in some to the debate about "software engineering".  What would
people think of someone who claimed to be an "engineer", but who designed
bridges so elaborately complicated that no one could figure out which parts
were load-bearing?

I don't claim to be an engineer. Do you, oh finder and sender on of
bugs who could not find the bugs in my code? If I were your manager, I
would in fact be very concerned that you could not do so when to do so
would have scored the points you so pathetically try to score here.

Software engineering is "how to program if you cannot", as Dijkstra
has said. You might need it. I don't. But you are by no stretch of the
imagination, an "engineer". Real engineers don't lie, because in
genuine engineering jobs, as opposed to computing jobs which in many
cases constitute welfare for white males, you lie like you do, you GO
TO JAIL.

This is why I don't take Nilges seriously when he rants about the design
of C.  He's demonstrated conclusively that he has no clue about competent
design, and someone who can't build even simple programs correctly is not
qualified to comment on any programming language.

You're lying. This thread in fact makes me very glad that I am no
longer a programmer, for commencing with the election of Reagan, I saw
the entry of people like you destroy workgroups and companies. I saw
the hiring of unqualified people (some with psychology in place of
compsci degrees, and, worse, zero interest in autodidactic computer
science) destroy the Mountain View site of Bell Northern Research.
Structured walkthroughs became savage and inane by turns, unqualified
people took trips and junkets, and around Christmas of 1985, while I
was working late on a 24 bit version of the SL.1 compiler, a holiday
party in another part of the building was ending in property damage
and drunken fistfights.

I saw people like you (including self-hating homosexuals) destroy
Catapult Software Training's Chicago office with your type of lies, as
well.

For let us not speak falsely now the hour is much too late.

You're lying. The code I posted and in which I have fixed all problems
reported to date has worked better than anything you've posted, and
YOU NEVER FIXED the %s bug that was in the code that started this
discussion! The other code samples you posted contained bugs, but your
rule seems to be "my mistakes must be forgiven, the 'heap' is a DOS
term, but if anyone I don't like, or need to ass-kiss, makes a
mistake, I'll be on his errors like a fly on shit".

Anyone here can go to the code a few posts above and download it,
compile and run it to get the following console output to verify that
you are lying, as you lied maliciously and libelously about Herb
Schildt, damaging his reputation in order to create a dishonest
impression that you are a qualified programmer, which YOU ARE NOT.

I have carefully documented how the Google Groups browser may make
minor modifications which a competent technician, WHICH YOU ARE NOT,
can fix them. Whereas you created a new thread, misspelling its title,
that started with a lie and here, continues with a lie. The code you
posted is crap and doesn't solve the problem which was to do the
replace() without using string.h.

You talk about "software quality" in the corporate register which must
of necessity take ownership of the term while not ever admitting that
the speaker-writer may not know his ass from a hole in the ground.
This is the register of people who do not know their trade and who are
complete frauds.

Whereas I am discussing a real programming problem, and working with
the real professionals here, like Ike Naar, Santosh, IO_x, and
Bacarisse, I have been able AS INTENDED to debug collaboratively
showing twerps like you (who isn't, apparently, trusted to actually
code real software at his job) how it's done. I've got the code into
the state it's in, no thanks to you, where it does, I believe, the
minimal amount of work without requiring the tables that more advanced
algorithms require.

This display of competence and professionalism, by someone returning
to C after almost 20 years, along with the competence and
professionalism of Naar, Santosh, et al., has exposed you and you are
lashing out with lies, Lash Larue.

The jig is up.


Replace


Replace "111123" by "ono" in
"1111123bbb1111123bbb11123bb11111231111112111111123"
Expect "1onobbb1onobbb11123bb1ono1111112111ono":
"1onobbb1onobbb11123bb1ono1111112111ono"
Replacements expected: 4: replacements: 4


Replace "111123" by "ono" in "bbb1111123bbbbb"
Expect "bbb1onobbbbb":
"bbb1onobbbbb"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "miracle" in "a stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "stupid" by "miracle" in "a stupid error"
Expect "a miracle error":
"a miracle error"
Replacements expected: 1: replacements: 1


Replace "the stupid error" by "a miracle" in "the stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "the" by "a" in "the miracle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "snirpKamunkle" by "e" in "a miraclsnirpKamunkle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "a miracle" by "" in "a miraclesnirpKamunkle"
Expect "snirpKamunkle":
"snirpKamunkle"
Replacements expected: 1: replacements: 1


Replace "a miracle" by "" in " a miraclesnirpKamunkle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 1: replacements: 1


Replace "a miracle" by "" in " a miraclesnirpKamunklea miraclea
miracle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 3: replacements: 3


Replace "a miracle" by "" in "a miracle a miraclesnirpKamunkle a
Miraclea miraclea miracle"
Expect " snirpKamunkle a Miracle":
" snirpKamunkle a Miracle"
Replacements expected: 4: replacements: 4


Replace "stupid error" by "miracle" in "a stupid errord"
Expect "a miracled":
"a miracled"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "miracle" in "a stupid errod"
Expect "a stupid errod":
"a stupid errod"
Replacements expected: 0: replacements: 0


Replace "stupid error" by "miracle" in "a sstupid error"
Expect "a smiracle":
"a smiracle"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "miracle" in "a stupid errorstupid error"
Expect "a miraclemiracle":
"a miraclemiracle"
Replacements expected: 2: replacements: 2


Replace "stupid error" by "miracle" in "a stupid error stupiderror"
Expect "a miracle stupiderror":
"a miracle stupiderror"
Replacements expected: 1: replacements: 1


Replace "b" by "a" in "bbbbbbbbbb"
Expect "aaaaaaaaaa":
"aaaaaaaaaa"
Replacements expected: 10: replacements: 10


Replace "%s" by "Cthulu" in "In the halls of R'yleh great %s lies
dreaming"
Expect "In the halls of R'yleh great Cthulu lies dreaming":
"In the halls of R'yleh great Cthulu lies dreaming"
Replacements expected: 1: replacements: 1


Replace "%s" by "Cthulu" in "%s%s%s%s%s%s"
Expect "CthuluCthuluCthuluCthuluCthuluCthulu":
"CthuluCthuluCthuluCthuluCthuluCthulu"
Replacements expected: 6: replacements: 6


Replace "ana" by "oat" in "banana"
Expect "boatna":
"boatna"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "+" in " a stupid errorstupid errorHeystupid
errors"
Expect " a ++Hey+s":
" a ++Hey+s"
Replacements expected: 3: replacements: 3


Replace "foo bar" by "bas" in "foo barfoo barf"
Expect "basbasf":
"basbasf"
Replacements expected: 2: replacements: 2


Replace "ba" by "ba" in "abab"
Expect "abab":
"abab"
Replacements expected: 1: replacements: 1


Replace "bab" by "boop" in "abab"
Expect "aboop":
"aboop"
Replacements expected: 1: replacements: 1


Replace "ana" by "ono" in "banana"
Expect "bonona":
"bonona"
Replacements expected: 1: replacements: 1


Replace "x" by "b" in "a"
Expect "a":
"a"
Replacements expected: 0: replacements: 0


Replace "x" by "b" in "x"
Expect "b":
"b"
Replacements expected: 1: replacements: 1


Replace "egregious" by "egregious" in "egregious"
Expect "egregious":
"egregious"
Replacements expected: 1: replacements: 1


Replace "egregious" by "x" in "egregious"
Expect "x":
"x"
Replacements expected: 1: replacements: 1




Testing complete: check output carefully: "Assertion failed" should
not occur!

 

[spinoza1111]

The fact that I can write it. The fact that I am (purely for my own
amusement) nearly done with writing an e-mail user-agent (not in C and
not likely to be seen off my own Mac). The fact that at SLAC more than
20 years ago, I wrote a software package (30k lines of C) to control and
gather statistics from a number of similar digital switches, running on
a MicroVAX. Some parts of the code ran on other VAXes (VMS) and IBM
mainframes under VM/CMS.

To do this we:

1) Used the Xerox suite of network protocols (IP not then being in the
ascendency).

2) Adapted a commercial threads microkernel (written in C) to run under
VMS and VM/CMS (note: we had no portability issues with the C). We had
to write a small amount of assembler for each host type (and fix a
number of bugs we found inside VM/CMS, mostly to do with timer handling).

Note also that all the C code written for this project was re-entrant (a
feature heavily used in the project). And we had no problems with that
either.

I could also throw in the assets database and associated front end (not
written in C) done at my last employer before retiring, but I can't be
bothered.

I might also point out that I was with each of my three employers for 15
years and left each voluntarily.

So, all in all, I think it can be said that I can read code.

Doesn't follow, at all. In fact, many programmers have attention-
hyperactivity disorder that makes them prefer to write new code rather
than make the longer, more focused, and more empathic effort to read,
tolerate, connect-with and finally understand The Code of the Other.

When I started in programming, in fact, I was struck by the sheer
number of nervous disorders and tics of my coworkers, although they
were a refreshing change of pace from my own. I was especially struck
by how many programmers seemed to have math anxiety. I taught a C
class in 1990: one commenter said "he uses too much math", which was
just nuts if you ask me.

Most famously Larry Ellison, the CEO of Oracle, had by his own account
AHD and by his own account succeeded at a famously difficult Fortran
class at the University of Illinois because as opposed to other
"boring" classes, he could focus for short but sharp amounts of time
on writing new code, which then as now is the focus in university
programming courses. I had the same experience at roughly the same
time, writing a bug free machine language program as my first program
ever on a freezing night at Northwestern's library.

But I found it harder to tolerate The Code of the Other, in my case
because the first Code of the Other I encountered was genuinely poor
code. I had to cultivate the skill at Bell Northern Research where I
inherited a mass of compilers and tools, that were written by
extremely bright people in Ottawa (celebrated in a book, now out of
print, called Knights of the New Technology).

This is why I have always been skeptical of the unprovable claim that
code (or English text) is "hard to read", which is phrased as an
innate property of the text, and not of the relation of the reader to
the text. It is based on a primitive, lower middle class, almost
magical "theory" of the text in which the text, like the Bible of the
fundamentalist, must give a singular answer, in the style and
shibboleths of the reader, and if it does not, then it's the author's
fault.

In fine, I really don't care that you've been a faithful employee of
three firms and written a lotta code. That may be admirable, and
thanks for sharing, but it doesn't make you an authority on software
readability.

 

[Stefan Ram]

long strLength(const char *s)

ISO C 90 might contain a provision stating that:

»The implementation may further restrict the
significance of an external name (an identifier that has
external linkage) to six characters and may ignore
distinctions of alphabetical case for such names«.

(This text was copied from a draft, but I remember
having read this in the ANSI document, too.)

 

[Ben Bacarisse]

Some of the best code I have dealt with turned out to need a while to
acclimatise to.

One should NEVER program to the lowest common denominator such as Bill
Cunningham for example.

There appears to be some strange opinion here that ALL code is
constantly being read by hundreds of people as the brilliance of your
output is ported and modded to 1000s of platforms and new projects. It
isn't. Far better to have a small routine complex but EFFICIENT that
"easy to read" and a dog. Complex? Comment it.

All code has at least one important reader -- the author. What odds
do you give that version 11 of this code (if I've counted correctly) is
finally bug free?

 

[Seebs]

All code has at least one important reader -- the author. What odds
do you give that version 11 of this code (if I've counted correctly) is
finally bug free?

The assumption that efficient code must be hard to read, or that efficiency
is likely to make code hard to read, is unsupported.

The problem with the Nilges string replace program is largely that the design
is gratuitously complicated. However, simply choosing remotely reasonable
names for the ptrIndex* variables would probably have addressed a great deal
of it. If you're constantly flipping back to see what something points to,
that suggests that you're doing it wrong.

Furthermore, the performance of his algorithm is likely to be unbelievably
bad, because on most systems, the overhead of malloc/free pairs is noticably
larger than the overhead of searching an entire string several times. So it's
not even actually efficient.

In general, you should write things for clarity first. Once you have
something which clearly works and is well-understood and tested, THEN it
is time to start thinking about such questions as "is it fast enough". If
not, then you profile to find out where the time goes. THEN you see whether
it's time to rewrite something.

But even if you're writing for efficiency, it's not usually necessary to
write unclear code. Contrary to popular belief, the execution time of code
is not harmed by indentation, decent variable naming conventions, or the
like. On modern compilers, intermediate variables are likely free too, so
writing for clarity by, say, giving a name to a particular intermediate
value, doesn't usually hurt performance.

As is usually the case, "Richard" (no last name) is apparently trolling,
stupid, or both.

-s

 

[Seebs]

You also missed my advice (upthread) to ditch the function completely
and use the standard library, which will wipe the floor with both versions.

Typically, yes.

That said, I do like the idiom
size_t lenstr(char *string) {
char *end = string;
while (*end++)
;
return end - string;
}

Not that it's likely to make a noticeable difference. Or that it's likely
worth it when obviously the standard library one will be fine.

-s

 

[Keith Thompson]

That said, I do like the idiom
size_t lenstr(char *string) {
char *end = string;
while (*end++)
;
return end - string;
}

Not that it's likely to make a noticeable difference. Or that it's likely
worth it when obviously the standard library one will be fine.

Note that ``end - string'' yields a value of type ptrdiff_t, a signed
type which very likely can't represent all values of type size_t.

This is unlikely to be an issue in practice. On typical 32-bit
systems, problems show up only for strings longer than 2 gigabytes,
and even then the properties of 2's-complement arithmetic are likely
to result in the correct answer anyway.

But all this analysis, resulting in the conclusion that it will
almost certainly work properly, becomes unnecessary if you just
use strlen().

 

[Phil Carmody]

Typically, yes.

That said, I do like the idiom
size_t lenstr(char *string) {
char *end = string;
while (*end++)
;
return end - string;
}

Not that it's likely to make a noticeable difference. Or that it's likely
worth it when obviously the standard library one will be fine.

You ran straight into the fencepost. And can we have more const,
pretty please?

Phil, who uses strlen().

 

[Chris M. Thomasson]

[...]

That said, I do like the idiom
size_t lenstr(char *string) {
char *end = string;
while (*end++)
;
return end - string;
}

Not that it's likely to make a noticeable difference. Or that it's likely
worth it when obviously the standard library one will be fine.

I believe that you have a bug in that code Seebs. Perhaps you meant
something like this instead:
_____________________________________________________
size_t
xstrlen(char const* string)
{
char const* end = string;
while (*end) ++end;
return end - string;
}
_____________________________________________________


?

 

[Seebs]

I believe that you have a bug in that code Seebs.

Extremely likely.

This is one of the reasons I rely on the standard library -- my success rate
in avoiding fencepost errors is slightly *less* than chance. I'm not actually
very good at this stuff, which is why I spend so much time thinking about how
to do it better.

-s

 

[bartc]

This may have gotten buried given that it started in a Nilges thread,
but it's actually pretty interesting.

There was some discussion of algorithms to perform the task:
Inputs: target string, replacement string, original string
Output: a newly-allocated string containing the original
string with each copy of the target string replaced with the
replacement string.

Here's a hunk of mine:

for (count = 0, t = strstr(target, in); t && *t; t = strstr(t, in))
{
++count;
t += inlen;
}

Here's a hunk of another one:

These hunks are essentially performing the same part of the core loop;
find the next occurrence of the target string in the original string.

I've looked at both. The first is easier on the eye, but I still can't
figure out what it does. You say, it finds the *next* occurence of the
target, why a loop then?

The second one was written by Edward Nilges ("spinoza1111"). He offers
in its defense the assertion that it's the "best" algorithm. (Nevermind
that it's got a bug; the bug could be fixed easily.)

You can't really compare these (assuming they really do do the same thing);
your code uses some presumably tried and tested library function (strstr) to
do the tricky part, so you're comparing a *call* to that function to an
experimental *implementation* of it. That doesn't sound fair..

it is, before trying to optimize. You may, or may not, be able to
outperform
a given library's implementation of strstr().

The efficiency varies. On my lccwin32 and DMC compilers, the time to find an
"A" string, in a string consisting entirely of As, seems to depend on the
length of the string it's searching (perhaps it's doing a strlen() first?).
On gcc it's instant.

(I came across the problem in a related function strchr(), in Malcolm's
Minibasic program, where it had the effect, on large input files, of slowing
down the interpreter from 80K lines per second to about 2K. Replacing the
strchr() call with one line of custom code (I think it was just looking for
next EOL), fixed that.)

 

[Seebs]

I've looked at both. The first is easier on the eye, but I still can't
figure out what it does. You say, it finds the *next* occurence of the
target, why a loop then?

Because it finds the next occurrence repeatedly until there's no more.

You can't really compare these (assuming they really do do the same thing);
your code uses some presumably tried and tested library function (strstr) to
do the tricky part, so you're comparing a *call* to that function to an
experimental *implementation* of it. That doesn't sound fair..

I think it's extremely fair, because it highlights the flaw in his "I
refuse to use the library functions" attitude.

Agreed that there are cases where there's reasons not to do that.

-s

 

[spinoza1111]

All code has at least one important reader -- the author.  What odds
do you give that version 11 of this code (if I've counted correctly) is
finally bug free?

This isn't a game, Ben. We can play that stupid game with any code if
the game is to target people, Richard posted a technical foul with s+
+.

However, I am not going to waste your time arguing that my code is
"readable". It's not one I can win if you can't really read code and,
like most programmers I've met, are in fact underqualified. I don't
think you are, but I do think many people here are.

So perhaps the code is unreadable...to you.

 

[Phred Phungus]

The humility is a good touch. You can use mine.

size_t Strlen(char *s)
{
size_t l = 0;
if (s) while (*s++) l++;
return l;
}

So this is your home-rolled strlen?

 

[spinoza1111]

spinoza1111wrote:


Yeah. And at *this* point, when you think you've fixed it all up just
so, it's still easy to suggest improvements in your code.




The glory involved in pointing out improvements in your code is about at
the same level as the glory involved in peeling a banana.

You have suggested no useful improvements.

And indeed I haven't. When I saw a copy of the code that demonstrated
you'd learned from my first observation, I looked at the code
sufficiently closely to find a couple more observations. If you show any
sign of learning from those, I'll offer some more. But I don't save them
up. Experience teaches me that you are not a quick learner.

You're not a teacher. Your Maoist game is to replace teachers with
shouting and slogans. We've seen evidence of your deep incompetence
elsethread, for a programmer with a proper education in computer
science would NEVER copy unpredictable elements into a linked list; a
properly educated programmer would have used a linked list of
pointers. And yet you published this error, which is far more serious
than a typographical error or even a software bug, and far worse than
any of Schildt's typos.

 > since you found no bugs,

I haven't looked yet.

Lazy bastard, aren't you. Or perhaps the code is "unreadable" despite
all the work I've done? You know, I discovered a long time ago that
there are two types of people who like to call either texts or code
"unreadable":

* Stupid people employed at positions for which they are not, in
reality, qualified

* Criminals who find the law unreadable in hopes of copping a plea of
plausible deniability

 > and would have been as my arch-enemy

I'm not your arch-enemy. You are.

"He's his own worst enemy" is a bully's catchphrase.

<shrug> I didn't look.

Now let's see if you were paying attention.







Yeah, I know.


I should have realised that its lack of verbosity would appear to you to
be a weakness rather than a strength.


Good programming is made up of many good decisions.

Incompetent programmers love nursery saws:
It saves them the agony of thought.
Incompetent programmers regress to childhood's laws
A land in which "is" becomes "ought".

No, it's a standard C idiom. You'll find it in K&R, for example.

Had C been a success as a programming language, an artifact not meant
to be a human language but instead to be at a midpoint between human
language and mathematical formalism, it wouldn't need idiomatic
expressions, and because of its idiotic idioms (including not only pre
and post increment and decrement but also sprintf) years later C was
exposed as unstandardizable and non-deterministic mess.

Ah, you've been taught another new word. Here's yet another: projection.


But I didn't even use a for loop! It's not necessary here.

Yes, it is. Competent programmers do not use the while when the actual
problem is for-like:

* A for-like loop problem may be defined as one in which the
variables referenced in the loop are not changed by the loop
* A while-like loop problem may be defined as one in which they
change

You used a while when to express the underlying logic a competent
programmer (one interested in "readability" not to slobs but to other
competent programmers) would have used a for.

It could, for example, be length.

But it's not, Len.

Rubbish. Any conforming implementation is required to support
initialisation syntax.

Here you go again with fraudulent talk, the sort of bullshit that will
land you in court. Because, of course, you know that there are
multiple standards.

 > I thought you wrote portable code. Oh well.

I do. You don't know what it means.

What an asshole. Your code can't be pasted and run into common older
implementations. When another's code fails this simple test, you
condemn their competence, but you're supposed to get away with this
shit.

 

[spinoza1111]

spinoza1111wrote:


You also missed my advice (upthread) to ditch the function completely
and use the standard library, which will wipe the floor with both versions.

Another sign of incompetence you manifest is the unpleasant use of
anthropomorphic terminology to refer to the possibility that you will
use physical violence, from shoving to calling security to something
more serious, to win.

 

[spinoza1111]

The assumption that efficient code must be hard to read, or that efficiency
is likely to make code hard to read, is unsupported.

Nobody's trying to be efficient. Instead, the goal was to produce, in
a language unfriendly towards encapsulation, an encapsulation. The
practical reason for this was actually to make it easy for a
participant in this discussion to execute some very basic steps so
that she or he could evaluate the code, and either find bugs or verify
that it worked for the accumulating range of test cases, leading to
agreement that the code will work for all cases in the absence of a
formal proof.

Of course, incompetent programmers (like you and Richard) prefer
"snippets" such as your initial example of how not to find %s. As in
Adorno's analysis of Pop music, the snippet *genre* allows you to
weasel out of your mistakes in the same way the conventions of Pop
music allow the musician to suck.

In more vivid terms, I'm conducting a symphony whereas you're a garage
band. It's easier for you to appear "correct" ... to morons. I might
sound like "the Depaul University Symphony" that used in the 1990s to
practice in a space in the old Woolworth's building; their version of
Beethoven's Seventh Symphony sounded like a crowd of musicians pursued
by a bear: but the fact remains, I'm doing something of a different,
and more difficult, *genre*, than your *genre*, which is that of the
corporate drone.

The problem with the Nilges string replace program is largely that the design
is gratuitously complicated.

We already know this. If you'd read Cormen's algorithms, you'd know
that "find and replace" is two separate problems that should ideally
be factored. However, in the so-called real world, this sort of
pragmatic problem occurs all the time: I can well imagine (having had
thirty years of experience) a situation which demands an unfactored
solution and the absence of string.h: stranger things have happened.

Applied computer science is an unsung and lonely business. Most
corporate "programmers" avoid it, preferring to sit around mocking
other people, because in fact, they are either (like you) uneducated
or poorly auto-didacted in comp sci, or educated in purely theoretical
matters.

Therefore, I set myself to solve the problem of "find and replace no
string.H" in response to your incompetent %s solution, and decided to
work collaboratively by submitting preliminary versions. Some of us
are unafraid of submitting preliminary versions and some of us fix
bugs, rather than mention them with a shit-eating grin as you did wrt
%s.

 

However, simply choosing remotely reasonable
names for the ptrIndex* variables would probably have addressed a great deal
of it.  If you're constantly flipping back to see what something points to,
that suggests that you're doing it wrong.

Actually, the naming convention makes a beautiful distinction between
unchanging string pointers and work pointers, if I do say so myself.
And I do.

Furthermore, the performance of his algorithm is likely to be unbelievably
bad, because on most systems, the overhead of malloc/free pairs is noticably
larger than the overhead of searching an entire string several times.  So it's
not even actually efficient.

You have no evidence for this, and you can't even reason about it
properly; characteristic of incompetent corporate programmers being
the irresponsible use of mathematical terminology without the ability
to do the math.

In fact, we segment the string in my solution into a linked list of
segments:

// ***** Segmentation *****
struct TYPsegmentstruct
{ char * strSegment;
long lngSegmentLength;
struct TYPsegmentstruct * ptrNext; };

Note on Nilges Magyar notation: TYP means "global to the compilation
unit because upper case AND a user-defined type". Instances of TYP are
USR if global or usr if local.

Where m is the number of matches there are in fact m mallocations and
m frees to create and destroy a linked list of segments between
matches. This may be a performance hit, but note that unlike the case
of Richard's "C Unleashed" solution (in which a linked list of
TYPlongAndHorrible can blow up), we can express the worst case
mathematically:

replace("xxxxx ... xxx", "x", "y")

We can then add this to our accumulating "data base" of test cases:

Replace "x" by "y" in "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Expect "yyyyyyyyyyyyyyyyyyyyyyyyyyyy":
"yyyyyyyyyyyyyyyyyyyyyyyyyyyy"
Replacements expected: 28: replacements: 28

We then step through the code for this instance to confirm a
performance bug: for the above example, 28 segments are created each
of zero length.

Although this bug is "only" performance-related, it is in fact a
showstopper for long strings. I'm obliged to you in a quantum/
infinitesimal sense, for you've drawn our attention to this issue,
puke face.

Its solution is elegant: it is to in some way mark the linked list to
show "a run of two or more zero-length segments occurs." The most
elegant way to do this is to sign TYPsegmentstruct.lngSegmentLength
negative.

It means that in the first loop, when we arrive at the malloc, we need
to:

* Check for a previous segment: this will be a nonzero
ptrSegmentStruct
* See if it has a zero or negative length
* If it does:
+ And if the latest segment is zero length, decrement
+ And the latest segment is not zero length, create a new zero
length segment
* If it doesn't, create a segment
* If no previous segment exists, create a segment
* In the assembly loop, skip all linked list nodes with zero or
negative segment lengths

I shall add this change. Your job is to ponder whether there's a risk
that this will add another bug, or whether this is itself buggy.

Oh Finder of Bugs at your day job,
Who can't find the bugs in this code,
Oh Misser of Bugs, oh Elmer, oh Fudd
I hope this isn't too much of a load.

Your garbage, in other words, can be useful in a structured
walkthrough chaired by someone, like me, who's not afraid of you.

Mock on, mock on, Voltaire, Rousseau;
Mock on, mock on; 'tis all in vain!
You throw the sand against the wind,
And the wind blows it back again.

William Blake

"Children are different. Garbage in, food out." - Ted Nelson

In general, you should write things for clarity first.  Once you have
something which clearly works and is well-understood and tested, THEN it
is time to start thinking about such questions as "is it fast enough".  If
not, then you profile to find out where the time goes.  THEN you see whether
it's time to rewrite something.

Corporatese, for you have no clear idea of clarity apart from pure
phenomena which are private to you. What seems clear is clear. You are
not qualified to speak of mathematical clarity: you've given no
evidence of being able to do math (your ability to disrupt civilized
conversation about mathematics doesn't count).

But even if you're writing for efficiency, it's not usually necessary to
write unclear code.  Contrary to popular belief, the execution time of code
is not harmed by indentation, decent variable naming conventions, or the
like.  On modern compilers, intermediate variables are likely free too, so
writing for clarity by, say, giving a name to a particular intermediate
value, doesn't usually hurt performance.

As is usually the case, "Richard" (no last name) is apparently trolling,
stupid, or both.

And note how corporatese allows the sudden shift into racist bullying,
as is the case in real corporations. A Bell Northern Research coworker
who did an install at Northern Telecom in North Carolina noticed how
smoothly, smoothly-spoken NT managers and techs would change their
language in a break room that happened to have a glass window onto the
cafeteria. As soon as they were confident that there were no African
Americans or women present, they would immediately shift from
corporate platitudes to crude remarks about the African American
secretaries in the cafeteria.

I have said before: "troll" is a racist word, and used inaccurately
when the target posts with sincerity, as does Richard.

You and Heathfield can't stand it that there's a growing mass of
posters and lurkers who want you to cease your nonsense.

 

[spinoza1111]

Typically, yes.

That said, I do like the idiom
        size_t lenstr(char *string) {
                char *end = string;
                while (*end++)
                        ;
                return end - string;
        }

Doesn't even compile on a "standard" compiler that doesn't support
initialization in decaration.

Contains a major bug. end is postincremented when *end == NUL,
therefore your code gives and off by one answer. This is obvious.

Confirming this on the Microsoft compiler in STANDARD C mode:

char *string;
char *end;
string = "123";
end = string;
while(*end++);
printf("%d\n", end - string);

This prints 4.

How DARE you. How DARE you attack Schildt et al. for bugs as if you
never made stupid mistakes? How DARE you call people "trolls" and
"morons" for making less serious mistakes?

Does your incompetence, hypocrisy and narcissism know no upper bound?