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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-08-12 15:55 +0300 |
| Message-ID | <td5iku$2gl2u$1@dont-email.me> |
| In reply to | #85864 |
12.08.2022 11:23 Muttley@dastardlyhq.com kirjutas: > On Wed, 10 Aug 2022 10:11:00 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> Sure, but "C/C++" isn't a good way to say that. You never see "C/Java". > > Last time I looked you couldn't compile C with a java compiler. That's not the point. When someone talks about "C/C++" they imply that the programming style and language syntax are so similar for both of them that there is no need to differentiate between these languages, at least for the discussion at hand. Alas, the overlap of style and syntax similarities between idiomatic C and C++ is pretty small and about the same size than between C and Java, it's just that many people with only superficial familiarity with the topic do not really understand that.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-12 14:43 +0000 |
| Message-ID | <td5otq$1cko$1@gioia.aioe.org> |
| In reply to | #85876 |
On Fri, 12 Aug 2022 15:55:57 +0300 Paavo Helde <eesnimi@osa.pri.ee> wrote: >12.08.2022 11:23 Muttley@dastardlyhq.com kirjutas: >> On Wed, 10 Aug 2022 10:11:00 -0700 >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> Sure, but "C/C++" isn't a good way to say that. You never see "C/Java". >> >> Last time I looked you couldn't compile C with a java compiler. > >That's not the point. When someone talks about "C/C++" they imply that >the programming style and language syntax are so similar for both of >them that there is no need to differentiate between these languages, at >least for the discussion at hand. > >Alas, the overlap of style and syntax similarities between idiomatic C >and C++ is pretty small and about the same size than between C and Java, 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. >it's just that many people with only superficial familiarity with the >topic do not really understand that. I think the lack of understanding is with you.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-08-12 18:07 +0300 |
| Message-ID | <td5qbq$2hcc7$1@dont-email.me> |
| In reply to | #85880 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-12 15:14 +0000 |
| Message-ID | <td5qoi$8m0$1@gioia.aioe.org> |
| In reply to | #85883 |
On Fri, 12 Aug 2022 18:07:38 +0300 Paavo Helde <eesnimi@osa.pri.ee> wrote: >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. I write my C++ code just like my C code except with C++ extensions so I've no idea what point you're making.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-12 12:11 -0700 |
| Message-ID | <87lerte0qb.fsf@nosuchdomain.example.com> |
| In reply to | #85884 |
Muttley@dastardlyhq.com writes:
> On Fri, 12 Aug 2022 18:07:38 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>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.
>
> I write my C++ code just like my C code except with C++ extensions so I've no
> idea what point you're making.
I think his point is that you write non-idiomatic C++ code.
Which you can certainly do if you like, but most of us don't.
--
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-13 09:38 +0000 |
| Message-ID | <td7reo$10pg$1@gioia.aioe.org> |
| In reply to | #85896 |
On Fri, 12 Aug 2022 12:11:08 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Muttley@dastardlyhq.com writes: >> On Fri, 12 Aug 2022 18:07:38 +0300 >> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>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. >> >> I write my C++ code just like my C code except with C++ extensions so I've no > >> idea what point you're making. > >I think his point is that you write non-idiomatic C++ code. > >Which you can certainly do if you like, but most of us don't. Perhaps its time someone describes what they mean by idiomatic C++ code. Off you go...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-13 17:56 +0200 |
| Message-ID | <td8hj9$2s47o$1@dont-email.me> |
| In reply to | #85907 |
On 13/08/2022 11:38, Muttley@dastardlyhq.com wrote: > On Fri, 12 Aug 2022 12:11:08 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> Muttley@dastardlyhq.com writes: >>> On Fri, 12 Aug 2022 18:07:38 +0300 >>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>> 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. >>> >>> I write my C++ code just like my C code except with C++ extensions so I've no >> >>> idea what point you're making. >> >> I think his point is that you write non-idiomatic C++ code. >> >> Which you can certainly do if you like, but most of us don't. > > Perhaps its time someone describes what they mean by idiomatic C++ code. > I'm not convinced it even makes sense to talk about "idiomatic" code out of context - I think both C and C++ are used for such a wide range of applications that the idea is close to meaningless. There are idioms that are used by many, and code can be idiomatic in a particular field, but not in general for the language. The "idiomatic" way to write C code for an 8051 microcontroller is very, very different from the "idiomatic" way to write C code for a POSIX command-line utility, yet both are C. C++ for a gaming engine kernel will be very different from C++ for a Windows database application. Comparing languages, C11 code will be very different from C90 code, as will C++20 code from C++98 code. I think it is perhaps enough to say that if you know you are writing a piece of code from scratch in C++, you won't write it in the same way as if you were writing it in C. Attempting to put figures on the differences, or give binary "idiomatic" / "non-idomatic" tags, is not really helpful.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-08-24 11:32 +0300 |
| Message-ID | <te4nn4$39989$1@dont-email.me> |
| In reply to | #85907 |
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));
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-24 11:33 +0100 |
| Message-ID | <87sflmszgi.fsf@bsb.me.uk> |
| 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));
> }
What you say is true, but you can make the point without writing clumsy
C and without assuming that the support functions have not been written
to handle prepare, combine and release actions for null pointers
correctly. The C code might, in fact, look like this:
A *resource1 = PrepareResourceA(arg1, arg2);
B *resource2 = PrepareResourceB(arg1, arg2, resource1);
bool result = CombineAB(resource1, resource2, presult);
ReleaseResourceA(resource1);
ReleaseResourceB(resource2);
return result;
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-24 04:37 -0700 |
| Message-ID | <26e15e33-fa29-46b7-9f9c-6af7d155b8f6n@googlegroups.com> |
| In reply to | #86020 |
On Wednesday, 24 August 2022 at 11:33:51 UTC+1, Ben Bacarisse wrote:
> Paavo Helde <ees...@osa.pri.ee> writes:
>
> > 13.08.2022 12:38 Mut...@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));
> > }
> What you say is true, but you can make the point without writing clumsy
> C and without assuming that the support functions have not been written
> to handle prepare, combine and release actions for null pointers
> correctly. The C code might, in fact, look like this:
>
> A *resource1 = PrepareResourceA(arg1, arg2);
> B *resource2 = PrepareResourceB(arg1, arg2, resource1);
> bool result = CombineAB(resource1, resource2, presult);
> ReleaseResourceA(resource1);
> ReleaseResourceB(resource2);
> return result;
>
Superficially, that code looks tidy.
In reality it isn't. It's not clear to a mantaining programmer that the earlier calls
can fail and return null pointers.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-24 13:31 +0100 |
| Message-ID | <878rndu8kx.fsf@bsb.me.uk> |
| In reply to | #86021 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 24 August 2022 at 11:33:51 UTC+1, Ben Bacarisse wrote:
>> Paavo Helde <ees...@osa.pri.ee> writes:
>>
>> > 13.08.2022 12:38 Mut...@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));
>> > }
>> What you say is true, but you can make the point without writing clumsy
>> C and without assuming that the support functions have not been written
>> to handle prepare, combine and release actions for null pointers
>> correctly. The C code might, in fact, look like this:
>>
>> A *resource1 = PrepareResourceA(arg1, arg2);
>> B *resource2 = PrepareResourceB(arg1, arg2, resource1);
>> bool result = CombineAB(resource1, resource2, presult);
>> ReleaseResourceA(resource1);
>> ReleaseResourceB(resource2);
>> return result;
>>
> Superficially, that code looks tidy.
> In reality it isn't.
It is tidy. In reality. You mean you don't like it because a reader
has to know what the called function really do.
> It's not clear to a mantaining programmer that the earlier calls
> can fail and return null pointers.
The same is true of all well-written code. It's also true of the C++
about which you did not make the same comment.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-24 14:09 +0000 |
| Message-ID | <te5be0$1r3b$1@gioia.aioe.org> |
| In reply to | #86020 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-24 15:31 +0100 |
| Message-ID | <87wnaxsofv.fsf@bsb.me.uk> |
| In reply to | #86024 |
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. None of the posted code is correct without a few declarations... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-24 14:38 +0000 |
| Message-ID | <te5d5e$m37$1@gioia.aioe.org> |
| In reply to | #86027 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-24 15:57 +0100 |
| Message-ID | <87r115sn88.fsf@bsb.me.uk> |
| In reply to | #86028 |
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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-24 10:41 -0700 |
| Message-ID | <878rndy1wg.fsf@nosuchdomain.example.com> |
| In reply to | #86029 |
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
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-24 21:48 +0100 |
| Message-ID | <87wnaxqsfy.fsf@bsb.me.uk> |
| In reply to | #86037 |
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... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-08-25 07:34 +0200 |
| Message-ID | <te71ll$3j56t$1@dont-email.me> |
| In reply to | #86045 |
On 24 Aug 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... > It's apparently the same as with C++: not very practical academics in charge, expressing their academic ideals. Idealism is a kind of advanced sabotage. Usually. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-25 11:29 +0100 |
| Message-ID | <87a67sy5u2.fsf@bsb.me.uk> |
| In reply to | #86050 |
"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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-25 04:14 -0700 |
| Message-ID | <392fc8fe-b516-434c-8962-c11e2154f4c6n@googlegroups.com> |
| In reply to | #86055 |
On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote: > "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: > > > On 24 Aug 2022 22:48, Ben Bacarisse wrote: > >> Keith Thompson <Keith.S.T...@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. > Low level, practical programmers tend to think of programming in terms of manipulating bits in memory. Academic computer science people tend to think of programming in terms of manipulating symbols. So a practical programmer will tend to say "set that bit to indicate the light is on", a computer scientist will say "bind that variable to true/false to indicate the status of the light".
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web