Re: PLEASE READ (was Re: recursive proofs)

From: Programmer Dude (Chris_at_Sonnack.com)
Date: 02/02/04 

Date: Mon, 02 Feb 2004 15:47:30 -0600

"Edward G. Nilges" wrote:

> Chris Sonnack then asked me to post code in May 2002...

Good God, man! Are you still licking wounds that are almost two
years old? Don't you know that if you keep licking it, it will
never heal?

> Chris [...] used the structure of the medium of to amplify one
> error, corrected the evening it was made,

You keep repeating this lie, I presume, in the hopes someone will
eventually believe it. And this despite the easily and widely
available archived record. Because I have a few moments to play,
let's take a stroll down memory lane...I find, in my own dusty
archives some snippets worth a smile or three [editorial comments
in the usual square brackets]:

For those not interested in the stroll, but would like to see Ed's
lies exposed, skip down to [[NOW IT GETS INTERESTING...]]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Thu, 06 Jun 2002 09:57:36

> The political problem of malloc...

The "political problem of malloc"?!?!
Bwa-ha-ha-ha-ha....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Thu, 06 Jun 2002 16:06:34

> Civis Romanus sum: I have no desire to be coded as a monster who
> is off topic for the sake of being off topic, for the simple reason
> I am not.

In this corner, you're coded as a one-note kook who's still stewing
over past hurts.

