Comparision of C Sharp and C performance

[spinoza1111]

I think you've missed the point. The parentheses around (a) are not
the issue because they are, of course, correct. The problem is the
lack of parentheses around the conditional expression.

Correctomundo: the conditional expression violates "my" rule, which I
developed in 1990, that "each macro that intends to return an
EXPRESSION must return an EXPRESSION surrounded by PARENTHESES: each
macro that intends to return a STATEMENT must return a STATEMENT LIST
surrounded by BRACES".

Why would
someone suggest that ABS might be written that way? It will trip
every beginner up.

Herb should have known the rule; he probably did know the rule.
However, most of his audience works in shops where rules in excess of
the language are known as "standards", and in these shops, employees
who cultivate their own approaches (including approaches that might be
recommended by people who consider themselves hotshots) are terminated
as "not part of the team". Therefore, it seems that Schildt and/or his
editors decided not to include a variety of "coding standards" that
have evolved because of the poor design of C.

Furthermore, a beginner taught a certain style which is in excess of
the rules of the language will be less quick to understand code
written in a different idiom, and many newbies are expected to change
code.

These "coding standards" that you wanted Herb to use are little more
than tics and pathologies in the sense that they are antibodies to the
grand pathology.

What is the grand pathology?

It is the basically sexual anxiety that causes technical males,
unwilling to admit their subordination, effeminisation and
brutalization by the corporate Big Other, to try to retrieve an ersatz
masculinity by pretending that an inferior language (C) is somehow
"close to the machine", and somehow more Authentic. This rage for
Authenticity is of course a tic of the profoundly inauthentic.

The coding standards, while effective in the case of "parenthesize
formal parameters in macros, when returning an expression return it in
parentheses, and when returning a list of C statements, make that list
into one compound statement by encasing the macro body in braces", are
like the body's immune system response to the HIV virus: the disease
is manifest in the response. The fact that these tics are needed
indicates that C sucks.

Code like that does not help anyone who has to deal with C in a real
job. People like that need correct examples and models of good
style. Why, for example, is he using 'gets'; C's worst function (and
an officially deprecated one) if he is just trying to help people muddle
though with this terrible language?

Don't blame Herb for the cowardice of C standards writers who won't
get rid of bad features once and for all when this might harm the
profits of vendors. The fact is that even if replacement features
exist, this newsgroup alone shows not even a rough consensus as to
what they should be, except for a consensus enforced by Fat Bastards
and their threats.

 

[spinoza1111]

spinoza1111wrote:


Macros don't return either expressions or statements.

Then you misunderstand their proper use despite your "expertise" in C.
If a macro returns anything else besides an expression or statement it
can cause errors. It can also cause errors if it is restricted by
outer parentheses or brackets to returning expressions-as-text or
statements-as-text, but this reduces the error space.

They represent
user-defined rules for relatively simple textual substitutions.
Functions return expressions (never statements).

Wow, I'll alert the media. Functions return expressions? This is
nonsense. Functions return the values of expressions. I'd say you're
thinking of Lisp, but you probably know less about Lisp than you know
about the high concepts of C as opposed to coding details and trivia.

I suppose a function could return a pointer to a function and this
could be called (painfully) "returning an expression", but for a C
function to return an unevaluated expression? It'd have to return the
source code and the user would have to call a C compiler!

That's one for the Heathfield tab of the Red Book, along with "Nilges
was never accepted to post at Comp.risks" and over in the Seebie tab,
"the 'heap' is a DOS term".

Operators are sometimes
spoken of as returning expressions (indeed, the Standard used to employ
that turn of phrase in one or two places);

All the more reason to ignore a Standard which was written to make
vendors rich.

 

[Ben Bacarisse]

Herb should have known the rule; he probably did know the rule.
However, most of his audience works in shops where rules in excess of
the language are known as "standards", and in these shops, employees
who cultivate their own approaches (including approaches that might be
recommended by people who consider themselves hotshots) are terminated
as "not part of the team". Therefore, it seems that Schildt and/or his
editors decided not to include a variety of "coding standards" that
have evolved because of the poor design of C.

What logic lead him to cover one important aspect of function-like
macros (putting parentheses round the parameters) and exclude another
(parentheses round the whole expression)? It look to me like a simple
mistake.

Don't blame Herb for the cowardice of C standards writers who won't
get rid of bad features once and for all when this might harm the
profits of vendors.

