Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #85804 > unrolled thread
| Started by | NOSPAM.Alan.Beck@darkrealms.ca (Alan Beck) |
|---|---|
| First post | 2022-08-08 09:43 +0000 |
| Last post | 2022-08-27 23:15 -0700 |
| Articles | 20 on this page of 114 — 19 participants |
Back to article view | Back to comp.lang.c++
To C or not to C++ NOSPAM.Alan.Beck@darkrealms.ca (Alan Beck) - 2022-08-08 09:43 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-08 20:02 +0300
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-09 05:38 +0000
Re: To C or not to C++ Ralf Fassel <ralfixx@gmx.de> - 2022-08-09 11:07 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-10 02:25 +0200
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-09 17:52 -0700
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-09 21:39 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-10 07:45 +0000
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-10 19:50 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-10 13:13 -0700
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-11 04:29 +0200
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 02:41 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-10 07:39 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-10 10:11 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 08:23 +0000
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-12 12:12 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 14:41 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:09 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-13 10:28 +0200
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-13 09:37 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-12 15:55 +0300
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 14:43 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-12 18:07 +0300
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 15:14 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:11 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-13 09:38 +0000
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-13 17:56 +0200
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-24 11:32 +0300
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 11:33 +0100
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-24 04:37 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 13:31 +0100
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-24 14:09 +0000
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 15:31 +0100
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-24 14:38 +0000
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 15:57 +0100
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-24 10:41 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 21:48 +0100
Re: To C or not to C++ "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-08-25 07:34 +0200
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 11:29 +0100
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 04:14 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 12:36 +0100
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 05:16 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 17:16 +0100
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 20:35 +0200
[OT] Bad CS course, no cookie (Was: To C or not to C++) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 21:32 +0100
Re: [OT] Bad CS course, no cookie (Was: To C or not to C++) David Brown <david.brown@hesbynett.no> - 2022-08-25 23:16 +0200
Re: [OT] Bad CS course, no cookie Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-26 00:33 +0100
Re: [OT] Bad CS course, no cookie David Brown <david.brown@hesbynett.no> - 2022-08-26 10:39 +0200
Re: [OT] Bad CS course, no cookie Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-26 10:57 +0100
Re: [OT] Bad CS course, no cookie David Brown <david.brown@hesbynett.no> - 2022-08-26 12:49 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 19:56 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-26 10:47 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-26 02:48 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-26 13:02 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-26 04:57 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-26 14:55 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-26 06:20 -0700
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-27 18:44 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-28 11:30 +0200
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 10:06 -0700
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 10:32 -0700
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 11:36 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 20:47 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-26 03:11 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 09:21 +0200
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-25 12:58 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 10:23 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 20:51 +0200
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 12:14 -0700
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-24 13:56 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-24 17:18 +0300
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-24 14:25 +0000
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 16:46 +0000
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-15 06:16 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-15 19:01 +0000
Re: To C or not to C++ Bo Persson <bo@bo-persson.se> - 2022-08-15 22:22 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-16 08:48 +0200
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-16 19:19 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-16 12:56 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-17 18:47 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-17 14:49 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-18 14:49 +0000
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-19 03:10 +0200
Re: To C or not to C++ d thiebaud <thiebauddick2@aol.com> - 2022-08-18 22:12 -0400
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-18 20:08 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-19 10:39 +0000
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-17 06:45 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-17 18:48 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-16 19:16 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:03 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-10 10:13 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-11 04:25 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-11 01:03 -0700
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 08:11 +0000
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-11 13:53 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-13 04:13 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-13 21:13 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-13 12:29 -0700
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-13 13:12 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-14 00:44 +0200
Re: To C or not to C++ Öö Tiib <ootiib@hot.ee> - 2022-08-12 02:54 -0700
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:12 -0700
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-12 16:22 -0700
Re: To C or not to C++ Öö Tiib <ootiib@hot.ee> - 2022-08-12 17:49 -0700
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-13 03:16 +0200
Re: To C or not to C++ Öö Tiib <ootiib@hot.ee> - 2022-08-13 09:08 -0700
Re: To C or not to C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 14:44 -0700
Re: To C or not to C++ Ralf Fassel <ralfixx@gmx.de> - 2022-08-10 12:06 +0200
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 07:04 +0000
Re: To C or not to C++ Bonita Montero <Bonita.Montero@gmail.com> - 2022-08-09 12:31 +0200
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-09 15:59 +0000
Re: To C or not to C++ Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-08-19 04:09 -0700
Re: To C or not to C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-13 12:17 -0700
Re: To C or not to C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-27 23:15 -0700
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-25 10:32 -0700 |
| Message-ID | <9af97d69-57b6-4b58-bd51-e7557692b3cen@googlegroups.com> |
| In reply to | #86065 |
On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > Computer science people would tend to think that it's important to have
> > a boolean type, because a lot of logic works on values which are inherently
> > true or false. Practical programmers would tend to say that it's not, because
> > most hardware won't support it. You will of course find exceptions.
> Many practical programmers would tend to say it's important to have a
> boolean type because it makes it easier to write clear code. (Some
> probably prefer to use zero and non-zero rather than explicit bool,
> false, and true.)
>
It does document that a value is logically bi-valued. So we can enable or disable
a button, but we can't have it in a half-enabled state. However the problem is
that when you look at C++ code which uses booleans, it's not clear what is
being passed
e.g. if you see
Button mybutton("OK", &rect, true);
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.
>
> Why would a "practical programmer" care whether there's direct hardware
> support for bool? If the compiler handles it correctly, it just works.
> In a very real sense, all hardware supports booleans, with more or less
> work required by the compiler.
>
Well one issue is whether if (flag == true) works as expected. If the hardware supports
1 bit types, then it must work, because flag cannot 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.
A theoretical person doesn't really have to worry about this, because in his world, all
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-25 11:36 -0700 |
| Message-ID | <87lerckw63.fsf@nosuchdomain.example.com> |
| In reply to | #86068 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>> > Computer science people would tend to think that it's important to have
>> > a boolean type, because a lot of logic works on values which are inherently
>> > true or false. Practical programmers would tend to say that it's not, because
>> > most hardware won't support it. You will of course find exceptions.
>> Many practical programmers would tend to say it's important to have a
>> boolean type because it makes it easier to write clear code. (Some
>> probably prefer to use zero and non-zero rather than explicit bool,
>> false, and true.)
>>
> It does document that a value is logically bi-valued. So we can enable or disable
> a button, but we can't have it in a half-enabled state. However the problem is
> that when you look at C++ code which uses booleans, it's not clear what is
> being passed
> e.g. if you see
> Button mybutton("OK", &rect, true);
> 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.
>> Why would a "practical programmer" care whether there's direct hardware
>> support for bool? If the compiler handles it correctly, it just works.
>> In a very real sense, all hardware supports booleans, with more or less
>> work required by the compiler.
>>
> Well one issue is whether if (flag == true) works as expected. If the hardware supports
> 1 bit types, then it must work, because flag cannot 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.
> A theoretical person doesn't really have to worry about this, because in his world, all
> 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 */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-25 20:47 +0200 |
| Message-ID | <te8g44$3naci$1@dont-email.me> |
| In reply to | #86068 |
On 25/08/2022 19:32, Malcolm McLean wrote:
> On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes: [...]
>>> Computer science people would tend to think that it's important
>>> to have a boolean type, because a lot of logic works on values
>>> which are inherently true or false. Practical programmers would
>>> tend to say that it's not, because most hardware won't support
>>> it. You will of course find exceptions.
>> Many practical programmers would tend to say it's important to have
>> a boolean type because it makes it easier to write clear code.
>> (Some probably prefer to use zero and non-zero rather than explicit
>> bool, false, and true.)
>>
> It does document that a value is logically bi-valued. So we can
> enable or disable a button, but we can't have it in a half-enabled
> state. However the problem is that when you look at C++ code which
> uses booleans, it's not clear what is being passed e.g. if you see
> Button mybutton("OK", &rect, true); 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.
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.
>>
>> Why would a "practical programmer" care whether there's direct
>> hardware support for bool? If the compiler handles it correctly, it
>> just works. In a very real sense, all hardware supports booleans,
>> with more or less work required by the compiler.
>>
> Well one issue is whether if (flag == true) works as expected. If the
> hardware supports 1 bit types, then it must work, because flag cannot
> 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.
> A theoretical person
> doesn't really have to worry about this, because in his world, all
> 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.
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.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-08-26 03:11 +0200 |
| Message-ID | <te96jc$5cs$1@gioia.aioe.org> |
| In reply to | #86055 |
On 8/25/2022 12:29 PM, Ben Bacarisse wrote: > "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes: > >> On 24 Aug 2022 22:48, Ben Bacarisse wrote: >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >>>> C23 will make bool, false, and true keywords. >>>> >>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf >>> I didn't know that, but I am not surprised because of the new course C >>> is taking. I hope it does not run aground... >> >> It's apparently the same as with C++: not very practical academics in >> charge, > > Who, in particular, do you mean? > >> expressing their academic ideals. > > In what way is making bool a type keyword expressing an academic ideal? > My thoughts were the reverse: the "purist" route -- of only using > already reserved identifiers -- has been ditched. > My take on this is that the academic idealist would be less bothered with practical distractions like maintainability. The idealist would code an algorithm just matching the theoretical model, so if a boolean type is involved, type bool it is. Your "purist" route also make sense, but more like the collector's focus rather than the innovator impulse. Using _Bool is clearly motivated by not breaking existing code, which is a priority in most industry jobs, arguably less in an academic environment where focus is more on researching new results rather than maintaining existing products. That said, I share your sentiment that keeping _Bool and staying on <stdbool.h> would have been the correct thing to do. The problem was solved, and solved well. No need to reopen and break it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-25 09:21 +0200 |
| Message-ID | <te77t8$3jk85$1@dont-email.me> |
| In reply to | #86045 |
On 24/08/2022 22:48, Ben Bacarisse wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> Muttley@dastardlyhq.com writes: >>>> On Wed, 24 Aug 2022 15:31:32 +0100 >>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>>>> Muttley@dastardlyhq.com writes: >>>>> >>>>>> On Wed, 24 Aug 2022 11:33:33 +0100 >>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>>>>>> bool result = CombineAB(resource1, resource2, presult); >>>>>> >>>>>> AFAIK even C 2011 doesn't have "bool". Its defined as the (ugly) _Bool in >>>>> C99. >>>>>> Obviously you can typedef however. >>>>> >>>>> I did not show headers. C has had bool (defined in stdbool.h) ever >>>>> since it got _Bool. >>>> >>>> Fair enough, didn't know that. Whats the point of _Bool then? To stop >>>> issues with C++ if a C99 file is included in a C++ project? >>> >>> Lots of old code defined bool. Suddenly making it a type keyword would >>> have broken that code. The identifier _Bool was reserved to the >>> implementation so it should not break anything. >> >> C23 will make bool, false, and true keywords. >> >> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf > > I didn't know that, but I am not surprised because of the new course C > is taking. I hope it does not run aground... > Some of the C23 changes are obvious and practical, such as "volatile semantics for lvalues" (embedded developers have been relying on this for decades, so it's nice to see it standardised), and the standardisation of "#warning" (again, something that people have used for decades). But there has definitely been a change in the principles. C23 makes "bool" the type and keyword, with "_Bool" as the "alternative spelling". Similarly we now have "static_assert", "alignas", etc. "void foo();" now means "void foo(void);". There are many things like this that arguably make C a slightly better and neater language, and will not harm anyone who has been writing decent C99 code over the past couple of decades. But C has a history older than that - and backwards compatibility is a prime reason the language is still alive and kicking. I suppose that we can rely on gcc to follow the fine tradition of supporting old, outdated and dangerous constructs when invoked without specific standards or warning flags - I expect it to still work with code that has "typedef int bool;" for a long time to come.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-08-25 12:58 +0000 |
| Message-ID | <jmKNK.852603$zgr9.534436@fx13.iad> |
| In reply to | #86052 |
David Brown <david.brown@hesbynett.no> writes: >On 24/08/2022 22:48, Ben Bacarisse wrote: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>> Muttley@dastardlyhq.com writes: >>>>> On Wed, 24 Aug 2022 15:31:32 +0100 >>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>>>>> Muttley@dastardlyhq.com writes: >>>>>> >>>>>>> On Wed, 24 Aug 2022 11:33:33 +0100 >>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>>>>>>> bool result = CombineAB(resource1, resource2, presult); >>>>>>> >>>>>>> AFAIK even C 2011 doesn't have "bool". Its defined as the (ugly) _Bool in >>>>>> C99. >>>>>>> Obviously you can typedef however. >>>>>> >>>>>> I did not show headers. C has had bool (defined in stdbool.h) ever >>>>>> since it got _Bool. >>>>> >>>>> Fair enough, didn't know that. Whats the point of _Bool then? To stop >>>>> issues with C++ if a C99 file is included in a C++ project? >>>> >>>> Lots of old code defined bool. Suddenly making it a type keyword would >>>> have broken that code. The identifier _Bool was reserved to the >>>> implementation so it should not break anything. >>> >>> C23 will make bool, false, and true keywords. >>> >>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf >> >> I didn't know that, but I am not surprised because of the new course C >> is taking. I hope it does not run aground... >> > >Some of the C23 changes are obvious and practical, such as "volatile >semantics for lvalues" (embedded developers have been relying on this >for decades, so it's nice to see it standardised), and the >standardisation of "#warning" (again, something that people have used >for decades). > >But there has definitely been a change in the principles. C23 makes >"bool" the type and keyword, with "_Bool" as the "alternative spelling". > Similarly we now have "static_assert", "alignas", etc. "void foo();" >now means "void foo(void);". There are many things like this that >arguably make C a slightly better and neater language, and will not harm >anyone who has been writing decent C99 code over the past couple of >decades. But C has a history older than that - and backwards >compatibility is a prime reason the language is still alive and kicking. > >I suppose that we can rely on gcc to follow the fine tradition of >supporting old, outdated and dangerous constructs when invoked without >specific standards or warning flags - I expect it to still work with >code that has "typedef int bool;" for a long time to come. > gcc 4.9 will be around forever. (an example, but really, the older C compilers will not go away just because C23 shows up).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-25 10:23 -0700 |
| Message-ID | <87ilmgw82w.fsf@nosuchdomain.example.com> |
| In reply to | #86052 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/08/2022 22:48, Ben Bacarisse wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>> C23 will make bool, false, and true keywords.
>>>
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
>> I didn't know that, but I am not surprised because of the new course
>> C
>> is taking. I hope it does not run aground...
>>
>
> Some of the C23 changes are obvious and practical, such as "volatile
> semantics for lvalues" (embedded developers have been relying on this
> for decades, so it's nice to see it standardised), and the
> standardisation of "#warning" (again, something that people have used
> for decades).
>
> But there has definitely been a change in the principles. C23 makes
> "bool" the type and keyword, with "_Bool" as the "alternative
> spelling". Similarly we now have "static_assert", "alignas", etc.
> "void foo();" now means "void foo(void);". There are many things like
> this that arguably make C a slightly better and neater language, and
> will not harm anyone who has been writing decent C99 code over the
> past couple of decades. But C has a history older than that - and
> backwards compatibility is a prime reason the language is still alive
> and kicking.
>
> I suppose that we can rely on gcc to follow the fine tradition of
> supporting old, outdated and dangerous constructs when invoked without
> specific standards or warning flags - I expect it to still work with
> code that has "typedef int bool;" for a long time to come.
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.
Code that uses bool, false, and true as identifiers is going to be a
little trickier to handle in lexical analysis and parsing.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-25 20:51 +0200 |
| Message-ID | <te8gbk$3nb4b$1@dont-email.me> |
| In reply to | #86067 |
On 25/08/2022 19:23, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 24/08/2022 22:48, Ben Bacarisse wrote: >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] >>>> C23 will make bool, false, and true keywords. >>>> >>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf >>> I didn't know that, but I am not surprised because of the new course >>> C >>> is taking. I hope it does not run aground... >>> >> >> Some of the C23 changes are obvious and practical, such as "volatile >> semantics for lvalues" (embedded developers have been relying on this >> for decades, so it's nice to see it standardised), and the >> standardisation of "#warning" (again, something that people have used >> for decades). >> >> But there has definitely been a change in the principles. C23 makes >> "bool" the type and keyword, with "_Bool" as the "alternative >> spelling". Similarly we now have "static_assert", "alignas", etc. >> "void foo();" now means "void foo(void);". There are many things like >> this that arguably make C a slightly better and neater language, and >> will not harm anyone who has been writing decent C99 code over the >> past couple of decades. But C has a history older than that - and >> backwards compatibility is a prime reason the language is still alive >> and kicking. >> >> I suppose that we can rely on gcc to follow the fine tradition of >> supporting old, outdated and dangerous constructs when invoked without >> specific standards or warning flags - I expect it to still work with >> code that has "typedef int bool;" for a long time to come. > > 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.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-25 12:14 -0700 |
| Message-ID | <87h720kuf2.fsf@nosuchdomain.example.com> |
| In reply to | #86076 |
David Brown <david.brown@hesbynett.no> writes:
> On 25/08/2022 19:23, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 24/08/2022 22:48, Ben Bacarisse wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>>>> C23 will make bool, false, and true keywords.
>>>>>
>>>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
>>>> I didn't know that, but I am not surprised because of the new course
>>>> C
>>>> is taking. I hope it does not run aground...
>>>>
>>>
>>> Some of the C23 changes are obvious and practical, such as "volatile
>>> semantics for lvalues" (embedded developers have been relying on this
>>> for decades, so it's nice to see it standardised), and the
>>> standardisation of "#warning" (again, something that people have used
>>> for decades).
>>>
>>> But there has definitely been a change in the principles. C23 makes
>>> "bool" the type and keyword, with "_Bool" as the "alternative
>>> spelling". Similarly we now have "static_assert", "alignas", etc.
>>> "void foo();" now means "void foo(void);". There are many things like
>>> this that arguably make C a slightly better and neater language, and
>>> will not harm anyone who has been writing decent C99 code over the
>>> past couple of decades. But C has a history older than that - and
>>> backwards compatibility is a prime reason the language is still alive
>>> and kicking.
>>>
>>> I suppose that we can rely on gcc to follow the fine tradition of
>>> supporting old, outdated and dangerous constructs when invoked without
>>> specific standards or warning flags - I expect it to still work with
>>> code that has "typedef int bool;" for a long time to come.
>> 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.)
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 */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-08-24 13:56 +0000 |
| Message-ID | <X5qNK.888606$wIO9.390978@fx12.iad> |
| In reply to | #86019 |
Paavo Helde <eesnimi@osa.pri.ee> writes:
>13.08.2022 12:38 Muttley@dastardlyhq.com kirjutas:
>>
>> Perhaps its time someone describes what they mean by idiomatic C++ code.
>>
>
>Perhaps the most visible difference is in that in proper C most of the
>application level code deals with error checking and resource cleanup,
>whereas in proper C++ most of the application level code implements
>business logic. Example with two resources, one can easily imagine more.
>A resource might be just a dynamically allocated array.
>
>C:
>
>int foo(int arg1, const char* arg2, X* presult) {
>
> A* resource1 = NULL;
> B* resource2 = NULL;
> int retval;
>
> if (PrepareResourceA(arg1, arg2, &resource1)!=0) {
> goto FAILURE;
> }
> resource2 = PrepareResourceB(arg1, arg2, resource1);
> if (!resource2) {
> goto FAILURE;
> }
> if (CombineAB(resource1, resource2, presult)!=0) {
> goto FAILURE;
> }
> // we know that ownership of B has moved over into result:
> resource2 = NULL;
> retval = 0; // success
> goto CLEANUP;
>
>FAILURE:
> retval = -1;
> goto CLEANUP;
>
>CLEANUP:
> if (resource1) {
> ReleaseResourceA(resource1);
> }
> if (resource2) {
> ReleaseResourceB(resource2);
> }
>
> return retval;
>}
>
>
>In C++, where errors are reported via exceptions, and ownership and
>resource cleanup are automatic:
>
>X foo(int arg1, std::string_view arg2) {
> A resource1 = PrepareResourceA(arg1, arg2);
> B resource2 = PrepareResourceB(arg1, arg2, resource1);
> return CombineAB(std::move(resource1), std::move(resource2));
Your example presumes that error recovery is basically kill the job.
The error recovery for PrepareResourceA may be significantly different
from the error recovery for PrepareResourceB, and lumping both into
some upstream exception handler (potentially in a completely different translation
unit) makes everything more complicated.
Fix the errors as soon as possible, in line.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-08-24 17:18 +0300 |
| Message-ID | <te5bup$3b9b3$1@dont-email.me> |
| In reply to | #86023 |
24.08.2022 16:56 Scott Lurndal kirjutas:
> Paavo Helde <eesnimi@osa.pri.ee> writes:
>> 13.08.2022 12:38 Muttley@dastardlyhq.com kirjutas:
>>>
>>> Perhaps its time someone describes what they mean by idiomatic C++ code.
>>>
>>
>> Perhaps the most visible difference is in that in proper C most of the
>> application level code deals with error checking and resource cleanup,
>> whereas in proper C++ most of the application level code implements
>> business logic. Example with two resources, one can easily imagine more.
>> A resource might be just a dynamically allocated array.
>>
>> C:
>>
>> int foo(int arg1, const char* arg2, X* presult) {
>>
>> A* resource1 = NULL;
>> B* resource2 = NULL;
>> int retval;
>>
>> if (PrepareResourceA(arg1, arg2, &resource1)!=0) {
>> goto FAILURE;
>> }
>> resource2 = PrepareResourceB(arg1, arg2, resource1);
>> if (!resource2) {
>> goto FAILURE;
>> }
>> if (CombineAB(resource1, resource2, presult)!=0) {
>> goto FAILURE;
>> }
>> // we know that ownership of B has moved over into result:
>> resource2 = NULL;
>> retval = 0; // success
>> goto CLEANUP;
>>
>> FAILURE:
>> retval = -1;
>> goto CLEANUP;
>>
>> CLEANUP:
>> if (resource1) {
>> ReleaseResourceA(resource1);
>> }
>> if (resource2) {
>> ReleaseResourceB(resource2);
>> }
>>
>> return retval;
>> }
>>
>>
>> In C++, where errors are reported via exceptions, and ownership and
>> resource cleanup are automatic:
>>
>> X foo(int arg1, std::string_view arg2) {
>> A resource1 = PrepareResourceA(arg1, arg2);
>> B resource2 = PrepareResourceB(arg1, arg2, resource1);
>> return CombineAB(std::move(resource1), std::move(resource2));
>
> Your example presumes that error recovery is basically kill the job.
>
> The error recovery for PrepareResourceA may be significantly different
> from the error recovery for PrepareResourceB, and lumping both into
> some upstream exception handler (potentially in a completely different translation
> unit) makes everything more complicated.
>
> Fix the errors as soon as possible, in line.
With exceptions the exception can be easily handled at the most correct
level, be it 1 or 20 stack frames above the actual error. If the
exception is caught and handled inside a PrepareResource*(), then it's
all fine. The exception only reaches foo() if it was not possible to
handle it at lower level.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-24 14:25 +0000 |
| Message-ID | <te5ccr$ant$1@gioia.aioe.org> |
| In reply to | #86025 |
On Wed, 24 Aug 2022 17:18:00 +0300 Paavo Helde <eesnimi@osa.pri.ee> wrote: >24.08.2022 16:56 Scott Lurndal kirjutas: >> The error recovery for PrepareResourceA may be significantly different >> from the error recovery for PrepareResourceB, and lumping both into >> some upstream exception handler (potentially in a completely different >translation >> unit) makes everything more complicated. >> >> Fix the errors as soon as possible, in line. > >With exceptions the exception can be easily handled at the most correct >level, be it 1 or 20 stack frames above the actual error. If the >exception is caught and handled inside a PrepareResource*(), then it's >all fine. The exception only reaches foo() if it was not possible to >handle it at lower level. The trouble with exceptions is people use them as glorified gotos, often the same people who think goto's are bad due to the not always obvious flow of control (though I've never noticed that except in BASIC). The irony is obviously lost on them.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-08-12 16:46 +0000 |
| Message-ID | <GtvJK.708422$5fVf.686222@fx09.iad> |
| In reply to | #85883 |
Paavo Helde <eesnimi@osa.pri.ee> writes: >12.08.2022 17:43 Muttley@dastardlyhq.com kirjutas: >> >> Rubbish. I've got multi thousand line originally C programs which I've happily >> compiled with C++ compilers in C++ mode due to a few minor C++ additions. > >This does not make it idiomatic C++ code. Where is it required that C++ code be idiomatic? What muttley describes would have been idiomatic C++ code in the cfront 2.1 days. C with classes is still a useful and common idiom.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-08-15 06:16 +0000 |
| Message-ID | <tdcobl$129p$1@gioia.aioe.org> |
| In reply to | #85880 |
Muttley@dastardlyhq.com wrote: > Rubbish. I've got multi thousand line originally C programs which I've happily > compiled with C++ compilers in C++ mode due to a few minor C++ additions. I assume it's C89. Modern C is more unlikely to be compilable as C++ as-is (for example because of out-of-order designated initializers, 'restrict', and so on). Even some completely standard-legal C89 won't compile as C++, such as: char *str = "hello"; (which is 100% valid standard C, but not valid C++.)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-15 19:01 +0000 |
| Message-ID | <tde56t$1jr6$1@gioia.aioe.org> |
| In reply to | #85928 |
On Mon, 15 Aug 2022 06:16:23 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Muttley@dastardlyhq.com wrote: >> Rubbish. I've got multi thousand line originally C programs which I've >happily >> compiled with C++ compilers in C++ mode due to a few minor C++ additions. > >I assume it's C89. Modern C is more unlikely to be compilable as C++ as-is >(for example because of out-of-order designated initializers, 'restrict', >and so on). Even some completely standard-legal C89 won't compile as C++, >such as: > > char *str = "hello"; > >(which is 100% valid standard C, but not valid C++.) Both clang and gcc will compile it but with a warning.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-08-15 22:22 +0200 |
| Message-ID | <jlvo7lF3u0kU1@mid.individual.net> |
| In reply to | #85942 |
On 2022-08-15 at 21:01, Muttley@dastardlyhq.com wrote: > On Mon, 15 Aug 2022 06:16:23 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> Muttley@dastardlyhq.com wrote: >>> Rubbish. I've got multi thousand line originally C programs which I've >> happily >>> compiled with C++ compilers in C++ mode due to a few minor C++ additions. >> >> I assume it's C89. Modern C is more unlikely to be compilable as C++ as-is >> (for example because of out-of-order designated initializers, 'restrict', >> and so on). Even some completely standard-legal C89 won't compile as C++, >> such as: >> >> char *str = "hello"; >> >> (which is 100% valid standard C, but not valid C++.) > > Both clang and gcc will compile it but with a warning. > And the warning says that it *is* valid?!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-16 08:48 +0200 |
| Message-ID | <tdfeji$91u$1@dont-email.me> |
| In reply to | #85946 |
On 15/08/2022 22:22, Bo Persson wrote: > On 2022-08-15 at 21:01, Muttley@dastardlyhq.com wrote: >> On Mon, 15 Aug 2022 06:16:23 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >>> Muttley@dastardlyhq.com wrote: >>>> Rubbish. I've got multi thousand line originally C programs which I've >>> happily >>>> compiled with C++ compilers in C++ mode due to a few minor C++ >>>> additions. >>> >>> I assume it's C89. Modern C is more unlikely to be compilable as C++ >>> as-is >>> (for example because of out-of-order designated initializers, >>> 'restrict', >>> and so on). Even some completely standard-legal C89 won't compile as >>> C++, >>> such as: >>> >>> char *str = "hello"; >>> >>> (which is 100% valid standard C, but not valid C++.) >> >> Both clang and gcc will compile it but with a warning. >> > > And the warning says that it *is* valid?! No, the warning tells you that it is /invalid/ : warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings] Muttley must have forgotten to mention that. (You don't need any flags to get this warning.) In the interests of letting people port C code to C++, compilers like gcc are a bit more lenient in what they accept than the standards require. And like most compilers, gcc and clang are not as strict to the standards as they might be unless you actively choose flags for that effect. This means if you want to check if something is valid C++ according to the standards, and try it using <https://godbolt.org> or similar, you want at least something like "-std=c++17 -Wpedantic" in your flags. There's still no guarantee the standards checking will be perfect, but it's likely to be pretty good.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-16 19:19 +0000 |
| Message-ID | <tdgqk2$17pq$1@gioia.aioe.org> |
| In reply to | #85953 |
On Tue, 16 Aug 2022 08:48:18 +0200 David Brown <david.brown@hesbynett.no> wrote: >On 15/08/2022 22:22, Bo Persson wrote: >> On 2022-08-15 at 21:01, Muttley@dastardlyhq.com wrote: >>> On Mon, 15 Aug 2022 06:16:23 -0000 (UTC) >>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>> Muttley@dastardlyhq.com wrote: >>>>> Rubbish. I've got multi thousand line originally C programs which I've >>>> happily >>>>> compiled with C++ compilers in C++ mode due to a few minor C++ >>>>> additions. >>>> >>>> I assume it's C89. Modern C is more unlikely to be compilable as C++ >>>> as-is >>>> (for example because of out-of-order designated initializers, >>>> 'restrict', >>>> and so on). Even some completely standard-legal C89 won't compile as >>>> C++, >>>> such as: >>>> >>>> char *str = "hello"; >>>> >>>> (which is 100% valid standard C, but not valid C++.) >>> >>> Both clang and gcc will compile it but with a warning. >>> >> >> And the warning says that it *is* valid?! > >No, the warning tells you that it is /invalid/ : > > warning: ISO C++ forbids converting a string constant to 'char*' > [-Wwrite-strings] > >Muttley must have forgotten to mention that. I didn't forget anything. The fact is both those compilers will compile it. A warning is a warning, its not an error.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-16 12:56 -0700 |
| Message-ID | <87h72cc67o.fsf@nosuchdomain.example.com> |
| In reply to | #85959 |
Muttley@dastardlyhq.com writes:
> On Tue, 16 Aug 2022 08:48:18 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>>On 15/08/2022 22:22, Bo Persson wrote:
>>> On 2022-08-15 at 21:01, Muttley@dastardlyhq.com wrote:
>>>> On Mon, 15 Aug 2022 06:16:23 -0000 (UTC)
>>>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>>> Muttley@dastardlyhq.com wrote:
>>>>>> Rubbish. I've got multi thousand line originally C programs which I've
>>>>> happily
>>>>>> compiled with C++ compilers in C++ mode due to a few minor C++
>>>>>> additions.
>>>>>
>>>>> I assume it's C89. Modern C is more unlikely to be compilable as C++
>>>>> as-is
>>>>> (for example because of out-of-order designated initializers,
>>>>> 'restrict',
>>>>> and so on). Even some completely standard-legal C89 won't compile as
>>>>> C++,
>>>>> such as:
>>>>>
>>>>> char *str = "hello";
>>>>>
>>>>> (which is 100% valid standard C, but not valid C++.)
>>>>
>>>> Both clang and gcc will compile it but with a warning.
>>>>
>>>
>>> And the warning says that it *is* valid?!
>>
>>No, the warning tells you that it is /invalid/ :
>>
>> warning: ISO C++ forbids converting a string constant to 'char*'
>> [-Wwrite-strings]
>>
>>Muttley must have forgotten to mention that.
>
> I didn't forget anything. The fact is both those compilers will compile it.
> A warning is a warning, its not an error.
As you probably already know, the standard does not require a conforming
compiler to reject anything unless there's a #error directive that
survives preprocessing. (At least that's the rule for C; I haven't
found wording in the C++ standard that requires rejecting a program with
a #error directive.) For any other violation of the language rules, all
the standard requires is a diagnostic, which can be a non-fatal warning.
You're right, it's not correct to say that `char *str = "hello";` "won't
compile as C++". A conforming compiler must diagnose it, but after
doing so it may either accept it or reject it. The warning quoted above
satisifies the standard's requirement for a diagnostic.
A C++ program containing that declaration is *ill-formed*.
The distinction between a warning and an error is less significant than
you imply it is.
I'd say the content of the warning was relevant. You chose to omit it
for some reason.
--
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 */
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-17 18:47 +0000 |
| Message-ID | <tdjd3l$nv2$1@gioia.aioe.org> |
| In reply to | #85960 |
On Tue, 16 Aug 2022 12:56:59 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >You're right, it's not correct to say that `char *str = "hello";` "won't >compile as C++". A conforming compiler must diagnose it, but after Thank you. We got there in the end. >I'd say the content of the warning was relevant. You chose to omit it >for some reason. The assertion was it wouldn't compile, not that it would compile with warnings. For an activity such as programming that requires attention to detail a lot of you here are rather lacking in that ability.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web