[And nearly two years later, nothing's changed.]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 14 Jun 2002 12:17:24

Besides, Richard's contributions to these groups are considerable
and valuable and time-tested. And what I've seen of his code
indicates a skilled and professional programmer.

So far, your batting averages suck and we've seen no code.
                                   ^^^^^^^^^^^^^^^^^^^^^^^
[Here's the first request for code.]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 14 Jun 2002 13:13:30

> ..............for in the period 1984..1995 I wrote thousands of
> lines of C and assisted Princeton mathematician John Nash with C.

Let's see one. You appear to claim notable skill... let's see one
of your better efforts. Are you willing to undergo some peer review?

[Again a request, and NOTE that I explicitly asked you if you were
willing to undergo peer review! Four days later we get our first
taste of code (see below).]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Tue, 18 Jun 2002 16:59

> But here's some code.
>
> Dim objPowerString As New powerString
> objPowerString.value = strInstring
> MsgBox("The tenth word: " & objPowerString.Word(10))
> objPowerString = Nothing
>
> Contrast C.
>
> #define MAXSTRING 1024
> int str[];
> str = malloc(MAXSTRING);
> if { str == NULL } bombOut("Cannot get storage\n");
> ...code to parse...
> printf("The tenth word: ...
> free(str);

A very, very--even extra-ordinarily--poor example. Here's what
might be a more fair and accurate comparison (note the one-to-one
correspondence):

    PowerString* ps = PowerString_Create ();
    ps->Parse (strInstring);
    printf ("The tenth word is: %s\n", ps->GetWord(10));
    PowerString_Destroy (ps);

Note that in both cases, the meat is in the PowerString code.
Note in both cases, allocation is up to the PowerString code.
Note in both cases, "Look, Ma, no string limits!"
Note in both cases: nearly identical *use* semantics.

[Note also the inclusion of *some* error handling in his C example,
but not in the VB example, which makes the comparison even less apt.
Below is a question Ed never answered...]

> Oh, and there's also the little matter of null termination.

Do you know what a BSTR is? You should. You've been using them
for many years...

[Speaking of questions never answered,...]

We're just waiting for you to support your claim that malloc/free
is more dangerous than, say, new/delete.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Tue, 18 Jun 2002 18:20:17

>> Note that you can do the same silly thing with delete.
>
> Not with object delete since the name of the object cannot be
> converted to an address and manipulated by silly bastards in
> a future modification of the text.

Wrong.

anObject* p = new anObject[10];
++p
delete p; // KA-most-assuredly-BOOM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 21 Jun 2002 14:50:33

>>>>> Because in C I wrote a string tool...

So why did you post that VB thing? I wanna see your stunningly
elegant C code, Ed.

[...]

> My C code is stunningly elegant when I am up to speed.

Let's see some of that stunningly elegant C code, Ed.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Oh, remember this one? This was fun. Ed suggested that 64 bits
for disk addressing would someday be not enough so we should,...
well, read it for yourself...]

Subject; Re: The Data Quality Act
   Date; Mon, 24 Jun 2002 16:13:47

>>> Then, in two years, we'll need long long long. Why not bite the
>>> bullet and do all math with unlimited precision, now?
>>
>> I would much rather my disk manager use hardware math and work
>> as fast as possible. There is really no need for unbounded math
>> with a disk manager. Consider that 64 bits gives you the ability
>> to address:
>>
>> 18,446,744,073,709,551,616
>>
>> bytes (or clusters or sectors or whatevers). Seems that should
>> be plenty for any *single* disk to manage, eh?
>
> Not if I want to download feature length movies.

And just how big do you suppose a feature length movie IS? Do you
have ANY feel for just how large the number above is??

[Later I demonstrated the math, picked some absurdly high numbers for
movie size and showed that it would take about 46 thousand YEARS to
fill the disk (with about 262000 of those huge (70406492913664 byte)
movies). And that's with a disk that addresses **bytes** using a
64-bit unsigned number--most address multi-byte clusters.

You'd think any programmer would be familiar with that old story
about the King, the chessboard and the grains of rice....]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Mon, 24 Jun 2002 17:33:47

> Dude, you wanted code. Here is an example.

So I see.

> virtualString is a VB-6 object...

[...I critiqued it, here severely edited. Those interested Go Ogle...]

> It is best viewed in a wide screen to avoid line wrap.

Yet you posted it in a manner that broke lines severely. Even so, I
find it very, very weird that you maintain a careful 71 column line
width in SOME comments, but go hog wild in others as well as in the
code itself.

I note, too, that you complain about maintaining other people's code,
but make no effort to write maintainable code yourself.

I can't say I'm terribly interested in wading through over 3000 lines
of (IMO) badly written code just to offer a critique (mostly because I
assume anything I have to say will fall on blind eyes).

I waste a few bytes with some basic comments.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
First, code style. I'm not going to belabor this, because some of it
is programmer's choice, but I will say that if you worked for me, you
and I would have a long talk about coding style.

One absolute rule of mine is this: source code is for humans; write
for clarity of expression above all else.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vertical whitespace. Learn it, use it, love it.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I would absolutely require a lot more comments in the code itself.
The lack of comments is one reason I'm not going to bother wading
through the code in any detail.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Nowhere do you document your functions or their parameters.
Nowhere do you document your class, it's methods or members.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I would recommend dropping the cute box comments (usually the sign
of an immature programmer--we all did it until the silliness and
effort of maintaining that crap began to wear).

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Horizontal alignment. Consider this snip:

    Private Type TYPstate
        strObjectName As String
        strFileValue As String
        intMaxRAMSize As Integer
        ' ...
    End Type

Compare the clarity of this revision:

    Private Type TYPstate
        strObjectName As String
        strFileValue As String
        intMaxRAMSize As Integer
        ' ...
    End Type

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Private Const GUIDGEN_PRIMARY_LOCATION =
    "C:\Program Files\Microsoft Visual Studio\Common\Tools\guidgen.EXE"

So, your code only works if VS is installed? Very Bad!!
And it only works if VS is installed in the default directories?
Worse!!

And what in the world do you need GUIDs in a string manager for
anyway? Surely there was a more portable solution!

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    OBJfso As New FileSystemObject ' File system: include Microsoft
                                      ' Scripting Runtime to compile
                                      ' this

First, the FSO is a real resource pig. Second, you've just made your
code considerably less portable for no reason (basic file i/o methods
would be a better choice, since they are native to VB, and I see
nothing in your code that requires FSO).

Second, what was it you were saying elsethread about how bad non-OOP
languages were due to the shipping requirements?!?!

Third, why are you creating folders? Your mkPageFileSubDir_ method
(why abbreviate make when the name is already long?) creates a paging
file subdir...do you know about Windows temp files and the Windows
temp directory?

[Fourth, it would be--IMO--better design to split file I/O from
the string class. THAT would be just good OOD.]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Don't comment on the obvious. Comment on WHY or something else that
isn't immediately apparent at first glance: [...]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
You seem to write code as you write text: unnecessarily verbose,
tortured and containing too many irrelevancies.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Wed, 26 Jun 2002 16:19:37

[Ed posted his C code string tokenizer...]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Wed, 26 Jun 2002 17:18:36

EGN> while ( intIndex1 < strlen(strInstring) )

RH> This is very poor style. You call strlen on *every* iteration
RH> of the loop.

Ouch! This may come from working in VB where the equivalent call
(Len) is very low overhead due to BSTR containing the size. Still,
good practice would definitely suggest you NEVER call a function
more than you must.

[So we talked about this issue almost two years ago!]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[[NOW IT GETS INTERESTING...]]

Subject; Re: The Data Quality Act
   Date; Thu, 27 Jun 2002 15:10:57

I spent a hour or so re-writing the C version to what I would
consider good C practice (and per my own style just for example).
In the process I found a SERIOUS bug in the C code. It occurs on
line 131 of the C text, in the main parse function:
[...]
I'm sure you can see the problem. The allocated string has no room
for the trailing nul.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: Thanks for those huge threads!
   Date; Fri, 28 Jun 2002 10:15:51

> (2) Dude, you created an apparent riposte to the C and the VB
> comparision essentially by reformatting and relabeling the code.

And it was *expressly* labeled as exactly that.

> Had this been done to commercial source, it would have constituted
> theft. As it happens it was an injury to me because it makes you
> appear as able to devise a competent reply quickly.

I was able to quickly expose the deficiencies of your code, yes. It
wasn't hard. Took maybe an hour (done in bits over an afternoon
filled with meetings and other work).

