Yeah sure

Post #103,012 by tuberculosis 5/21/03 6:35:41 PM Reply	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 by jb4 5/22/03 5:35:11 PM Reply	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 by tuberculosis 5/22/03 11:02:21 PM Reply	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 by ChrisR 5/22/03 11:08:45 PM Reply	(++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 by jb4 5/23/03 9:59:45 AM Reply	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 by jb4 5/23/03 9:38:10 AM Reply	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 by tuberculosis 5/23/03 11:13:30 AM 5/23/03 11:15:41 AM Reply	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 Edited by tuberculosis May 23, 2003, 11:15:41 AM EDT Expand All History
Post #103,308 by jb4 5/23/03 6:30:59 PM Reply	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 by tuberculosis 5/23/03 11:14:34 PM Reply	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 by jb4 5/27/03 12:07:47 PM Reply	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 by Another Scott 5/27/03 12:26:47 PM Reply	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 by jb4 5/23/03 9:53:40 AM Reply	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 by tuberculosis 5/23/03 11:30:59 AM Reply	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 by jb4 5/23/03 6:44:36 PM Reply	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 by deSitter 5/23/03 11:10:24 PM Reply	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 by CRConrad 5/24/03 3:25:53 PM Reply	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 by deSitter 5/25/03 2:44:12 AM Reply	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 by CRConrad 5/25/03 8:16:39 AM Reply	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 by drewk 5/27/03 9:10:08 AM Reply	Can someone start a new thread please? === Implicitly condoning stupidity since 2001.
Post #103,608 by CRConrad 5/27/03 10:19:41 AM Reply	What for, aren't the long ones the best?

Welcome to IWETHEY!