It's gone. The next C standard will not have gets. If there is ever
a 5th edition, presumably the code will be corrected to remove
repeated use of a deprecated function (85 uses).

But that is not the point. The world is changed by education not
standards committees. Educators should take the lead in teaching the
best practise.

<snip>

 

[Keith Thompson]

1) In the terminology of C (and that is what we discuss here) a value
is a (trivial) expression.

I don't think so. A value is something that exists during the
execution of a program; it can be stored in an object, or it can be
the result of evaluating an expression. An expression exists in C
source code (and its evaluation occurs during execution).

For example the expression 123 consists of a token that's a decimal
constant consisting of the three source characters '1', '2', and
'3'. The value that we refer to as 123 is of type int, and it
exists during program execution; when stored, it's made of bits,
not characters.

2) the return statement in the body of the code does indeed return a(n
evaluated) expression.

It returns a value which is the result of evaluating an expression.

[...]

 

[spinoza1111]

What logic lead him to cover one important aspect of function-like
macros (putting parentheses round the parameters) and exclude another
(parentheses round the whole expression)?  It look to me like a simple
mistake.

He didn't want to explain "my" 1990 rule (parenthesize formal
parameters in macro definitions, decide whether to return an
expression or a statement, return nothing else, if you return an
expression return it in its own set of round parentheses, if you
return a statement return the statement list in its own set of braces)
because there might have been counter-examples and the rule is rather
complicated.

To be able to understand it, the programmer has to know the difference
between a formal and an actual parameter and Herb could not assume
this knowledge in his readers.

It occured to me when in 1987 I used the preprocessor heavily to
create usable strings (based on the model of Rexx) and it is not the
sort of thing that occurs to C programmers without my experience in
other languages, which at the time included direct machine language,
assembler, Fortran, Cobol, PL.1, Pascal, Basic, theoretical Algol and
Rexx. It would have been too hard for Herb to explain to the entry-
level reader and it would have contradicted the readers' own
experience: it is not a rule that is in general use.

Although useful, it was basically just another neurotic tic (such as
being proud of returning something nice to the OS in a main
procedure), although taking excess pride in what you return in main()
is far more pathological since it results from thinking of the OS as a
Lacanian Big Other. Acceptable languages do not need programmers to
develop neurotic patterns of behavior.

It's gone.  The next C standard will not have gets.  If there is ever
a 5th edition, presumably the code will be corrected to remove
repeated use of a deprecated function (85 uses).

Pray, what is gets() replaced with?

But that is not the point.  The world is changed by education not
standards committees.  Educators should take the lead in teaching the
best practise.

They do. They say "don't use C, use Java". Educators must NOT allow
their agenda to be set by greedy corporations or little C coders.
Their job in computer science is to prepare people who can think
CRITICALLY and TALK BACK to Fat Bastards in corporations who say that
C, or awk, or RPG or ourveryownlanguagewhichsucks are the greatest
thing since oral sex. And as it happens, people who hate C sometimes
program rings around C lovers precisely because they know how it
sucks.

 

[spinoza1111]

spinoza1111wrote:


It's possible, but I don't think it very likely.


Macros don't return expressions, statements, or *anything else*.

Yes they do. When they are evaluated, they return a fully substituted
string. You really need to learn the relationship between the ways
functions are evaluated at run time and macros are evaluated at
preprocessor time because the similarities and differences are
fundamental computer science.

Right. Well done. I misspoke, and you caught me. That's one brownie
point to you. Treasure it.

When I stumble, Homer farts: when you stumble, Homer Simpson farts. I
am however willing to accept for the moment that you made a simple
mistake, as opposed to your deliberate lie that I wasn't in
comp.risks. I will take it out of the Red Book. Go and sin no more.

 

[spinoza1111]

spinoza1111wrote:


For someone who claims expertise in English your reading skills leave
much to be desired. A C pre-processor macro (which would be the default
use for the word 'macro' in this newsgroup) does not return anything; it
causes a textual substitution in the source code.

(Sigh) Look inside the preprocessor, or write one as a class project
in a computer science class.

You will in fact see the macro processor "returning" a fully
substituted string, which is the value of the macro when supplied with
actual parameters.

