The function below is from Richard HeathField's fgetline program. For
some reason, it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient. This could lead to unnecessarily bad performance on very
long strings. It is also written in a hard-to-read and clunky style.
char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
334  11243 
Antoninus Twink said:
The function below is from Richard HeathField's fgetline program.
It appears to be from my emgen utility, in fact.
For
some reason, it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient. This could lead to unnecessarily bad performance on very
long strings.
If it becomes a problem, I'll fix it. So far, it has not been a problem.
It is also written in a hard-to-read and clunky style.
A matter of opinion. Which bit did you find hard to read?
char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
It is not obvious to me that this code correctly replaces the code I wrote.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Mon, 8 Oct 2007 00:16:07 +0200 (CEST), in comp.lang.c , Antoninus
Twink <no****@nospam.comwrote:
>The function below is from Richard HeathField's fgetline program.
Troll alert.
>it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient. This could lead to unnecessarily bad performance on very
long strings.
Possibly but consider the three laws of optimisation, and the data
typically being processed.
>It is also written in a hard-to-read and clunky style.
I disagree.
char *t, *u;
if(t=u=malloc(strlen(s)+1))
hilarious !
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Antoninus Twink wrote:
The function below is from Richard HeathField's fgetline program. For
some reason, it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient.
What new, R.H. has written slow code for years. ;-)
This could lead to unnecessarily bad performance on very
long strings. It is also written in a hard-to-read and clunky style.
ROTFL
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
Hmm.. who's code was hard-to-read and clunky?
Anyway, you are missing the point. Strings are usually rather short, and
when located in L1 cache, is doesn't matter much, scanning it 2 or 3 times.
However, a real spead-up here, would be to drop malloc() and use fixed
sized strings. That's the way, to beat the crap out of OO code.
--
Tor <torust [at] online [dot] no>
C-FAQ: http://c-faq.com/
Tor Rustad said:
<snip>
>
Anyway, you are missing the point. Strings are usually rather short, and
when located in L1 cache, is doesn't matter much, scanning it 2 or 3
times.
The important thing is to avoid reading it n times.
However, a real spead-up here, would be to drop malloc() and use fixed
sized strings. That's the way, to beat the crap out of OO code.
If performance were the primary consideration, that's exactly what I'd have
done. Since it wasn't, it isn't. I considered robustness in the face of
long strings to be more important.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Antoninus Twink <nos...@nospam.comwrote:
The function below is from Richard HeathField's fgetline
program. For some reason, it makes three passes through
the string (a strlen(), a strcpy() then another pass to
change dots) when two would clearly be sufficient. ...
For some reason you've capitalised three letters in his
name, when two would clearly be sufficient.
--
Peter
Mark McIntyre wrote:
Antoninus Twink <no****@nospam.comwrote:
.... snip ...
>
> char *t, *u;
if(t=u=malloc(strlen(s)+1))
hilarious !
What is hilarious? It should detect the failure of malloc quite
reliably. Of course the lack of blanks is rather foul.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
"Peter Nilsson" <ai***@acay.com.auwrote in message
news:11*********************@g4g2000hsf.googlegrou ps.com...
Antoninus Twink <nos...@nospam.comwrote:
>The function below is from Richard HeathField's fgetline
program. For some reason, it makes three passes through
the string (a strlen(), a strcpy() then another pass to
change dots) when two would clearly be sufficient. ...
For some reason you've capitalised three letters in his
name, when two would clearly be sufficient.
Perhaps when he says his name out loud with a nervous tinge, it sound as if
there should be to capital letters... Speaking out load:
"That darn Heath, possible minor/stutter, Field!"
Na... Nobody is that serious about the pronouncement of somebody's name...
Ahh, it could be a simple typo...
Peter Nilsson said:
Antoninus Twink <nos...@nospam.comwrote:
>The function below is from Richard HeathField's fgetline
program. For some reason, it makes three passes through
the string (a strlen(), a strcpy() then another pass to
change dots) when two would clearly be sufficient. ...
For some reason you've capitalised three letters in his
name, when two would clearly be sufficient.
The mis-capitalisation is consistent with that used by a troll named "Paul"
(with an email address containing "paulcr"), who once threatened to break
my nose, apparently because he didn't know C very well.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
Antoninus Twink said:
>The function below is from Richard HeathField's fgetline program.
It appears to be from my emgen utility, in fact.
>For
some reason, it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient. This could lead to unnecessarily bad performance on very
long strings.
If it becomes a problem, I'll fix it. So far, it has not been a problem.
But what's frustrating is that it's an inefficiency that's completely
gratuitous! We all know that micro-optimization is bad, but this is a
micro-anti-optimization, which is surely worse!
The most natural way to look at this is "copy the characters from one
string to another, replacing . by _ when we see it". This has the
benefit of being a 1-pass algorithm. Instead, you split this up "first
copy one string to another; then go back to the beginning and swap . for
_". This makes a simple single operation into two, at the same time
introducing an extra pass through the string! It's not as if there's so
much fiendish complexity here that there's any benefit in breaking it up
into two separate operations.
>
>It is also written in a hard-to-read and clunky style.
A matter of opinion. Which bit did you find hard to read?
The function is a completely trivial one, yet I can't see it all at once
in my editor without scrolling! Whitespace can help readability, but
excessive whitespace can reduce it, and at the same time give too much
weight to things that aren't important.
>
>char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
It is not obvious to me that this code correctly replaces the code I wrote.
If you believe that it doesn't correctly replace the code you wrote, it
would be easy to demonstrate that by pointing out a specific input s for
which it gives a different result, or an error (syntax error or
undefined behavior or whatever).
Antoninus Twink wrote:
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>Antoninus Twink said:
>>It is also written in a hard-to-read and clunky style.
A matter of opinion. Which bit did you find hard to read?
The function is a completely trivial one, yet I can't see it all at once
in my editor without scrolling! Whitespace can help readability, but
excessive whitespace can reduce it, and at the same time give too much
weight to things that aren't important.
You must have a very small screen.
--
Ian Collins.
Antoninus Twink wrote:
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>It is not obvious to me that this code correctly replaces the code I wrote.
If you believe that it doesn't correctly replace the code you wrote
He hasn't said that this is what he believes. He is stating that your
code does not *obviously* replace his correctly. It is up to you to
prove it does, if you're going to say his is defective and you have come
up with a replacement.
--
Philip Potter pgp <atdoc.ic.ac.uk
"Antoninus Twink" <no****@nospam.comschrieb im Newsbeitrag
news:sl*******************@nospam.com...
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>Antoninus Twink said:
>>It is also written in a hard-to-read and clunky style.
A matter of opinion. Which bit did you find hard to read?
The function is a completely trivial one, yet I can't see it all at once
in my editor without scrolling!
20 lines don't fit your screen???
Bye, Jojo
On Sun, 07 Oct 2007 19:59:08 -0700, Peter Nilsson wrote:
Antoninus Twink <nos...@nospam.comwrote:
>The function below is from Richard HeathField's fgetline
program. For some reason, it makes three passes through
the string (a strlen(), a strcpy() then another pass to
change dots) when two would clearly be sufficient. ...
For some reason you've capitalised three letters in his
name, when two would clearly be sufficient.
And two letters in InEfficiency, when zero would clearly be
sufficient.
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.
Philip Potter said:
Antoninus Twink wrote:
>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>>It is not obvious to me that this code correctly replaces the code I
wrote.
If you believe that it doesn't correctly replace the code you wrote
He hasn't said that this is what he believes.
I always knew you could read, Philip. :-) Some other people, I'm not so
sure about.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Peter Nilsson <ai***@acay.com.auwrote:
Antoninus Twink <nos...@nospam.comwrote:
The function below is from Richard HeathField's fgetline
program. For some reason, it makes three passes through
the string (a strlen(), a strcpy() then another pass to
change dots) when two would clearly be sufficient. ...
For some reason you've capitalised three letters in his
name, when two would clearly be sufficient.
Well, yes. Now look at OP's /nom de Usenet/. Surprised?
Richard
In article <sl*******************@nospam.com>, Antoninus Twink
<no****@nospam.comwrites
>The function below is from Richard HeathField's fgetline program.
I know Richard has a thing about JN but can we not all sink to the same
level.
We should be discussing C, as it is used here, not all trying to be
pedants and petty point scoring.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Antoninus Twink <no****@nospam.comwrites:
The function below is from Richard HeathField's fgetline program. For
some reason, it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient. This could lead to unnecessarily bad performance on very
long strings. It is also written in a hard-to-read and clunky style.
char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
I would move the ++ part
,----
| while(*u++=(*s=='.' ? '_' : *s))
| s++;
`----
But yes, much nicer, easier to read and understand and possibly
faster. And hopefully working :-;
Antoninus Twink wrote:
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>Antoninus Twink said:
The function is a completely trivial one, yet I can't see it all at once
in my editor without scrolling! Whitespace can help readability, but
excessive whitespace can reduce it, and at the same time give too much
weight to things that aren't important.
>>char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
It is not obvious to me that this code correctly replaces the code I wrote.
If you believe that it doesn't correctly replace the code you wrote, it
would be easy to demonstrate that by pointing out a specific input s for
which it gives a different result, or an error (syntax error or
undefined behavior or whatever).
What happens when malloc returns a null pointer?
--
Thad
Thad Smith wrote:
Antoninus Twink wrote:
>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>>Antoninus Twink said:
>The function is a completely trivial one, yet I can't see it all at
once in my editor without scrolling! Whitespace can help readability,
but excessive whitespace can reduce it, and at the same time give too
much weight to things that aren't important.
>>>char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
It is not obvious to me that this code correctly replaces the code I
wrote.
If you believe that it doesn't correctly replace the code you wrote,
it would be easy to demonstrate that by pointing out a specific input
s for which it gives a different result, or an error (syntax error or
undefined behavior or whatever).
What happens when malloc returns a null pointer?
AFAICT it returns a null pointer value, same as Richard's version.
Thad Smith <Th*******@acm.orgwrites:
>>>>
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
What happens when malloc returns a null pointer?
It returns null obviously , why?
Richard Heathfield <rj*@see.sig.invalidwrites:
Antoninus Twink said:
>The function below is from Richard HeathField's fgetline program.
It appears to be from my emgen utility, in fact.
>For
some reason, it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient. This could lead to unnecessarily bad performance on very
long strings.
If it becomes a problem, I'll fix it. So far, it has not been a
problem.
Why write it to be slower for the same functionality. It's basic level 1
pointer stuff.
>
>It is also written in a hard-to-read and clunky style.
A matter of opinion. Which bit did you find hard to read?
It covers about 20 lines - this is harder to read when the other is
about 4 and easy to follow. In my experience excessive white space is rarely welcome in
the real world especially when using a debugger.
>
>char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
It is not obvious to me that this code correctly replaces the code I
wrote.
Which part do you think doesn't "correctly" replace the code? Always
better to highlight the errors since we are all prone to making them. I
guess there is some feature in your code that you are alluding too that
is not obvious to others.
On 8 Oct 2007 at 9:04, Philip Potter wrote:
Antoninus Twink wrote:
>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>>It is not obvious to me that this code correctly replaces the code I wrote.
If you believe that it doesn't correctly replace the code you wrote
He hasn't said that this is what he believes. He is stating that your
code does not *obviously* replace his correctly. It is up to you to
prove it does, if you're going to say his is defective and you have come
up with a replacement.
On the contrary: the code was four lines and used common C idioms. If it
isn't completely obvious to someone (or at the very least if they can't
mentally check in 10 seconds) what it does, then I don't believe they
know the language well enough to write it professionally.
(And if in turn you read my words to the letter, you'll notice that I
make no claim that Mr HeathField falls into this class of people: it is
my belief that he is being deliberately obtuse.)
On 8 Oct 2007 at 12:22, Richard wrote:
>char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
I would move the ++ part
,----
| while(*u++=(*s=='.' ? '_' : *s))
| s++;
`----
But yes, much nicer, easier to read and understand and possibly
faster. And hopefully working :-;
That's indeed easier to read, though it's always satisfying to write a
loop with no body :)
Richard said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Antoninus Twink said:
<snip>
>>>
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
It is not obvious to me that this code correctly replaces the code I
wrote.
Which part do you think doesn't "correctly" replace the code?
That's not what I said.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Philip Potter <pg*@see.sig.invalidwrites:
Antoninus Twink wrote:
>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>>It is not obvious to me that this code correctly replaces the code I wrote.
If you believe that it doesn't correctly replace the code you wrote
He hasn't said that this is what he believes. He is stating that your
code does not *obviously* replace his correctly. It is up to you to
Don't be ridiculous. It was quite clear what RH meant. The shorter code
is FAR more obvious to me anyway - especially since it removes 2
unnecessary string operations which may or may not have caused hard to
spot behaviour. The shorter version is far, far more obvious in every
way. This is, of course, IMO abnd I am sure that a nOOb who cant read
the "?" operator and has no idea about post increment and pointer
dereferncing might have difficulties with the compact nature of the
second version. Personally I think it is easy enough to read at first
glance and the reduction in library calls makes it *easier* to
understand. having said that, I haven't tested or scrutinised the code
to ensure it reproduces in all cases exactly what the original code
produces.
prove it does, if you're going to say his is defective and you have
come up with a replacement.
No one said it was deceptive. heatjfield suggested it didn't do the same
thing "obviously". The original was, however long winded, overly white
spaced and unnecessarily inefficient IMO. Real code review if you
like. No one needs 20 lines for such a simple piece of code. This is C :
elegance and efficiency is everything. I suspect that it was overly
wordy for a reason since I would be surprised to see production quality
code like that.
Richard said:
Philip Potter <pg*@see.sig.invalidwrites:
>Antoninus Twink wrote:
>>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
It is not obvious to me that this code correctly replaces the code I
wrote.
If you believe that it doesn't correctly replace the code you wrote
He hasn't said that this is what he believes. He is stating that your
code does not *obviously* replace his correctly. It is up to you to
Don't be ridiculous. It was quite clear what RH meant.
Well, I agree, but you appear to have misunderstood it nonetheless. I said
*precisely* what I meant to say, which is that it was not obvious to me
that this code correctly replaces the code I wrote.
<snip>
>prove it does, if you're going to say his is defective and you have
come up with a replacement.
No one said it was deceptive.
Nor did anyone say it was defective.
heatjfield suggested it didn't do the same thing "obviously".
Well, I said it wasn't obvious to me that it does the same thing. Your
paraphrase of what I said is susceptible to interpretations that cannot
reasonably be drawn from my original phrasing.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
"Antoninus Twink" <no****@nospam.comschrieb im Newsbeitrag
news:sl*******************@nospam.com...
>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>>Antoninus Twink said:
It is also written in a hard-to-read and clunky style.
A matter of opinion. Which bit did you find hard to read?
The function is a completely trivial one, yet I can't see it all at once
in my editor without scrolling!
20 lines don't fit your screen???
What a ridiculous argument.
It doesn't fit my source window in gdb for a start.
Why 20 lines when it can be 4 perfectly eligible, efficient lines?
Don't defend code just because of the source. The second version is
superior for production level code in at least two ways:
1) screen real estate (this IS important in the real world).
2) less library calls. less to worry about IMO.
>
Bye, Jojo
Richard Heathfield <rj*@see.sig.invalidwrites:
Richard said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>Antoninus Twink said:
<snip>
>>>>
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
It is not obvious to me that this code correctly replaces the code I
wrote.
Which part do you think doesn't "correctly" replace the code?
That's not what I said.
Yes it is. If its not "obvious" then there is an issue. It is obvious to
me. Which part is not obvious to you?
Richard Heathfield <rj*@see.sig.invalidwrites:
Philip Potter said:
>Antoninus Twink wrote:
>>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
It is not obvious to me that this code correctly replaces the code I
wrote.
If you believe that it doesn't correctly replace the code you wrote
He hasn't said that this is what he believes.
I always knew you could read, Philip. :-) Some other people, I'm not so
sure about.
It was perfectly obvious what you meant. Word games don't even begin to
cover it.
Richard wrote:
[ ... ] heatjfield suggested [ ... ]
What is it with people mangling Richard's surname? :)
Richard said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Richard said:
>>Richard Heathfield <rj*@see.sig.invalidwrites:
It is not obvious to me that this code correctly replaces the code I
wrote.
Which part do you think doesn't "correctly" replace the code?
That's not what I said.
Yes it is.
No, it isn't. Read it again.
If its not "obvious" then there is an issue.
Yes. The issue is that the suggested replacement code is overly terse and
difficult to read.
It is obvious to me. Which part is not obvious to you?
Not least the need to compress functionality into the fewest possible
source characters at the expense of readability and maintainability. I
recognise that a terse style is considered "cool" by some, but in my
experience it is merely expensive.
I still haven't bothered to attempt to /read/ the suggested replacement
code, partly since its style discourages reading, and partly because of
its source. If, as I suspect, the OP is just a sock-puppet for the guy who
threatened to break my nose (see elsethread), I'm not terribly interested
in working out whether the functionality of his code does or does not
accurately reflect that of my own.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
santosh said:
Richard wrote:
>[ ... ] heatjfield suggested [ ... ]
What is it with people mangling Richard's surname? :)
It's sheer ignorance. Getting someone's name right is a basic mark of
respect, which is why I *always* take care with names - I hate getting
them wrong, and have done so only rarely. "Kylheku" and "Dijkstra" are two
that I've got wrong in the past, but I always get them right now.
If someone continually gets a name wrong, it's a reasonable sign that they
consider that person to be not worth the bother of taking trouble for.
Richard Riley's inability or unwillingness to take out a second or two to
get my name right is therefore suggestive. And if he is so short of time
and care when composing Usenet articles that he *doesn't even have time to
get my name right*, I see no reason why I or anyone should accord his
hurried, careless views any weight. Furthermore, I would venture to
suggest that there *may* be a correlation between those who write hurried,
careless Usenet articles and those who write hurried, careless C.
And if someone habitually gets a particular name wrong in precisely the
same way that a violence-threatening troll habitually does (not Richard
Riley, I hasten to add, but this Antoninus Twink character that everyone
is treating so seriously), then it's hard to avoid the conclusion that
we're dealing with a sock puppet.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard wrote:
<snip>
Why 20 lines when it can be 4 perfectly eligible, efficient lines?
Don't defend code just because of the source. The second version is
superior for production level code in at least two ways:
1) screen real estate (this IS important in the real world).
2) less library calls. less to worry about IMO.
As far as the second point applies to this specific example, it could be
possible that the strcpy implementation is more efficient than a manual
coded loop. This could become noticeable for large string numbers or
sizes.
Minor point, but since this whole thread is nit-picking, I though I'd
mention it.
"Richard" <rg****@gmail.comschrieb im Newsbeitrag
news:dj************@news.individual.net...
"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
>"Antoninus Twink" <no****@nospam.comschrieb im Newsbeitrag
news:sl*******************@nospam.com...
>>On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
Antoninus Twink said:
It is also written in a hard-to-read and clunky style.
A matter of opinion. Which bit did you find hard to read?
The function is a completely trivial one, yet I can't see it all at once
in my editor without scrolling!
20 lines don't fit your screen???
What a ridiculous argument.
Indeed. Not mine though but Antonius'...
It is definitly easier to read. Yes it could have been written more compact,
I esp. disliked the "return t;" in 2 lines and with a different brace style
one could save another couple of lines and still keep it simple.
It doesn't fit my source window in gdb for a start.
esp. in a debugger it is much easier to follow the flow if not everything is
done in one line
Why 20 lines when it can be 4 perfectly eligible, efficient lines?
see above, because it is easier to debug.
For that reason I liked your improvement to Antonius' version (moving the ++
part into the otherwise empty body of the loop).
Don't defend code just because of the source.
?? You mean RH being the source and I defend it because of that? Or what
else are youn trying to say here?
The second version is
superior for production level code in at least two ways:
1) screen real estate (this IS important in the real world).
2) less library calls. less to worry about IMO.
We're talking about one call to strcpy, which in a decent implementation is
lightning fast and higly optimized, so saving it doesn't really save much.
Bye, Jojo
"Antoninus Twink" <no****@nospam.comschrieb im Newsbeitrag
news:sl*******************@nospam.com...
On 8 Oct 2007 at 12:22, Richard wrote:
>>char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
I would move the ++ part
,----
| while(*u++=(*s=='.' ? '_' : *s))
| s++;
`----
But yes, much nicer, easier to read and understand and possibly
faster. And hopefully working :-;
That's indeed easier to read, though it's always satisfying to write a
loop with no body :)
Try to resist the temptation, it's hard, I know...
Bye, Jojo
Richard Heathfield wrote:
santosh said:
>Richard wrote:
>>[ ... ] heatjfield suggested [ ... ]
What is it with people mangling Richard's surname? :)
It's sheer ignorance. Getting someone's name right is a basic mark of
respect, which is why I *always* take care with names - I hate getting
them wrong, and have done so only rarely. "Kylheku" and "Dijkstra" are
two that I've got wrong in the past, but I always get them right now.
If someone continually gets a name wrong, it's a reasonable sign that
they consider that person to be not worth the bother of taking trouble
for. Richard Riley's inability or unwillingness to take out a second
or two to get my name right is therefore suggestive. And if he is so
short of time and care when composing Usenet articles that he *doesn't
even have time to get my name right*, I see no reason why I or anyone
should accord his hurried, careless views any weight. Furthermore, I
would venture to suggest that there *may* be a correlation between
those who write hurried, careless Usenet articles and those who write
hurried, careless C.
And if someone habitually gets a particular name wrong in precisely
the same way that a violence-threatening troll habitually does (not
Richard Riley, I hasten to add, but this Antoninus Twink character
that everyone is treating so seriously), then it's hard to avoid the
conclusion that we're dealing with a sock puppet.
Regarding your last paragraph, there is strong evidence that
this "Antoninus Twink" and "Paul", (having an email beginning
with "paulcr"), who posted a few months ago are the same.
<http://groups.google.com/group/comp.lang.c/msg/f2e171fc9691cd7d?dmode=source>
<http://groups.google.com/group/comp.lang.c/msg/b571a9a155facb48?dmode=source>
As you can see, the "User-Agent" and "NNTP-Posting-Host" fields in the
header are identical. Further the timezone is also the same.
Whether the "Paul" in the second message above is indeed the one who
threatened you is not so easily verifiable, but it seems very likely.
On 8 Oct 2007 at 17:38, Richard Heathfield wrote:
Not least the need to compress functionality into the fewest possible
source characters at the expense of readability and maintainability. I
recognise that a terse style is considered "cool" by some, but in my
experience it is merely expensive.
Wading through 20 lines of code that do a 4-line job in a roundabout way
can also be expensive.
I still haven't bothered to attempt to /read/ the suggested replacement
code, partly since its style discourages reading, and partly because of
its source. If, as I suspect, the OP is just a sock-puppet for the guy who
threatened to break my nose (see elsethread), I'm not terribly interested
in working out whether the functionality of his code does or does not
accurately reflect that of my own.
It's a pair of declarations, a simple return statement, and two lines of
moderately dense but completely idiomatic C. It's not like you need to
set aside a rainy afternoon to dedicate to reading it.
Actually I suspect that you've read it closely, because you'd like
nothing more than to humiliate me by pointing out a bug in it. As it's
manifestly correct, you've turned to word games instead of admitting
that your own code might, just might, admit some improvement.
And who on earth has said anything about breaking your nose? It sounds
to me like you're suffering from some form of paranoia.
Antoninus Twink wrote:
On 8 Oct 2007 at 17:38, Richard Heathfield wrote:
>Not least the need to compress functionality into the fewest possible
source characters at the expense of readability and maintainability.
I recognise that a terse style is considered "cool" by some, but in
my experience it is merely expensive.
Wading through 20 lines of code that do a 4-line job in a roundabout
way can also be expensive.
>I still haven't bothered to attempt to /read/ the suggested
replacement code, partly since its style discourages reading, and
partly because of its source. If, as I suspect, the OP is just a
sock-puppet for the guy who threatened to break my nose (see
elsethread), I'm not terribly interested in working out whether the
functionality of his code does or does not accurately reflect that of
my own.
<snip>
And who on earth has said anything about breaking your nose? It sounds
to me like you're suffering from some form of paranoia.
The email address of the poster who wrote this threatening message:
<http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/82c5c4b2e59984e0?dmode=source>
And this message:
< http://groups.google.com/group/comp....8?dmode=source
&utoken=0qjyGSsAAAAoZoYpti9uhwqsYFEYUqETYYZ-k6tkIFJmSBA4M7hURISd8ZKZA3rNsODuE9WiCO4>
begins identically.
Your messages in this thread share with the second message linked above,
identical "User-Agent", "NNTP-Posting-Host" headers as well as the
timezone.
A is related to B.
B is realted to C.
So
A is related to C.
:)
Richard Heathfield wrote:
Tor Rustad said:
<snip>
>Anyway, you are missing the point. Strings are usually rather short, and
when located in L1 cache, is doesn't matter much, scanning it 2 or 3
times.
The important thing is to avoid reading it n times.
>However, a real spead-up here, would be to drop malloc() and use fixed
sized strings. That's the way, to beat the crap out of OO code.
If performance were the primary consideration, that's exactly what I'd have
done. Since it wasn't, it isn't. I considered robustness in the face of
long strings to be more important.
I didn't look at the original code.
In particular, if the function in question, was supposed to interact
with a human providing input, OP's objections was nonsense.
--
Tor <torust [at] online [dot] no>
C-FAQ: http://c-faq.com/
"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
"Richard" <rg****@gmail.comschrieb im Newsbeitrag
news:dj************@news.individual.net...
>"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
>>"Antoninus Twink" <no****@nospam.comschrieb im Newsbeitrag
news:sl*******************@nospam.com...
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
Antoninus Twink said:
>It is also written in a hard-to-read and clunky style.
>
A matter of opinion. Which bit did you find hard to read?
The function is a completely trivial one, yet I can't see it all at once
in my editor without scrolling!
20 lines don't fit your screen???
What a ridiculous argument.
Indeed. Not mine though but Antonius'...
It is definitly easier to read. Yes it could have been written more compact,
I esp. disliked the "return t;" in 2 lines and with a different brace style
one could save another couple of lines and still keep it simple.
>It doesn't fit my source window in gdb for a start.
esp. in a debugger it is much easier to follow the flow if not everything is
done in one line
You are being purposely obstructive for some reason. No one mentioned 1
line. It is however important, in my experience, to keep tight code
close together so it can be examined without excessive scrolling or
white space cluttering up the display.
>
>Why 20 lines when it can be 4 perfectly eligible, efficient lines?
see above, because it is easier to debug.
No, it isn't. by adding the s++ line I suggested you have ability to
examine data on every iteration. Set your watched variables, step. Done.
For that reason I liked your improvement to Antonius' version (moving the ++
part into the otherwise empty body of the loop).
Two reasons : because it meant you didnt have the same s++ twice. Less
code as it happens. In addition a suitable break point to examine the
flow. Contrary to a lot of opinion here I belieb debuggers are very
useful and incredibly handy for teaching new programmers how a system
works. As well, of course, as being able to set watch points and HW
breakpoints.
>
>Don't defend code just because of the source.
?? You mean RH being the source and I defend it because of that? Or what
else are youn trying to say here?
Just that. I can see no advantages whatsoever to the original code. It
is wordy, spacey and inefficient.
>
>The second version is
superior for production level code in at least two ways:
1) screen real estate (this IS important in the real world).
2) less library calls. less to worry about IMO.
We're talking about one call to strcpy, which in a decent implementation is
lightning fast and higly optimized, so saving it doesn't really save
much.
So, which, as a C programmer, do you prefer?
To me there is only one contender. Sorry and all that but I feel
strongly about it. Really.
>
Bye, Jojo
Antoninus Twink <no****@nospam.comwrites:
On 8 Oct 2007 at 17:38, Richard Heathfield wrote:
>Not least the need to compress functionality into the fewest possible
source characters at the expense of readability and maintainability. I
recognise that a terse style is considered "cool" by some, but in my
experience it is merely expensive.
Wading through 20 lines of code that do a 4-line job in a roundabout way
can also be expensive.
>I still haven't bothered to attempt to /read/ the suggested replacement
code, partly since its style discourages reading, and partly because
of
Rubbish. I sometimes wonder if you only program in a class room. Even
K&R have this type of thing by page 20.
The code is as simple as it can get. A malloc and a typical if then else
duplication of a string using ?: It can hardly get any simpler. It seems
you are not as open to code corrections and/or improvements as you
frequently state. Why am I not surprised?
>its source. If, as I suspect, the OP is just a sock-puppet for the guy who
threatened to break my nose (see elsethread), I'm not terribly interested
in working out whether the functionality of his code does or does not
accurately reflect that of my own.
Working out?!?!?! A glance should be enough.
So know we go from "not obvious" to "I am too self important to even
bother looking at it". Not much new there then.
>
It's a pair of declarations, a simple return statement, and two lines of
moderately dense but completely idiomatic C. It's not like you need to
set aside a rainy afternoon to dedicate to reading it.
Actually I suspect that you've read it closely, because you'd like
nothing more than to humiliate me by pointing out a bug in it. As it's
manifestly correct, you've turned to word games instead of admitting
that your own code might, just might, admit some improvement.
I hate to agree. But I agree.
>
And who on earth has said anything about breaking your nose? It sounds
to me like you're suffering from some form of paranoia.
santosh <sa*********@gmail.comwrites:
Richard Heathfield wrote:
>santosh said:
>>Richard wrote:
[ ... ] heatjfield suggested [ ... ]
What is it with people mangling Richard's surname? :)
It's sheer ignorance. Getting someone's name right is a basic mark of
respect, which is why I *always* take care with names - I hate getting
them wrong, and have done so only rarely. "Kylheku" and "Dijkstra" are
two that I've got wrong in the past, but I always get them right now.
If someone continually gets a name wrong, it's a reasonable sign that
they consider that person to be not worth the bother of taking trouble
for. Richard Riley's inability or unwillingness to take out a second
or two to get my name right is therefore suggestive. And if he is so
short of time and care when composing Usenet articles that he *doesn't
even have time to get my name right*, I see no reason why I or anyone
should accord his hurried, careless views any weight. Furthermore, I
would venture to suggest that there *may* be a correlation between
those who write hurried, careless Usenet articles and those who write
hurried, careless C.
And if someone habitually gets a particular name wrong in precisely
the same way that a violence-threatening troll habitually does (not
Richard Riley, I hasten to add, but this Antoninus Twink character
that everyone is treating so seriously), then it's hard to avoid the
conclusion that we're dealing with a sock puppet.
Regarding your last paragraph, there is strong evidence that
this "Antoninus Twink" and "Paul", (having an email beginning
with "paulcr"), who posted a few months ago are the same.
<http://groups.google.com/group/comp.lang.c/msg/f2e171fc9691cd7d?dmode=source>
<http://groups.google.com/group/comp.lang.c/msg/b571a9a155facb48?dmode=source>
As you can see, the "User-Agent" and "NNTP-Posting-Host" fields in the
header are identical. Further the timezone is also the same.
Whether the "Paul" in the second message above is indeed the one who
threatened you is not so easily verifiable, but it seems very likely.
Why would you post that?
Off Topic for a start and NOTHING to do with C.
The poster was quite correct in his improvements of RHs code. Regardless
of who or what he is.
santosh said:
By the way, I'd have thought something like Perl would be
better suited to your task.
Perl is available in lots of places, it's true - but it has not yet been
ported *everywhere*.
But of course, it's best to code it
whatever language you are most familiar with.
Or indeed a language for which an implementation exists on the target
machine.
"Oh?" I hear you say. "What machine /is/ he targeting?" My answer is
simple: "how on earth should I know? Suddenly we need to know what machine
people run our code on? When did /that/ rule come in?"
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard said:
Antoninus Twink <no****@nospam.comwrites:
>On 8 Oct 2007 at 17:38, Richard Heathfield wrote:
>>Not least the need to compress functionality into the fewest possible
source characters at the expense of readability and maintainability. I
recognise that a terse style is considered "cool" by some, but in my
experience it is merely expensive.
Wading through 20 lines of code that do a 4-line job in a roundabout way
can also be expensive.
>>I still haven't bothered to attempt to /read/ the suggested replacement
code, partly since its style discourages reading, and partly because
of
Rubbish.
Precisely. And I don't intend to waste my time looking at rubbish posted by
one troll and lauded by another.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
"Antoninus Twink" <no****@nospam.comschrieb im Newsbeitrag
news:sl*******************@nospam.com...
>On 8 Oct 2007 at 12:22, Richard wrote:
>>>char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
I would move the ++ part
,----
| while(*u++=(*s=='.' ? '_' : *s))
| s++;
`----
But yes, much nicer, easier to read and understand and possibly
faster. And hopefully working :-;
That's indeed easier to read, though it's always satisfying to write a
loop with no body :)
Try to resist the temptation, it's hard, I know...
Bye, Jojo
To reiterate why : it makes it nigh on impossible to debug. And people
do use debuggers in the real world. A lot.
santosh <sa*********@gmail.comwrites:
Antoninus Twink wrote:
>On 8 Oct 2007 at 17:38, Richard Heathfield wrote:
>>Not least the need to compress functionality into the fewest possible
source characters at the expense of readability and maintainability.
I recognise that a terse style is considered "cool" by some, but in
my experience it is merely expensive.
Wading through 20 lines of code that do a 4-line job in a roundabout
way can also be expensive.
>>I still haven't bothered to attempt to /read/ the suggested
replacement code, partly since its style discourages reading, and
partly because of its source. If, as I suspect, the OP is just a
sock-puppet for the guy who threatened to break my nose (see
elsethread), I'm not terribly interested in working out whether the
functionality of his code does or does not accurately reflect that of
my own.
<snip>
>And who on earth has said anything about breaking your nose? It sounds
to me like you're suffering from some form of paranoia.
The email address of the poster who wrote this threatening message:
<http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/82c5c4b2e59984e0?dmode=source>
And this message:
<http://groups.google.com/group/comp....8?dmode=source
&utoken=0qjyGSsAAAAoZoYpti9uhwqsYFEYUqETYYZ-k6tkIFJmSBA4M7hURISd8ZKZA3rNsODuE9WiCO4>
begins identically.
Your messages in this thread share with the second message linked above,
identical "User-Agent", "NNTP-Posting-Host" headers as well as the
timezone.
A is related to B.
B is realted to C.
So
A is related to C.
:)
Santosh, you are not Heathfield's lapdog. No one cares. Can we stick to
the issue at hand - namely efficient coding in C and the possible
ramifications of wordy, overly engineered solution compared to small
precise, elegant solutions which utilise the features of the language.
"Richard" <rg****@gmail.comschrieb im Newsbeitrag
news:mn************@news.individual.net...
"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
>"Richard" <rg****@gmail.comschrieb im Newsbeitrag
news:dj************@news.individual.net...
>>"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
"Antoninus Twink" <no****@nospam.comschrieb im Newsbeitrag
news:sl*******************@nospam.com...
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
>Antoninus Twink said:
>>It is also written in a hard-to-read and clunky style.
>>
>A matter of opinion. Which bit did you find hard to read?
>
The function is a completely trivial one, yet I can't see it all at
once
in my editor without scrolling!
20 lines don't fit your screen???
What a ridiculous argument.
Indeed. Not mine though but Antonius'...
It is definitly easier to read. Yes it could have been written more
compact,
I esp. disliked the "return t;" in 2 lines and with a different brace
style
one could save another couple of lines and still keep it simple.
>>It doesn't fit my source window in gdb for a start.
esp. in a debugger it is much easier to follow the flow if not everything
is
done in one line
You are being purposely obstructive for some reason. No one mentioned 1
line.
The real work in Antonius' version is done in one line:
while(*u++=(*s=='.' ? s++, '_' : *s++));
It is however important, in my experience, to keep tight code
close together so it can be examined without excessive scrolling or
white space cluttering up the display.
Excessive scrolling and 20 lines (that could easily be deduced to some 15)
is not the same
>>Why 20 lines when it can be 4 perfectly eligible, efficient lines?
see above, because it is easier to debug.
No, it isn't. by adding the s++ line I suggested you have ability to
examine data on every iteration. Set your watched variables, step. Done.
Which is exactly my point. Yes, with your change this is possibnle, with
Antonius' it is not.
>For that reason I liked your improvement to Antonius' version (moving the
++
part into the otherwise empty body of the loop).
Two reasons : because it meant you didnt have the same s++ twice. Less
code as it happens. In addition a suitable break point to examine the
flow.
Agreed
Contrary to a lot of opinion here I belieb debuggers are very
useful and incredibly handy for teaching new programmers how a system
works. As well, of course, as being able to set watch points and HW
breakpoints.
>>Don't defend code just because of the source.
?? You mean RH being the source and I defend it because of that? Or what
else are youn trying to say here?
Just that. I can see no advantages whatsoever to the original code. It
is wordy, spacey and inefficient.
It could be condensed by using a different bracing style, without making it
more difficult to read.
The OP claimed a Bug and/or gross inefficiency. This is nonsense. There's no
bug and the inefficiency is minor and outwheight by the simplicity of the
code. Even if I see room for improvment.
>>The second version is
superior for production level code in at least two ways:
1) screen real estate (this IS important in the real world).
2) less library calls. less to worry about IMO.
We're talking about one call to strcpy, which in a decent implementation
is
lightning fast and higly optimized, so saving it doesn't really save
much.
So, which, as a C programmer, do you prefer?
I liked your version, for it's elegance and Richard's for it's simplicity.
Antonius' version is too terse, good for teaching C maybe, but not good for
production code.
Bye, Jojo
Richard said:
<snip>
Can we stick to
the issue at hand - namely efficient coding in C and the possible
ramifications of wordy, overly engineered solution compared to small
precise, elegant solutions which utilise the features of the language.
The code as written took about a minute to write, tops. EVEN IF the
suggested replacement (which, no matter what you may choose to believe, I
haven't bothered to analyse or even read) were correct and even if it were
able to do the same job in zero time, the total time it is likely to save
me over the rest of my expected lifetime is significantly lower than the
time it would take to do the necessary edit, compilation, and testing of
the replacement code.
The OP is suggesting micro-optimisation with a vengeance. He is suggesting
that I replace working code that is called *once* per program invocation
and which does its job so fast that gprof can't keep up. This is silly
beyond words. That you cannot understand this does not surprise me - after
all, you even struggle to get people's names right. Mind you, I've noticed
that you're coming along nicely on that front - another ten or fifteen
years at this rate of learning and you might just be ready to take your
place in this group as someone whose articles are actually worth reading
other than for mere rebuttal.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard <rg****@gmail.comwrites:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Philip Potter said:
>>Antoninus Twink wrote:
On 7 Oct 2007 at 22:55, Richard Heathfield wrote:
It is not obvious to me that this code correctly replaces the code I
wrote.
If you believe that it doesn't correctly replace the code you wrote
He hasn't said that this is what he believes.
I always knew you could read, Philip. :-) Some other people, I'm not so
sure about.
It was perfectly obvious what you meant. Word games don't even begin to
cover it.
Yes, it's perfectly obvious what he meant. It's also perfectly
obvious that if he had meant that he believes that it doesn't
correctly replace the code he wrote, the could and would have said so.
He didn't.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" This thread has been closed and replies have been disabled. Please start a new discussion. |