> I worked hard on the example code.

I thought you claimed it was easy to do.

> You stole that work in order to assert dominance.

Ask your lawyer to explain the concept of "stole" to you.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 11:42:25

>>> You screwed up the line length in your browser.
>>
>> Nope. You did.
>
> Funny. I did not change it from a default.

I'll say it again: Google broke your lines.

[It took effort to convince Ed about the line-wrap problem, let
alone any bugs in his code...]

> If you'd found a bug or a cool improvement, I would have been
> impressed.

Really? Seems like you wiggled around and went into denial and THEN
start throwing up some bizarre legal smokescreen rather than address
things on their technical merits.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 12:33:39

>>> The allocated string has no room for the trailing nul.
>>
>> Sorry for missing this during my own review.
>
> You missed it because you know C and it isn't there.

Sorry, Ed, you're in *serious* denial here. There are two major
bugs in your "parsing" function. The first is exactly what I said
it is, and I'll go over it more carefully for you. [..snip...]

[So, two days later, Ed **denies** he even *has* a bug!]

> You appear not to have done your homework, for if the bug had been
> in the original it would have blown up immediately, and you did not
> bother to test your proposed code scrap.

Guess what, Ed. I loaded your original, unmodified (mod line wrapping)
source into VC++ and it DOES crash reporting:

    +--------------------------------------------------+
    | DEBUG ERROR! |
    | Program: C:\Docs\@\Test\Quick Test\Test-D.exe |
    | DAMAGE: after Normal block (#40) at 0x00300150 |
    | (Press Retry to debug the application) |
    | |
    | [Abort] [Retry] [Ignore] |
    +--------------------------------------------------+

The bug is real. Your code is broken. It breaks on the very first
non-empty-string use of the words() function in main(). Specifically,
it breaks when words() attempts to free the first returned substring,
BECAUSE it detects that you hosed that substring.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 12:40:18

Incidentally, VC++ has this to say about your source:

C:\Docs\@\Test\Quick Test\nilges_original.c :

(115) warning C4018: '<' : signed/unsigned mismatch
(123) warning C4018: '<=' : signed/unsigned mismatch
(130) warning C4018: '>=' : signed/unsigned mismatch
(293) warning C4100: 'argv' : unreferenced formal parameter
(293) warning C4100: 'argc' : unreferenced formal parameter

The last two are entirely ignorable (and trivially fixed). The
first three are telling you something important. Do you know
what it is and what it means? [Ed never replied.]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[More denial!..]

Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 13:00:07

> You cannot universally and in good faith to use "lack of readability"
> as an excuse for your failure to see an nonexistent bug.

As I have clearly shown, the bug is quite real.

I'll now show you the other bug, which is, in some regards, even worse.

I realize your power of denial is very strong, so I'm going to ask you
to try something. I want you to add a *single* line to your version
of your program and run it, and then I want you to come back and tell
us what happened.

[...snip code... Ed never tried this and reported back.]

If this doesn't crash, I'll be very, very surprised. I'll give you
and the rest of the gang a chance to figure out why. The answer is
in the post that replies to this post. I'll give you a huge helping
hint. This will crash:

   itempars ("Hello, World, What's happening?", 1, "Z", -1);

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Ed calls himself a VB programmer, yet....]

Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 13:05:41

