How to convert Infix notation to postfix notation

[lawrence.jones]

You do keep making these unfounded assertions, don't you? How do *we*
know you're not written by Douglas Hofstadter?

Well, *I* know, because I've met him and his functioning metabolism.
He's a bit more substantial (at least in a physical sense) than
Hofstadter's writing.

 

[Seebs]

Well, *I* know, because I've met him and his functioning metabolism.
He's a bit more substantial (at least in a physical sense) than
Hofstadter's writing.

We can't prove that the nym has not since been taken over by an AI
collective.

-s

 

[Ian Collins]

You will recall that I expressed several other concerns. Let's see if
you've addressed them yet.

My first step was to remove all your comments. That's because they are
C99-style comments, and I don't have a C99 compiler. (Nor do most
people. You probably don't.)

Richard, you are becoming a worn out record; it isn't that hard to get a
C99 compiler.

Once line wrapping is fixed, the only warning of note is the lack of
return from main.

No one appears to have spotted then lack of a newline at end of the
final printf.

 

[Seebs]

No one appears to have spotted then lack of a newline at end of the
final printf.

Ironic, given that he has excess newlines elsewhere.

-s

 

[Ben Bacarisse]

[snipped]

#define ADDFACTOR \
        int addFactor(char *strInfix, \
                      char *strPolish, \
                      int *intPtrIndex, \
                      int intEnd, \
                      int intMaxPolishLength)
ADDFACTOR;

[snipped]

