| Joe Pfeiffer <pfeiffer@cs.nmsu.edu>: Nov 02 10:35AM -0700 >> - Alf > I have been a C programmer since K&R was the standard when did they > make this change? The oldest copy of he standard I have is N1256, for C99. _Bool and stdbool.h are in that standard. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 02 07:03PM +0100 What I'm curious about is: why is bool in <stdbool.h> a macro and not a typedef of _Bool ? For my taste the latter one would have been the cleaner solution. |
| olcott <NoOne@NoWhere.com>: Nov 02 12:17PM -0600 On 11/2/2020 11:14 AM, Bonita Montero wrote: >>> You don't need C18 for this. This features are included in C99. >> So then C99 changed the K&R standard of bool as a native type? > bool isn't a native type in any C-standard, even not in K&R C. Yes. I have switched to C++ for such a long time that I forgot that the original purpose of C was to create a portable language that was efficient enough to use to implement Unix. In other words when we construe C as a higher level assembly language then bool as a native type does not make sense. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Nov 02 12:17PM -0600 On 11/2/2020 11:35 AM, Joe Pfeiffer wrote: >> make this change? > The oldest copy of he standard I have is N1256, for C99. _Bool and > stdbool.h are in that standard. I think that I still have the original lying around somewhere. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 02 02:03PM -0500 On 11/2/20 12:35 PM, Joe Pfeiffer wrote: >> make this change? > The oldest copy of he standard I have is N1256, for C99. _Bool and > stdbool.h are in that standard The "Subject:" header demonstrates the pitfalls of talking about the non-existent "C/C++" language. bool is not now, and never has been, a primitive type in C. bool is now, and always has been, a primitive type in standard C++ (I think it might have been a typedef or macro in some of the older pre-standard versions of C++). The built-in type _Bool was added to C in C99, along with a header (<stdbool.h>) that declares 'bool' as a macro expanding to _Bool. None of those things were part of K&R C, nor C90. |
| scott@slp53.sl.home (Scott Lurndal): Nov 02 07:05PM >What I'm curious about is: why is bool in <stdbool.h> a macro and >not a typedef of _Bool ? For my taste the latter one would have >been the cleaner solution. The macro, not being a language feature, can be #undef'd if necessary in legacy C headers that already were using a typedef for 'bool'. |
| olcott <NoOne@NoWhere.com>: Nov 02 01:05PM -0600 On 11/2/2020 1:03 PM, James Kuyper wrote: > The built-in type _Bool was added to C in C99, along with a header > (<stdbool.h>) that declares 'bool' as a macro expanding to _Bool. None > of those things were part of K&R C, nor C90. Thanks for this very thorough answer. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| David Brown <david.brown@hesbynett.no>: Nov 02 10:41PM +0100 On 02/11/2020 19:17, olcott wrote: >>>> You don't need C18 for this. This features are included in C99. >>> So then C99 changed the K&R standard of bool as a native type? >> bool isn't a native type in any C-standard, even not in K&R C. _Bool is a native type in C, added in C99. Like bool in C++, it has distinct properties unlike other integer types of the same size (typically, but not necessarily, it is one byte in size - which is typically, but not necessarily, 8 bits). In particular, it can only ever hold the value 0 or 1. (Compilers know this, and take advantage of that in optimisation.) Assignment "_Bool b = x;" is treated exactly as "b = (x == 0) ? 0 : 1;" > Yes. I have switched to C++ for such a long time that I forgot that the > original purpose of C was to create a portable language that was > efficient enough to use to implement Unix. Correct. > In other words when we > construe C as a higher level assembly language Wrong. C was designed to reduce the need to write assembly, not to be a "high level assembly". > then bool as a native > type does not make sense. A native boolean type would always have made sense. But C was a smaller language when it was created, and gained new useful features as the language, tools, and use of the language grew and matured. |
| David Brown <david.brown@hesbynett.no>: Nov 02 10:48PM +0100 On 02/11/2020 17:56, Joe Pfeiffer wrote: > I expect (someone who knows better is welcome to correct me) the reason > it was done this way instead of simply defining a new type "bool" was to > avoid breaking old code that had its own definition of bool. "bool", "true" and "false" are valid identifiers in C, and so making 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.) _Bool, on the other hand, is an identifier reserved for the implementation - new keywords are therefore almost always given _Keyword style names in C. And they are usually matched with a new <std...> header that defines "keyword" as a macro for "_Keyword", along with any other convenient types, macros, functions, etc., for the new feature. The definitions in standard headers are usually macros, so that people can #undef them if they want for compatibility with old code. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Nov 02 02:51PM -0800 On Monday, November 2, 2020 at 4:48:33 PM UTC-5, David Brown wrote: > "bool", "true" and "false" are valid identifiers in C, and so making > 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. 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. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 02 08:30PM On 02/11/2020 14:32, Öö Tiib wrote: >> for (auto& copy : copies()) >> copy->flush(aMessage); > But derived class has already access to protected members of its base? Only for if the context is the `this` pointer: class foo { protected: void f1() {} }; class bar : public foo { public: void f2(foo& o) { o.f1(); } }; int main() { bar o1; bar o2; o2.f2(o); } prog.cpp: In member function 'void bar::f2(foo&)': prog.cpp:12:8: error: 'void foo::f1()' is protected within this context o.f1(); ^ prog.cpp:4:7: note: declared protected here void f1() {} /Flibble -- ¬ |
| red floyd <myob@its.invalid>: Nov 02 10:42AM -0800 On 11/2/2020 5:42 AM, Paavo Helde wrote: > std::string strB(strA, 0, strA.find('\n')); > std::cout << strB << "\n"; > } I'm not saying this is the best or most efficient way. I'm suggesting it was a rationale for adding the overload. |
| 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