> I did not use VB-6 threads.

No one did. They don't exist. There was a complex work-around that
involved an Active-X object. Or you can do what I did once, and drop
down into a dll for simple multi-threading so long as you never refer
back to the VB environment.

> I learned to avoid them in VB-6 because of the inadequate underlying
> implementation.

Repeat: there was NO implementation of threading in VB from 1-6.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 13:58:48

And here we are. How many of you spotted the bug?
[...big snip of detailed explanation...]

Either way you look at it, the code is seriously broken. The breakage
only applies if "parsing" what Ed names 'string delimiting'. If doing
'set delimiting', these bugs aren't hit by program execution.

Two things are noteworthy here.

First, ALWAYS test your code with *bogus* input, NOT just input you
expect to work. Had this code been even lightly tested to see how
it handled simple variations of input, this bug would have been easy
to spot.

Second, ALWAYS check return values from functions if they can return
failure values.

So, Ed. TWO major bugs in the heart of the code. Impressed, yet?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 17:54:38

[I posted the first of several original versions of a string tokenizer
that used completely different designs and trivially "fixed" all Ed's
stated objections to C solutions. Go Ogle if interested. Or you can
see them all, and Ed's original disaster and my rewrites at:

    http://www.sonnack.com/Chris/Software/Code/Toking/index2.html
]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Ed still in denial two days later...]

Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 18:16:52

> Dude claimed a bug which I have checked out and there is no bug in
> this code:
> [...]

The bug is in the very next line.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Finally Ed begins to acknowledge there "may" be a bug...]

Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 18:24:17

> This MAY be a genuine bug.

No MAY about it.

[...]

> I think having written this that you probably ARE wrong, but I am
> going to take your post home. You were certainly wrong on the null
> length issue and at best are 1 for two down.

I'm astounded by your ability to deny basic truth.

If you ever achieve sanity and clarity, you're going to owe me a very
*large* public apology.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Finally, four days later, Ed acknowledges (NOT FIXES)...]

Subject; Re: The Data Quality Act
   Date; Sun, 30 Jun 2002 23:24:16

> OK. It appears that the malloc needed to malloc one more byte.

Yes.

> Chris is probably one for two since I believe a null string with a
> string delim is handled.

I'm afraid the other bug still exists. It has to do with what happens
with you "parse" a string using string delimiting, but the string has
no delimiter present.

Add this stand-alone code block to your main() function and see what
happens. This code block reveals both errors:

[snip]

> Chris, I apologize for teasing and mocking you about this error,..

Accepted. Now you're "one for two".

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Sun, 30 Jun 2002 23:40:50

> I have to check out your objection for parsing zero length
> string-delimited strings but so far you have not, as far as
> I can see, found a bug.

Try with this sample exerciser:

[...snip...gee, it was hard to get through that thick skull...]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Apparently no penetration so far...]

Subject; Re: The Data Quality Act
   Date; Wed, 03 Jul 2002 15:30:06

>>> You are silent on the VB example and on its superiority.

Silent no more! Unfortunately, the superiority turns out to be
very much NOT in evidence.

>> Erm but the VB code had a bug, I pointed it out.
>
> We need to get off this infantile emphasis on bugs.

Okay, let's just talk about design issues and compare the VB OO
version to the C non-OO version.
[...]
Anyway, you asked for comments on your VB solution...
[...]
The AddItem method is called for each item added to the items array.
If a string has 200 tokens, this is called 200 times. Notice that it
always calls the allocateItemSpace_() method.
[...]
The important part of this is that we always enlarge our array--by
one item--by calling ReDim. So, that 200-item string makes us ReDim
the array 200 times.
[...]
One comment: the efficiency of building the complement string by
appending character after character is questionable. Each iteration
requires a new copy of the existing string with room for the append.
This also implies deallocating the previous copy.

Even VB has better ways to do this.
[...]
Despite a lot of talk about how OOP just naturally leads to better,
richer, less filling error handling, here's error-handling at its
most crude and (pardon the expression) BASIC. Not in any way better
than poor old C.
[...]
The worst problem is that every control path of every iteration has
us hit something like this:

    USRstate.strOriginal & USRstate.strDelimiter

This uses the VB string concatenation operator, "&", to add the
delimiter (or sometimes the delimiter complement) to the end of
the main string. Which could be huge. So we need to make a huge
copy every time through the loop. Every single time, DESPITE that
we are always re-generating one of the same two strings (orig+delim,
or orig+delim_compl).

