It just seems non-obvious to me that always returning a value is necessarily
better than not having to return a value.
Probably.
Oh great, so you haven't opened it.
You posted code, you got feedback.
I'm not complaining. You are. You need to use Ben Bacarisse as a role
model. If you have technical insight, share it. Shove your corporatese
and generalizations about people's competence (whether Schildt's,
Navia's, or mine), up your ass, because this medium simply isn't one
where you have a broad enough signal to make the online judgements you
make on Navia and I, and you were out of line with Schildt because you
don't know Microsoft platforms.
Schildt is weak on non-Microsoft and should not have used upper case
file names in #include statements for this reason. But for the same
reason, you weren't qualified to tech review his book. What is worse,
you enabled a series of personal attacks because you only published 20
flaws, but made references to hundreds, which you have not, as far as
I can see, documented.
I would never *dream* of giving you advice based on the theory that you were
interested in showing consideration for others. I'm telling you how to reduce
the likelihood that people will think you're an idiot. You can pursue that
out of pure self interest, no worries!
I have plenty of consideration for others, but unlike a feminized
corporate dweeb "this animal defends itself when attacked".
Corporatese? I don't think so.
I do. When you are at a loss for enough to say technically you venture
without warning into abstractions with which you're not qualified to
deal. For example, your claim that Schildt somehow made software
incorrect by publishing a book is nonsense, because what makes
software incorrect is the refusal of technicians to abandon C.
People performing tasks such as "reading diagnostic messages" or "skimming
output from code" tend to perform them more reliably and more quickly when
the format and structure of the material is conducive to maintaining a
state called "flow".
No shit, Dick Tracy. Have you ever heard about the use of white space
in technical writing?
http://www.eric.ed.gov/ERICWebPortal/custom/portlets/recordDetails/de...
Basic familiarity with the literature: Always a plus.
These comments were all on the original edition. You asked what benefit
a format string might have, I gave an example.
Not an unreasonable one, though.
It still doesn't work.
Corporatese, because a naming standard doesn't work or fail. It is
usable or otherwise. Learn to write before you write another document
that trashes a decent person's career, punk.
Perhaps, but he's the reason people mostly adopted it -- and while Systems
Hungarian may well have been useful in 1962, it's been worthless since the
80s or so in nearly all languages.
Your laziness doesn't control. I find Systems Hungarian easy to
maintain. I also find that most programmers are too lazy to maintain
another's naming standards. Systems Hungarian was abandoned out of
laziness. Szymonyi was told how to name variables at IBM but went his
own way, stealing the idea and taking credit for it.
Probably not for this one. (If you're on x86, for instance, consider
that there's a single instruction for this operation, which is likely to
get used if it's a good fit. There's a reason compilers often have built-in
implementations of common library functions.)
When I see the need, I'll use assembler to get the instruction. The
legacy C libraries are too full of gotchas to be worth the trouble in
the case of strings. If I were to use C for a "real" project, first
thing I'd do would be to reinvent strings.
No one said you did. I was referring to the "Lot Of Useless Crap". You
already got the Lot Of Useless Crap. It's there. You might as well use
it.
Can I quote you as you misrepresent Schildt? Peter Seebach says, use
Useless Crap.
(Chortle)
One of the things that fluent speakers learn is that beyond the raw formal
lexicon of a language, it will usually have idioms. C has had idioms for
true and false since 1978, and it would make sense to stick with those
idioms. (Or, if you prefer, you could always use the boolean type, since
there is one in C99.)
I'd rather use C Sharp.
Oh, I'm all for elegance, regardless of who invented it, but -1 isn't
elegant.
I don't think you know what elegance is. For starters elegance is
conceptual unity, and for this reason I have always been sickened by
discussions among programmers, with their consistent misuse of
language ("language x isn't efficient, but language y is"). Right up
there is having to argue with some dweeb about whether a snippet is
elegant out of context. As it happened, it was best for me in my
limited time, simply to show that this conversion could be grammar-
driven, to use -1 as truthiness.
I am so glad not to be a programmer anymore, because programmers don't
realize that while a guy like Dijkstra was indeed concerned with
elegance of coding languages, what he meant was integrated syntax and
semantics, and would probably regard it as silly to waste a person's
time criticising -1 as truthiness.
Also, while you yourself have not demonstrated the willingness or
ability to post code extempore, you probably excuse your own stylistic
and technical failings by calling new code throwaway, while acting as
if others only have the right here to post bug free code...a common
failing of the twerps here. I come here for your feedback on technical
matters on C exclusively because as I have said you appear to me to
know C while having much to learn about programming.
Not since 1999 it doesn't.
But even in 1978... Let's consider the question.
If we are to define "false" and "true", what should they be?
Obviously:
if (false) {
}
should not execute the contents of the block. How about... 0?
Okay. So what's true? "!false" is true. What's !0? 1. true is 1.
Wow, I'll alert the media. 1==!0? New math indeed.
You wouldn't say this if you had in the past to debug at machine code
level, because 1 looks too much like 0 to be a good way to represent
truthiness. -1 is best.
Your continued assertions that you are the gold standard of the "intelligent
reader" are unsupported.
However, it gets a bit deeper than that.
There are many functions and APIs which have standardized on using negative
values to indicate *errors*. Because of this, readers who are experienced
with C will usually regard a "-1" as an error indicator. Your theory that it
would make sense for it to be regarded as a particularly idiomatic "true"
is fascinating, but it doesn't match the real world.
I don't have to follow broken standards. I am very familiar, from
longer experience than you, that in many situations 0 means "all
clear". This is an unfortunate problem because in other contexts, it
means false.
The problem is not using -1 for truthiness. It is that globally, C is
a broken language that fosters bad practices, buggy code, personality
dysfunction, and the politics of personal destruction when people
scapegoat others for their refusal to use a safer language.
Your code has a buffer overrun that exists because you didn't pay attention
to the well-established idioms that allow experienced programmers to avoid
buffer overruns.
Well, sure, if I were in a C workgroup (not if hell froze over, but
let's suppose) then I would use my coworker's idioms which, no matter
what you believe, vary all over the map because C IS BROKEN. As it
happens, in the code you reviewed, there probably is an off by one
situation which I fixed this evening in code not ready for release.
FYI, this evening, I changed the malloc to malloc exactly n bytes
where n is the total number of characters in the infix expression that
aren't blanks or parentheses to see my append test FAIL (properly)
because I am now appending more than the allocated number of bytes,
less one for the Silly Assed Null, whereas earlier I'd allocated far
too many bytes.
Which was actually a good thing, because I realized in bantering with
you that I needed to make sure that append failed correctly!
It now (at this minute) fails all the time, because I "forgot" that I
ALSO add extra blanks around output tokens, and these weren't
accounted for.
If I were outputting infix, I would simply not output blanks, but
blanks are necessary in suffix because operands can be adjacent in
suffix.
The most elegant solution would be to only insert a blank where
necessary but this would require the routine which runs before parsing
and counts outputting characters to know when in the output two
operands would be adjacent. I believe that this would be when they are
separated in the infix by a binary operator.
This might complicate the pre-scan, and another less optimal solution
would simply to request twice the bytes needed from malloc, an
inelegant solution indeed.
The point being I shall think this true
Without, in all probability, any help from you.
That's pretty substantive.
Ahh, that won't happen. I'm not about to put real effort into this stuff.
No, you prefer to shit all over a person and leave. As you did to
Schildt. You want sympathy for being autistic without taking
responsibility for the fact that autistic people are very bad at
understanding other minds...and have no standing when assessing the
knowledge of a Schildt, which you nonetheless do.
I view you as an amusing kook, no more. The moment I saw multiple responses
**** you, asshole. I am nothing of the kind. I am an experienced
programmer with thirty years of experience who left in the field in
disgust when it was taken over by autistic twerps.
from you continuing to assert your tinfoil hat theory about how the
standards process worked, without even ONE bit of supporting evidence, I
gave up. I have not taken you seriously since, nor do I now.
No, it isn't.
It's odd, because you keep talking about what users would expect, but you
appear to have carefully avoided learning anything about how users form
their expectations.
Users? I don't use the word.
Lots of handwaving, but you haven't addressed the point. The purpose of the
code is to be used. The person using it does not care about the internal
implementation; that person's sole interest is to get an infix expression
converted to RPN, for reasons we are not privileged to speculate on.
This is just wrong. For one thing, this "user" has to know, not
whether the code is "correct" (for in fact all code is "incorrect" in
the absolute sense that a computer is ultimately a finite state
automaton) but its limitations, and in this case and many others, this
"user" (I prefer "caller") would rather read the code. And note that
despite this, this "user" does not, in fact, give a rat's ass that the
code uses -1 to signal truthiness, since the code returns a string.
And you also failed, now that I think of it, to realize that
infix2Polish should NOT free() this string: it is the caller's
responsibility to free() it. Yet you added this to your Vicious Tirade
with the same lack of diligence you showed in "C: the Complete
Nonsense".
Yes, main() should: but you did not say this because as in the Vicious
Tirade you did not make constructive suggestions. Had you done so,
McGraw Hill might not have treated you like a joke.
Why is it when I submitted a proposal to O'Reilly in 1999, it was
accepted? Why is it when I contacted Apress in 2001 I was invited to
write a book? Why is it I get stuff published, whereas you failed to
get an errata published? Why did my 13 year old get errata published
and not you?
It's because you were destructive and had no insight as to what was
going on.
You should have done your homework as I did when I taught IBM
mainframe C at Transunion. I had enough familiarity from Princeton and
Bell-Northern to be able to describe the culture of C, including its
case sensitivity and use of ASCII in place of EBCDIC. Whereas you
attacked Schildt without having any experience, as far as I can see,
on his platforms.
You had no standing, and this is why McGraw Hill rejected you. You
were the crazy man with the tinfoil hat. The problem is that the
Internet empowers creeps like you to sound authoritative, because it
confuses pointers to facts with facts.
Withdraw "C: The Complete Nonsense". Apologize publically to Herb. And
here, do not presume ever again to advise me on scientific or
stylistic issues. Confine your comments to your area of competence,
which is C.