// --------------------------------------------------------------- //
Parse add factor
//
// int addFactor(char *strInfix,
//               char *strPolish,
//               int *intPtrIndex,
//               int intEnd,
//               int intMaxPolishLength) //
// addFactor = mulFactor [ *|/ mulFactor ] //
ADDFACTOR
{
    char chrMulOp = ' ';
    int intStartIndex = 0;
    if (!mulFactor(strInfix,
                   strPolish,
                   intPtrIndex,
                   intEnd,
                   intMaxPolishLength))

[snipped]

The strange thing about this coding style is that it
will save you *no* keystrokes.
Since you actually duplicate the function prototype in the comment block
just above the function definition.
Whenever you have to change the function's arguments
you will have to change the (redundant) comment as well.

Yes. This, however, gives the best result for the program reader.

I disagree.  In fact I think the more usual style helps the reader at

If you mean by "the more usual style" putting trivia before important
functions, I reject this. It's more important to me that main() not be
last than it return a value.

No, that's not what I mean.

If on the other hand you mean a list of prototypes followed by the
functions in which the function prototype is re-coded, I reject this.
It is far, far worse than an extra comment, since mistakes in
correspondence cause the program not to even compile,

In my book that is a far, far better, not far, far worse. Compiler
errors are good and easy to fix. The compiler can't check the comment
so and misinformation slips by silently.

or compile with errors.

Your compiler should be better than this. A mismatch between
prototype and function header is a show stopper, and a good compiler
should put its foot down about this.

Mistakes in the comment cause at worse a mistake in
apprehension which is correctable by changing the comment.

Or simply by writing the function header in the normal fashion. That
way, no misapprehension is possible and mistakes (in so far as they
relate only to the header or the prototype) will be caught by an
automatic tool -- the type checker of the compiler.

Yes, as the API evolves you have to edit in two places, but all your
edits are checked, rigorously, by the compiler. This is one of those
places where a little extra work by the writer benefits future
readers.

My way is clearly the best.

I see. I won't entertain the hope of changing you mind, but by laying
out the case for the more usual style, beginners may choose for
themselves.

The problem here is that like "Levine the
Genius Tailor" in Gerald Weinberg's Psychology of Computer
Programming, people have been so crippled by the defects of C that
they fetishize, reify and rationalize those defects, making a normal
human response to those defects (including coding great "pseudo-code"
which C cannot handle) itself a defect, and "normalizing" their own
deviance. Their being mentally crippled into people who write code
that is objectively disorganized (trivia before important things)
becomes in their own eyes a virtue.

You have to think this because you need an explanation that fits the
data you have: (a) that your method is is clearly the best; and (b)
that hardly anyone else uses it.

I have different data, and my explanation is simpler. C experts are
not suffering from mass hysteria, they just don't like abusing the
pre-processor in a way that hinders code comprehension later one.

C has many faults, and one of them is that it has this problem in the
first place, but the minor inconvenience it causes authors should not
be taken as an excuse to obfuscate your code. Another fault is the
obfuscation possible by misuse of the pre-processor. You do it twice,
in my view, since SKIP_WHITE_SPACE does not assist the important
readers -- one ones who check and maintain code.

In that case he need only split the screen and view the macro
definition versus the code.

Yes, I agree that the problem caused by your method is easy to
overcome, but the alternative (the usual method) has no impact on
readability at all.

<snip>

 

[spinoza1111]

On Thu, 05 Nov 2009 20:52:43 -0800,spinoza1111wrote:
[snipped]
#define ADDFACTOR \
        int addFactor(char *strInfix, \
                      char *strPolish, \
                      int *intPtrIndex, \
                      int intEnd, \
                      int intMaxPolishLength)
ADDFACTOR;
[snipped]
// --------------------------------------------------------------- //
Parse add factor
//
// int addFactor(char *strInfix,
//               char *strPolish,
//               int *intPtrIndex,
//               int intEnd,
//               int intMaxPolishLength) //
// addFactor = mulFactor [ *|/ mulFactor ] //
ADDFACTOR
{
    char chrMulOp = ' ';
    int intStartIndex = 0;
    if (!mulFactor(strInfix,
                   strPolish,
                   intPtrIndex,
                   intEnd,
                   intMaxPolishLength))
[snipped]
The strange thing about this coding style is that it
will save you *no* keystrokes.
Since you actually duplicate the function prototype in the comment block
just above the function definition.
Whenever you have to change the function's arguments
you will have to change the (redundant) comment as well.
Yes. This, however, gives the best result for the program reader.
I disagree.  In fact I think the more usual style helps the reader at

If you mean by "the more usual style" putting trivia before important
functions, I reject this. It's more important to me that main() not be
last than it return a value.

No, that's not what I mean.

If on the other hand you mean a list of prototypes followed by the
functions in which the function prototype is re-coded, I reject this.
It is far, far worse than an extra comment, since mistakes in
correspondence cause the program not to even compile,

In my book that is a far, far better, not far, far worse.  Compiler
errors are good and easy to fix.  The compiler can't check the comment
so and misinformation slips by silently.

Misinformation can be corrected. But the absence of information
cannot.

Your compiler should be better than this.  A mismatch between
prototype and function header is a show stopper, and a good compiler
should put its foot down about this.

No, this is absurd. You don't want me to repeat information in the
comment because you basically don't like documentation, but you want
potential compile errors and having to code things twice.

Or simply by writing the function header in the normal fashion.  That
way, no misapprehension is possible and mistakes (in so far as they
relate only to the header or the prototype) will be caught by an
automatic tool -- the type checker of the compiler.

Yes, as the API evolves you have to edit in two places, but all your
edits are checked, rigorously, by the compiler.  This is one of those
places where a little extra work by the writer benefits future
readers.

As usual your arguments make more sense. I think the issue is trivial
but I shall consider changing to this scheme based on what you have
said (not what Heathfield or Seebach have said).

But note that the argument that "the documentation might be wrong" is
similar to the attacks on Schildt. Basically, too many programmers are
victims of educational systems which instill in them a hatred of
language, and as such use the excuse of possible incorrectness to call
for the elimination and not critique of comments and entire computer
books such as Schildt.

The function of documentation or a computer book is not to be 100%
accurate (that if anything would be software's function) but to
provide reassurance that the program or technology is a human affair
and not completely uncontrollable and daemonic.

I see.  I won't entertain the hope of changing you mind, but by laying
out the case for the more usual style, beginners may choose for
themselves.

You are the first person to change my mind in this case, but don't
break your arm patting yourself on the back, because you are right
only when you're right.

OK, next release there will be a list of function prototypes and the
decls will be repeated at function headers: the comment decls will be
eliminated. Is this what you want? You will be anon.

You have to think this because you need an explanation that fits the
data you have: (a) that your method is is clearly the best; and (b)
that hardly anyone else uses it.

I've already changed my mind on this issue only. But I do say the C
cripples the mind and heart.

I have different data, and my explanation is simpler.  C experts are
not suffering from mass hysteria, they just don't like abusing the
pre-processor in a way that hinders code comprehension later one.

C has many faults, and one of them is that it has this problem in the
first place, but the minor inconvenience it causes authors should not
be taken as an excuse to obfuscate your code.  Another fault is the

I don't think my code was obfuscated. I think it is very clear and
laid out very well for the reader.

obfuscation possible by misuse of the pre-processor.  You do it twice,
in my view, since SKIP_WHITE_SPACE does not assist the important
readers -- one ones who check and maintain code.

Do you want me to have to go through the overhead of function call for
this op? Or do you think it should be hard coded wherever it appears?

Yes, I agree that the problem caused by your method is easy to
overcome, but the alternative (the usual method) has no impact on
readability at all.

"Readability" is meaningless since nobody here is honest about
readability,

 

[spinoza1111]

Richard, you are becoming a worn out record; it isn't that hard to get a
C99 compiler.

Once line wrapping is fixed, the only warning of note is the lack of
return from main.

No one appears to have spotted then lack of a newline at end of the
final printf.

This will be fixed in the next release. But on what systems is it
necessary? It is not in Windows, and it sounds to me as if the systems
where it is necessary are broken. Explain.

 

[spinoza1111]

There was an amusing bit in a book (Tom Holt, I think) in which someone
does something which results in a massive object of some sort falling
on him.  (Not fatal for various reasons.)  From under it, a weak voice
calls out: "Okay, now who spotted my deliberate mistake."


He might be looking only at errors, rather than warnings -- many IDE-based
compilers show you errors, but if it's just warnings all you get is a
tiny little icon somewhere changing color.

Do your homework before making unfounded claims about people.

This is the output from the current compile. It is shown, jerk face,
in a window:

1>------ Build started: Project: infix2PolishC, Configuration: Debug
Win32 ------
1>Compiling...
1>infix2PolishC.C
1>Linking...
1>LINK : C:\egnsf\infix2PolishC\iinfix2PolishC version 4\Debug
\infix2PolishC.exe not found or not built by the last incremental
link; performing full link
1>Embedding manifest...
1>Build log was saved at "file://c:\egnsf\infix2PolishC\iinfix2PolishC
version 4\infix2PolishC\Debug\BuildLog.htm"
1>infix2PolishC - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped
==========

If there are warnings, they appear alongside error messages.

People who fail to complete the tasks of growing up have, as the
"secret contour of their weakness" a secret fear that they are playing
with children's toys. Your position and your behavior do not make me
confident that you are a real grownup no matter what your age, and I
believe that this is why instead of participating in problem solving,
you prefer to "prove" (over and over again, paradoxically enough) that
"Schildt" or "Nilges" is the problem person and not you.

Here, you made a wild and unfounded charge about the Microsoft
development environment, which lists warnings alongside errors and
provides a count of errors and warnings at the end. This when you
could have verified your facts by a little research.

 

[spinoza1111]

In <[email protected]>,




Twice, now. I expect to have to post it twice or three times more
before he eventually notices. At that point, he'll claim that he knew
all along, but that he'd made a deliberate decision to include those
mistakes, since any decent compiler ought to be capable of guessing
what he intended. Or something along those lines, anyway.


Yes. But he claims a clean compile. This suggests that he is failing
to invoke his compiler correctly.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Richard Heathfield aka Fat Bastard is lying. Cf. message below from
Ian Collins: "Once line wrapping is fixed, the only warning of note is
the lack of return from main".

This warning is not provided by Microsoft's compiler since it's a
trivial issue: C programming skill is displayed far more accurately by
the Spark Notes test than claiming that // comments are wrong,
worrying about what main returns, or out and out lying. I will add the
return in the next release.

 

[spinoza1111]

In

spinoza1111wrote:

FINALLY something substantial...I hope.

All my comments on your code have been substantial, whether you
realise it or not.

Oh for Christ's sake...you're too incompetent to use a global edit
change? No, this doesn't make the cut, and I won't change the use of
the comments.

I didn't ask you to. Learn to read. Comments are not the issue I was
raising.

 I refer you to my definition of programming, per

Dijsktra and Knuth: it's the communication of intent as to using
computers between human beings, and if you act like an ape, you
aren't qualified to be in this conversation. It was clear even to
you that the lines are comments, and you know how to change them.
But because you're here to throw your weight around, you won't, and
you endanger my reputation with your posts as you harm Navia's
business and personal reputation.

No, bozo. My take was basically "okay, so he's using C99 comments,
which my compiler rejects - fair enough, I'll delete them, no harm
done". You are entitled to post C99 code here, because C99 is C too.
Comments are not the issue I was raising.

If this were a physical space I'd have long since asked you to
leave, and physically ejected you if necessary. And no, I wouldn't
call Security, either. I'd do it myself.

If wishes were horses, beggars would ride.

I've already said that I don't use balanced comments because they
are error prone.

They aren't, but // comments are legal in C99. (They are a syntax
error in C90.) If your code is intended to be C99-conforming, //
comments are not a syntactic issue. Comments are not the issue I was
raising.

[...] the people who get ahead are the back-stabbers: who
write attacks with 20 "errors" and then make reference to "100s".

You've been invited to supply 21 correct statements made by Schildt in
a C book. You have failed to do so. I conclude that you believe he
has not made 21 correct statements. Otherwise you'd be able to cite
them. If you are tempted to reply "do your own homework", remember
that the same reply applies to his errors - if you want to know what
the rest are, go find them.

**** you, asshole.

You want a cite? I can provide one easily. By the way, losing your
temper in a technical discussion is counter-productive. And resorting
to expletives is a definite sign of losing your temper.

This suggestion is too minor to include in the Change Record but I
will make it.

Hallelujah - you actually learned something. Of course it's a minor
change. But it stops linewrap from breaking that line of code (given
a sensible line width in your Usenet editor).

Consider yourself credited with a minor formatting correction.

What you choose to write in your change log is no concern of mine.

This was noticed by Nick and I added it to Issues 30 minutes before
this post appeared, so no cigar.

I'm not after a cigar. And yes, I've seen Nick's reply. I had not seen
it at the time that I posted my reply; otherwise I would simply have
mentioned that "Nick has already addressed this point" and moved on.

Furthermore, it's not a
showstopper, because it appears only when (1) an unusual request for
malloc limitation is made to check the program's use of malloc (a
test made in tester() as well) and (2) the request is made using an
invalid non- number.

Oh, it's not a showstopper for *you*. It's only a showstopper for real
programmers who care about getting it right.

So again, no credit for you.

So what? How is that relevant to the broken code you posted?

Duh. Ever hear of a typo?

Yep. But a decent-quality modern compiler will warn you about several
common printf mismatches, of which your line of code had two. (My
compiler told me about both of them.) Ever hear of compiling before
posting?

And what is more, are you even fucking

Losing your temper again, I see. It is not unreasonable to interpret
such behaviour as a childish tantrum stemming from having no
technical arguments.

I knew the fix as soon as Nick pointed out this minor error.

Get a better compiler, and it will save you some egg for your supper.

OK, this will be done in rel 5 and you will be credited since it
seems to be somewhat of a consensus. What should your name be in the
Change Record? Heathfield? Anon? Fat Bastard? Whatever you like.

Your change log is your business, not mine. I have no confidence in
your ability to judge what constitutes a good change.

Note what this clown is doing. It would have been a simple matter
for him to paste the "60 diagnostic messages" into this email.

Last time I did that, you ignored them. So what's the point of posting
them again? But okay, since you're so keen to see them, here they
are:

foo.c: In function `addFactor':
foo.c:109: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:133: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:137: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c: In function `expression':
foo.c:172: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:187: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:199: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:203: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c: In function `infix2Polish':
foo.c:232: warning: passing arg 1 of `errorHandler' discards
qualifiers from pointer target type
foo.c: In function `mulFactor':
foo.c:248: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:256: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c:269: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c:299: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:308: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c: In function `stringAppendChar':
foo.c:344: warning: passing arg 1 of `errorHandler' discards
qualifiers from pointer target type
foo.c: In function `testCase':
foo.c:378: warning: passing arg 1 of `malloc' as unsigned due to
prototype
foo.c:380: warning: passing arg 1 of `errorHandler' discards
qualifiers from pointer target type
foo.c: In function `tester':
foo.c:394: warning: passing arg 1 of `testCase' discards qualifiers
from pointer target type
foo.c:394: warning: passing arg 2 of `testCase' discards qualifiers
from pointer target type
foo.c:395: warning: passing arg 1 of `testCase' discards qualifiers
from pointer target type
foo.c:395: warning: passing arg 2 of `testCase' discards qualifiers
from pointer target type
foo.c:396: warning: passing arg 1 of `testCase' discards qualifiers
from pointer target type
foo.c:396: warning: passing arg 2 of `testCase' discards qualifiers
from pointer target type
foo.c:397: warning: passing arg 1 of `testCase' discards qualifiers
from pointer target type
foo.c:397: warning: passing arg 2 of `testCase' discards qualifiers
from pointer target type
foo.c:398: warning: passing arg 1 of `testCase' discards qualifiers
from pointer target type
foo.c:398: warning: passing arg 2 of `testCase' discards qualifiers
from pointer target type
foo.c:399: warning: passing arg 1 of `testCase' discards qualifiers
from pointer target type
foo.c:399: warning: passing arg 2 of `testCase' discards qualifiers
from pointer target type
foo.c:400: warning: passing arg 1 of `testCase' discards qualifiers
from

read more »- Hide quoted text -

- Show quoted text -...

I'm going to ignore this until you explain what you Silly Option you
set in your ButtFuck 1100 Compiler to get these messages because as is
they make no sense and I don't think you understand them. If you could
you would explain them. Other posters aren't getting these errors.

The "different width due to prototype" error is probably my use of
literal 1 as an argument for a formal int parameter. If in some
hypertechnical dialect of C I need to case literals, that's a problem
with C and a compiler that reports that as a warning has a bug.

If someone can point out a good programming practice that would
prevent these messages, I will incorporate it. In most cases, the
warnings appear to be complaining about passing a literal string to
testCase from tester. This is standard practice, so Richard Heathfield
is probably either lying or has made an incompetent error.

However, Richard Heathfield has a track record of lying and
obfuscating the truth and that's what he appears to be doing. There is
in fact no evidence that he can even program: he has never, to my
knowledge, taken the risk of posting extempore code to help newbies.

Nor do I see all posts here, because Heathfield and Seebach are
spamming this discussion. Because they are spamming the discussion,
they need to produce evidence on request, and, if it's important
evidence, they need to send it to me by email.

It might be time to move these discussions to Facebook in order to
force people like Seebach and Heathfield to be honest. Does anybody
have an opinion about this?

I am suggesting a workgroup on Facebook for developing and reviewing C
code.

But I am not going to be able to look at all responses here owing to
the spamming of this discussion by Seebach and Heathfield. If you have
something I really must see, send email to (e-mail address removed) or
apply for Facebook friendship to "Edward Nilges" in Hong Kong.

 

[Seebs]

This will be fixed in the next release. But on what systems is it
necessary? It is not in Windows, and it sounds to me as if the systems
where it is necessary are broken. Explain.

The formal answer is just: There is no guarantee that stdout displays
text except after a full line has been sent, and if output isn't ended
by a newline, some systems helpfully buffer it. This is more significant
on systems like some old IBM mainframes which really didn't offer
character-at-a-time behavior.

But if you want to learn C, learn this first: The point is not to cast
blame on systems you don't like, but to write code which is robust anyway.

-s

 

[Seebs]

Does gcc+glibc conform?

I don't think so... But as an interesting data point, I wrote a non-trivial
hunk of code using C99 features freely, and it works fine in gcc+glibc.
So apparently it's "good enough" these days.

-s

 

[spinoza1111]

Does gcc+glibc conform? Does MS conform? Does Borland conform? I think
you'll find the answer is "no" in all three cases. Which C99 compiler
do you recommend, on which platforms does it work, and from where can
it be downloaded?


Well, I disagree. For a start, testCase's prototype needs fixing. It
is broken in (at least) two places. Three if you count the brain-dead
macro.


I haven't even begun to look at the code yet. I'm quite content to let
the compiler worry about the first tranche of problems. If ever he

"Tranche?" Interesting word. In finance it means a group of
securitized loans sold by a bank. Toxic "tranches" cause the Panic of
2008 because as it happened, many of the debtors in these tranches
were deadbeats.

On Richard Heathfield's web site, it appears that he worked for a
series of banks and insurance companies, and probably was terminated
more than once for being a thug and a bully. But it's probable that he
was some sort of manager who lied about people and bullied programmers
into creating software that hid rather than revealed the problems that
caused the fall of Northern Rock and other banks.

gets a clean compile - which doesn't look likely - I'll consider
looking at the code. I think you know, Ian, that even I'm not
normally so obdurate as this, but I've had long experience of this
particular idiot, and I know perfectly well that there's no point
looking at his junk code until it's been de-junked as much as
possible by automated means.

OK: no posts in this discussion by Richard Heathfield or Peter Seebach
will be read by me since they are not participating honestly in this
discussion. If either of you two assholes have technical issues you
shall have to send them to my email address, and if they are genuine
issues I will post them here and credit your contributions. Otherwise,
you're out.

 

[spinoza1111]

"Tranche?" Interesting word. In finance it means a group of
securitized loans sold by a bank. Toxic "tranches" cause the Panic of
2008 because as it happened, many of the debtors in these tranches
were deadbeats.

On Richard Heathfield's web site, it appears that he worked for a
series of banks and insurance companies, and probably was terminated
more than once for being a thug and a bully. But it's probable that he
was some sort of manager who lied about people and bullied programmers
into creating software that hid rather than revealed the problems that
caused the fall of Northern Rock and other banks.


OK: no posts in this discussion by Richard Heathfield or Peter Seebach
will be read by me since they are not participating honestly in this
discussion. If either of you two assholes have technical issues you
shall have to send them to my email address, and if they are genuine
issues I will post them here and credit your contributions. Otherwise,
you're out.






- Show quoted text -- Hide quoted text -

- Show quoted text -

Also, besides my new policy with regards to The Two Assholes (Seebach
and Heathfield), I will also start using Navia's compiler as well as
the Microsoft compiler to compile new releases of this code. This will
help, perhaps, to spot other issues without me having to listen to
Heathfield's garbage; there are genuine issues in what he posts, but
he's so dishonest about them that they are almost impossible to find.

 

[Ian Collins]

Does gcc+glibc conform? Does MS conform? Does Borland conform? I think
you'll find the answer is "no" in all three cases. Which C99 compiler
do you recommend, on which platforms does it work, and from where can
it be downloaded?

Sun cc, Linux and (Open)Solaris. www.sun.com.

Well, I disagree. For a start, testCase's prototype needs fixing. It
is broken in (at least) two places. Three if you count the brain-dead
macro.

The lack of const is bad form, not a constraint violation.

 

[Ben Bacarisse]

OK, next release there will be a list of function prototypes and the
decls will be repeated at function headers: the comment decls will be
eliminated. Is this what you want? You will be anon.

That is overstating it -- I don't really want anything in relation to
your program. I was simply saying how I (and, I am pretty sure,
almost everyone else here) would handle the issue of function
prototypes.

This is not the only point I'd raise about your program. I didn't
comment on everything because Seebs had already made almost all the
point I would have made.

Do you want me to have to go through the overhead of function call for
this op? Or do you think it should be hard coded wherever it
appears?

All I'd say is that it's what I'd do. I doubt the function call
overhead is significant but if that turns out to be a problem, C has
function inlining.

<snip>

 

[spinoza1111]

By the way: I having met Brian Kernighan in 1987, and his having
answered my concerns about Beautiful Code in an email this year, I
asked him by email if he had any opinions one way or the other about
the Schildt controversy.

Brian responded, but he said he has no opinion he wishes to express at
this time.

I do know that Schildt is disturbed by the campaign against him, but
does not wish to speak publically. My sources for this information
cannot be disclosed.

Back to coding rel 5...

 

[Ben Bacarisse]

In
<bfd8a61b-daca-486b-bb75-0f13c1e94c6e@h14g2000pri.googlegroups.com>,
spinoza1111 wrote:

Who cares who said it? Truth is truth, no matter what the source.

It's odd. He seems to like my posting style. The irony is that I got
it from you. You once said that the only way to reply to spiniza1111
was to snip everything that was not topical and to respond only to
what was left. I found it successful (yes I slipped once and talked
about grammars for maybe two messages).

Anyway, I think a move to Faceook has been mooted. I think that is an
excellent idea.

 

[Seebs]

Brian responded, but he said he has no opinion he wishes to express at
this time.

He is a tactful sort.

I do know that Schildt is disturbed by the campaign against him, but
does not wish to speak publically. My sources for this information
cannot be disclosed.

Or believed.

We know you make various claims which are unsupported by evidence; why should
we expect this one to be different? For that matter, what "campaign"?
Imagine that you had never gotten interested in the Schildt thing. Would
anyone know or care about alleged errors in a book that's been out of print
for years? I doubt it. I have no evidence that there's been a single
response to that page since the previous century that does not have its
origins in your massive public campaign to bring everyone's attention to
the fact that, at one point or another, two members of the C
community, both fairly well-respected (Clive Feather, most notably, but also
me to a much lesser extent), had expressed the view that Schildt's books
were poor.

If Schildt wanted to, say, tell me that he thought I was wrong, he could do
so. I've corrected statements before when people showed me actual arguments
that they were *incorrect* -- not just that someone who obviously knows
nothing about the material dislikes them.

-s

 

[Seebs]

(a) the Spark Notes test is a joke, and (b) who has claimed that //
comments are wrong?

Does someone have a link to the original Spark Notes test that our
charming correspondant seemed to think was relevant in some way to
something?

-s