Understanding both the differences and commonality between function
evaluation at run time and macro substitution helps to understand why
the two forms of "subroutine" can be interchanged in certain cases.
Being able to explain it is fundamental to being a literate computer
scientist, whereas low-level technicians have this ability beaten out
of them in the corporation lest they "disruptively" transform a
function into a macro or vice-versa (or to or from an inline) thus
exceeding their remit.

There are indeed forms of English I have not mastered. One is the tone
of the authoritarian bully. Another is the ability to collapse trees
into vectors in the sense of replacing structure with the rows of
meaningless boxes that confront the alienated clerk.

1) In the terminology of C (and that is what we discuss here) a value is
a (trivial) expression.
2) the return statement in the body of the code does indeed return a(n
evaluated) expression.




Your behaviour is typical of the playground bully. You continue to use
quotes to taunt people.

Only when some ASSHOLE here starts in on me or one of my colleagues,
switching the discussion to the bona fides and competence of his
interlocutor when bested in a technical or social discussion. But a
Tom Brown who fights back, especially against not just Flashman but
the whole upper form, is not a bully.

The first quote was a deliberate and malicious lie. The second a silly
error made in a document that accused Schildt of errors.

 

[Ben Bacarisse]

He didn't want to explain "my" 1990 rule (parenthesize formal
parameters in macro definitions, decide whether to return an
expression or a statement, return nothing else, if you return an
expression return it in its own set of round parentheses, if you
return a statement return the statement list in its own set of braces)
because there might have been counter-examples and the rule is rather
complicated.

To be able to understand it, the programmer has to know the difference
between a formal and an actual parameter and Herb could not assume
this knowledge in his readers.

This is nonsense. It does not fit the facts: he does explain the part
you think is too complex -- what you call the actual/formal parameter
distinction. He leaves out the simple bit that would make his ABS
example usable.

He sensibly makes no mention of the statement part of your rule
because there is a better options available: the do ... while (0)
idiom.

Pray, what is gets() replaced with?

Nothing. Of course you can write it in a line or two so there is no
loss if someone wants to perpetuate the problem.

They do. They say "don't use C, use Java".

I thought we were talking about Herbert Schildt. At least I was.
Writing four editions of a C text does not seem like a good way to say
"don't use C".

<snip>

 

[spinoza1111]

This is nonsense.  It does not fit the facts: he does explain the part
you think is too complex -- what you call the actual/formal parameter

....which IS the actual/formal distinction...

distinction.  He leaves out the simple bit that would make his ABS
example usable.

He sensibly makes no mention of the statement part of your rule
because there is a better options available: the do ... while (0)
idiom.

That's a silly idiom, although you're smart enough to see the need we
both address. I can think of no earthy reason why

#DEFINE GROSS2NET do net = gross - tax; while(0)

is preferable to

#DEFINE GROSS2NET { net = gross - tax; }

