Post #101,848
5/14/03 1:31:46 PM
|
Still waiting for ...
... Smalltalk, Python, Objective C, ruby, Squeak, etc compilers for the embedded arena.
Know of any that are of the quality of the Paradigm or IAR C/C++ compilers?
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,307
5/16/03 3:50:38 PM
|
Depends on constraints
But for embedded - you just need C. C++ doesn't add anything interesting.
What's your target platform?
There are squeak implementations for various ARM's and similar tiny gadgets btw.
What kind of embedded software are you working on?
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,529
5/19/03 9:37:12 AM
|
Platforms:
80x86 (in embedded appications)
68HC1x
MCS-51 series (8051, 8091, etc.)
680x0 (again, in embedded applications)
And, as you can probably guess, I strongly disagree that "C++ doesn't add anything interesting." Besides polymorphism, which is extremely "interesting", it adds substantially better typing and several enhancements against C95 (including, but not limited to, my all-time favorite: the bool type).
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,591
5/19/03 2:04:00 PM
|
Don't even get me started
on the idiocy of the bool type.
Its implementation and promotion rules are just dumb.
Repeat after me - there is no bool type, there is no bool type, there is no bool type.
Every idiot C programmer that ever typedef'd a bool (or worse, #defined's TRUE or FALSE) should burn in hell.
0 is false.
!false is true.
Live with it.
As for polymorphism - you can make your own in C with about the same amount of work.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,594
5/19/03 2:25:40 PM
|
I'll get you started, alright!
Because, with all due respect, in this particular case, you're quite full of shit. The bool type (or more accurately, its absence) was the single biggest omission of C, vastly surpassing its other glaring omissions and shortcuts. Wasn't it you who was whining about how it takes 4 bytes to represent a bool in somebody's POS implementation of C++? Well, chucko, guess how many bytes it takes to represent the non-bool in every implementation of C 1.... (Hint: 3 more than it takes in all my C++ compiler's implementations...and that even includes..(gasp!) Micros~1's implementation!) And look, you're so blinded by your dogmatic disdain for C++ (or, perhaps, even ignorance of it), that you contradict yourself: 0 is false.
!false is true. Congratulations! You've just explained the definition of the ANSI C++ bool type! Not bad! Live with it. I can, and I do daily. Can you? (from your post, I rather doubt it.) Repeat after me - there is a bool type, there is a bool type, there is a bool type. In C++. And in C (ref. X3J11 C99 standard). Live with it! 1 Prior to C99, that is.... :-) 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,597
5/19/03 2:51:26 PM
|
No I'm not
C's mission in life is to provide portable assembler.
That's it. At that particular job, C is a masterwork. (And I agree with Dennis Ritchie's opinion of C99 - it strays from the mission too far).
If the processor supported bool, then I'd agree with you - there ought to be a bool. But the processor doesn't. It supports bytes, shorts, longs, floats, and doubles. If there's a glaring problem with C, its the unfortunate naming of byte as char.
Instead, we have a kludge of syntactic sugar on some indeterminate integer type.
Examples of idiocy:
bool b = 0; // fine its false
bool b = false; // fine
cout << b << endl; // print's 0 - why not false? You can't change it either because ostream::operator<<(bool b) is defined as a member function of ostream.
bool b = true; // fine
bool b = 5; cout << b << endl; // print's 1?!?!
b = false;
cout << b++ << ' ' << b++ << ' ' << b++ << ' ' << b++ << endl;
this print's 0 1 1 1
interestingly, b-- won't compile, operator is not permitted. So if you were going to use it as a use counter bool offers surprising behavior.
Bottom line - bool is a quirky POS that you don't really need if you just accept that you can do your conditional branching using any convenient integer type.
So don't try to tell me that this is a good idea. Its not. It's pretentiousness at its very worst.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,611
5/19/03 4:43:28 PM
|
The problem is, you're trying to treat a bool as a number
after complaining mightly (and accurately) that it is not. Your problem is here: bool b = 5: What you're really done is: bool b = static_cast<bool>(5); One could argue that trying to cast a value to a bool is a non-sequitir, and one would be right. However, since that one was not on the ANSI committee, and since the overarching goal of the committee was not to break existing code (no matter how screwed up that existing code might be), the committee compromised, and decided that a standard conversion from an integer type to bool shall exist and that any non-zero integer value casted (either implicitly via the standard conversion, or explicitly via a casting operator) shall be considered to be the value 'true' (again, being consistent with C -- can't break exisiting, screwed-up code...). Bottom line - bool is a quirky POS that you don't really need if you just accept that you can do your conditional branching using any convenient integer type. Now you've really gone off the deep end, and are again contradicting yourself. If, indeed, "C's mission in life is to provide portable assembler [...]" (an assertion I don't accept, BTW; but for the moment let's let that stand), where in the hell does it follow that using the presence or absence of a "convenient integer type" is sufficient (or even necessary) for conditional branching? Conditional branching is the result of the conformance or non-conformance to a predetermined condition set by the programmer at the decision point. So the choice to follow an execution path is based on the evaluation of the presence or absence of a condition (which in assembler can be the presence/absence of a non-zero value, but can just as easily be the presence/absence of a carry, a flag value, the sign-bit, etc.) Your "portable assembler" does not give us such granularity, it has quite arbitrarily given us the presence/absence of a non-zero value to make decisions on. But what is the non-zero value that represents x > y? You can of course justify some mathematical hash that reduces itself to a zero/non-zero value, but in reality, there is none. What we really have is a boolean decision: is the relation true or not? The committee, rightly identifying that, abstracted the decision to a yes/no result, then created a type to represent that decision (which has the happy side effect of being available to the programmer for his/her other uses -- and abuses-- as well; abuses such as trying to set a boolean varialbe to the value of 5, for example). It beats hell out of the various kludges that C had to come up with to approximate that abstraction. Its no accident that the type of the relation operators in C++ is bool (not int); and, you know what? They're right...a relational operator expresses a boolean not integral relation! Now for someone who jumps all down my throat wailing the praises of Objective C, Smalltalk and other so-called "pure" OO languages, for you to make a statement like the blockquoted one above is so oxymoronic. Make me wonder whether Bryce hijacked your login.... 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,617
5/19/03 5:07:44 PM
|
No, I'm trying to branch on a condition
And it actually amounts to jump-if-zero. Which is fine. I can write very interesting programs with that structure. The fact that relational operators evaluate to zero on false and (as a convention) one on not-false makes this mechanism easier to use and follow.
There's nothing oxymoronic about my position on this.
C isn't a high level language. Its a very low level language. Its not for writing applications (although it gets used for that). Its for writing maximally efficient processor independent code. If you bother to read the K&R or study your computer history, you'll find that C was specifically created to make it easy to produce portable code while remaining close to the machine.
As I'm in the midst of moving, all of my K&R's (I own several because its just not good to be without one) are in boxes or I'd quote it at you.
The important thing to remember is that C actually has no concept of "true" and "false". Trying to force fit it into the language hasn't done anybody any favors. The bool whiners are also losers that write shit like:
if(condition == true) // this is just stupid
rather than
if(condition)
Furthermore, the C convention fits nicely with pointers, jump-if-zero is the correct semantic.
char* foo = "Hi there";
if(foo == NULL) // is totaly stupid
if(foo) ....// perfectly reasonable given the framework of the language
Keep in mind that I don't think every language ought to be like every other language. I like my C primitive and I like my application development languages rich and convenient - for very different reasons.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,631
5/19/03 7:08:23 PM
|
21st Century Schitzoid Man
OK, first you say you're trying to branch on a condition (the title of your post), then you say stuff like: Furthermore, the C convention fits nicely with pointers, jump-if-zero is the correct semantic.
char* foo = "Hi there";
if(foo == NULL) // is totaly stupid
if(foo) ....// perfectly reasonable given the framework of the language So which is it??? 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. 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. That has truthness. And therefore the correct way to determine that truthness is to ask it, thus: if (foo == NULL) Now I will agree that: if(condition == true) // this is just stupid
rather than
if(condition) is "just stupid"...so long as 'condition' is truly a conditional expression (or an object of type bool or one that has a cast operator of type bool...;-)...); if it is a numeric expression, then both are equally stupid, which you would have to agree if what you're really trying to do is "branch on a condition". 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,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?
|
Post #102,950
5/21/03 10:53:43 AM
|
Comments on supposed idiocy
Examples of idiocy:
[...]
cout << b << endl; // print's 0 - why not false? You can't change it either because ostream::operator<<(bool b) is defined as a member function of ostream.
At least it is consistent. For example ... \n enum Color {RED, GREEN, BLUE};\n cout << GREEN << endl; // Also prints 1However, I will agree that the decision to print 0/1 for false/true is ... surprising. Continuing ... bool b = true; // fine
bool b = 5; cout << b << endl; // print's 1?!?! That's right. Bool (despite your declarations to the contrary) is not a integer type. b = false;
cout << b++ << ' ' << b++ << ' ' << b++ << ' ' << b++ << endl;
this print's 0 1 1 1
interestingly, b-- won't compile, operator is not permitted. So if you were going to use it as a use counter bool offers surprising behavior. Yes. This a concession to backwards compatibilty with existing code. But you know this. No one is claiming this is the correct way to define bools in a green field language. Bottom line - bool is a quirky POS that you don't really need if you just accept that you can do your conditional branching using any convenient integer type. This seems an odd statement. Of course you don't need it. You don't need enums either. You don't need strings. There are a lot of things you don't need. However, bool is a common abstraction. One that programmers often provide themselves. Unfortunately, it is not possible to provide a user defined bool type in C++ that has the following behavior ... void f(int i) { cout << "Integer version called"; }\nvoid f(bool b) { cout << "Bool version called"; }\n\nint main(int argc, char** argv) {\n f(argc == 0); // Prints "Bool version called"\n}Before bool was defined as a built in type, the integer version would have been called. So don't try to tell me that this is a good idea. Its not. It's pretentiousness at its very worst.
Wow strong language. It seems to me, given the design constraints (backwards compatibility, desire to overload on bool) the choices were far from as bad as you paint it. --
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #103,207
5/22/03 11:53:06 PM
|
Re: Comments on supposed idiocy
It seems to me, given the design constraints (backwards compatibility, desire to overload on bool) the choices were far from as bad as you paint it. I understand the design forces at work that lead to this mess. Incrementing a flag as a one way latch was a common idiom in a lot of older code. What I really question is whether the increased complexity is worth it. I don't think it is. They had a choice between not having a bool and leaving the branching consitent with C, or adding a proper bool type and breaking a bunch of code. The gutless wonderdogs did neither. This is my beef. I dislike inconsistency and C++ has it in spades. The whole thing is a sign of muzzy headed thinking and committee dynamics. Compare C++ to Objective C and the amateurishness of C++'s design shines like the top of the Chrysler Building.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,592
5/19/03 2:05:09 PM
|
Don't even get me started
on the idiocy of the bool type.
Its implementation and promotion rules are just dumb.
Repeat after me - there is no bool type, there is no bool type, there is no bool type.
Every idiot C programmer that ever typedef'd a bool (or worse, #defined's TRUE or FALSE) should burn in hell.
0 is false.
!false is true.
Live with it.
As for polymorphism - you can make your own in C with about the same amount of work.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,599
5/19/03 3:06:49 PM
|
You didn't mention types of programs
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,612
5/19/03 4:48:20 PM
|
Sorry, thot I was clear earlier...
..We're doing embedded processing (and by that, I mean "real" embedded stuff, not Micros~1's bastardation of the term). Realtime data acquisition and control stuff, with a microprocessor of some sort (like the sort I mentioned) running things.
For this, I've got some real good C95 compilers, and some ANSI (and not-so-ANSI) C++ compilers. I haven't seen a C99 compiler in this space yet. (In fact, I haven't seen a C99 compiler in any space yet; I don't think either Micros~1's or Borland's are C99-compliant yet).
No Smalltalk.
No Objective C (which I would expect to be the first).
No Python or Ruby.
Yet...
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,619
5/19/03 5:20:34 PM
|
Still doesn't tell me enough
What is your memory budget? Persistent storage? Is there a file system? Do you drive a display? What about a network interface? If you have a couple megabytes, you can likely use your C compiler to bring up squeak and use Smalltalk (one guy has a 400k image working). So just because nobody ported it to your machine doesn't mean you can't use it. The tiny smalltalk guys use a pair of executables - a tiny executive on the device and a big fat dev environment on a regular machine. They push down little clusters of serialized objects to the executive to update the exec.
This is more likely to succeed than porting the ObjectiveC runtime I think.
But its up to you - all you need is a C compiler and you can run whatever you like in there - you just have to port the machine yourself. Most Squeak ports take a week or so but that's for a full blown machine with video, network, file system access, keyboard and mouse. You can skip any of these or implement them in new ways.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,630
5/19/03 6:57:25 PM
|
Re: Still doesn't tell me enough
What is your memory budget? Persistent storage? Is there a file system? Do you drive a display? What about a network interface? Whatever the device will support. (1MB for the 80186, 64K for the HJC1x or the 8051...you get the picture). EPROM or Flash. We partition the total memory address space between ROM and RAM. Not usually. I did recently get to work on a box that supported QNX as its OS/Kernel, and we used a 486 in protected mode. A "file system" was supported (the flash was made to look like a file system). Such luxuries are rare, however.... Yes, generally an LCD of insufficient size ;-) . sometimes color, often monochrome, never using standard parts (except for that QNX box I mentioned earlier...) In your (and my) dreams.... So what I hear you saying is that we download a VM-equivalent for Smalltalk, then download class definitions, and away we go? 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,667
5/19/03 10:03:08 PM
|
The VM's are all written in very portable C
you have to port them if you want to use them. There's a reason Squeak runs binary equivalent on Windows, Linux, Solaris, Macintosh, Mac OS X, the Sharp Zarus, and some other little handheld gadgets. The core VM is portable but there are stubs you need to do hardware/filesystem/network/display/input device interfacing.
FWIW, there have been a number of embedded Smalltalk projects over the years.
You might not be able to afford Squeak on your smaller devices. You may be able to afford PocketSmalltalk though. There is some info here: [link|http://www.iutc3.unicaen.fr/serge/62|http://www.iutc3.unicaen.fr/serge/62] or [link|http://www.pocketsmalltalk.com/|http://www.pocketsmalltalk.com/]
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #102,675
5/19/03 10:37:48 PM
|
Re: The VM's are all written in very portable C
I've got a spare 2gig laptop disk that was intended as a testing place for "FORTH OS" so I think I will play around with this.
Has anyone ever tested Smalltalk as an extension of the FORTH VM? Kinda like running win or startx from the command prompt. FORTH is paradoxically fast in some situations, like moving data (probably why it's good for graphics). You could have a completely portable hardware interface in FORTH.
[link|http://www.zetetics.com/bj/papers/moving1.htm|http://www.zetetics....apers/moving1.htm]
How would ST map onto this?
-drl
|
Post #102,694
5/20/03 12:31:42 AM
|
Funny you should mention it
Just ran across a thread on Squeak list talking about changing a couple low level operations in the VM to support something more like IDT on message sends to allow any object to be used as a CompiledMethod (the object that represents executable code). Which raised the following comment:
Incidentally, does anyone know of prior art for doing that kind
of jumping from VM to meta-interpreter and back, in Smalltalk or other
similar (OO, bytecode) systems? There's a company doing exactly that to
enable call/cc in Java, and I'm curious if their patent application has
any validity.
------
My first thought was that your question reminded me of indirect-threaded
Forth implementations, which is the classic style of Forth
implementation. In an indirect-threaded Forth, each "subroutine"
(called a "word" in Forth) begins with the address of its interpreter.
Also, consider the similar, but slightly different, direct-threaded
Forth implementation style where every "word" begins with machine code
which is the interpreter for that "word" (it is typically a jump or call
to the interpreter for that class of Forth "word").
Maybe that could be seen as prior art, without needing to squint too
hard? I suppose this goes back to the late 1960s or early 1970s. There
was a nice article in Byte (1980? or early 1980s) with a title something
like "Threaded Interpreters" which went into some detail about
indirect-threading, direct-threading, subroutine-threading, and
token-threading.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #103,039
5/21/03 10:16:51 PM
|
Re: Funny you should mention it
Well, the ideal system to me would be:
1) A FORTH VM for hardware abstraction
2) A Smalltalk windowing environment. If the basic Smalltalk ideas
map onto FORTH constructs like code and parameter fields, and
threading, and dictionaries, then it's a done deal to write Smalltalk in FORTH.
3) An APL system coded in Smalltalk. This would be an acid test
because APL HAS to be very fast at moving data, which is what
really takes the most time.
-drl
|
