| David Brown <david.brown@hesbynett.no>: Nov 03 12:58AM +0100 >> them keywords in C99 would have broken existing code. (C++ had them as >> keywords since the language was created > Not in its original specification, bool was added during ISO/ANSI standardization. Fair enough. > I recall reading an article in C++ Report that talked about the compromises > that were made to break as little code as possible that already used #define bool int, > comprises that included (regrettably, in my opinion) the integer conversions. A lot of C++ would have been a neater, safer and stronger language if it had had fewer compromises to be compatible with C. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 02 04:05PM -0800 > them keywords in C99 would have broken existing code. (C++ had them as > keywords since the language was created - also, C++ is more willing to > risk breakage in existing code than C is in new standards.) [...] That's not quite true. C++ has had bool as a builtin type, and false and true as keywords, since its first ISO standard, in 1998. But the first and second editions of Stroustrup's "The C Programming Language" (1986 and 1991, respectively) don't mention bool, and for example document that the "!" operator yields a result of type int with the value 0 or 1. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| olcott <NoOne@NoWhere.com>: Nov 02 06:45PM -0600 On 11/2/2020 6:05 PM, Keith Thompson wrote: > [...] > That's not quite true. C++ has had bool as a builtin type, and false > and true as keywords, since its first ISO standard, in 1998. But the Yes for C++, not for C. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 07:41AM +0100 > The macro, not being a language feature, can be #undef'd if necessary > ... Why should someone include <stdbool.h> and undef bool ? |
| David Brown <david.brown@hesbynett.no>: Nov 03 11:35AM +0100 On 03/11/2020 01:05, Keith Thompson wrote: > (1986 and 1991, respectively) don't mention bool, and for example > document that the "!" operator yields a result of type int with the > value 0 or 1. Yes, another poster (Daniel) pointed that out. (I have the second edition of the book on my shelf, but it's a /long/ time since I read it.) |
| David Brown <david.brown@hesbynett.no>: Nov 03 11:38AM +0100 On 03/11/2020 07:41, Bonita Montero wrote: >> The macro, not being a language feature, can be #undef'd if necessary >> ... > Why should someone include <stdbool.h> and undef bool ? Because they include one header that itself uses <stdbool.h>, and another that defines its own "bool" type? You won't (or shouldn't) get this kind of thing in newly written headers - even if code is written to C90 standards it should not knowingly use identifiers that conflict with newer C code. But it's possible that you get such troubles when using older code and newer code together, so the C standards committee use macros to let people work around such issues without having to change the old (and presumably tested and working) code. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 12:39PM +0100 > Because they include one header that itself uses <stdbool.h>, and > another that defines its own "bool" type? ... Why should I confuse with my code by defining bool differently ? |
| David Brown <david.brown@hesbynett.no>: Nov 03 01:10PM +0100 On 03/11/2020 12:39, Bonita Montero wrote: >> Because they include one header that itself uses <stdbool.h>, and >> another that defines its own "bool" type? ... > Why should I confuse with my code by defining bool differently ? /You/ would not do so - because you write C++ code, and you do so today using relatively modern standards. But someone else may have written C code last century, or at least C90 code, and used their own "bool" type. And if a C programmer needs to use that old (or old standard) code along with modern code that uses <stdbool.h>, then "#undef bool" could be part of their solution. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 01:23PM +0100 > And if a C programmer needs to use that old (or old standard) code > along with modern code that uses <stdbool.h>, then "#undef bool" could > be part of their solution. It could be better to spend 5mins by sarch & replace the custom bool -type with a different name to prevent confusion by others who read the source. |
| Bo Persson <bo@bo-persson.se>: Nov 03 01:45PM +0100 On 2020-11-03 at 13:23, Bonita Montero wrote: > It could be better to spend 5mins by sarch & replace the custom bool > -type with a different name to prevent confusion by others who read > the source. Yes, unless you can't. For example if some of the code is used in medical equipment and any source change would need recertification in several different countries. Then it would be *a lot* less expensive to use your old headers in new code, and just undef the conflicting macros. Bo Persson |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 02:26PM +0100 > For example if some of the code is used in medical equipment and any > source change would need recertification in several different countries. You're joking. The code has the same functionality, no matter what this type is called. |
| David Brown <david.brown@hesbynett.no>: Nov 03 03:49PM +0100 On 03/11/2020 14:26, Bonita Montero wrote: >> source change would need recertification in several different countries. > You're joking. > The code has the same functionality, no matter what this type is called. Don't worry about it. You can use bool. Leave the difficult development issues to people who know about them. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 03:56PM +0100 >> The code has the same functionality, no matter what this type is called. > Don't worry about it. You can use bool. Leave the difficult > development issues to people who know about them. If there's a need to read the code, there's surely a need to change it anyway. So if someone gets confused by a mis-typed bool because of a #undef / re-#define, there's no problem with aliasing the own type with a unique name. The whole argumentation is ridiculous. It's like saying uint**_t has to be a macro because it could be redefined. |
| David Brown <david.brown@hesbynett.no>: Nov 03 05:25PM +0100 On 03/11/2020 15:56, Bonita Montero wrote: >> development issues to people who know about them. > If there's a need to read the code, there's surely a need to change > it anyway. As I said - if you don't understand why some development practices require that you do not change the code without exceptional reason, leave such serious development to other people. In certain fields, such as medical devices, parts of automotive development, aeronautic development, and the like, if code has been tested and certified, it does not change. For example, a bug was found in the engine management code for the dreamliner aircraft engines which would cause the engine to stop after about 400 days (IIRC). It was cheaper and lower risk to add a "restart the engine controller every 120 days" requirement to the maintenance manuals than to fix the bug - despite the bug fix being trivial in the code. Do you think developers in such conservative processes will change the code in the headers to avoid confusion, or add an #undef and document the strangeness in the code? The programming world does not consist solely of windows apps which treat users as beta testers. There are programmers who would consider a half-dozen lines of code in a week to be unusually productive. You do not change such code lightly. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 05:29PM +0100 > In certain fields, such as medical devices, parts of automotive > development, aeronautic development, and the like, if code has been > tested and certified, it does not change. You don't understand what I've said. As long as no one will read the code there's no confusion about redefined bools. But if someone will read the code it's very likely that there's also a need to change it. And when change it, you can remove this bool-alias-confusion in a minute. |
| scott@slp53.sl.home (Scott Lurndal): Nov 03 05:12PM >read the code it's very likely that there's also a need to change it. >And when change it, you can remove this bool-alias-confusion in a >minute. You have no clue what's involved in real software development, it appears. |
| Bart <bc@freeuk.com>: Nov 03 05:13PM On 03/11/2020 16:25, David Brown wrote: > the strangeness in the code? > The programming world does not consist solely of windows apps which > treat users as beta testers. You're singling out windows apps unfairly. I've seen considerable numbers of bugs in apps across Android and whatever passes for an OS in smart TVs. And in my car (causing it to not restart after an auto engine cuttoff, or make the satnav go crazy). May applications are just ambitious or too many layers of software where one part doesn't what another is doing. (Whenever I plan to watch TV during a meal I've taken to setting it up beforehand so that it doesn't go cold while sorting out network and operational problems.) And when it's not actual bugs, the user interfaces are generally temperamental. That 'restart every 120 days' requirement is similar to any workaround a an applications developer will advise a client until a problem is sorted. You identify a problem, but acknowledge also that a client needs to be getting on with their work. And it is common that a too-quick fix can screw other things. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 06:15PM +0100 >> minute. > You have no clue what's involved in real software development, it > appears. Nothing what you say is related to what I said. |
| Richard Damon <Richard@Damon-Family.org>: Nov 03 12:37PM -0500 On 11/3/20 9:56 AM, Bonita Montero wrote: > type with a unique name. > The whole argumentation is ridiculous. It's like saying uint**_t > has to be a macro because it could be redefined. The big difference is that it is very unlikely for code written before C99 propsed these types, for code to have used those types. Prior to C99 there were a lot of types invented for these purposes, but they used other names. In one sense, the standard avoided some of the perhaps 'better' names to avoid conflict, and leave room for applications to continue to use those other names. bool, on the other hand was a VERY largely imlemented type, as it is so fundamentally natural. The name bool, is also by far the most natural name. It also has special properties that can't be emulated by other types easily in C (like all non-zero values become 1). Because of this, it was useful to make it a way that code could 'erase' the definition, and rather than defining an typeundef statement, they made it a macro. bool is also a name not likely to be used in another context, where restricting the scope of the definition would likely make a difference (because people DID think of it as sort of a reserved word, that just hadden't been implemented, so they did it). |
| David Brown <david.brown@hesbynett.no>: Nov 03 08:07PM +0100 On 03/11/2020 18:13, Bart wrote: >> The programming world does not consist solely of windows apps which >> treat users as beta testers. > You're singling out windows apps unfairly. I'm not sure it is unfair to suggest that Windows programs are often more poorly coded. But it was not my intention to suggest that /only/ Windows programs are badly written (or badly tested, or otherwise badly developed) - or that this applies to all programs on Windows. But it is my understanding that Bonita writes general Windows programs, which was why I mentioned them. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Nov 03 11:29AM -0800 On Tuesday, November 3, 2020 at 2:07:58 PM UTC-5, David Brown wrote: > developed) - or that this applies to all programs on Windows. But it is > my understanding that Bonita writes general Windows programs, which was > why I mentioned them. Right, you felt it necessary to make an ad hominem attack on Bonita. But why the ad hominem attack? Daniel |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 04:49PM +0100 >> } > I'm not saying this is the best or most efficient way. > I'm suggesting it was a rationale for adding the overload. Consider what we've shown as alternatives that make this overload superfluous. |
| 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