Re: strlen(), K+1: clarification
- From: Ben Bacarisse <ben.usenet@xxxxxxxxx>
- Date: Fri, 22 Feb 2008 12:32:43 +0000
spinoza1111 <spinoza1111@xxxxxxxxx> writes:
<snip>
One issue can be resolved here. By posting repeatedly but snidely
about it without clarifying things (being a hater of clarity as shown
in his harassment of Schildt), Clive has managed to confuse a parallel
I drew last month between his use of K+1 to terminate a for loop
(where the C for repeatedly evaluates the for condition while the
Visual Basic and other for statements do not) and my use, in 2003, of
a strlen() in a for condition.
Ah, at last. Your repeated and persistent claims about the supposed
code posted by Clive Feather were, as I most people here had
concluded, not true. There was no strlen() in the loop condition. I
don't suppose you'll apologise for saying he made the same mistake as
you?
You now would like to suggest that K+1 in a condition is the same as
strlen. If you had not said he'd used strlen there would have been
no confusion.
I'd pointed out that because Clive is so clearly One of the Thugs, his
thug pals here won't call him to account, and allow him to claim that
the K+1 is optimized away in all situations, which of course it is not
when optimizing is off. IF c for loops should NEVER contain invariant
operations (a claim made to me by the Thugs in 2003), and IF their use
indicates incompetence, THEN Clive is incompetent: this is the crazy
logic of this group when someone is being singled out for stalking and
harassment, even as Clive had to fabricate a Scholastic and closet C
with which to abuse Schildt.
Clive, although he has some issues, is not incompetent and has a right
to be here.
But the interesting technical point, revelatory as must be said of
Clive's limitations (for as regards Schildt, he's clearly one who
starts the personal destruction and must take the consequences) is
that only the most unimaginative nonprogrammer would fail to see that
strlen(s) and K+1 are the same from the standpoint of an effective
optimization strategy, which isn't (as Clive may fancy) just about the
elimination of unneeded arithmetic operation but about the search for
and elimination of repeated invariants, which strlen(s) can often
be...is usually.
Which brings up a technical problem I'd like to discuss, because my
purpose here apart from brisk self-defense isn't gossiping and
trashing personalities like some sort of little baby girl.
C programs can't be optimized, and once again, we see: C sucks.
That is, in
strcpy(s, "ABC"); for (a, i = 0; i < strlen(s); i++) ...
you can't optimise strlen(s) and move its evaluation out of the loop
because you don't know in general what a does, and this is not because
of some convenient Cloud of Unknowing which can be invoked as a deus
ex machina as Clive invoked the Great God, Undefinabus, it's because
of aliasing. Because of a's call, optimization either stops in its
tracks or proceeds to a train wreck but in the equivalent C Sharp code
s = "ABC"; a(); for (i = 0; i < s.length; i++) ...
the call of a(), insofar as a is safe code (as it almost always is),
has no effect on s when s is not global: if s is a global, because of
the absence of aliasing, a can be examined to see if it changes s.
Or, the optimizer can store the length of s in a temp after i is
zeroed. A C optimizer could also perform this "code motion" to avoid
a's affecting the length of s; but then the body of the loop has to be
examined for aliased modifications to s and its length.
More precisely, the C optimizer has to find only the possibility and
at this point it has to fail to optimize. The C Sharp optimizer
likewise has to give up when it finds safe code, but the safety of the
latter is a design feature which means that statistically, we can
predict that optimized C programs fail much more frequently than
optimized C Sharp, Java or even VB programs!
And, of course, they do, to the delight of the Fat Bastards and the
thugs who won't learn anything new because they are too busy harassing
people.
This means that statistically, C Sharp and Java code may be just as
"efficient" or even faster than actually running C code because the
maintainers of the latter cannot optimize the code safely.
In fact, as opposed to Java, C Sharp and Visual Basic programs, C
programs should not be optimized because after optimization many will
exhibit buggy behavior. To optimize a C program you need to employ Yet
Another Fat *** (YAFB) of a C consultant to check the program for
nonstandard praxis that defeats optimization, and this is simply not
necessary as regards Java and .Net, unless the programmer of the .Net
application (not the Java application) has opened a can clearly marked
Worms, using unsafe facilities.
One final note. Clive will have difficulty in seeing the similarity of
strlen(s) and K+1 I am sure. This is because people who learn things
in school by rote and without pleasure (anhedonically) tend to become
nasty little sods in later life, and to in general have knowledge that
doesn't scale.
Clive may very well believe that strlen() cannot be optimized because K
+1 simplification is math and he may have learned that "compiler
optimization is the optimization of mathematical operations".
But I've discovered that as long as you have even my layman's
knowledge of math, you realize that many optimizations easily transfer
to string operations! In fact, string concatenation and strings
themselves seem to form a group, mathematically, where a null string
is the zero element and, perhaps, a string of length one is 1.
This means that you can eliminate K + A in an optimization-safe
language like C Sharp using safe code when dataflow analysis shows you
that A is a null string and the plus sign is string concatenation.
There is much wrong in here that I just can't face picking it apart.
I'll leave you to believe that strings + concatenation form a group
and that C can't be optimised.
--
Ben.
.
- Follow-Ups:
- Re: strlen(), K+1: clarification
- From: spinoza1111
- Re: strlen(), K+1: clarification
- References:
- strlen(), K+1: clarification
- From: spinoza1111
- strlen(), K+1: clarification
- Prev by Date: Re: strlen(), K+1: clarification
- Next by Date: Re: strlen(), K+1: clarification
- Previous by thread: Re: strlen(), K+1: clarification
- Next by thread: Re: strlen(), K+1: clarification
- Index(es):