Comparision of C Sharp and C performance

B

Ben Bacarisse

These files contain all of the code listings in

C: The Complete Reference, 4th Edition
So one might reasonably expect well honed source code.

I'd hope that would be the case, but the zip file is almost certainly
under the publisher's control and they may have copied it from edition
to edition without any input from the author. I hope this is not the
case, but I don't have the book to check it against.

<snip code>

My personal favourite is listing 12 from chapter 13 the gist of which
is a loop to print a string:

while (*str) if (!ferror(fp)) fputc(*str++, fp);

(white space edited). This can't be what was intended. I'd write it:

while (*str && fputc(*str++, fp) != EOF);

I am not sure that quoting from the file is permitted, but I hope one
line for illustration is OK. As a book author yourself, you will know
more about that than I do.

I did read the T&Cs on the site and consequently I think that even
using the above link is (technically) not permitted since I can't find
it on the site[1]. This is simply because the domain name has changed.
The new link is:
http://www.mhprofessional.com/downloads/products/0072121246/0072121246_code.zip

[1] It's one the those "if we forget to remove stuff we used to link to,
you can't use it even if you can still find it" clauses.
 
B

Ben Bacarisse

Walter Banks said:
Ben Bacarisse wrote:

listing 3 parser.c
listing 9 littlec.c
listing 18 lclib.h
listing 19 lclib.c

Is that obvious? Oh well...

Form the page you cited:

"there are no header files"

and it does seem that the .h listing is not used and not required.
Slightly odd, but so be it. Listing 3, 9 and 19 are all that are
required.
 
S

Seebs

My personal favourite is listing 12 from chapter 13 the gist of which
is a loop to print a string:

while (*str) if (!ferror(fp)) fputc(*str++, fp);

(white space edited). This can't be what was intended. I'd write it:

while (*str && fputc(*str++, fp) != EOF);

I am not sure that quoting from the file is permitted, but I hope one
line for illustration is OK. As a book author yourself, you will know
more about that than I do.

It's generally fine.

Yes, the code example will indeed loop forever if fp has an error.
I think that's sort of typical; there's a ton of stuff Schildt does
which ends up calling putc(EOF).

-s
 
P

Phil Carmody

Francis Glassborow said:
Clearly wrong :) Indeed it is when someone is unclear that it becomes
harder to decide if they are wrong.

Sometimes, but the bilgemonger is rampantly unclear, one might even
chose the word 'illucid', and yet it's trivial to decide, practically
every time, that he's wrong.

I can't believe this inane subthread is still going on. Some
people seriously need to learn how, /and why/, to use killfiles.

Phil
 
W

wolfgang.riedel

Slick. Do you have the code?

No, but it's quite evident to implement the Sieve of Eratosthenes by
#define, #include (the same files for
a) iterating over n, 2n, 3n... - and
b) iterating over 3, 5, 7 etc.
c) checking whether a number was not #define((d) as non-prime).
The complexity - and therefore the filesize(s) was impressive.

Greetings, Wolfgang
 
F

Flash Gordon

Walter said:

You don't need lclib.h since it isn't included, which is good since (as
I assume the text of the book explains) it gives two incompatible
declarations for the print function separated by the word "or" on a line
on it's own. Assuming the text explains it this is reasonable.

Also, obviously, one would hope the text explains that if doing it for
real header files should be used for the declarations!

Having done the edits specified in the comments for if you don't have
conio.h and _getche, and then gone through replacing the checks for \r
with checks for \n, and in the one obvious place (where it is skipping
passed the line termination) changed it to incrementing a pointer by one
instead of two it works with one of the test files provided! A further
fix, so the sources still work on Windows, is to change the mode of the
fopen call so it opens the text file in text mode instead of binary
mode. This will even work for Windows text format C files on a MacOS X
machine, since \r is counted as a white space character on MacOS X.