This, combined with the realization you were creating a new array
every time you added a token, are the primary reasons I'd call this
design "completely broken". The code may well work as designed,
but that design is a problem.
[...]
But if your start index is, say, 1, and the matching delimiter is
the last, you'll ask InStr() to scan the 57 Kb string three times
plus the last time that should succeed.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Still no acknowledgement of error or simple test cases...]

Subject; Re: The Data Quality Act
   Date; Tue, 09 Jul 2002 17:05:02

> (2) Admission of genuine error such as a bug in the use of malloc

No admission of the second error which was clearly reported and proved.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Tue, 09 Jul 2002 17:18:12

> The non-JIT solution wastes time up front counting when the loop
> contains a break.

ROFL!! If I ever needed proof of your total programming incompetence,
that single sentence above provides more than I could ask. Let's
consider the situation you describe: a For loop that's going to iterate
over our largish string. Something like this:

    For ix = 1 To N
        ' ...doing something in here...
    Next N

Now, tell me something, Ed. How do you get "N"? By calling the items
property, yes? And what happens when you call the items property, Ed?
Ah, that's right, YOU PARSE THE WHOLE STINKING STRING!!

So, it seems clear to me you don't even understand your own design!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Ed demonstrates again his lack of true understanding of VB...]

Subject; Re: The Data Quality Act
   Date; Wed, 10 Jul 2002 14:38:00

>> It's really kind of a shame you have to make a copy here. But I
> don't know of a convenient way around it in VB, does anyone else?
>
> Hmm, not sure you are making a copy.

My, God! You *really* don't know your own preferred language!
Yes, Ed, you DO make a copy.

> What I believe happens in the VB6 run time: a pointer to the string
> heap is placed on the stack.

A pointer to the "string heap"? Do you even know what a VB string IS
under the hood? What's its proper name? I bet you don't know.

> Then a copy is made but only if the target at the point of call is a
> string. If it is anything else VB6 may convert without copy.

And what is the target in this case: the String, named Value.

Don't take my word for this, Ed. Do a SIMPLE EXPERIMENT to see what
happens. I did to check that I was right. It took about a minute.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[And now the revisionist lies begin to appear...]

Subject; Re: The Data Quality Act
   Date; Thu, 11 Jul 2002 13:06:19

>> Final category is places where the code is flat out broken and
>> won't run. There are none of these (I've noticed so far) in the
>> VB version (but there were two big ones in your C version).
>
> We fixed them.

No. You never admitted the second error, nor presented a fix I saw.
[...]
> I think the problem is that I presented end-to-end solutions which
> worked the first time out,...

No, they didn't. Your C solution crashed immediately and refused
to run until I fixed your error. Even then it produced erroneous
results due to the other bug. That's two major bugs in the single
function of substance in your C solution.

Your VB solution at least runs, but it's poorly designed--particularly
for a tool object. Worse, I say it ALSO produces erroneous results:

For the string: ",Moe,,Larry,Curley,,Shemp,Curley-Joe,CurleyJoeBesser,"

Your VB routine claims there are *nine* tokens. Do you feel there
should be a (blank) token *after* the final comma? That would make
10 tokens...

So, in my book, you presented two broken programs.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Fri, 12 Jul 2002 12:18:16

> That was a failure to increment a malloc, in one of the two places
> where it was necessary,...

And what about the other major bug?

["increment a malloc? :-) ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[There's not much point in going on, Ed *still* hasn't acknowledged
the basic design problems, nor what I'd consider a definite bug. I
close with this comparison of his VB tokenizer and mine...]

Subject; Re: The Data Quality Act
   Date; Tue, 16 Jul 2002 12:17:53

I did some comparison tests -- your VB PowerString against the VB
version I whipped up (a class called TOKENS_OBJ--code was posted
upthread). The results were surprising, even to me:

    Reading every line of a MEDIUM file (26K-chars, 1652 lines),
    breaking it into words and writing the words back out to a
    second file:

        * CJS TOKENS_OBJ - 170 msecs
        * EGN PowerString - 5778 msecs (over 30 times as long)

    Reading every line of a LARGE file (302K-chars, 10K-lines),
    breaking it into words and writing the words back out to a
    second file:

        * CJS TOKENS_OBJ - 1442 msecs
        * EGN PowerString - 51724 msecs (over 35 times as long)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|