Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70089 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2019-11-28 12:19 -0800 |
| Last post | 2020-02-18 18:46 +0100 |
| Articles | 20 on this page of 113 — 20 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:19 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-29 00:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 09:15 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-29 10:58 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 12:49 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-07 07:53 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-12-07 08:22 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:44 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-10 23:44 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:08 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:42 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:09 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:14 -0800
Re: two's complement idea Daniel <danielaparker@gmail.com> - 2020-01-21 13:08 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-22 00:07 -0500
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-21 23:21 -0800
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 01:51 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-22 11:28 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 11:52 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-22 04:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:19 -0700
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:07 -0700
Re: two's complement idea boltar@nowhere.org - 2020-01-21 16:44 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-21 20:01 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-22 11:26 +0000
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2020-01-22 20:04 +0100
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 11:30 -0800
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 19:57 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:24 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-24 07:29 +1300
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-23 10:09 +0100
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:29 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:08 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-24 12:27 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:06 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 10:07 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 11:36 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-24 17:34 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2020-01-24 17:57 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 12:19 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 14:19 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 14:11 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:26 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 17:35 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 22:27 +0200
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:21 -0500
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 11:06 +1300
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 22:12 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:24 -0500
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 09:04 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 04:15 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 19:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 00:05 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 01:19 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 19:50 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 11:57 +0000
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-25 13:42 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 14:58 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:58 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:34 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 12:41 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 16:08 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 02:20 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-27 15:03 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 06:44 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-06 10:18 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:05 -0700
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 20:03 +0300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:37 -0700
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:45 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 19:56 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 09:49 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 21:33 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:00 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 22:23 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:46 +1300
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 10:55 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-26 03:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:28 -0800
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 22:22 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-25 18:24 -0500
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 12:54 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 12:44 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 14:58 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 14:53 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 19:10 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:20 -0600
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 20:51 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 21:02 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-26 19:06 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 18:50 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 14:18 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-27 22:13 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 21:38 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 19:37 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-27 19:15 -0800
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-28 11:45 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 16:31 +1300
Re: two's complement idea Manfred <noname@add.invalid> - 2020-01-26 18:50 +0100
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-26 18:57 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 20:46 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:14 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 22:15 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 21:06 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-28 13:08 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:50 -0800
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 08:21 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:12 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 07:48 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-18 18:46 +0100
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 07:19 -0700 |
| Message-ID | <86eet66kcj.fsf@linuxsc.com> |
| In reply to | #71485 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Tuesday, January 21, 2020 at 5:09:42 AM UTC-5, Tim Rentsch wrote: > >> Tiib writes: >> >>> On Tuesday, 14 January 2020 17:08:45 UTC+2, Tim Rentsch wrote: >>> >>>> Tiib writes: >>>> >>>>> On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: >>>> >>>> [...] >>>> >>>>>> Your comments are not really about macros but about how various >>>>>> people misuse macros. Any language feature can be misused. >>>>>> My question is about macros, not about people who misuse them. >>>>> >>>>> Programmer who is ordered to write software for platform where he >>>>> can not avoid wasting workdays into dealing with that misuse of >>>>> feature by platform vendors still can not avoid disliking the >>>>> feature that allows such annoying misuses. Especially in places >>>>> where usage of inline functions, templates or constants would >>>>> be as simple but would not cause the issues existence of whose >>>>> you dismiss. >>>> >>>> That may be interesting but it doesn't address the question >>>> I was asking. >>> >>> Your question was "Why do C++ fans hate the C preprocessor so much?". >> >> Yes, and your responses don't speak to that question. They do >> explain why you don't like how some people use macros, but >> nothing about the macros themselves. My question is about >> reactions to the preprocessor (and macros in particular), not >> about reactions to how people might misuse it. Do you not >> understand the difference? > > Do you don't understand that he considers that the way they invite > misuse, might be precisely the thing that he finds objectionable about > macros? [...] Please understand this: Your understandings are not my understandings. Your motivations are not my motivations. Your goals are not my goals. Your assumptions about meaning and communication do not match my own. I have the impression that your question is meant to be rhetorical. Mine was not: it was asked as just a question, nothing more.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-02 08:07 -0700 |
| Message-ID | <4d96f1dd-3d0e-493f-85d3-2229b28ebd63@googlegroups.com> |
| In reply to | #72753 |
On Thursday, April 2, 2020 at 10:19:50 AM UTC-4, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > > On Tuesday, January 21, 2020 at 5:09:42 AM UTC-5, Tim Rentsch wrote: ... > >> Yes, and your responses don't speak to that question. They do > >> explain why you don't like how some people use macros, but > >> nothing about the macros themselves. My question is about > >> reactions to the preprocessor (and macros in particular), not > >> about reactions to how people might misuse it. Do you not > >> understand the difference? > > > > Do you don't understand that he considers that the way they invite > > misuse, might be precisely the thing that he finds objectionable about > > macros? [...] > > Please understand this: Your understandings are not my understandings. That is quite clear. You appear to misunderstand a great many things. > Your motivations are not my motivations. Certainly not - I'd be appalled to have motivations that would lead me to behave the way that you do! > I have the impression that your question is meant to be rhetorical. Not quite. Your rejection of his response as an answer to your question would make more sense if you had been unaware of the point I was raising, and I'm sincerely interested in knowing whether that was the case. I'd also be interested in knowing whether you might have rejected it as invalid or irrelevant, and if so, why. In a sense, it was a rhetorical question - I would have hoped for a meaningful response, but I was not surprised by your failure to give one. > Mine was not: it was asked as just a question, nothing more. Yes, but you claimed incorrectly that he had not answered your question, implying that you failed to understand how his response qualifies as an answer to your question. I was merely explaining that to you (without, to be fair, any expectation that you would understand my explanation).
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-21 16:44 +0000 |
| Message-ID | <r079pt$1ij1$1@gioia.aioe.org> |
| In reply to | #71481 |
On Tue, 21 Jan 2020 02:09:32 -0800 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Tiib writes: > >> On Tuesday, 14 January 2020 17:08:45 UTC+2, Tim Rentsch wrote: >> >>> Tiib writes: >>> >>>> On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: >>> >>> [...] >>> >>>>> Your comments are not really about macros but about how various >>>>> people misuse macros. Any language feature can be misused. >>>>> My question is about macros, not about people who misuse them. >>>> >>>> Programmer who is ordered to write software for platform where he >>>> can not avoid wasting workdays into dealing with that misuse of >>>> feature by platform vendors still can not avoid disliking the >>>> feature that allows such annoying misuses. Especially in places >>>> where usage of inline functions, templates or constants would >>>> be as simple but would not cause the issues existence of whose >>>> you dismiss. >>> >>> That may be interesting but it doesn't address the question >>> I was asking. >> >> Your question was "Why do C++ fans hate the C preprocessor so much?". > >Yes, and your responses don't speak to that question. They do >explain why you don't like how some people use macros, but >nothing about the macros themselves. My question is about >reactions to the preprocessor (and macros in particular), not >about reactions to how people might misuse it. Do you not >understand the difference? The sort of developers who hate macros are the ones who've never had to do cross platform development.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-21 20:01 +0000 |
| Message-ID | <slrnr2em4s.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71491 |
On Tue, 2020-01-21, boltar@nowhere.org wrote: ... > The sort of developers who hate macros are the ones who've never had to do > cross platform development. How about those of us who had to do it, and hated it? By the way, even for that scenario, the preprocessor is overused. See the "#ifdefs considered harmful" paper. /Jorgen PS. I don't hate macros. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-22 11:26 +0000 |
| Message-ID | <r09bhj$1cbg$1@gioia.aioe.org> |
| In reply to | #71494 |
On 21 Jan 2020 20:01:32 GMT Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >On Tue, 2020-01-21, boltar@nowhere.org wrote: >.... >> The sort of developers who hate macros are the ones who've never had to do >> cross platform development. > >How about those of us who had to do it, and hated it? > >By the way, even for that scenario, the preprocessor is overused. How? If an API call isn't supported on a given platform you have no choice but to ifdef. >See the "#ifdefs considered harmful" paper. I have paint to watch drying instead. No doubt it comes from the same ivory tower that claims gotos should never be used.
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2020-01-22 20:04 +0100 |
| Message-ID | <r0a6k9$569$1@dont-email.me> |
| In reply to | #71507 |
Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: > I have paint to watch drying instead. Nice idiom > No doubt it comes from the same ivory > tower that claims gotos should never be used. > Ivory tower, for sure? We have while, for, break, continue, return, and exceptions. All these compile to some sort of goto in machine code. What good reasons are left for a literal goto? I can see it in C for error handling (because it lacks exceptions) - in C++ there is hardly a good reason IMHO. Christian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-22 11:30 -0800 |
| Message-ID | <87r1zr70gm.fsf@nosuchdomain.example.com> |
| In reply to | #71519 |
Christian Gollwitzer <auriocus@gmx.de> writes:
[...]
> What good reasons are left for a literal goto? I can see it in C for
> error handling (because it lacks exceptions) - in C++ there is hardly
> a good reason IMHO.
https://softwareengineering.stackexchange.com/a/133523/33478
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2020-01-22 19:57 +0000 |
| Message-ID | <20200122195749.5a81e70a52048598b4c1d605@cvine--nospam--.freeserve.co.uk> |
| In reply to | #71519 |
On Wed, 22 Jan 2020 20:04:58 +0100 Christian Gollwitzer <auriocus@gmx.de> wrote: > Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: > > I have paint to watch drying instead. > Nice idiom > > > No doubt it comes from the same ivory > > tower that claims gotos should never be used. > > > > Ivory tower, for sure? We have while, for, break, continue, return, and > exceptions. All these compile to some sort of goto in machine code. > > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. It is a better solution than exceptions for breaking out of a nested loop, usually.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-23 10:03 +1300 |
| Message-ID | <h8rrl4F25s3U2@mid.individual.net> |
| In reply to | #71522 |
On 23/01/2020 08:57, Chris Vine wrote: > On Wed, 22 Jan 2020 20:04:58 +0100 > Christian Gollwitzer <auriocus@gmx.de> wrote: >> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>> I have paint to watch drying instead. >> Nice idiom >> >>> No doubt it comes from the same ivory >>> tower that claims gotos should never be used. >>> >> >> Ivory tower, for sure? We have while, for, break, continue, return, and >> exceptions. All these compile to some sort of goto in machine code. >> >> What good reasons are left for a literal goto? I can see it in C for >> error handling (because it lacks exceptions) - in C++ there is hardly a >> good reason IMHO. > > It is a better solution than exceptions for breaking out of a nested > loop, usually. Extracting the loop is better still! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-23 09:24 +0000 |
| Message-ID | <r0bop3$12pk$1@gioia.aioe.org> |
| In reply to | #71524 |
On Thu, 23 Jan 2020 10:03:32 +1300 Ian Collins <ian-news@hotmail.com> wrote: >On 23/01/2020 08:57, Chris Vine wrote: >> On Wed, 22 Jan 2020 20:04:58 +0100 >> Christian Gollwitzer <auriocus@gmx.de> wrote: >>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>> I have paint to watch drying instead. >>> Nice idiom >>> >>>> No doubt it comes from the same ivory >>>> tower that claims gotos should never be used. >>>> >>> >>> Ivory tower, for sure? We have while, for, break, continue, return, and >>> exceptions. All these compile to some sort of goto in machine code. >>> >>> What good reasons are left for a literal goto? I can see it in C for >>> error handling (because it lacks exceptions) - in C++ there is hardly a >>> good reason IMHO. >> >> It is a better solution than exceptions for breaking out of a nested >> loop, usually. > >Extracting the loop is better still! Good luck with that.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-24 07:29 +1300 |
| Message-ID | <h8u6vcF25s3U4@mid.individual.net> |
| In reply to | #71528 |
On 23/01/2020 22:24, boltar@nowhere.org wrote: > On Thu, 23 Jan 2020 10:03:32 +1300 > Ian Collins <ian-news@hotmail.com> wrote: >> On 23/01/2020 08:57, Chris Vine wrote: >>> On Wed, 22 Jan 2020 20:04:58 +0100 >>> Christian Gollwitzer <auriocus@gmx.de> wrote: >>>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>>> I have paint to watch drying instead. >>>> Nice idiom >>>> >>>>> No doubt it comes from the same ivory >>>>> tower that claims gotos should never be used. >>>>> >>>> >>>> Ivory tower, for sure? We have while, for, break, continue, return, and >>>> exceptions. All these compile to some sort of goto in machine code. >>>> >>>> What good reasons are left for a literal goto? I can see it in C for >>>> error handling (because it lacks exceptions) - in C++ there is hardly a >>>> good reason IMHO. >>> >>> It is a better solution than exceptions for breaking out of a nested >>> loop, usually. >> >> Extracting the loop is better still! > > Good luck with that. Thank you.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-23 10:03 +1300 |
| Message-ID | <h8rrl2F25s3U1@mid.individual.net> |
| In reply to | #71519 |
On 23/01/2020 08:04, Christian Gollwitzer wrote: > Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >> I have paint to watch drying instead. > Nice idiom > >> No doubt it comes from the same ivory >> tower that claims gotos should never be used. >> > > Ivory tower, for sure? We have while, for, break, continue, return, and > exceptions. All these compile to some sort of goto in machine code. > > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. With the help of clang-tidy warnings, we have finally cleansed our decades old code base of goto :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@KVI.nl> |
|---|---|
| Date | 2020-01-23 10:09 +0100 |
| Message-ID | <r0bnrq$t9g$1@gioia.aioe.org> |
| In reply to | #71519 |
Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: > Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >> I have paint to watch drying instead. > Nice idiom > >> No doubt it comes from the same ivory >> tower that claims gotos should never be used. >> > > Ivory tower, for sure? We have while, for, break, continue, return, and > exceptions. All these compile to some sort of goto in machine code. > > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. > > Christian Maybe to exit nested loops? I wonder why C++ does not have named loops, so that in a break it would be possible to specify which loop to exit.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-23 09:29 +0000 |
| Message-ID | <r0bp1g$148e$1@gioia.aioe.org> |
| In reply to | #71526 |
On Thu, 23 Jan 2020 10:09:15 +0100 "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote: >Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: >> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>> I have paint to watch drying instead. >> Nice idiom >> >>> No doubt it comes from the same ivory >>> tower that claims gotos should never be used. >>> >> >> Ivory tower, for sure? We have while, for, break, continue, return, and >> exceptions. All these compile to some sort of goto in machine code. >> >> What good reasons are left for a literal goto? I can see it in C for >> error handling (because it lacks exceptions) - in C++ there is hardly a >> good reason IMHO. >> >> Christian > >Maybe to exit nested loops? I wonder why C++ does not have named loops, >so that in a break it would be possible to specify which loop to exit. That would be a much more useful addition to the language than the endless edge case rubbish (lambda capture initialisation, digit seperators, auto returns) and pointless STL classes and defs (optional, variant, byte, any, data()) that they've thrown in since 2011.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-24 01:08 +0000 |
| Message-ID | <KsrWF.100713$UPz1.20603@fx15.am4> |
| In reply to | #71529 |
On 23/01/2020 09:29, boltar@nowhere.org wrote: > On Thu, 23 Jan 2020 10:09:15 +0100 > "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote: >> Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: >>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>> I have paint to watch drying instead. >>> Nice idiom >>> >>>> No doubt it comes from the same ivory >>>> tower that claims gotos should never be used. >>>> >>> >>> Ivory tower, for sure? We have while, for, break, continue, return, and >>> exceptions. All these compile to some sort of goto in machine code. >>> >>> What good reasons are left for a literal goto? I can see it in C for >>> error handling (because it lacks exceptions) - in C++ there is hardly a >>> good reason IMHO. >>> >>> Â Â Â Â Christian >> >> Maybe to exit nested loops? I wonder why C++ does not have named loops, >> so that in a break it would be possible to specify which loop to exit. > > That would be a much more useful addition to the language than the endless edge > case rubbish (lambda capture initialisation, digit seperators, auto returns) > and pointless STL classes and defs (optional, variant, byte, any, data()) > that they've thrown in since 2011. > Digit separators are genuinely useful (and also incredibly simple to implement, compared to the rest of that lot). What's the problem with them?
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-24 12:27 +0000 |
| Message-ID | <r0enql$1krl$1@gioia.aioe.org> |
| In reply to | #71534 |
On Fri, 24 Jan 2020 01:08:54 +0000 Bart <bc@freeuk.com> wrote: >On 23/01/2020 09:29, boltar@nowhere.org wrote: >> On Thu, 23 Jan 2020 10:09:15 +0100 >> "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote: >>> Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: >>>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>>> I have paint to watch drying instead. >>>> Nice idiom >>>> >>>>> No doubt it comes from the same ivory >>>>> tower that claims gotos should never be used. >>>>> >>>> >>>> Ivory tower, for sure? We have while, for, break, continue, return, and >>>> exceptions. All these compile to some sort of goto in machine code. >>>> >>>> What good reasons are left for a literal goto? I can see it in C for >>>> error handling (because it lacks exceptions) - in C++ there is hardly a >>>> good reason IMHO. >>>> >>>> Â Â Â Â Christian >>> >>> Maybe to exit nested loops? I wonder why C++ does not have named loops, >>> so that in a break it would be possible to specify which loop to exit. >> >> That would be a much more useful addition to the language than the endless >edge >> case rubbish (lambda capture initialisation, digit seperators, auto returns) >> and pointless STL classes and defs (optional, variant, byte, any, data()) >> that they've thrown in since 2011. >> > >Digit separators are genuinely useful (and also incredibly simple to >implement, compared to the rest of that lot). What's the problem with them? Well ok, I'm sure they can make the code a little bit more readable. But in the scheme of things that it would be nice to have in C++ they were hardly top of the list whereas named loops is an extremely useful language construct and should be easy to implement.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-24 01:06 +0000 |
| Message-ID | <KqrWF.100712$UPz1.15399@fx15.am4> |
| In reply to | #71519 |
On 22/01/2020 19:04, Christian Gollwitzer wrote:
> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org:
>> I have paint to watch drying instead.
> Nice idiom
>
>> No doubt it comes from the same ivory
>> tower that claims gotos should never be used.
>>
>
> Ivory tower, for sure? We have while, for, break, continue, return, and
> exceptions. All these compile to some sort of goto in machine code.
>
> What good reasons are left for a literal goto? I can see it in C for
> error handling (because it lacks exceptions) - in C++ there is hardly a
> good reason IMHO.
>
(Copied from a post elsewhere)
I still use it [goto], although rarely. For example:
For temporary code, until it can be done properly
To temporarily by-pass code or to cut to the action for debugging
When translating an algorithm or code from another language, that
itself uses goto
When using this language as a target language for another, and I
need goto to emulate the control flow of a statement that has no
direct equivalent
To implement state machines
Via inline assembly, to deal with error recovery across functions
(although it's a long time since I used that); but also to implement
threaded code in interpreters
Or just when I can't be bothered with too-convoluted code, and goto
is the fastest and simplest way of expressing my intent
Even with this, I think my incidence of using goto is once per 400 lines
or so, so 'spaghetti code' is unlikely.
I would not design a new language without goto.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2020-01-24 10:07 +0100 |
| Message-ID | <h8vqe4Fiqq9U1@mid.individual.net> |
| In reply to | #71533 |
On 2020-01-24 at 02:06, Bart wrote:
> On 22/01/2020 19:04, Christian Gollwitzer wrote:
>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org:
>>> I have paint to watch drying instead.
>> Nice idiom
>>
>>> No doubt it comes from the same ivory
>>> tower that claims gotos should never be used.
>>>
>>
>> Ivory tower, for sure? We have while, for, break, continue, return,
>> and exceptions. All these compile to some sort of goto in machine code.
>>
>> What good reasons are left for a literal goto? I can see it in C for
>> error handling (because it lacks exceptions) - in C++ there is hardly
>> a good reason IMHO.
>>
>
> (Copied from a post elsewhere)
>
> I still use it [goto], although rarely. For example:
>
> For temporary code, until it can be done properly
>
> To temporarily by-pass code or to cut to the action for debugging
>
> When translating an algorithm or code from another language, that
> itself uses goto
>
> When using this language as a target language for another, and I
> need goto to emulate the control flow of a statement that has no
> direct equivalent
>
> To implement state machines
>
> Via inline assembly, to deal with error recovery across functions
> (although it's a long time since I used that); but also to implement
> threaded code in interpreters
>
> Or just when I can't be bothered with too-convoluted code, and goto
> is the fastest and simplest way of expressing my intent
>
> Even with this, I think my incidence of using goto is once per 400 lines
> or so, so 'spaghetti code' is unlikely.
>
I find that an extremely high use of goto. Would rather expect once in a
million lines, or so.
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-24 11:36 +0200 |
| Message-ID | <r0edqo$gmo$1@dont-email.me> |
| In reply to | #71537 |
On 24.01.2020 11:07, Bo Persson wrote: > On 2020-01-24 at 02:06, Bart wrote: >> Even with this, I think my incidence of using goto is once per 400 >> lines or so, so 'spaghetti code' is unlikely. >> > > I find that an extremely high use of goto. Would rather expect once in a > million lines, or so. FWIW, I just grepped our C++ codebase (600 KLOC) for goto, it appears there is one goto per 8000 lines. This is a bit surprising, I did not expect so many gotos.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-24 17:34 -0800 |
| Message-ID | <acfc347c-239e-4916-9ce8-8489d173018e@googlegroups.com> |
| In reply to | #71539 |
On Friday, 24 January 2020 11:36:39 UTC+2, Paavo Helde wrote: > On 24.01.2020 11:07, Bo Persson wrote: > > On 2020-01-24 at 02:06, Bart wrote: > >> Even with this, I think my incidence of using goto is once per 400 > >> lines or so, so 'spaghetti code' is unlikely. > >> > > > > I find that an extremely high use of goto. Would rather expect once in a > > million lines, or so. > > FWIW, I just grepped our C++ codebase (600 KLOC) for goto, it appears > there is one goto per 8000 lines. This is a bit surprising, I did not > expect so many gotos. Often it just is not worth to refactor code to get rid of gotos. Real programmer can write fortran-program in any programming language and gotos are smallest of issues with such.
[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