So really it's only the searching for \r and opening the file in text
mode that is not mentioned in the sources to actually make it (as far as
I'm aware) very portable.

One thing that immediately struck me about it's written just doing a
quick scan of the parser is this little peace from parcer.c
if(find_func(token)) { /* call user-defined function */
call();
*value = ret_value;
}

This suggests that find_func returns that it found the function, but a
global is used to parse the actual function found over to the call()
function!

It's actually worse than that, since the start of call is..
/* Call a function. */
void call(void)
{
char *loc, *temp;
int lvartemp;

loc = find_func(token); /* find entry point of function */
if(loc == NULL)
sntx_err(FUNC_UNDEF); /* function not defined */
else {


Which as you can see immediately repeats the call to find_func which has
just occurred! If this was fixed in the obvious way, you would also need
to simplify the way the main function in littlec.c handles finding and
calling the main function in the C program being interpreted.

I've searched the code, and the only calls to these two functions would
not be harmed by the obvious improvement to the code, and it would
actually simplify the interpreter code, speed it up, and generally be
better practice!

There may be good reasons for token itself being a global, and for other
globals, but on this part it doesn't help especially as for every call
to a function the find_func function gets called twice with identical data.

Please feel free to pass this information on to Schildt so that he can
improve and simplify his code!

Oh, and there is also the obvious problem in using gets in the getnum
function littlec provides. This entire (small) function could most
simply be replaced by a call to scanf with a format string to get a
number from stdin directly, or for additional safety there are any
number of other things one could do (such as if this is simply example
code appropriate loops calling getc to drop leading spaces then get at
maximum a suitable number of characters and handling too many characters
relatively sensibly).

It might be the rest of it is fine, I'm not going to do a full review of it.
 
S

spinoza1111

Sometimes, but the bilgemonger is rampantly unclear, one might even
chose the word 'illucid', and yet it's trivial to decide, practically
every time, that he's wrong.

I can't believe this inane subthread is still going on. Some
people seriously need to learn how, /and why/, to use killfiles.

Phil

Your lack of social skills is not an argument. You see, in real
communication, there's a basic impulse towards understanding which
means that in real communication, as opposed to your apelike chatter,
the listener tries to understand under what conditions what the other
says is true. Whereas you look for flaws in the mode of hysterical
autistic children.

By admitting Herb was "clear", Seebach was expressing the initial envy
that caused him to write his vitriolic tirade.
 
S

spinoza1111

Sometimes, but the bilgemonger is rampantly unclear, one might even
chose the word 'illucid', and yet it's trivial to decide, practically

....if one's illiterate. "Illucid" is not a word.
every time, that he's wrong.

If you don't know what I mean, then how do you know I'm wrong?

If Herb is clear, how could he say something false? To be "clear" is
to be "understandable", to be "understandable" is to help people
understand. To understand is to have knowledge, and knowledge is
justified true belief.

There are false statements in Herb's book just as there are in nearly
all books even after careful proofreading. These false statements
aren't clear. You're confusing human language with a formal language.
 
S

spinoza1111

Yes, this code is buggy. If there is a nonzero value at *str and ferror
(fp) returns true it will loop.

However, this is as much the "fault", if "fault" there be, in McGraw
Hill's technical editors, since it's long been known that bug-free
software can only be obtained with group reviews (group reviews free
of the insane back-stabbing one sees here).

Instead of his stupid and shameful vendetta against Schildt as a
person, Seebach should have accepted McGraw Hill's offer of a small
amount of money to tech review the book like a true professional.
 
S

spinoza1111

spinoza1111wrote:

ny sort would cost time.





Sorry, but now I am confused. How does using a deliberately bad

You are being childish, because there are no bad algorithms. The
purpose of the "bad" algorithm was to execute cycles.
algorithm help show that C# is not interpreted?

We already know it's not interpreted. I have explained to you already
that the JIT "compiler" (which is a "compiler" only the basic sense of
Aho et al. because it translates code) transforms byte codes to native
instructions during the first time they are processed. This is not
"interpretation".
BTW As I have said before (and is implicit in quite a few posts from
other people) interpreted/compiled is not a binary choice. Actually when
I reflect on your defence of Schildt's Small C Interpreter being a
compiler it seems that you simply choose whichever definition suits your
argument.

Bullshit. As a person who's written and published the Quick Basic
compiler-interpreter and other such products, I know that in terms of
work, a compiler-interpreter writer is not done when he's done
scanning, parsing, front-end optimization and code generation (where
he still has to emit code for the interpreted machine).

He has to write the interpreter itself.

A compiler writer who generates straightforward native code has to do
LESS.
 
S

spinoza1111

Do that.  I dare say that the seismic tremors rippling out from
the raising of your voice will wash across the pond and leave
Seebach awash with dismay and shame.  Then again, perhaps not.

You are a child, a Peter Pan, since you assume your actions have no
consequence and you transfer this assumption onto others.

Grow up.
 
S

spinoza1111

We've been over this before.  Spinny lied a whole lot in the process,
but the basic executive summary is that there exists at least one sense
of "clear" which implies "leading to knowledge", and at least one sense
of "knowledge" which is "justified true belief".  Spinny simply ignores
all the other senses of the word "clear".  He also commits a category
error; he can't distinguish between justified true belief about a message,
and the message's content being a justified true belief about reality.

The other senses of the word don't apply to texts: here they are
(Compact OED)

2. Transparent (clear as glass not meant as a metaphor)
3. Free of obstruction (the roadway was clear but Seebie smashed his
Dad's car anyway)
4. Free of disease, contamination or guilt (Seebie's conscience is not
clear)
5. Not touching: away from ("Stay clear away from Seebie-Weebie")

The only sense that applies to a TEXT is 1:

1. Easy to perceive or understand

Therefore, Seebach said in a self-contradictory fashion (one that is
consequently necessarily FALSE) that Herb's book was either "easy to
perceive" (which makes no sense unless referring to its type style) or
"easy to understand". The first definition of "understand" is
"perceive intended meaning", the second, "infer from information
received", and the third, "be sympathetically aware of".

But: if you perceive-or-understand my meaning you have justified true
belief. Your knowledge that it is false is nice to have, but DON'T
break your arm patting yourself on the back. You know a negative fact
similar in fact to the stupid "undefined" assertions many of you like
to bandy. You know little in terms of logical strength.

I am saying something innovative and philosophical over and above the
dictionary. It is that anyone who says something false hasn't said
something understandable, since in communicative v instrumental
reason, where in communicative reason (cf Habermas) the goal is always
to share truth, our job is not only to parse what another person is
saying. It is to make a good faith effort to assign it an
interpretation which makes it true, and to give up (without having
"understood" in this sense) only after that good faith effort was
made.

Whereas the childish game here is to find falsehoods because that way,
in a zero-sum game, the children who play that game build little
careers, not by acquiring academic preparation, but by ruining
reputations and standing of people who have!

It is well known that it's easy to write bugs. It's the reason
"structured walkthoughs" were invented in the past, and why open
source is a collective effort today. But overall, one has to ask
whether the bugs are life-threatening as in the case of a buggy auto
chip or CAT scanner, the software for which is developed in all cases
by groups. Herb worked on his own because he and McGraw Hill did not
agree with Kernighan, who'd written (in "The Elements of Programming
Style") that printed programs must or should be bug free. A noob could
try the buggy code out and learn a lot by fixing it. An experienced
programmer of a CAT scanner would be actionably committing malpractice
if he blindly copied code from the book.






In short, given the phrase "pink elephants", he can't comprehend that it
can be clear that this denotes pachyderms in a pale red, without it being

In all cases, a literate person understands "pink elephants" as a
metaphor for something that does not exist, not a red pachyderm. Only
CHILDREN have problems with figures of speech, esp. children with
autism.
true that such things exist.  Even if we grant his cherry-picked definition,
it is obvious to everyone else that the "justified true belief" would be
about the semantic content of a given piece of writing, not necessarily
implying that the semantic content of the piece of writing describes the
world.

If Herb codes a bug, as anyone can, we know it's wrong. But what you
so pretentiously label the "semantic content" of what you know, all
other things being equal, is just that it's wrong, and this is no
thanks to Herb.

A related error is your belief that "knowing" that constructs are
"undefined" is valuable knowledge.

But he'll doubtless be glad to explain all of this to you; if you play
your cards right, you should be able to quote the exact dictionary he claims
to be quoting and get him to tell you it's crap and only the dictionary he
named is any good.

At the end of the day, to call Herb "clear" and then to charge him
with error is not careful writing. It's corporatese, where the back-
stabber masks the back-stabbing with superficial flattery. You needed
only one extra word ("apparently", the adverb, modifying "clear", the
adjective: adverbs not only modify verbs, in case nobody told you) to
sound half-sensible, and you did not use it because you were writing a
careless and offensive document.
 
S

spinoza1111

I honestly can't tell, from his post, whether he thought he was addressing
me or you.

I was addressing you. A grownup doesn't refuse a job offer from McGraw
Hill and go off and post a document without meeting (ideally in
person) with the target. But we know that you discard email when you
don't want to defend yourself like a grownup. Instead (like the
typical corporate politician) you prefer creating rumors.

It is unacceptable that your canard became a C FAQ and you never even,
it seems, met with Schildt.
 
J

John

...if one's illiterate. "Illucid" is not a word.


If you don't know what I mean, then how do you know I'm wrong?

If Herb is clear, how could he say something false? To be "clear" is
to be "understandable", to be "understandable" is to help people
understand. To understand is to have knowledge, and knowledge is
justified true belief.

There are false statements in Herb's book just as there are in nearly
all books even after careful proofreading. These false statements
aren't clear. You're confusing human language with a formal language.

You can goto http://shootout.alioth.debian.org/
to see the performance comparing between C/C++/C#/java/.....

John Cui
 
N

Nick Keighley

The Sinclair Spectrum is a nice example.  As a line was typed it was
transformed: keywords were stored as single bytes (the top-half of the
"character" set) - that they'd been typed in as special key-presses
helped of course,

it basically meant the user was doing the lexical analysis! As I
understood it if you typed "IF" (I assuming IF is a valid keyword in
Spectrum Basic) the the interpreter didn't understand you but if you
typed shift-bucky-I (the I key having the word "IF" on it as well)
then an "IF" was added to the program. The interpreter had its key
words pre-tokenised for it!

and numeric constants were followed by a marker byte
(that meant "don't display the next 5 bytes") and then the number
transformed into binary.  So what was interpreted was a lot more
"binary-like" than the visible BASIC.

I'd not call that compilation though!

I was citing it as an unarguable example of interpretation. The far
end of the spectrum so to speak.
 
A

Aatu Koskensilta

spinoza1111 said:
But: if you perceive-or-understand my meaning you have justified true
belief. Your knowledge that it is false is nice to have, but DON'T
break your arm patting yourself on the back.

I'm afraid you're not being very clear. You seem to be suggesting if we
understand your meaning we have justified true belief we know to be
false. This is a peculiar doctrine.
I am saying something innovative and philosophical over and above the
dictionary.

What you're doing is nothing but a bit of disingenuous (and incompetent)
logic chopping.
 
R

Richard Tobin

My personal favourite is listing 12 from chapter 13 the gist of which
is a loop to print a string:

while (*str) if (!ferror(fp)) fputc(*str++, fp);

(white space edited). This can't be what was intended. I'd write it:

while (*str && fputc(*str++, fp) != EOF);
[/QUOTE]
As for the change I agree for one reason only really - I hate condition
and result on the same line when using explicit logic tokens.

You are missing the point. The original code doesn't work.
If an error occurs, it will loop indefinitely, because it will
never reach the end of the string.

As for style, I would write something like

while(*str)
if(fputc(*str++, fp) == EOF)
break;

separating the normal loop control from the exceptional condition
(and would usually do something other than just break when an error
occurs).

-- Richard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,278
Latest member
BuzzDefenderpro

Latest Threads

Top