Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #72243 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2020-03-13 00:13 +0100 |
| Last post | 2020-03-21 01:43 -0700 |
| Articles | 20 on this page of 122 — 17 participants |
Back to article view | Back to comp.lang.c++
Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-13 00:13 +0100
Re: Structured binding considered harmful Maciej Sobczak <see.my.homepage@gmail.com> - 2020-03-13 00:46 -0700
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-14 09:10 +0100
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-13 09:40 -0700
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-14 09:05 +0100
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-14 03:19 -0700
Re: Structured binding considered harmful Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-15 11:08 +0000
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-15 09:46 -0700
Re: Structured binding considered harmful "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-03-15 19:27 +0100
Re: Structured binding considered harmful Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-15 15:15 -0700
Re: Structured binding considered harmful "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-03-16 05:23 +0100
Re: Structured binding considered harmful "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-03-16 05:54 +0100
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-16 00:20 -0700
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-13 23:08 -0400
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-14 08:59 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-14 10:09 -0400
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-14 18:32 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-14 18:33 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-15 17:50 +0100
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-16 00:11 +0100
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-16 05:24 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-16 06:46 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-16 12:52 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-16 08:32 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-16 13:51 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-16 20:06 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-17 06:37 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-17 07:17 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-17 18:37 +0100
Re: Structured binding considered harmful "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-03-17 18:50 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 06:30 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 11:38 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 08:17 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 13:19 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 08:31 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 14:15 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 10:13 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 15:45 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 11:36 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 17:59 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 13:18 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 18:27 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 14:41 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 19:46 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 19:46 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-19 06:41 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-19 07:02 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-19 12:41 +0100
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-19 06:10 -0700
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-19 14:15 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-19 19:23 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-20 09:18 +0100
Re: Structured binding considered harmful James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-20 05:31 -0700
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-20 13:40 +0100
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-20 08:50 -0700
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-20 09:30 -0700
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-20 10:13 -0700
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-20 10:36 -0700
Re: Structured binding considered harmful Ian Collins <ian-news@hotmail.com> - 2020-03-21 12:06 +1300
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-20 16:37 -0700
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-20 17:17 -0700
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-21 10:09 -0700
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-21 11:21 -0700
Re: Structured binding considered harmful Öö Tiib <ootiib@hot.ee> - 2020-03-21 13:09 -0700
Re: Structured binding considered harmful Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-21 22:33 +0000
Re: Structured binding considered harmful Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-20 17:30 +0000
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-20 10:49 -0700
Re: Structured binding considered harmful Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-20 18:47 +0000
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-20 17:41 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-20 18:06 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-21 06:31 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-21 09:50 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-21 14:59 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-21 10:42 -0400
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-21 16:09 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-21 11:12 -0400
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-20 18:05 -0400
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-20 15:57 -0700
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-20 23:23 -0400
Re: Structured binding considered harmful Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-20 21:08 -0700
Re: Structured binding considered harmful Ralf Goertz <me@myprovider.invalid> - 2020-03-21 08:24 +0100
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-21 01:36 -0700
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-21 06:30 +0100
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-21 09:51 -0400
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-22 13:22 +0100
Re: Structured binding considered harmful Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-22 13:24 +0000
Re: Structured binding considered harmful James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 06:32 -0700
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-22 07:59 -0700
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-22 13:02 -0400
Re: Structured binding considered harmful Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-22 17:09 +0000
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-22 13:35 -0400
Re: Structured binding considered harmful Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-22 17:54 +0000
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-22 17:19 -0400
Re: Structured binding considered harmful Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-22 21:46 +0000
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-22 19:06 -0400
Re: Structured binding considered harmful danielaparker@gmail.com - 2020-03-22 17:11 -0700
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-22 22:16 -0400
Re: Structured binding considered harmful Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-03-25 20:38 +0000
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-25 20:01 -0400
Re: Structured binding considered harmful danielaparker@gmail.com - 2020-03-22 10:58 -0700
Re: Structured binding considered harmful Ian Collins <ian-news@hotmail.com> - 2020-03-23 07:41 +1300
Re: Structured binding considered harmful James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 15:01 -0400
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-22 10:24 -0400
Re: Structured binding considered harmful James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-20 20:15 -0700
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-21 08:32 +0100
Re: Structured binding considered harmful David Brown <david.brown@hesbynett.no> - 2020-03-21 11:27 +0100
Re: Structured binding considered harmful Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-03-21 13:34 +0000
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-21 07:11 -0700
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-21 10:45 -0400
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-21 08:03 -0700
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-19 08:24 -0700
Re: Structured binding considered harmful Ian Collins <ian-news@hotmail.com> - 2020-03-19 09:05 +1300
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-18 19:47 -0400
Re: Structured binding considered harmful James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-18 11:43 -0700
Re: Structured binding considered harmful Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-18 19:48 +0100
Re: Structured binding considered harmful James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-18 12:37 -0700
Re: Structured binding considered harmful jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-16 16:11 +0100
Re: Structured binding considered harmful Ian Collins <ian-news@hotmail.com> - 2020-03-17 08:17 +1300
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-16 13:12 -0700
Re: Structured binding considered harmful Sam <sam@email-scan.com> - 2020-03-16 20:13 -0400
Re: Structured binding considered harmful Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-17 19:46 +0000
Re: Structured binding considered harmful Daniel <danielaparker@gmail.com> - 2020-03-21 01:43 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-03-23 07:41 +1300 |
| Message-ID | <hdppqgF9v62U4@mid.individual.net> |
| In reply to | #72470 |
On 23/03/2020 03:59, Daniel wrote: > On Sunday, March 22, 2020 at 9:32:53 AM UTC-4, James Kuyper wrote: >> >> Keep in mind that Bonita has no better manners than Sam. > > False on this thread. Bonita's replies to Sam are restrained and respectful > and her point is justifiable. Sipping attributions is never respectful. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-03-22 15:01 -0400 |
| Message-ID | <r58cmv$vaa$1@dont-email.me> |
| In reply to | #72470 |
On 3/22/20 10:59 AM, Daniel wrote: > On Sunday, March 22, 2020 at 9:32:53 AM UTC-4, James Kuyper wrote: >> On Sunday, March 22, 2020 at 8:22:22 AM UTC-4, jacobnavia wrote: ... >>> Your tone. That's right, that hideous tone you use. That overflowing >>> self esteem that transpires "You are an idiot, a wanna-be. I am a real >>> expert", that complete lack of elementary manners, that's what makes you >>> so nauseating. ... >> Keep in mind that Bonita has no better manners than Sam. > > False on this thread. Bonita's replies to Sam are restrained and respectful > and her point is justifiable. Bonita routinely insults anyone who disagrees with her, calling them incompetent. If anyone dares to claim to have actual experience disagreeing with what she considers to be possible, she routinely responds by calling them liars. She often does these things instead of responding to the points they raised. This wouldn't be so bothersome if she restricted such activities to people who were actually incompetent or liars. However, many of the people she's accused of incompetence have demonstrated more competence in this newsgroup than she ever has, and many of the things that she says have to be lies because they don't fit her understanding of how things work are things I have observed with my own eyes. And, as Ian rightly pointed out, there's nothing respectful about quoting other people's words without properly attributing them. >> He's only claiming to be able to do what she says cannot be done, and that > claim implies nothing more than ordinary C++ programming skills. > > I find this response even more depressing than Sams'. Even > Sam concedes he is trolling Bonita. His "claim", to the extent he is making > one, is wrong. The point of contention is whether whether auto can always be > used safely, Some people are arguing that auto can't always be used safely - but with no one disagreeing with them on that point, it can't accurately be described as a point of contention. What is being claimed is that auto can often be used safely - what it conceals about the type it stands in for is often something that there is no need to know about, at least, not if the code actually compiles without relevant warnings or error messages.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-22 10:24 -0400 |
| Message-ID | <cone.1584887043.213674.33341.1004@monster.email-scan.com> |
| In reply to | #72466 |
[Multipart message — attachments visible in raw view] — view raw
jacobnavia writes: > Your tone. That's right, that hideous tone you use. That overflowing self > esteem that transpires "You are an idiot, a wanna-be. I am a real expert", > that complete lack of elementary manners, that's what makes you so > nauseating. Doing a mental inventory, I can recall very, very few instances where I found someone's contributions to Usenet history to be unworthy of my partake. And the response from me, in those cases, was strictly limited to adjusting my filter. But without making a grandiose announcement of that fact, with pomp and circumstance. The need to do so, that I observe in others, betrays their own vanities, egos and delusions of self-grandeur and self-importance. Which far exceeds mine's. > But surely you will not understand that. To do that, you would have to know > less of C++ and more about manners. No shit? Screw that.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-03-20 20:15 -0700 |
| Message-ID | <a64fb1bc-933e-4395-8f94-dd96f033ce16@googlegroups.com> |
| In reply to | #72416 |
On Friday, March 20, 2020 at 8:40:21 AM UTC-4, Bonita Montero wrote: > > If know C++, you often don't need to know the exact type, and > > therefore don't need to read the part where the container was > > defined or declared. ... > > Usually not. "Often" is fully compatible with "usually not". A situation that comes up 30% of the time could still be described as coming up fairly often, despite not usually coming up. So that doesn't constitute a disagreement.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-21 08:32 +0100 |
| Message-ID | <r54ftg$k03$1@dont-email.me> |
| In reply to | #72431 |
Le 21/03/2020 à 04:15, James Kuyper a écrit : > On Friday, March 20, 2020 at 8:40:21 AM UTC-4, Bonita Montero wrote: >>> If know C++, you often don't need to know the exact type, and >>> therefore don't need to read the part where the container was >>> defined or declared. ... >> >> Usually not. > > "Often" is fully compatible with "usually not". A situation that > comes up 30% of the time could still be described as coming up > fairly often, despite not usually coming up. So that doesn't > constitute a disagreement. > That is often true, sometimes. :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-21 11:27 +0100 |
| Message-ID | <r54q7c$jh4$1@dont-email.me> |
| In reply to | #72437 |
On 21/03/2020 08:32, jacobnavia wrote: > Le 21/03/2020 à 04:15, James Kuyper a écrit : >> On Friday, March 20, 2020 at 8:40:21 AM UTC-4, Bonita Montero wrote: >>>> If know C++, you often don't need to know the exact type, and >>>> therefore don't need to read the part where the container was >>>> defined or declared. ... >>> >>> Usually not. >> >> "Often" is fully compatible with "usually not". A situation that >> comes up 30% of the time could still be described as coming up >> fairly often, despite not usually coming up. So that doesn't >> constitute a disagreement. >> > > That is often true, sometimes. > > :-) > Can we pretend that this is stackoverflow.com, mark this post as "the answer", and close the thread? This pantomime thread has been seriously tedious. <https://i.pinimg.com/originals/d5/46/b2/d546b28c3c679602ef229917efff1ed1.gif>
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2020-03-21 13:34 +0000 |
| Message-ID | <mJodG.2292$EF4.964@fx21.ams1> |
| In reply to | #72440 |
On 21/03/2020 10:27, David Brown wrote: > On 21/03/2020 08:32, jacobnavia wrote: >> Le 21/03/2020 à 04:15, James Kuyper a écrit : >>> On Friday, March 20, 2020 at 8:40:21 AM UTC-4, Bonita Montero wrote: >>>>> If know C++, you often don't need to know the exact type, and >>>>> therefore don't need to read the part where the container was >>>>> defined or declared. ... >>>> >>>> Usually not. >>> >>> "Often" is fully compatible with "usually not". A situation that >>> comes up 30% of the time could still be described as coming up >>> fairly often, despite not usually coming up. So that doesn't >>> constitute a disagreement. >>> >> >> That is often true, sometimes. >> >> :-) >> > > Can we pretend that this is stackoverflow.com, mark this post as "the answer", and close the thread? This pantomime thread has been seriously tedious. > > <https://i.pinimg.com/originals/d5/46/b2/d546b28c3c679602ef229917efff1ed1.gif> Unsurprisingly tedious, relative speaking, perhaps, of course! /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin “You won’t burn in hell. But be nice anyway.” – Ricky Gervais “I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2020-03-21 07:11 -0700 |
| Message-ID | <fce49374-9d2b-4a01-ae5e-147e34eb0965@googlegroups.com> |
| In reply to | #72440 |
On Saturday, March 21, 2020 at 6:28:08 AM UTC-4, David Brown wrote: Regarding auto, the only substantive issue here is whether auto can always be used safely, and the _answer_ is clearly and demonstrably "no", which is Bonita's point. In particular it can't be used with classes following popular proxy idioms without introducing undefined behavior. I don't believe that's applicable to the OP's post, though :-) Daniel
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-21 10:45 -0400 |
| Message-ID | <cone.1584801925.188497.3850.1004@monster.email-scan.com> |
| In reply to | #72445 |
[Multipart message — attachments visible in raw view] — view raw
Daniel writes: > On Saturday, March 21, 2020 at 6:28:08 AM UTC-4, David Brown wrote: > > Regarding auto, the only substantive issue here is whether auto can always be > used safely, and the _answer_ is clearly and demonstrably "no", which is > Bonita's point. Can a while loop always be used safely? Of course not. I've seen plenty of while-loops that result in undefined behavior, due to memory corruption. Everyone: please stop using while loops. They are not safe.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2020-03-21 08:03 -0700 |
| Message-ID | <c6e057e3-f11a-4854-9559-ac614f9e668b@googlegroups.com> |
| In reply to | #72447 |
On Saturday, March 21, 2020 at 10:45:35 AM UTC-4, Sam wrote: > > Can a while loop always be used safely? Of course not. "Therefore, send not to know For whom the troll trolls, It trolls for thee."
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2020-03-19 08:24 -0700 |
| Message-ID | <b3ec069f-5143-4d8e-902c-78083a782133@googlegroups.com> |
| In reply to | #72396 |
On Thursday, March 19, 2020 at 7:02:26 AM UTC-4, Sam wrote: > Bonita Montero writes: > > > It's usually not possible to guess the contained type. > > Someone who knows C++ does not need to guess. That's clearly wrong as, depending on the container, type deduction via auto is not always the right thing to do. One example is std::vector<bool>, or proxied containers generally. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-03-19 09:05 +1300 |
| Message-ID | <hdfd8nF9v62U1@mid.individual.net> |
| In reply to | #72379 |
On 19/03/2020 07:41, Sam wrote: > Bonita Montero writes: > >>>> v can be a type castable to an integer. >> >>> Or a suitable operator== overload. Please learn a little bit of C++. >> >> If you arguing against yourself there's nothing more to say. > > Here are your toys. You can go home now. See what happens when you feed the troll? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-18 19:47 -0400 |
| Message-ID | <cone.1584575225.621637.121838.1004@monster.email-scan.com> |
| In reply to | #72385 |
[Multipart message — attachments visible in raw view] — view raw
Ian Collins writes: > On 19/03/2020 07:41, Sam wrote: >> Bonita Montero writes: >> >>>>> v can be a type castable to an integer. >>> >>>> Or a suitable operator== overload. Please learn a little bit of C++. >>> >>> If you arguing against yourself there's nothing more to say. >> >> Here are your toys. You can go home now. > > See what happens when you feed the troll? I'm still hungry.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-03-18 11:43 -0700 |
| Message-ID | <4db9abf9-d24d-471b-af9c-e1fd45b1199e@googlegroups.com> |
| In reply to | #72375 |
On Wednesday, March 18, 2020 at 12:59:44 PM UTC-4, Bonita Montero wrote:
> >> There's no limitation on my side.
> >
> > ... That's a major limitation of one's ability to understand C++ code.
>
> Everyone without your crystal ball has this limitation.
I don't own a crystal ball. All I have is the ability to understand C++
syntax. Yet that ability is sufficient for me to understand the
following code:
> > for (const auto &v:container)
> > {
> > if (v == 0)
> > {
> > ++number_of_zeroes;
> > }
> > }
>
> v can be a type castable to an integer.
Yes it can, but that's not a requirement. It would be sufficient for it
to be comparable with 0 for equality. Pointers cannot, in general (there
are specific exceptions) be safely converted to integer types, but they
can all be compared with 0 for equality - the 0 is handled as a null
pointer constant which gets implicitly converted into a null pointer of
the pointer's type before making the comparison. A class type with a
compatible overload for operator==() would also make it work.
If this code has been successfully compiled by a conforming
implementation of C++ without generating any diagnostics, it's
guaranteed that the type is comparable with 0 for equality. If it hasn't
been compiled that way yet, you'll find out the first time you do try to
compile it that way. Of course, if the relevant type is a typedef or a
template parameter, you won't find out until the first time that you
compile it when that typedef or parameter describes a problematic type -
but even so, you will find out at compile time, not run time.
> > Noone really needs to know the type of the container, in this instance.
>
> But in most other instances.
I've found it quite common that I didn't need to know the exact type
that "auto" has been used for. Whenever that is the case, using auto
rather than the explicit type improves the readability. I will agree
that "auto" should not be used when that is not the case.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-18 19:48 +0100 |
| Message-ID | <r4tqd3$2r3$2@news.albasani.net> |
| In reply to | #72380 |
> I don't own a crystal ball. All I have is the ability to understand
> C++ syntax. Yet that ability is sufficient for me to understand the
> following code:
In this example maybe. But often it's impossible to guess the type.
>>> for (const auto &v:container)
>>> {
>>> if (v == 0)
>>> {
>>> ++number_of_zeroes;
>>> }
>>> }
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-03-18 12:37 -0700 |
| Message-ID | <3c768e8e-6a9a-445b-abb3-a4254827b080@googlegroups.com> |
| In reply to | #72382 |
On Wednesday, March 18, 2020 at 2:48:20 PM UTC-4, Bonita Montero wrote:
> > I don't own a crystal ball. All I have is the ability to understand
> > C++ syntax. Yet that ability is sufficient for me to understand the
> > following code:
>
> In this example maybe. But often it's impossible to guess the type.
It's also often unnecessary to guess the type. If it's both necessary
and impossible with this approach, don't use this approach. But there's
nothing wrong with this approach when it's either unnecessary or trivial
to guess the type, and that is often the case.
Keep in mind that it's often not necessary to guess the exact type of
something; it's often only necessary to guess certain characteristics of
the type.
> >>> for (const auto &v:container)
> >>> {
> >>> if (v == 0)
> >>> {
> >>> ++number_of_zeroes;
> >>> }
> >>> }
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-16 16:11 +0100 |
| Message-ID | <r4o4up$osl$1@dont-email.me> |
| In reply to | #72317 |
Le 16/03/2020 à 11:46, Sam a écrit : > Bonita Montero writes: > >>> Using structured binding you have to specify the number of fields of >>> the class and many other IRRELEVANT things that make more >>> dependencies that make the code more prone to failure. >> >> People who can handle C++ also can handle this. > > Furthermore, having delicate code that requires substantial work to > implement a tiny change is one of the key defining features of C++, and > this simply makes it even better. > > That's the point. C++ started with many good ideas like "information hiding", in the sense that you limit the access to irrelevant detail to specify interfaces that are more robust to changes in the underlying implementation. Structured binding goes against that principle head on: you expose everything and any change to the implementation of the base class needs a rewrite of user code! The existing way of "binding", i.e. declaring the variables and assigning to those variables the fields you want to access should be prefered. Structured binding is a mistake.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-03-17 08:17 +1300 |
| Message-ID | <hda1mgFnq38U7@mid.individual.net> |
| In reply to | #72330 |
On 17/03/2020 04:11, jacobnavia wrote: > Le 16/03/2020 à 11:46, Sam a écrit : >> Bonita Montero writes: >> >>>> Using structured binding you have to specify the number of fields of >>>> the class and many other IRRELEVANT things that make more >>>> dependencies that make the code more prone to failure. >>> >>> People who can handle C++ also can handle this. >> >> Furthermore, having delicate code that requires substantial work to >> implement a tiny change is one of the key defining features of C++, and >> this simply makes it even better. >> >> > > That's the point. > > C++ started with many good ideas like "information hiding", in the sense > that you limit the access to irrelevant detail to specify interfaces > that are more robust to changes in the underlying implementation. > > Structured binding goes against that principle head on: you expose > everything and any change to the implementation of the base class needs > a rewrite of user code! Ah but if you are using a type with named members, you wouldn't need to use structured binding, would you? Structured binding is useful for objects with unnamed members (arrays, tuples) or objects with generic names (map, pair etc). So no, structured binding is not a mistake. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2020-03-16 13:12 -0700 |
| Message-ID | <f86374e0-fbe7-472f-b2ba-9e59c7dcdea2@googlegroups.com> |
| In reply to | #72330 |
On Monday, March 16, 2020 at 11:11:32 AM UTC-4, jacobnavia wrote:
>
> C++ started with many good ideas like "information hiding", in the sense
> that you limit the access to irrelevant detail to specify interfaces
> that are more robust to changes in the underlying implementation.
>
> Structured binding goes against that principle head on:
Not necessarily
> you expose everything and any change to the implementation of the base
> class needs a rewrite of user code!
>
Consider
std::map<std::string, int> m = { {"one",1}, {"two",2} };
for (const auto& [key, value] : m) // (*)
{
std::cout << "key: " << key << ", value: " << value << "\n";
}
for (const auto& kv : m) // (**)
{
std::cout << "key: " << kv.first << ", value: " << kv.second << "\n";
}
(*) reveals less of the implementation detail of std::map than (**),
in particular, it does not depend on the particular representation of the
value_type being std::pair<const std::string,int>.
Daniel
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-16 20:13 -0400 |
| Message-ID | <cone.1584404012.181772.60175.1004@monster.email-scan.com> |
| In reply to | #72330 |
[Multipart message — attachments visible in raw view] — view raw
jacobnavia writes: > Le 16/03/2020 à 11:46, Sam a écrit : >> Bonita Montero writes: >> >>>> Using structured binding you have to specify the number of fields of the >>>> class and many other IRRELEVANT things that make more dependencies that make >>>> the code more prone to failure. >>> >>> People who can handle C++ also can handle this. >> >> Furthermore, having delicate code that requires substantial work to >> implement a tiny change is one of the key defining features of C++, and this >> simply makes it even better. >> >> > > That's the point. > > C++ started with many good ideas like "information hiding", in the sense > that you limit the access to irrelevant detail to specify interfaces that > are more robust to changes in the underlying implementation. > > Structured binding goes against that principle head on: you expose > everything and any change to the implementation of the base class needs a > rewrite of user code! So? Sometimes that's exactly what you want. You may very well want a particular change to be incompatible, by design, and force all existing callers to adapt. And for changes that should not break existing functionality, you have other ways of skinning that cat. Like adding another enum value, or something. And all structured bindings that employ that particular enum type continue to work exactly as they do now. Amazing, isn't it? And wasn't someone around here just kvetching, recently, how using structured bindings can end up miscompiling code because it went undetected and did /not/ require the "rewrite of user code". Oh, that was you: # jacobnavia writes: # # > As you see the "get" template receives an index that IS HARDCODED TO THE INDEX # > OF THE FIELD, and any changes by INSERTING A NEW FIELD will make those indexes # > silently access the WRONG FIELD, But, you're not saying that /any/ change mandates a rewrite, since it's going to get miscompiled? Sir/ma'am/whatever: can you kindly make up your mind exactly what's the problem with structured bindings?
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web