You may be smart enough to provide a reason why I should use null
while, which forces the maintenance programmer to go through several
levels of mental processing ("duh me see while why is that: is dis a
loop: oooooh no because while is false: is dis a nop: no, because it
is one trip: how cleverly stupid, how stupidly clever, reason in
madness"). My example same as yours can be plugged into any context
that allows a statement, but results in less useless thinking.

One assumption here is that of self-presence but the fact is that
truly intelligent people often have somewhat longer seek times than
mediocre fellows. For example, John Horton Conway of Princeton, the
mathematician who invented the Game of Life, says he forgets whether
he's proved theorems so simply proves them again.

Whereas for the lower middle class, intelligence is measured by
clerkish speed, as if we all must scramble to do the bidding of our
betters. This is a slave morality you ask me.

Nothing.  Of course you can write it in a line or two so there is no
loss if someone wants to perpetuate the problem.



I thought we were talking about Herbert Schildt.  At least I was.
Writing four editions of a C text does not seem like a good way to say
"don't use C".

Only if the middle class fantasy of "freedom" obtains, but the fact is
that the white collar worker is directed to work in C.

 

[spinoza1111]

spinoza1111wrote:


It's possible, but I don't think it very likely.


Macros don't return expressions, statements, or *anything else*.




Right. Well done. I misspoke, and you caught me. That's one brownie
point to you. Treasure it.

You are a swine, Heathfield. You expect to be forgiven for what you
claim to be typos but are not nearly as gracious with newbies and
people who attract your swinish anger because they know more than you.

 

[spinoza1111]

spinoza1111wrote:



There is no sensible rule, simple or complicated, about what macros
return, because macros don't return anything. We covered this already.

No, macros return their expansion. Crack a book.

 

[Richard Tobin]

Pray, what is gets() replaced with?

It doesn't need a replacement, since we already have fgets().

-- Richard

 

[spinoza1111]

spinoza1111wrote:


Citation?

The word return is nowhere used in the following article:http://en.wikipedia.org/wiki/Macro_(computer_science)

So I think the onus is on you to justify your assertion.

What an incredibly pompous and yet illiterate, corporate thing to say!
Take your onus and shove it up your anus.

How stupid can you get?

In a sense your stupidity is understandable, chump. This is because I
came upon the C preprocessor from richer "preprocessors", the macro
assembler included in IBM BAL for mainframes and the PL.1 facility...a
design goal of the PL.1 product, not met in full, being able to use PL.
1's facilities at compile time. The PL.1 preprocessor evolved from the
realisation in the 1950s that if "simple textual substitution" could
be extended to assembly time, it might be useful to provide Turing
complete features at assembly time so that different versions of
source code could be generated accurately.

Therefore the more aware and widely cultivated programmer will not
think of the C preprocessor as representing textual substitution,
since merely with the addition of formal and actual parameters, a form
of computation (not Turing complete) is going on inside the macro, and
the macro is best spoken of as the subject of active voice sentences,
and it does return something merely when given actual parameters.

But do take your onus and shove it.

"Never use a metaphor, simile, or other figure of speech which you are
used to seeing in print." George Orwell never examined the
contradiction between the "simple" English and the fact that the Party
in 1984 is in a sense doing what he wants, yet he clearly intended to
warn us away from simplified English Newspeak.

Nonetheless, this is one of his most important rules...one that's
violated all the time in the corporation, where employees were
prepared to use "safe" chunks of speech without thought.

Here, the "onus" is on "you" to "justify" because the Tribunal (to be
fair) has forgotten what little it has learned and if it's not in the
Holy Book of Wikipedia (sighs and flute notes) it is heresy, because
programmer-eunuchs no longer program the Holy Computer (sighs and
flute notes) and have no clue.

And how very foolish to use the half-literate ravings of 14 year olds,
thugs, criminals and convenience store clerks as an authority. The
Dark Age begins, and its Domesday book? Wikipedia.

 

[Richard Tobin]

No, macros return their expansion.

[/QUOTE]

Please provide a reference to the Standard that supports your claim.

It's clear what he means, he's just not using C-standard terminology.
He's also not using everyday-C terminology; for example most people
would say that getchar() returns the character read even if it's
implemented as a macro.

In some languages macros are literally functions that return their
expansion, which is then evaluated to return a result; their users
just have to tolerate the ambiguous use of "return".

-- Richard

 

[Ben Bacarisse]

...which IS the actual/formal distinction...

Presumably you agree, then, that the ABS macro is simply wrong. I have
no abjection to your claim that what you call the actual/formal
parameter distinction is the actual/formal parameter distinction.

I would be more interested in how you justify this error persisting
through so many revisions (you do agree it is badly wrong, yes?). In
fact, I would like to know how bad the code in a C book has to be
before you'd criticise it.

That's a silly idiom, although you're smart enough to see the need we
both address. I can think of no earthy reason why

#DEFINE GROSS2NET do net = gross - tax; while(0)

is preferable to

#DEFINE GROSS2NET { net = gross - tax; }

Re-read the exchange from the last time we talked about this -- there's
no point in repeating it all. Google shows over 2,600,000 matches for
"do while (0) macro" (without the quotes) if you'd rather read someone
else's opinion.

You may be smart enough to provide a reason why I should use null
while, which forces the maintenance programmer to go through several
levels of mental processing ("duh me see while why is that: is dis a
loop: oooooh no because while is false: is dis a nop: no, because it
is one trip: how cleverly stupid, how stupidly clever, reason in
madness"). My example same as yours can be plugged into any context
that allows a statement, but results in less useless thinking.

Not if the programmer, trying to get by in the world, had read a good C
book rather than the bad one you are championing. It is a staggeringly
common idiom and it is a shame that the opportunity was missed to teach
it in a best-selling C text.

<snip>

 

[Dennis \(Icarus\)]

That from the chap (spinoza1111) who whines about how hostile the group is


Dennis

 

[spinoza1111]

That from the chap (spinoza1111) who whines about how hostile the group is

Yes, it is, and MEN defend themselves and their good name here. In all
cases, my hostility starts when I see good people like Adler walk in
here to be insulted by people who don't even program but who send bugs
on to other programmers because he thinks that, and shows that, void*
can be assigned a sensible meaning and used as a pointer which can be
dereferenced. Had he stayed, you faggots would have been on his ass,
lying about him as you lie about Kenny, Schildt, Navia and me.

 

[spinoza1111]

Presumably you agree, then, that the ABS macro is simply wrong.  I have
no abjection to your claim that what you call the actual/formal
parameter distinction is the actual/formal parameter distinction.

I would be more interested in how you justify this error persisting
through so many revisions (you do agree it is badly wrong, yes?).  In
fact, I would like to know how bad the code in a C book has to be
before you'd criticise it.

Because not all shops follow my rule, and it belongs less in an
introductory text and more in a book on style.

Re-read the exchange from the last time we talked about this -- there's
no point in repeating it all.  Google shows over 2,600,000 matches for
"do while (0) macro" (without the quotes) if you'd rather read someone
else's opinion.

No, I want you to show me that you have the skill to explain this,
right here and now. In fact, my version of your do while loop has a
real problem, and I want you to show me how you avoid it.

It is that in

#DEFINE GROSS2NET do { net = gross - taxes; } while(0)

the user must remember to terminate the macro call with a semicolon.
This in addition to its unreadability makes my solution better, I
believe, and I want you to show me if my wrong.

 

[spinoza1111]

How silly. And for years myself and other long term programmers managed
to understand what "the macro returns X" means.

Thanks for enlightening us.

To programmers only familiar with macros in C it's unnatural to use
the active voice when talking about what macros do. They think of
preprocessing as a word-processing operation with the preprocessor in
control.

But more seasoned programmers who have used Turing-complete macro
processors such as the PL/1 macro processor, MASM and BAL for IBM
mainframes tend to say that the macro is an active piece of code which
returns something. They understand that the absence of loops or go to
statements in the C preprocessors mean that it is not Turing complete
at preprocessor time, but if they've studied computer science they
understand from their automata class that there are lower-powered
abstract machines nonetheless capable of wide classes of computation,
such as the finite state automaton.

Programmers who've studied computer science in a real university have
also had the ability to cultivate critical thinking, so they draw the
conclusion that C preprocessor macros can do a lot of damage. Thus
they evolve rules for its use such as "a C preprocessor macro must
return either an expression or a statement: if it returns an
expression, its definition must be surrounded by round parentheses: if
it returns a statement, its definition must be surrounded by curly
brackets: furthermore, each formal parameter in the body of either
type of macro must be surrounded by round parentheses wherever it
appears".

Note these things about this rule:

(1) It was too advanced for the level at which Schildt was writing
(2) It belongs in a more advanced textbook on C style and standards
(3) Heathfield's language is to impoverished to even express this rule
(4) It is not important to the beginner, who should not even think
about writing new macros

 

[spinoza1111]

Please provide a reference to the Standard that supports your claim.

It's clear what he means, he's just not using C-standard terminology.[/QUOTE]

I have nothing but contempt for "C-standard terminology" because it's
a way for Sophists like Seebach to pretend to authority without having
taken, by his own admission, a single class in computer science.

He's also not using everyday-C terminology; for example most people
would say that getchar() returns the character read even if it's
implemented as a macro.

Heathfield would probably say that whatever function the getchar()
expansion returns "rilly" returns the value. I would say that the
getchar() macro RETURNS a string: the source code for the function
call. Once you start defining symbols and using #if and #ifdef, you do
need to talk *en passant* about what the macro, now supplied with a
brute intelligence lower than a Turing machine but with its own
combination of charm and malignity, is doing. It's like a little virus
which means to mess you up, and this is why we have my rule for coding
macros, which I shall here express in iambic pentameter:

If MACRO you would code then do it right
Don't be a loser or a clueless wight:
Decide for now and always what it is:
EXPRESSION or a STATEMENT, hotshot whiz?
If an expression it be, parentheses
Must enclose the definition roundly:
If a statement, then brackets what are curley
Must make it a single statement instead of something snurly!
Furthermore each and every parameter formal
Must be parenthesized to make your form normal.
Follow these rules and laugh at the schools
Set up to teach the flaw'd standard to fools.