| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 25 11:36AM -0700 > Obviously this is creating a button. Obviously it's got the display text "OK". Obviously > rect is some sort of rectangle containing the position. But what is "true"? > If we make enabled / disabled an enum, then it's more clear what the code is doing. Agreed -- but what does that have to do with what we were discussing? You were talking about hardware support. The same considerations apply to a built-in boolean type or to a 2-element enum. > bools are initialised to 1 or 0 and all operations on them yield 1 or 0. In the practical > programmer's world, things can get more messy, because some of the code might > be written in another language, for example. First off, why would you write `if (flag == true)` rather than `if(flag)`? But for a boolean type that's built into the language, like C's _Bool or C++'s bool, none of that is an issue in the absence of memory corruption. Conversions to bool always yield false or true (0 or 1). If some of the code is written in another language, then *of course* you have to make sure that anything converted to a native boolean is normalized. Anything that stores a value other than 0 or 1 in a C or C++ boolean object is buggy, and needs to be fixed. None of this has anything to do with some distinction between theoretical and practical programmers. Sometimes I'm a theoretical programmer, and sometimes I'm a practical programmer. In either role, I care that something is supported by the combination of the hardware and the compiler. As long as the compiler does its job, it works. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| David Brown <david.brown@hesbynett.no>: Aug 25 08:47PM +0200 On 25/08/2022 19:32, Malcolm McLean wrote: > some sort of rectangle containing the position. But what is "true"? > If we make enabled / disabled an enum, then it's more clear what the > code is doing. We've had the "No true Scotsman" argument, now we are onto "Whataboutism". Are you planning on working your way through Wikipedia's list of argument fallacies? Keith said booleans can make code /clearer/ - he did not claim it magically makes all code as clear as it could possibly be. "mybutton("OK", &rect, true);" is a step up from "mybutton("OK", &rect, 1);". You could well say that "mybutton("OK", &rect, button_state_enabled);" is better - but so what? That does not stop the fact that a simple, standardised boolean type is a massive improvement in clarity compared to either "int" or home-made types that differ wildly. > have any bit pattern other than bit clear / bit set. If bool is > something provided by software, and the underlying type is an > integer, then it might hold unexpected values. Sometimes I wonder if you actually do much programming in C (or C++). Do you know how "bool" (or "_Bool") is defined in C? The standards say how it must work, the compiler implements it. If "flag" is declared as "bool", then when you read it, it either equals "false" or it equals "true". There is no middle ground, no "unexpected" value, unless you have screwed up your code so badly with bugs and undefined behaviour that you really can't rely on anything. > 0. In the practical programmer's world, things can get more messy, > because some of the code might be written in another language, for > example. Practical programmers are concerned with writing correct code. And they are concerned with writing clear and concise code - they follow the rules of the language, and expect the compiler to follow its part of the bargain. They know that a "bool" holds either "false" or "true", because there is no valid way to put anything else into the bool, and (baring bugs, when any assumption can be violated) they don't write code that does something different. |
| David Brown <david.brown@hesbynett.no>: Aug 25 08:51PM +0200 On 25/08/2022 19:23, Keith Thompson wrote: > Remember that C99 removed implicit int, which in principle broke a lot > of existing code. Most compilers continued to accept implicit it in > some mode, perhaps with a non-fatal warning. Yes, that is an example of gcc supporting old and dangerous constructs even when nominally using standards that disallow it. > Code that uses bool, false, and true as identifiers is going to be a > little trickier to handle in lexical analysis and parsing. I expect the gcc folks will figure out a way to handle it - at least in cases where the "homemade" bool type and values are directly compatible with the "real" type and values. (For the type, that would really just mean manually doing "typedef _Bool bool;" or "#define bool _Bool", since alternatives like enumerations, int, or char do not have the same semantics.) |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 25 12:14PM -0700 > really just mean manually doing "typedef _Bool bool;" or "#define bool > _Bool", since alternatives like enumerations, int, or char do not have > the same semantics.) I wouldn't expect (or want) a compiler to handle a user-defined bool differently depending on whether it thinks it's compatible with the built-in bool. But this discussion probably belongs in comp.lang.c anyway. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 25 09:32PM +0100 > type). And that was for "there's no need to test the code, because we > prove it is correct on the blackboard" programming, which is as > academic as it comes. Care to name and shame? That's an extraordinary thing to say (if it was not a joke)? -- Ben. |
| David Brown <david.brown@hesbynett.no>: Aug 25 11:16PM +0200 On 25/08/2022 22:32, Ben Bacarisse wrote: >> academic as it comes. > Care to name and shame? That's an extraordinary thing to say (if it was > not a joke)? "Beware of bugs in the above code; I have only proved it correct, not tried it." (Donald Knuth) Several of our courses covered provable code, with mathematical derivation from specifications through to code. The "programming" language was somewhat idealised and limited and had no implementation - the idea was that if you wanted to use the code, you'd translate the derived algorithm into a practical real language. So if you want to look at sorting algorithms, for example, you start with a list of items of some type (the type does not matter), and a post condition that the list is sorted. You work through step by step, with each step justified mathematically, until you have "executable" code at the end. If you have made no mistakes underway, you have a proven correct implementation of the specifications - not just one that has passed some test cases. (You can look up the book "Programming from Specifications" by Carroll Morgan, which is freely available.) I think the only programming language that we were actually taught was a functional programming language very much like Haskell. When we had practical work that involved actual programming on computers, we were expected to learn whatever language the course tutor thought appropriate for the task - C, Modula 2, and Occam, perhaps more. |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Aug 25 11:11PM +0300 On 25/08/2022 21:00, Stefan Ram wrote: > JiiPee <kerrttuPoistaTama11@gmail.com> writes: >> Can anybody suggest this to Bjarne? hehe > Until then you could use inheritance. New idea for me. Also, can put another class inside the other one preventing the friend to get acces to the inside class. |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Aug 25 11:13PM +0300 On 25/08/2022 21:13, Alf P. Steinbach wrote: > void foo() {} > void foo2() {} > }; yes thats a good one. I used similar before. although I still think the new friend might be useful, if normal friend is also there. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 25 11:38AM -0700 On 8/25/2022 3:37 AM, Malcolm McLean wrote: > "update pointers" routine when it deletes a shared object. Fortunately the system > provides an "is_valid" method, so you can guard against objects being deleted > when it's your turn for the processor. Sounds like a need for a proper Lifetime Management protocol... |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment