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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-17 14:49 -0700 |
| Message-ID | <87zgg2bkwg.fsf@nosuchdomain.example.com> |
| In reply to | #85965 |
Muttley@dastardlyhq.com writes:
> 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.
You could have helped by providing just a little extra information. You
chose not to. Consider trying to be helpful rather than just showing off
your ability to be obscure.
--
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-18 14:49 +0000 |
| Message-ID | <tdljh5$kqv$1@gioia.aioe.org> |
| In reply to | #85967 |
On Wed, 17 Aug 2022 14:49:35 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Muttley@dastardlyhq.com writes: >> 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. > >You could have helped by providing just a little extra information. You >chose not to. Consider trying to be helpful rather than just showing off >your ability to be obscure. A little extra info about what? I was replying to a 1 line assertion another poster made. Not my fault if that confused you.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-08-19 03:10 +0200 |
| Message-ID | <tdmnth$omg$1@gioia.aioe.org> |
| In reply to | #85971 |
On 8/18/2022 4:49 PM, Muttley@dastardlyhq.com wrote:
> On Wed, 17 Aug 2022 14:49:35 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Muttley@dastardlyhq.com writes:
>>> 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.
>>
>> You could have helped by providing just a little extra information. You
>> chose not to. Consider trying to be helpful rather than just showing off
>> your ability to be obscure.
>
> A little extra info about what? I was replying to a 1 line assertion another
> poster made.
Which is the textbook definition of taking out of context.
Not my fault if that confused you.
>
In fact the post you are referring to is:
"...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++.)"
Wherein the first line says "it won't compile as C++", and the last line
says "not valid C++".
A human being would read both, and understand that the message here is
about legal vs. not-legal C++, rather than questioning if some compiler
actually accepts the code fragment. This, considering that even the
first statement (the "won't compile" part) is counterpoised to the first
part of the same phrase, which clearly says that the matter is about
"standard-legal" C or C++.
This is for as human beings go. Then, there are the nitpickers.
[toc] | [prev] | [next] | [standalone]
| From | d thiebaud <thiebauddick2@aol.com> |
|---|---|
| Date | 2022-08-18 22:12 -0400 |
| Message-ID | <tdmrj1$1pjv$1@gioia.aioe.org> |
| In reply to | #85989 |
> In fact the post you are referring to is: > > "...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++.)" > > Wherein the first line says "it won't compile as C++", and the last line > says "not valid C++". > > A human being would read both, and understand that the message here is > about legal vs. not-legal C++, rather than questioning if some compiler > actually accepts the code fragment. This, considering that even the > first statement (the "won't compile" part) is counterpoised to the first > part of the same phrase, which clearly says that the matter is about > "standard-legal" C or C++. > > This is for as human beings go. Then, there are the nitpickers. A human being would read this as saying that it won't compile and is invalid. You should learn to express what you mean clearly.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-18 20:08 -0700 |
| Message-ID | <87ilmpaq1u.fsf@nosuchdomain.example.com> |
| In reply to | #85990 |
d thiebaud <thiebauddick2@aol.com> writes:
>> In fact the post you are referring to is:
>> "...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++.)"
>> Wherein the first line says "it won't compile as C++", and the last
>> line says "not valid C++".
>> A human being would read both, and understand that the message here
>> is about legal vs. not-legal C++, rather than questioning if some
>> compiler actually accepts the code fragment. This, considering that
>> even the first statement (the "won't compile" part) is counterpoised
>> to the first part of the same phrase, which clearly says that the
>> matter is about "standard-legal" C or C++.
>> This is for as human beings go. Then, there are the nitpickers.
>
> A human being would read this as saying that it won't compile and is
> invalid. You should learn to express what you mean clearly.
Please don't snip attribution lines.
I read the original statement as saying *incorrectly* that it won't
compile (in fact it may or may not compile, depending on the compiler
and settings), and *correctly* that it's not valid C++ (more precisely,
it's ill-formed). I didn't bother to comment on the minor error.
--
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-19 10:39 +0000 |
| Message-ID | <tdnp9m$1ufd$1@gioia.aioe.org> |
| In reply to | #85989 |
On Fri, 19 Aug 2022 03:10:08 +0200 Manfred <noname@add.invalid> wrote: >In fact the post you are referring to is: > > "...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++.)" > >Wherein the first line says "it won't compile as C++", and the last line >says "not valid C++". > >A human being would read both, and understand that the message here is >about legal vs. not-legal C++, rather than questioning if some compiler >actually accepts the code fragment. This, considering that even the >first statement (the "won't compile" part) is counterpoised to the first >part of the same phrase, which clearly says that the matter is about >"standard-legal" C or C++. > >This is for as human beings go. Then, there are the nitpickers. Ah, the No True Scotsman fallacy, its been a while since I've seen that :)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-08-17 06:45 +0000 |
| Message-ID | <tdi2pt$dpc$1@gioia.aioe.org> |
| In reply to | #85959 |
Muttley@dastardlyhq.com wrote: > I didn't forget anything. The fact is both those compilers will compile it. > A warning is a warning, its not an error. Compilers are not the authorities of what's legal C++ and what isn't. Just because a compiler might accept something and compile it into something doesn't mean it's officially valid standard C++.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-17 18:48 +0000 |
| Message-ID | <tdjd50$oi1$1@gioia.aioe.org> |
| In reply to | #85963 |
On Wed, 17 Aug 2022 06:45:19 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Muttley@dastardlyhq.com wrote: >> I didn't forget anything. The fact is both those compilers will compile it. >> A warning is a warning, its not an error. > >Compilers are not the authorities of what's legal C++ and what isn't. >Just because a compiler might accept something and compile it into >something doesn't mean it's officially valid standard C++. The original assertion was that it wouldn't compile, not whether it was 100% legal or not.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-08-16 19:16 +0000 |
| Message-ID | <tdgqel$15eg$1@gioia.aioe.org> |
| In reply to | #85946 |
On Mon, 15 Aug 2022 22:22:13 +0200 Bo Persson <bo@bo-persson.se> 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?! He said it won't compile. It WILL compile. A warning is just text.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-12 12:03 -0700 |
| Message-ID | <87tu6he12a.fsf@nosuchdomain.example.com> |
| In reply to | #85864 |
Muttley@dastardlyhq.com writes:
> On Wed, 10 Aug 2022 10:11:00 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>Muttley@dastardlyhq.com writes:
[...]
>>> Depends on the job requirements. Some places require knowledge of both
>>> languages and someone good with C++ isn't always good at writing efficient C.
>>
>>
>>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.
int class;
--
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-10 10:13 +0200 |
| Message-ID | <tcvpc2$1p184$1@dont-email.me> |
| In reply to | #85819 |
On 10/08/2022 02:25, Manfred wrote: > On 8/9/2022 11:07 AM, Ralf Fassel wrote: >> * Juha Nieminen <nospam@thanks.invalid> >> | I have never even heard of the "sketch" language so I can't comment. >> | If I had to make a completely wild guess it's probably some kind of >> | "higher-level" language with its own pros and cons compared to both >> | C and C++. >> >> On the Arduino, you usually only write the loop() (in C/C++) > > Note that the expression (C/C++) is considered a Bad Word nowadays. That wording implies that it was once a more acceptable term - I don't think anyone knowledgable in the two languages has been happy about conflating them. (It's fine to say "C /and/ C++", or "C /or/ C++".) But a lot of people with less knowledge and experience do mix the language names, and think of them as variants or at least that C++ is just "C with some extra features". And the Arduino targets relative beginners, and goes out of its way to try to hide that kind of "complexity" from users. > The fact is that, even if in principle a C code fragment can be compiled > as C++ code, which might suggest the two languages are closely related, > in truth they are now very different languages, so that they can't be > mixed with each other. They /are/ very closely related languages - and most well-written C code can be turned into working C++ code with only a few changes (such as casting the result of calls to malloc - the casts are perfectly fine in C, but not idoimatic) and without a change in functionality. C is the base language on which C++ builds. And yes they /can/ be mixed, and they /are/ mixed. C++ is designed to be easy to mix with C, and incompatibilities are not made without good reason. Indeed, a good deal of the things people dislike about C++, or that are not "good modern language design", trace back to compatibility with C. One area of programming where C and C++ are regularly mixed, is resource-constrained embedded systems. You can easily have a project with an RTOS in C90, some libraries in C99, application code in C++ of some sort, drivers in modern C - a full mix. Typically the only code that is compiled as both C and C++ is the C headers, but you sometimes get more complicated headers that provide different features depending on the language at the time. > If you are writing code that compiles both as C and C++, then you are in > fact writing C code, not C++. That's just silly. You are, in fact, writing code that is C code /and/ C++ code. It might not be idiomatic code, but it is perfectly valid. Some people are under the mistaken impression that to be "real" C++, you need to use lots of C++ features - that code is not "real" C++ unless it has classes (preferably with lots of inheritance, virtual methods, etc.), templates, standard library container classes, and the like. That's nonsense. /Real/ programmers - i.e., people who make a living as programmers - know there are many ways to design code and many ways to implement it, with different pros and cons. C++ is a multi-paradigm language designed to support a huge range of different styles of code. If the only difference between your C code and your C++ code is that you use "enum class" instead of "enum" to make your code safer, you are writing C++ code. > > It may or may not be important to you, but if you show up at a job > interview talking about C/C++, you will effectively show up as someone > who does not know what they are talking about, so beware. > That is perhaps true for technical interviews, but before you get to that stage you often have to pass through layers of HR folk who really do think there is a language called "C/C++" (and who also want candidates with 10 years of Rust experience). > which >> handles incoming events, plus interrupt functions etc, whereas main() is >> provided by the IDE. >> >> This code piece is called a 'sketch', which you compile and download to >> the arduino. >> >> R' >
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-08-11 04:25 +0200 |
| Message-ID | <td1pb9$68h$1@gioia.aioe.org> |
| In reply to | #85833 |
On 8/10/2022 10:13 AM, David Brown wrote: > On 10/08/2022 02:25, Manfred wrote: >> On 8/9/2022 11:07 AM, Ralf Fassel wrote: >>> * Juha Nieminen <nospam@thanks.invalid> >>> | I have never even heard of the "sketch" language so I can't comment. >>> | If I had to make a completely wild guess it's probably some kind of >>> | "higher-level" language with its own pros and cons compared to both >>> | C and C++. >>> >>> On the Arduino, you usually only write the loop() (in C/C++) >> >> Note that the expression (C/C++) is considered a Bad Word nowadays. > > That wording implies that it was once a more acceptable term - I don't > think anyone knowledgable in the two languages has been happy about > conflating them. (It's fine to say "C /and/ C++", or "C /or/ C++".) I first heard of C++ in the late '80s, and it was described to me as: "It's C, wherein structs can contain functions" (which sounded immediately as a cool feature to me). At that time C/C++ was not a Bad Word™, and I think this was justified, for 2 main reasons: - C++ was still relatively young, and the view of C++ as a mere evolution of C was still diffuse. It would take some more time for C++ programmers to gain more maturity and fully grasp the different landscape of the two (see how many are still arguing that C code is C++ code as well, even today) - C++11 had not happened, yet. Today, none of the above is true. > > But a lot of people with less knowledge and experience do mix the > language names, and think of them as variants or at least that C++ is > just "C with some extra features". And the Arduino targets relative > beginners, and goes out of its way to try to hide that kind of > "complexity" from users. > >> The fact is that, even if in principle a C code fragment can be >> compiled as C++ code, which might suggest the two languages are >> closely related, in truth they are now very different languages, so >> that they can't be mixed with each other. > > They /are/ very closely related languages - and most well-written C code > can be turned into working C++ code with only a few changes (such as > casting the result of calls to malloc - the casts are perfectly fine in > C, but not idoimatic) and without a change in functionality. C is the > base language on which C++ builds. I disagree. If you program in C++, i.e. you model a problem domain in C++ from scratch, then you end up with a /very/ different result than you would if you used C. > > And yes they /can/ be mixed, and they /are/ mixed. C++ is designed to > be easy to mix with C, and incompatibilities are not made without good > reason. Indeed, a good deal of the things people dislike about C++, or > that are not "good modern language design", trace back to compatibility > with C. What I mean by "mixed" here is in fact "confused". Nothing to do with C++ calling C functions, and vice versa (however this might be accomplished) > > One area of programming where C and C++ are regularly mixed, is > resource-constrained embedded systems. You can easily have a project > with an RTOS in C90, some libraries in C99, application code in C++ of > some sort, drivers in modern C - a full mix. Typically the only code > that is compiled as both C and C++ is the C headers, but you sometimes > get more complicated headers that provide different features depending > on the language at the time. Well, I think you agree that a C++ application using a C library is not really about mixing the two languages, don't you? > > >> If you are writing code that compiles both as C and C++, then you are >> in fact writing C code, not C++. > > That's just silly. You are, in fact, writing code that is C code /and/ > C++ code. It might not be idiomatic code, but it is perfectly valid. Again, I disagree. And it is not silly. Let's take an example that makes some sense: you write some code that involves a linked list (or any other container, for that matter) - consider a C implementation and a C++ implementation. Are you seriously arguing that the C implementation is a C++ implementation just as well? (Please note that I /know/ that the C implementation would be legal C++ code. I'm just saying that if you write such a C implementation in a C++ program, then you are Doing It Wrong™) > > Some people are under the mistaken impression that to be "real" C++, you > need to use lots of C++ features - that code is not "real" C++ unless it > has classes (preferably with lots of inheritance, virtual methods, > etc.), templates, standard library container classes, and the like. > That's nonsense. /Real/ programmers - i.e., people who make a living as > programmers - know there are many ways to design code and many ways to > implement it, with different pros and cons. C++ is a multi-paradigm > language designed to support a huge range of different styles of code. > If the only difference between your C code and your C++ code is that you > use "enum class" instead of "enum" to make your code safer, you are > writing C++ code. > >> >> It may or may not be important to you, but if you show up at a job >> interview talking about C/C++, you will effectively show up as someone >> who does not know what they are talking about, so beware. >> > > That is perhaps true for technical interviews, but before you get to > that stage you often have to pass through layers of HR folk who really > do think there is a language called "C/C++" (and who also want > candidates with 10 years of Rust experience). > >> which >>> handles incoming events, plus interrupt functions etc, whereas main() is >>> provided by the IDE. >>> >>> This code piece is called a 'sketch', which you compile and download to >>> the arduino. >>> >>> R' >> >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-11 01:03 -0700 |
| Message-ID | <f75964cd-8199-49a1-9850-00c02e0d4d05n@googlegroups.com> |
| In reply to | #85842 |
On Thursday, 11 August 2022 at 03:26:05 UTC+1, Manfred wrote: > On 8/10/2022 10:13 AM, David Brown wrote: > > On 10/08/2022 02:25, Manfred wrote: > > > > They /are/ very closely related languages - and most well-written C code > > can be turned into working C++ code with only a few changes (such as > > casting the result of calls to malloc - the casts are perfectly fine in > > C, but not idoimatic) and without a change in functionality. C is the > > base language on which C++ builds. > I disagree. If you program in C++, i.e. you model a problem domain in > C++ from scratch, then you end up with a /very/ different result than > you would if you used C. > > It depends what sort of programming you are doing. I work with algorithms. For example the other day I was looking at nesting (the problem of packing small objects into bins). There are several ways of approaching the problem, none of which bear any relation to the programming language you happen to be using. > > > >> If you are writing code that compiles both as C and C++, then you are > >> in fact writing C code, not C++. > > > > That's just silly. You are, in fact, writing code that is C code /and/ > > C++ code. It might not be idiomatic code, but it is perfectly valid. > Again, I disagree. And it is not silly. > > Let's take an example that makes some sense: you write some code that > involves a linked list (or any other container, for that matter) - > consider a C implementation and a C++ implementation. > > Are you seriously arguing that the C implementation is a C++ > implementation just as well? > (Please note that I /know/ that the C implementation would be legal C++ > code. I'm just saying that if you write such a C implementation in a C++ > program, then you are Doing It Wrong™) > I've got several bits of code where you need two linked lists. The objects are placed round the perimeter of closed shapes, so they have "previous" and "next" members. However they are also in another ordering. For instance if the shapes intersect and the goal is to create another shape by joining intersections. Often you need to split or delete the objects as part of processing. The way I implement this is to just use the C method. I have "previncontour", "nextincontour" and "previnresult", "nextinresult" pointer members. It's maybe not the best way of doing it, but it is simple and it works. However the code is C++, the objects are C++ classes rather than C structs.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-08-11 08:11 +0000 |
| Message-ID | <td2dk0$b8s$1@gioia.aioe.org> |
| In reply to | #85842 |
Manfred <noname@add.invalid> wrote: >> They /are/ very closely related languages - and most well-written C code >> can be turned into working C++ code with only a few changes (such as >> casting the result of calls to malloc - the casts are perfectly fine in >> C, but not idoimatic) and without a change in functionality. C is the >> base language on which C++ builds. > > I disagree. If you program in C++, i.e. you model a problem domain in > C++ from scratch, then you end up with a /very/ different result than > you would if you used C. Sometimes that's a good thing, sometimes not so much. There's a portion of C++ programmers (thankfully a relatively small portion in my experience) who think that anything that comes from C should be avoided if there's a C++ equivalent. Combine that with a lack of "know your tools" experience and it often results in code that's more inefficient and wasteful than it would need to be. My answer to that kind of mentality is always along the lines of, for example, "std::fopen() *is* C++. If it's standard C++, then it's C++. How can you even say that something supported by the C++ standard is 'not C++'? Know your tools. If it's the best tool for a particular task, then use it. It doesn't matter if it 'comes from C'. Who cares? There are tons of things in C++ that 'come from C'. Would you avoid using 'for' loops because they 'come from C'?"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-11 13:53 +0200 |
| Message-ID | <td2qk0$25mc3$1@dont-email.me> |
| In reply to | #85842 |
On 11/08/2022 04:25, Manfred wrote: > On 8/10/2022 10:13 AM, David Brown wrote: >> On 10/08/2022 02:25, Manfred wrote: >>> On 8/9/2022 11:07 AM, Ralf Fassel wrote: >>>> * Juha Nieminen <nospam@thanks.invalid> >>>> | I have never even heard of the "sketch" language so I can't comment. >>>> | If I had to make a completely wild guess it's probably some kind of >>>> | "higher-level" language with its own pros and cons compared to both >>>> | C and C++. >>>> >>>> On the Arduino, you usually only write the loop() (in C/C++) >>> >>> Note that the expression (C/C++) is considered a Bad Word nowadays. >> >> That wording implies that it was once a more acceptable term - I don't >> think anyone knowledgable in the two languages has been happy about >> conflating them. (It's fine to say "C /and/ C++", or "C /or/ C++".) > > I first heard of C++ in the late '80s, and it was described to me as: > "It's C, wherein structs can contain functions" (which sounded > immediately as a cool feature to me). > At that time C/C++ was not a Bad Word™, and I think this was justified, > for 2 main reasons: > - C++ was still relatively young, and the view of C++ as a mere > evolution of C was still diffuse. It would take some more time for C++ > programmers to gain more maturity and fully grasp the different > landscape of the two (see how many are still arguing that C code is C++ > code as well, even today) > - C++11 had not happened, yet. > > Today, none of the above is true. Yes, C++ was originally "C with classes", and it is not unreasonable to have used the term "C/C++" in those early days. I was thinking from the time when C++ became more established and standardised as a language of choice for a lot of types of development. But I take your point. > >> >> But a lot of people with less knowledge and experience do mix the >> language names, and think of them as variants or at least that C++ is >> just "C with some extra features". And the Arduino targets relative >> beginners, and goes out of its way to try to hide that kind of >> "complexity" from users. >> >>> The fact is that, even if in principle a C code fragment can be >>> compiled as C++ code, which might suggest the two languages are >>> closely related, in truth they are now very different languages, so >>> that they can't be mixed with each other. >> >> They /are/ very closely related languages - and most well-written C >> code can be turned into working C++ code with only a few changes (such >> as casting the result of calls to malloc - the casts are perfectly >> fine in C, but not idoimatic) and without a change in functionality. >> C is the base language on which C++ builds. > > I disagree. If you program in C++, i.e. you model a problem domain in > C++ from scratch, then you end up with a /very/ different result than > you would if you used C. > C++ is multi-paradigm. There is no single "C++ way" to model a task or program. It can be done in lots of different ways, depending on the task and the people working on it. The same applies to a fair extent to C - I have seen plenty of C programs that are object oriented in design, or event based, or have "actors" passing messages between them, or many other ways to organise the C code. It may be true that much of C programming is "plain imperative" - sets of functions that do things. But it is not restricted to that. Now, C++ certainly makes many other types of code structure and task modelling easier - more natural in the language, more efficient to write, more efficient at run-time, and better static checking. So when deciding how to attack a programming task, you might pick different approaches with C++ than with C, because of different balances in what fits well with the language. But equally you might not do so - if the problem lends itself to an imperative approach, you can do that in C++ too (and take advantage of better typing and other features that C does not have). >> >> And yes they /can/ be mixed, and they /are/ mixed. C++ is designed to >> be easy to mix with C, and incompatibilities are not made without good >> reason. Indeed, a good deal of the things people dislike about C++, >> or that are not "good modern language design", trace back to >> compatibility with C. > > What I mean by "mixed" here is in fact "confused". Nothing to do with > C++ calling C functions, and vice versa (however this might be > accomplished) > Well, in that sense the languages most certainly /can/ be "mixed" - it is done regularly. What you mean, I think, is that they should not be mixed - you feel a programmer should either think, model and design in a "C way" and program in C, or they should think, model and design in a "C++ way" and program in C++. While I think there is something in that argument, I don't see it as clear-cut or absolute. >> >> One area of programming where C and C++ are regularly mixed, is >> resource-constrained embedded systems. You can easily have a project >> with an RTOS in C90, some libraries in C99, application code in C++ of >> some sort, drivers in modern C - a full mix. Typically the only code >> that is compiled as both C and C++ is the C headers, but you sometimes >> get more complicated headers that provide different features depending >> on the language at the time. > > Well, I think you agree that a C++ application using a C library is not > really about mixing the two languages, don't you? > In embedded systems like this, everything is compiled together. Even if you don't touch the library source code itself, it's common to have hooks, user-defined macros, callbacks, and other connections so that the library code can absolutely be using the programmer's own code. Plenty of mixing goes on. >> >> >>> If you are writing code that compiles both as C and C++, then you are >>> in fact writing C code, not C++. >> >> That's just silly. You are, in fact, writing code that is C code >> /and/ C++ code. It might not be idiomatic code, but it is perfectly >> valid. > > Again, I disagree. And it is not silly. > > Let's take an example that makes some sense: you write some code that > involves a linked list (or any other container, for that matter) - > consider a C implementation and a C++ implementation. > > Are you seriously arguing that the C implementation is a C++ > implementation just as well? > (Please note that I /know/ that the C implementation would be legal C++ > code. I'm just saying that if you write such a C implementation in a C++ > program, then you are Doing It Wrong™) > I appreciate what you are saying - I just think it is blatantly incorrect to say the code is "C, not C++". What you mean is that it is not /idiomatic/ C++ code. It is not code written in a way that /you/ would write it in C++. C++ is used in a huge range of systems, with a huge range of different requirements. You think that if someone needed a dynamically resizeable list of items, in C++ they'd always reach for a std::vector while in C they'd write it themselves, and therefore the languages are different. When I program in C++, if I needed such a list I'd write it myself, far closer to what you think of as "C style". The standard library std::vector will not do what I need it to do, so I would not use it. But what I write would still be C++.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-08-13 04:13 +0200 |
| Message-ID | <td71c6$q2e$1@gioia.aioe.org> |
| In reply to | #85853 |
On 8/11/2022 1:53 PM, David Brown wrote: > On 11/08/2022 04:25, Manfred wrote: >> On 8/10/2022 10:13 AM, David Brown wrote: >>> On 10/08/2022 02:25, Manfred wrote: [...] >>> >>>> The fact is that, even if in principle a C code fragment can be >>>> compiled as C++ code, which might suggest the two languages are >>>> closely related, in truth they are now very different languages, so >>>> that they can't be mixed with each other. >>> >>> They /are/ very closely related languages - and most well-written C >>> code can be turned into working C++ code with only a few changes >>> (such as casting the result of calls to malloc - the casts are >>> perfectly fine in C, but not idoimatic) and without a change in >>> functionality. C is the base language on which C++ builds. >> >> I disagree. If you program in C++, i.e. you model a problem domain in >> C++ from scratch, then you end up with a /very/ different result than >> you would if you used C. >> > > C++ is multi-paradigm. There is no single "C++ way" to model a task or > program. It can be done in lots of different ways, depending on the > task and the people working on it. The same applies to a fair extent to > C - I have seen plenty of C programs that are object oriented in design, > or event based, or have "actors" passing messages between them, or many > other ways to organise the C code. It may be true that much of C > programming is "plain imperative" - sets of functions that do things. > But it is not restricted to that. > > Now, C++ certainly makes many other types of code structure and task > modelling easier - more natural in the language, more efficient to > write, more efficient at run-time, and better static checking. So when > deciding how to attack a programming task, you might pick different > approaches with C++ than with C, because of different balances in what > fits well with the language. But equally you might not do so - if the > problem lends itself to an imperative approach, you can do that in C++ > too (and take advantage of better typing and other features that C does > not have). > I think the distinction about object-orientation (whose popularity has dropped considerably in the last decade or so, btw) or imperative-ness of the languages is rather marginal. I agree that both languages can do with both just fine. But the difference I have i mind goes much farther than that, just trivial examples: - in C code you use macros everywhere, in C++ you tend to avoid them in favor of templates - in C you use raw pointers everywhere, in C++ you don't. - anywhere templates are the good choice (not because they are fancy or because they are C++-ish, but because they behave well for the task at hand), you'd use totally different constructs in C. - the list obviously can grow ad libitum, I just won't make it long here. > >>> >>> And yes they /can/ be mixed, and they /are/ mixed. C++ is designed >>> to be easy to mix with C, and incompatibilities are not made without >>> good reason. Indeed, a good deal of the things people dislike about >>> C++, or that are not "good modern language design", trace back to >>> compatibility with C. >> >> What I mean by "mixed" here is in fact "confused". Nothing to do with >> C++ calling C functions, and vice versa (however this might be >> accomplished) >> > > Well, in that sense the languages most certainly /can/ be "mixed" - it > is done regularly. What you mean, I think, is that they should not be > mixed - you feel a programmer should either think, model and design in a > "C way" and program in C, or they should think, model and design in a > "C++ way" and program in C++. > > While I think there is something in that argument, I don't see it as > clear-cut or absolute. > >>> >>> One area of programming where C and C++ are regularly mixed, is >>> resource-constrained embedded systems. You can easily have a project >>> with an RTOS in C90, some libraries in C99, application code in C++ >>> of some sort, drivers in modern C - a full mix. Typically the only >>> code that is compiled as both C and C++ is the C headers, but you >>> sometimes get more complicated headers that provide different >>> features depending on the language at the time. >> >> Well, I think you agree that a C++ application using a C library is >> not really about mixing the two languages, don't you? >> > > In embedded systems like this, everything is compiled together. Even if > you don't touch the library source code itself, it's common to have > hooks, user-defined macros, callbacks, and other connections so that the > library code can absolutely be using the programmer's own code. Plenty > of mixing goes on. > >>> >>> >>>> If you are writing code that compiles both as C and C++, then you >>>> are in fact writing C code, not C++. >>> >>> That's just silly. You are, in fact, writing code that is C code >>> /and/ C++ code. It might not be idiomatic code, but it is perfectly >>> valid. >> >> Again, I disagree. And it is not silly. >> >> Let's take an example that makes some sense: you write some code that >> involves a linked list (or any other container, for that matter) - >> consider a C implementation and a C++ implementation. >> >> Are you seriously arguing that the C implementation is a C++ >> implementation just as well? >> (Please note that I /know/ that the C implementation would be legal >> C++ code. I'm just saying that if you write such a C implementation in >> a C++ program, then you are Doing It Wrong™) >> > > I appreciate what you are saying - I just think it is blatantly > incorrect to say the code is "C, not C++". What you mean is that it is > not /idiomatic/ C++ code. It is not code written in a way that /you/ > would write it in C++. > > C++ is used in a huge range of systems, with a huge range of different > requirements. You think that if someone needed a dynamically resizeable > list of items, in C++ they'd always reach for a std::vector while in C > they'd write it themselves, and therefore the languages are different. > When I program in C++, if I needed such a list I'd write it myself, far > closer to what you think of as "C style". The standard library > std::vector will not do what I need it to do, so I would not use it. But > what I write would still be C++. It's not about idiomatic for the sake of itself, it's about the best solution you choose given the problem you have and the tools you have. If you write a C-style linked list in a C++ program, it's probably due to some specifics of the domain you are operating in, rather than a solution commonly adopted by C++ programmers. I have no doubt that it works best in your case, I don't believe that it works best in most cases. For one, there's a reason raw pointers are seldom used in C++ - not because it's the "C++ way", or it's any fancy. It just is because code works better this way. As I wrote elsethread, I am not saying that C++ is better than C in an absolute sense. I am convinced that the choice between the two languages depends entirely on the problem domain: in some cases C is better, in other it's the other way around. However, if C++ is chosen because it is a better solution for the problem at hand, then I see that, unsurprisingly, you end up writing code that is quite different from C. (btw, std::list still exists, it's not banned or anything)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-13 21:13 +0200 |
| Message-ID | <td8t45$2t69g$1@dont-email.me> |
| In reply to | #85903 |
On 13/08/2022 04:13, Manfred wrote:
> On 8/11/2022 1:53 PM, David Brown wrote:
>> On 11/08/2022 04:25, Manfred wrote:
>>> On 8/10/2022 10:13 AM, David Brown wrote:
>>>> On 10/08/2022 02:25, Manfred wrote:
> [...]
>
> I think the distinction about object-orientation (whose popularity has
> dropped considerably in the last decade or so, btw) or imperative-ness
> of the languages is rather marginal. I agree that both languages can do
> with both just fine.
> But the difference I have i mind goes much farther than that, just
> trivial examples:
> - in C code you use macros everywhere, in C++ you tend to avoid them in
> favor of templates
I don't use macros "everywhere" in C. I know some people do, but it is
certainly not necessary - in fact, my usage of macros in C and C++ is
mostly quite similar.
There is an old-fashioned style of C programming where you use "#define
NO_OF_THINGS 20" and use function-like macros for code size/speed
efficiency. But in modern C you'd use "static const int no_of_things =
20;", or "enum { no_of_things = 20 };" for the purpose, and static
inline functions instead of function-like macros.
Yes, there are things that you can do in C++ with templates that have a
rough equivalent in C that is only possible with macros. (There's also
lots you can do with C++ templates that has no sane equivalent in C.)
But they are not "everywhere". And they are mostly defined once, tucked
away - just like some of the more bizarre C++ definitions. And then
what does it matter? When you use "pow" in your code, it generally
doesn't matter if it is a C++ templated function, a C11 _Generic macro,
or a pre-C11 compiler-specific "magic" macro. (Well, it matters when
you want to make your own quarternion class and provide a power function
for that...)
> - in C you use raw pointers everywhere, in C++ you don't.
> - anywhere templates are the good choice (not because they are fancy or
> because they are C++-ish, but because they behave well for the task at
> hand), you'd use totally different constructs in C.
> - the list obviously can grow ad libitum, I just won't make it long here.
>
C++ has many more features than C. You can do more with the language,
and do things in a way that cannot (sanely) be done in C. I don't think
there are many that would argue differently, and there is little benefit
in listing some of these features.
But if you don't need such features - the code you have can be expressed
simply with functions and simple types - then code written in C++ does
not necessarily look much different from code written in C.
>>
>> I appreciate what you are saying - I just think it is blatantly
>> incorrect to say the code is "C, not C++". What you mean is that it
>> is not /idiomatic/ C++ code. It is not code written in a way that
>> /you/ would write it in C++.
>>
>> C++ is used in a huge range of systems, with a huge range of different
>> requirements. You think that if someone needed a dynamically
>> resizeable list of items, in C++ they'd always reach for a std::vector
>> while in C they'd write it themselves, and therefore the languages are
>> different. When I program in C++, if I needed such a list I'd write it
>> myself, far closer to what you think of as "C style". The standard
>> library std::vector will not do what I need it to do, so I would not
>> use it. But what I write would still be C++.
>
> It's not about idiomatic for the sake of itself, it's about the best
> solution you choose given the problem you have and the tools you have.
>
> If you write a C-style linked list in a C++ program, it's probably due
> to some specifics of the domain you are operating in, rather than a
> solution commonly adopted by C++ programmers.
Yes, I agree. My point is that if I do that, and write a C-style linked
list in C++, then I am writing C++, not C. It might be C++ code that is
structured almost identically to C code - it might even be possible to
compile it as C. But it is still C++.
> I have no doubt that it
> works best in your case, I don't believe that it works best in most cases.
Sure - again, I agree. I am merely objecting to categorical and
artificial divisions, declaring that a piece of code is "not C++" based
on a purely subjective idea of how C++ "should" be written.
> For one, there's a reason raw pointers are seldom used in C++ - not
> because it's the "C++ way", or it's any fancy. It just is because code
> works better this way.
>
I am not convinced on either point. First, I think raw pointers /are/
often used in C++ - much more often, probably, than they should be.
Secondly, I don't think the point is that smart pointers (or containers,
or other ways of managing indirect references) "work better" than raw
pointers. For the most part, they just make it easier to write correct
code, especially in the face of subtle issues such as exception safety.
And they make it harder to write incorrect code, since you can no
longer forget to delete your allocated objects. They don't work faster,
or give smaller code, or compile faster - nor do they let you do
something you could not do before using raw pointers, which are things I
would say would qualify as "work better". Perhaps this is just a
quibble about the wording, but I feel the important point of many C++
features is to improve code quality, safety and correctness above all else.
> As I wrote elsethread, I am not saying that C++ is better than C in an
> absolute sense. I am convinced that the choice between the two languages
> depends entirely on the problem domain: in some cases C is better, in
> other it's the other way around.
Agreed.
> However, if C++ is chosen because it is a better solution for the
> problem at hand, then I see that, unsurprisingly, you end up writing
> code that is quite different from C.
>
The choice of language is often not made on purely technical "it's a
better solution" grounds. But while I think that your argument is valid
for a lot of code, I don't think it /always/ applies - and I don't think
it is appropriate to categorise all C++ code that is structured like a C
solution as somehow not "real" C++.
> (btw, std::list still exists, it's not banned or anything)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-13 12:29 -0700 |
| Message-ID | <30afe66c-8f37-488e-bc5a-ad9d3aa211f1n@googlegroups.com> |
| In reply to | #85912 |
On Saturday, 13 August 2022 at 20:13:33 UTC+1, David Brown wrote:
> On 13/08/2022 04:13, Manfred wrote:
> > On 8/11/2022 1:53 PM, David Brown wrote:
> >> On 11/08/2022 04:25, Manfred wrote:
> >>> On 8/10/2022 10:13 AM, David Brown wrote:
> >>>> On 10/08/2022 02:25, Manfred wrote:
> > [...]
> >
> > I think the distinction about object-orientation (whose popularity has
> > dropped considerably in the last decade or so, btw) or imperative-ness
> > of the languages is rather marginal. I agree that both languages can do
> > with both just fine.
> > But the difference I have i mind goes much farther than that, just
> > trivial examples:
> > - in C code you use macros everywhere, in C++ you tend to avoid them in
> > favor of templates
> I don't use macros "everywhere" in C. I know some people do, but it is
> certainly not necessary - in fact, my usage of macros in C and C++ is
> mostly quite similar.
>
> There is an old-fashioned style of C programming where you use "#define
> NO_OF_THINGS 20" and use function-like macros for code size/speed
> efficiency. But in modern C you'd use "static const int no_of_things =
> 20;", or "enum { no_of_things = 20 };" for the purpose, and static
> inline functions instead of function-like macros.
>
Generally you'd do that to declare an array rather than use dynamic allocation.
But on most systems the speed improvement no longer justifies the
extra complexity and scope for error you introduce by having a hard limit.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-13 13:12 -0700 |
| Message-ID | <87a687ewcx.fsf@nosuchdomain.example.com> |
| In reply to | #85914 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 13 August 2022 at 20:13:33 UTC+1, David Brown wrote:
[...]
>> There is an old-fashioned style of C programming where you use "#define
>> NO_OF_THINGS 20" and use function-like macros for code size/speed
>> efficiency. But in modern C you'd use "static const int no_of_things =
>> 20;", or "enum { no_of_things = 20 };" for the purpose, and static
>> inline functions instead of function-like macros.
>>
> Generally you'd do that to declare an array rather than use dynamic allocation.
> But on most systems the speed improvement no longer justifies the
> extra complexity and scope for error you introduce by having a hard limit.
In C, `static const int no_of_things = 20;` doesn't make `no_of_things`
a constant expression. You can use it as an array length at block scope
*if* the implementation supports variable-length arrays (VLAs), which
were made optional in C11. This:
static const int no_of_things = 20;
int arr[no_of_things];
is illegal (a constraint violation) in C at file scope. (It works in
C++, but I'd use constexpr rather than const.)
enum { no_of_things = 20; } does give you a constant expression, but is
limited to type int. (C23 will change that.)
--
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-14 00:44 +0200 |
| Message-ID | <td99g2$2ua2j$1@dont-email.me> |
| In reply to | #85914 |
On 13/08/2022 21:29, Malcolm McLean wrote:
> On Saturday, 13 August 2022 at 20:13:33 UTC+1, David Brown wrote:
>> On 13/08/2022 04:13, Manfred wrote:
>>> On 8/11/2022 1:53 PM, David Brown wrote:
>>>> On 11/08/2022 04:25, Manfred wrote:
>>>>> On 8/10/2022 10:13 AM, David Brown wrote:
>>>>>> On 10/08/2022 02:25, Manfred wrote:
>>> [...]
>>>
>>> I think the distinction about object-orientation (whose popularity has
>>> dropped considerably in the last decade or so, btw) or imperative-ness
>>> of the languages is rather marginal. I agree that both languages can do
>>> with both just fine.
>>> But the difference I have i mind goes much farther than that, just
>>> trivial examples:
>>> - in C code you use macros everywhere, in C++ you tend to avoid them in
>>> favor of templates
>> I don't use macros "everywhere" in C. I know some people do, but it is
>> certainly not necessary - in fact, my usage of macros in C and C++ is
>> mostly quite similar.
>>
>> There is an old-fashioned style of C programming where you use "#define
>> NO_OF_THINGS 20" and use function-like macros for code size/speed
>> efficiency. But in modern C you'd use "static const int no_of_things =
>> 20;", or "enum { no_of_things = 20 };" for the purpose, and static
>> inline functions instead of function-like macros.
>>
> Generally you'd do that to declare an array rather than use dynamic allocation.
Do what? The thing I said is old-fashioned, or the two better (in some
ways) alternatives?
As Keith says, you can't use a "static const int" for a static array
size in C. But you can use an enumeration constant for array sizes, so
that is what I do. (Sometimes #define'd macros are unavoidable for this
kind of use in C, if you need the value to be calculated at compile time
- even if the result is clearly known at compile-time, it is still not a
"constant" by the language rules. C++ is much stronger there.)
> But on most systems the speed improvement no longer justifies the
> extra complexity and scope for error you introduce by having a hard limit.
>
I think you are extrapolating from your own code and assuming it always
applies. Speed differences may or may not be relevant, depending on the
platform and what you are doing with the array. But used correctly and
appropriately, a hard limit is much simpler and has far less scope for
error - a statically declared array of fixed size carries much more
information for error checking (by the compiler, and by code) than a
pointer to a dynamically allocated array.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web