Post #102,673
5/19/03 10:25:26 PM
|
You are fighting the language
There is no boolean in C. There is only jump-if-zero if(something-that-might-be-zero) // implies jump past statement if zero { } // statement ends here so here is where we jump The idea of boolean in C is something you have invented in your head. It is not in the language and does not need to be there. If you're really trying to branch on a condition, then the line:
if (foo) // where foo is a pointer
is completely meaningless! Where is the condition your trying to branch on?!? I don't see it, and neither do you. Of course I see it. The condition being branched on is the zero-ness of foo. If foo evaluates to zero, then we skip past the next statement. What is so hard about that? What you're doing is being lazy; failing to bother to fully express the condition you're ostensibly trying to branch on. The pointer foo is not a condition, it's a fscking pointer awready. It has no more truth or falsehood than does a glass of water. What you're really asking is whether foo is NULL or not. No, I'm asking if its zero - which is the same as null in C. That has truthness. And therefore the correct way to determine that truthness is to ask it, thus:
if (foo == NULL)
I'd say that's bad form. Much better to just write if(foo)... There is no true or false - there is only zero and non-zero in C. The if statement jumps past the next statement on zero. This is the correct way to think in C. The rest is fantasy made up by people who confuse logic and programming. They are not the same.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,796
5/20/03 1:41:24 PM
|
Tell you what...
I can see this descending into the type of circular non-reasoning that tends to pervade these fora, so I'll simply stop.
It's true at the most concrete level that C has no concept of booleanism. It's false that C at the level of being a translator for abstract ideas into a working program that C has no concept of booleanism. You have chosen to argue the former position, and from that position, you are right. I have chosen to argue from the latter position, and from that position I am right.
We can't solve this impasse, so let's stop trying, OK?
(I'll even let you get in the last word...)
jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #102,910
5/21/03 7:50:59 AM
|
Can I put my oar in?
The way C handles "true" and "false" tends to drive me up the wall. I will write if( condition == 0 ) because that's usually what I want to know. A language needs *something* to be a boolean type and C's use of 0 and not-0 is not intuitive (to me)!
So what's the alternative? PHP and languages of that ilk use a genuine boolean type: expressions evaluate to a "true" or "false" value which is not an integer and can be assigned and passed around and used in conditionals. Much neater. Another alternative is exceptions: if it succeeds, it returns a value. Otherwise it fails. Many assembly calls on the x86 do this. Icon does this, too.
I avoid programming in C these days.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #103,012
5/21/03 6:35:41 PM
|
Yeah sure
I understand what you are saying.
It doesn't bother me that C has no boolean. The CPU has no boolean either. When I write C, I see hardware level pseudocode. This is the Zen of C.
Working at (almost) the level of the machine to produce specific behaviors in the hardware. IOW, when I'm writing in C I care as much about how something gets done as what gets done.
When I write applications in Smalltalk or Java or whatever, I don't generally care how something gets done as long as it gets done with reasonable efficiency. Its at that level that I'm happy to have a boolean and all the abstraction that comes with it. That's a different Zen.
Apart from all this, I continue to assert that C++'s boolean is the stupidest implementation of boolean ever created and only serves to add lovely plumage to the platypus.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #103,168
5/22/03 5:35:11 PM
|
Such flowerly language toward such a misguided conclusion
Apart from all this, I continue to assert that C++'s boolean is the stupidest implementation of boolean ever created and only serves to add lovely plumage to the platypus. Put aside your disdain for the nale of the language and observe what is really going on for a second. A C++ object of tyep bool can have exactly one of exactly 2 values: the value 'true', and the value 'false'. These "values" are not integers, they're not enumerators of type bool, either. They are proper values in and of themselves. Now how is having a boolean type whose values can only be true and false be "the stupidest implementation of boolean ever created"? (Hint: It can't....)jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #103,198
5/22/03 11:02:21 PM
|
Yeah right
IFF C++ had a real boolean, the following statements would be compiler errors: bool b1 = 0; bool b2 = 1; bool b3 = 500; Instead, only the two following assignment statements ought to be valid. bool proper = true; bool sane = false; Don't fucking allow an assignment and then change the value of what was assigned without so much as a by your fucking leave sir. increment operators ought not to be allowed - or - ought to be paired with decrement oprerators for symmetry.
A C++ object of tyep bool can have exactly one of exactly 2 values: the value 'true', and the value 'false'. These "values" are not integers, they're not enumerators of type bool, either. They are proper values in and of themselves.
OK, so why does cout << "false is " << false << endl; produce "false is 0" on the output stream? Looks pretty fishy to me. Sorry, I can't take this kind of shit seriously - not even a little. There's no consistency of behavior in the bool type - its a really thin veneer on (depending on implementation, char, short, int, or long) and the veneer has more holes than Amish swiss cheese. Find me a quirkier implementation of bool (in a language that has one) and I might retract my statement. But I certainly don't know of any.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #103,200
5/22/03 11:08:45 PM
|
(++true == false)
If you got increments and decrements, then I'd think they should work like the not operator (!true = --true).
Just a thought to muck with the standard some more. :-)
|
Post #103,251
5/23/03 9:59:45 AM
|
Just add a little gasoline, and stir!_____;-)
Actually, I don't understand why the decrement operator is not defined on a bool. However, if I were the king of X3J16, I'd not support a wrap-around approach to the increment or decrement operators. I'd support: \nfalse++ == true\nfalse-- == false\ntrue-- == false\ntrue++ == true\n (with the pre-increment and pre-decrement operators working the same way.) I'd also not support implicit conversions to or from bool; you'd have to explicitly cast a non-bool to a bool or vice versa. (That should mitigate Todd's objections a teensy bit....) jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #103,245
5/23/03 9:38:10 AM
|
OK, Now I see wht your problem is
...and you may have a point, but your disdain is misguided. As I have stated earlier, the statement bool b = 500; works because there is an implicit, compiler-supplied conversion from type int (and all its siblings) to type bool. What you are really entering when you type the above line is bool b = static_cast<bool>(500); The bool type is fine, its the implicit conversion you disdain. Which I find interesting, to say the least, because in the you have defended C's implicit conversions and promotions. And also because you jump up and down stating that integer values should be treated as boolean entities when placed in an if/while/for conditional clause. So your objection to the bool type as implemented in C++ paradoxically boils down to the fact that there is an implicit conversion from itn to bool, which should be OK in your world. Taken to its (il)logical conclusion, you should also argue that C++ (and therefore C) should also reject such standard things as: \nfloat f = 1;\nint i = 1.0;\nchar c = 14; \nfloat f2 = 1.0; // the reason why is left as an exercise for the reader...\n The point is that implicit conversions and promotions are just as much a part of C as is the nonsense of treating integers as boolean entities, which you so rabidly defend. jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #103,271
5/23/03 11:13:30 AM
5/23/03 11:15:41 AM
|
I thought you were going to give up on this
bool b = 500;
works because there is an implicit, compiler-supplied conversion from type int (and all its siblings) to type bool. What you are really entering when you type the above line is
bool b = static_cast<bool>(500);
The bool type is fine, its the implicit conversion you disdain.
Which I find interesting, to say the least, because in the you have defended C's implicit conversions and promotions. Actually, what I am really typing is what I really typed - which is stupid and ought not to be allowed. It looks like C++ has been taking lessons from Clippy. I don't object to C's conversions because they are (mostly) sensible. When mixed mode operations are encountered, the types are "promoted" to prevent loss of precision. The promotion rules are simple and comprehensible. C++ takes an extreme approach to type conversion which is the source of many many surprises and bugs (the construction of temporaries and such). In practice, this has made it nearly impossible to write predictable code. I also find the behavior inconsistent with how enum's work. You can do this: enum Traffic { RED, YELLOW, GREEN }; Traffic aTraffic = (Traffic) 7; cout << aTraffic << endl; // this will print 7 There's no value clamping here (and thus no inadvertent loss of information). Finally, your comparisons with C are falling flat. C is weakly typed. C++ is meant to be strongly typed (which is why we have 5 kinds of cast operator). But its only *sometimes* strongly typed. Rule number 1 - never surprise the programmer. Unfortunately, C++'s rule seems to be *always* surprise the programmer. (Edit - clippy bit)
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #103,308
5/23/03 6:30:59 PM
|
How sensible is this?!?
\nint i = 723.524;\nchar * ptr = i;\nint j = ptr;\n I don't object to C's conversions because they are (mostly) sensible. When mixed mode operations are encountered, the types are "promoted" to prevent loss of precision. The promotion rules are simple and comprehensible. Yeah, that's real "sensible", preserves "precision", and "comprehensible", all right. But it's C, so its OK, right? Stupid things like this are OK for you if they happen in C, but in C++, they are "stupid and ought not to be allowed." Pot. Kettle. Black. jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #103,345
5/23/03 11:14:34 PM
|
Not convinced
You keep taking one little aspect per message and - yes - by itself each item isn't *so* bad. But its cumulative and, as a complete package, the sum is stupider than the parts.
So I'm not going to bother with this anymore. You clearly have your hammer - go pound your nails (and screws, crockery, whatever looks inviting).
Bear in mind that I used to be a (really pedantic language lawyer) expert at your particular hammer. I never use it anymore (since 1997). The drawbacks outweigh the benefits and there are much better tools.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #103,622
5/27/03 12:07:47 PM
|
Nor am I
The only thing I keep taking in each one of your messages is the current objection, and showing where said objection is inconsistent.
I can understand how that can be annoying.
Go. Get thee hence. Write fine programs using whatever tool(s) you have available. I'll do the same.
jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #103,625
5/27/03 12:26:47 PM
|
You guys should be using Modula-2. :-P (new thread)
Created as new thread #103624 titled [link|/forums/render/content/show?contentid=103624|You guys should be using Modula-2. :-P]
|
Post #103,248
5/23/03 9:53:40 AM
|
And an answer to your question.
OK, so why does
cout << "false is " << false << endl;
produce "false is 0" on the output stream? Looks pretty fishy to me. For two reasons: the first is the implicit conversion thing again, unless told otherwise the stream class converts objects of type bool to integers before converting them to text. This is a function of the stream class and not of the language (but, you already knew that, didn't you...). Second, you want text? Try: cout << boolalpha << "false is " << false << endl; In other words, the display of bool values is divorced from their internal representation, just like using any formatter in a printf statement. I can make floats look like integers, too...wanna see? If you objection to bool is based on formatting decisions by an I/O library, that's pretty weak! jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #103,274
5/23/03 11:30:59 AM
|
Wrong answer
the implicit conversion thing again, unless told otherwise the stream class converts objects of type bool to integers before converting them to text. OK, why? The stream class has an overload on type bool - so its not the implicit conversion thing. More telling - this default tells me that the bool type isn't quite viewed as a non-integer by the implementers of the language and libs. IOW, they don't buy their own BS about bool not being some indeterminate integer type with stupidly defined operators. If you objection to bool is based on formatting decisions by an I/O library, No, its the package. The whole thing is a hack job and bad one at that. Better to leave it off. What was so broken by not having this abortion in the language?
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #103,310
5/23/03 6:44:36 PM
|
Wrong answer back
OK, why? The stream class has an overload on type bool - so its not the implicit conversion thing. Todd...first, the stream class has on overload on operator <<, not on the type. Second, the operator << overload knows that the type of the value it is being passed is bool, and based on the settings of that stream object's attributes (like, for example, the manipulator settings in effect at the time), determines a rendering. Unless told otherwise, it casts it to an int, and displays the number. More telling - this default tells me that the bool type isn't quite viewed as a non-integer by the implementers of the language and libs. IOW, they don't buy their own BS about bool not being some indeterminate integer type with stupidly defined operators. Actually, (and this answers the rhetorical "OK, why?" from the first citing) The default has much. more to do with the rules for outputing locale-neutral text than for any other reason. P.J. and his team have always been very reticent to spontaneously spout text, because there is always the problem of non-English speaking audience (which is a larger audience that then English-speaking audience). The fact that there is a native, built-in way to get a locale-specific textual representation of a bool lends the lie to your assertion that the "the bool type isn't quite viewed as a non-integer by the implementers of the language and libs." (Oh, and can we finally get past the red herring that the language and the library are both required to make up "C++", or are you now going to argue that SWING and AWT are integral, inseparable parts of Java?) jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #103,343
5/23/03 11:10:24 PM
|
They've turned it into Pascal
I never thought boolean types were of any value at all, other than to complicate things. 0 is false - that much is certain, and that's what you need, a definition of certainty. Note that true can be -1 or 1 - or really anything that is not 0. The most useful definition is true=-1, because it means the biggest unsigned integer - all the bits = 1. Whatever the number of bits, -1 will always be the state with all of them on. What's the point? Boolean really should mean 2s complement arithmetic. It's not a type, it's an algebra.
-drl
|
Post #103,406
5/24/03 3:25:53 PM
|
Circular definition.
Ross vents his usual frustration with anything invented after 1969: I never thought boolean types were of any value at all, other than to complicate things. That's because you're a fuckwit. 0 is false - that much is certain, and that's what you need, a definition of certainty. Only if you're a religious nutcase... But I digress. Back on track: So you only need "a definition of certainty" for FALSE, but NO "definition of certainty" for TRUE? Why is that? Where's the logic in it? Note that true can be -1 or 1 - or really anything that is not 0. Yeah, that's SOOO "certain" and un-"complicated". The most useful definition is true=-1, because it means the biggest unsigned integer - all the bits = 1. Whatever the number of bits, -1 will always be the state with all of them on. Only if you run it on a twos-complement processor. Or did you think that's somehow a Law Of Nature, or something...? What's the point? Good question; personally, I don't think you have one, except hanging out your crankiness. (Which, in your case, usually means hanging out your crank... And stepping on it.) Boolean really should mean 2s complement arithmetic. It's not a type, it's an algebra. Only if you DEFINE it in the idiotic C way (and run it on a twos-complement processor). Circular definition much, fuckwit?
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #103,463
5/25/03 2:44:12 AM
|
Re: Circular definition.
Because false implies the possibility of true. Otherwise there is no meaning to false. Therefore the Boolean "type" is superfluous. What you need is false and not false. You could turn it around of course, and call 0 "true". This isn't so odd. When a return code is 0, that's good and it means the function worked "truly". Do I need to explain it more?
(PS: I'm listening to Steppenwolf 7 - "Renegade - Foggy Mental Breakdown - Hippo Stomp". That was invented in 1970.)
-drl
|
Post #103,478
5/25/03 8:16:39 AM
|
Self-contradiction, and logically inconsistent definition.
Ross exposes the depths of his (and C's) illogic: Because false implies the possibility of true. Otherwise there is no meaning to false. Therefore the Boolean "type" is superfluous. So, following that line of (what I will perhaps to charitably call) reasoning: "Because the existence of an integer i implies the existence of the next one, i+1, the integer type is superfluous." That's funny -- down here on Earth, it's usually accepted that precisely *because* integers behave in one way that is particular to them and not to anything else, that's why you *do* need (or at least, want) a specific type "integer". (Extending a parallel to the behaviour of true/false values and a boolean type is left as an excercise for the reader with brains bigger than his haemmorhoids.) What you need is false and not false. Exactly. And since "not false" _I_S_ true, this means that what you need is false and true. You could turn it around of course, and call 0 "true". This isn't so odd. When a return code is 0, that's good and it means the function worked "truly". Actually, while C *doesn't* turn it around in if statements (i.e, 0 is "false" there), in function return codes it *does* work exactly as you say! So on the one hand, 0 is "false", but AT THE SAME TIME it means "worked TRULY". And you claim any *change* to this illogical piece of shit is the problem?!? You need to get your head examined, man! Alternatively, you (and Todd) could just admit that you don't really give a shit about all the logic and consistency you're *talking* about, but just don't want to accept that anything you learned twenty-five years ago could possibly not have been the ultimate pinnacle of reason and sense you once thought it was. Because that _I_S_ where the real problem is for you two, isn't it? Do I need to explain it more? Don't try to be condescending to me, Bubba -- it only works *downwards*. (PS: I'm listening to Steppenwolf 7 - "Renegade - Foggy Mental Breakdown - Hippo Stomp". That was invented in 1970.) Yeah, well, "listening" -- but you're probably listening to it with utter disdain. (BTW, _Der Steppenwolf_ (the one from 1927, that is) is way over-rated, AFAICS.)
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #103,598
5/27/03 9:10:08 AM
|
Can someone start a new thread please?
===
Implicitly condoning stupidity since 2001.
|
Post #103,608
5/27/03 10:19:41 AM
|
What for, aren't the long ones the best?
|
