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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-16 05:24 +0100 |
| Message-ID | <r4mv14$d1t$1@news.albasani.net> |
| In reply to | #72309 |
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-16 06:46 -0400 |
| Message-ID | <cone.1584355585.390551.41705.1004@monster.email-scan.com> |
| In reply to | #72312 |
[Multipart message — attachments visible in raw view] — view raw
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-16 12:52 +0100 |
| Message-ID | <r4npa6$47h$1@news.albasani.net> |
| In reply to | #72317 |
>> 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. The issue here to complain about is the use of auto which results in intransparent types. I use auto only when absolutely necessary. In the "auto considered harmful" thread someone give a weird example which could get seemingly readable by using auto. But I rather prefer a 40 character type than an auto.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-16 08:32 -0400 |
| Message-ID | <cone.1584361927.52974.43460.1004@monster.email-scan.com> |
| In reply to | #72322 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes:
>>> 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.
>
> The issue here to complain about is the use of auto which results
> in intransparent types. I use auto only when absolutely necessary.
> In the "auto considered harmful" thread someone give a weird example
> which could get seemingly readable by using auto. But I rather prefer
> a 40 character type than an auto.
So, your argument boils down to mostly personal preference. If you prefer to
explicitly declare every type, you can still do so. This hasn't been
outlawed. You can continue writing out and spelling everything out.
But now, there's an option to simply avoid doing that. And, as an extra
bonus, I can do:
auto e=container.end();
auto p=std::find_if(container.begin(), e, [](const auto &value)
{
return value == 42;
});
if (p != e)
{
std::cout << "Find it" << std::endl;
}
Now, when I suddenly realize that my container must be a std::list, instead
of a std::vector, since there's a new requirement to be able to modify it
without invalidating all existing iterators, you can simply change the
declaration only, and not have to change a shitload of code.
If you prefer to do that, instead, because you believe you gain something
from the pain of doing that, you are welcome to continue writing the same
verbose, explicit declarations you're already doing. But, I'm glad I have
another option, now.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-16 13:51 +0100 |
| Message-ID | <r4nso0$pkl$1@news.albasani.net> |
| In reply to | #72325 |
> So, your argument boils down to mostly personal preference. If you're not the designer of the code or a visionary you've to find the container-type for which you're getting the auto variable(s). And that's more work than reading the concrete type. > Now, when I suddenly realize that my container must be a std::list, > instead of a std::vector, since there's a new requirement to be able to > modify it without invalidating all existing iterators, you can simply > change the declaration only, and not have to change a shitload of code. Having the concrete type maintains readability - that's more important than having less typing. As someone said in another thread he got tired of overly use of auto in a source he didn't write himself.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-16 20:06 -0400 |
| Message-ID | <cone.1584403572.850018.60175.1004@monster.email-scan.com> |
| In reply to | #72327 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes: >> So, your argument boils down to mostly personal preference. > > If you're not the designer of the code or a visionary you've to find > the container-type for which you're getting the auto variable(s). And > that's more work than reading the concrete type. I know that if I have a container, I can call begin(), and/or end(), drop the result into an auto, and have something to work with. I would think this would save me quite a bit of time for not having to do what you think I would have to do. >> Now, when I suddenly realize that my container must be a std::list, instead >> of a std::vector, since there's a new requirement to be able to modify it >> without invalidating all existing iterators, you can simply change the >> declaration only, and not have to change a shitload of code. > > Having the concrete type maintains readability - that's more important > than having less typing. As someone said in another thread he got tired > of overly use of auto in a source he didn't write himself. I suppose that it's a matter of personal preference. I am aware of the fact that iterator and algorithm semantics are remarkably consistent. People's Exhibit A: my previous message in this thread. I'm not sure how clearly identifying that something is a list iterator translates into "readability". If all I need to do is passed something into std::find, find_if, or some other algorithm that correctly adapts itself to any compliant iterator, I'm not sure the value added in explicitly designating the inputs as list or vector iterators. The end result, the concept, in the end, is the same. And I find the concept of readability to be quite the opposite of yours'. To me, a compact designation that something is merely a beginning or an ending iterator of a sequence is all I need to make it readable. See a spelled out type take up a quarter of a width of a line, for some reason, doesn't appeal as very readable to me.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-17 06:37 +0100 |
| Message-ID | <r4pnn6$r2g$1@news.albasani.net> |
| In reply to | #72335 |
> I suppose that it's a matter of personal preference. If I have to figure out of which type a container is I doing an auto in a for, that's not a matter of preference. If I f.e. have a pair<const key, value>, I know immediately that I'm using a map or unordered_map.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-17 07:17 -0400 |
| Message-ID | <cone.1584443868.151175.70671.1004@monster.email-scan.com> |
| In reply to | #72337 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes:
>> I suppose that it's a matter of personal preference.
>
> If I have to figure out of which type a container is I doing an
> auto in a for, that's not a matter of preference. If I f.e. have
> a pair<const key, value>, I know immediately that I'm using a map
> or unordered_map.
Well, the trick is to arrange things so that it doesn't matter.
for (auto &[key,value]:container)
will work for that map. But replacing that container with a std::vector of
tuples will also work, if it becomes necessary. You'll be surprised to learn
that the above line of code will remain unchanged.
Something quite similar happened a year or so, ago. I used an unordered_set
of rectangle objects (x/y/width/height) that I used to implement GUI
algorithms. I initially relied on the unordered_set itself to eliminate the
duplicates.
Through profiling I determined a little bit of a bottleneck in set
operations that will benefit from replacing the unordered_set with a vector,
to take advantage of modern CPU's optimizations on linear memory access.
So that's what I did, and I just added a few bits to all the rectangle
container oeprators to dedupe the rectangles after wrangling with them. And,…
that was it. Apart from simply redefining the container as such, and a few
tweaks to a few functions, that was it. 99% of the existing code used auto
and required no changes whatsoever.
So, if someone likes C++ so much that they prefer to do a lot of unnecessary
work, because they think the resulting code is more readable, more power to
them. If they think that
for (std::unordered_set<rectangle>::iterator rb=rs.begin(), re=rs.end();
rb != re; rb++)
{
rectangle &r=*rb;
// …
}
makes their resulting code so beautiful and purty, they can knock themselves
out. As for me,
for (auto &r:rs)
will also work, and I'll just move on to bigger and better things. I think
I'll survive not having to experience the beauty of the resulting code if I
was forced to rewrite it due to the container change.
I think I'll cope with not appreciating the "readability" of knowing that
the underlying iterators are std::unordered_set<rectangle>::iterator or
std::vector<rectangle>::iterator. I'll just have to deal with the fact that
it will never be clear to me how that adds to "readability". For me, it
appears that the exact task at hand, for which I need to chew through the
rectangles, is what's more important. Where those rectangles come from, from
which container, and its semantics, who cares.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-17 18:37 +0100 |
| Message-ID | <r4r1st$581$2@news.albasani.net> |
| In reply to | #72344 |
> will work for that map. But replacing that container with a std::vector > of tuples will also work, if it becomes necessary. You'll be surprised > to learn that the above line of code will remain unchanged. This ease doesn't justify the lesser readability.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-03-17 18:50 +0100 |
| Message-ID | <r4r2kj$uih$1@dont-email.me> |
| In reply to | #72351 |
On 17.03.2020 18:37, Bonita Montero wrote: >> will work for that map. But replacing that container with a >> std::vector of tuples will also work, if it becomes necessary. You'll >> be surprised to learn that the above line of code will remain unchanged. > > This ease doesn't justify the lesser readability. Point. IMO they could/should just have opened up the $ namespace for keywords. Instead of all this grotesquely convoluted symbol based syntax. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-18 06:30 -0400 |
| Message-ID | <cone.1584527410.378593.99994.1004@monster.email-scan.com> |
| In reply to | #72351 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes: >> will work for that map. But replacing that container with a std::vector of >> tuples will also work, if it becomes necessary. You'll be surprised to learn >> that the above line of code will remain unchanged. > > This ease doesn't justify the lesser readability. I find it quite the opposite. Verbose code that spells out the data type of each variable results in too much visual clutter that's taken up by minor details that are largely irrelevant to the task at hand. When trying to understand existing code it's more readable to me when the bulk of it describes what it does, instead of how it does it.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-18 11:38 +0100 |
| Message-ID | <r4stml$f6$1@news.albasani.net> |
| In reply to | #72362 |
> I find it quite the opposite. Verbose code that spells out the data type > of each variable results in too much visual clutter that's taken up by > minor details that are largely irrelevant to the task at hand. ... The details aren't minor if you aren't the writer of the code or you've not looked for the code for a long time. I can understand the guy that told in the auto-thread that he suffered reading code from someone else who overly used auto.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-18 08:17 -0400 |
| Message-ID | <cone.1584533844.436908.99994.1004@monster.email-scan.com> |
| In reply to | #72363 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes:
>> I find it quite the opposite. Verbose code that spells out the data type of
>> each variable results in too much visual clutter that's taken up by minor
>> details that are largely irrelevant to the task at hand. ...
>
> The details aren't minor if you aren't the writer of the code or you've
> not looked for the code for a long time.
Even if I did not write the code,
for (auto &rectangle:container)
draw(rectangle);
Tells me everything I need to know, without the visual noise of whether
"container" is a set or a vector. That is completely, and utterly
irrelevant. Which will still be completely and utterly irrelevant if I
didn't write that.
> I can understand the guy that
> told in the auto-thread that he suffered reading code from someone else
> who overly used auto.
I can also understand that. After being set in one's ways, and coding in pre-
C++11 for your entire working career, learning something new and different,
and adapting to it, can be tough.
But, it can be done. I was in the same boat about eight years ago. But I
plowed through it, and did it. It took a little bit of time, but it was
doable. Not knowing the type of some object was, at first, a fish-out-of-
water experience, but I figured out at some point how, in many cases, it's
really irrelevant and I don't need to know. Now being exposed to both coding
styles, I like the auto style better. But I can still work with the existing
code base that spells everything out. I can happily work with both styles of
existing code.
And if someone can't, I think that someone will, eventually, just take their
job from them, if it comes down to that. It might even be me.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-18 13:19 +0100 |
| Message-ID | <r4t3jv$jsv$1@news.albasani.net> |
| In reply to | #72364 |
> Even if I did not write the code, > for (auto &rectangle:container) > draw(rectangle); > Tells me everything I need to know, without the visual noise of whether > "container" is a set or a vector. You need to know it. > "container" is a set or a vector. That is completely, and utterly > irrelevant. Which will still be completely and utterly irrelevant if I > didn't write that. No, that's relevant if you want to understand the code. [rest of stupid stuff unread]
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-18 08:31 -0400 |
| Message-ID | <cone.1584534687.702706.99994.1004@monster.email-scan.com> |
| In reply to | #72365 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes: >> Even if I did not write the code, >> for (auto &rectangle:container) >> draw(rectangle); >> Tells me everything I need to know, without the visual noise of whether >> "container" is a set or a vector. > > You need to know it. I can decide for myself what I need to know. >> "container" is a set or a vector. That is completely, and utterly >> irrelevant. Which will still be completely and utterly irrelevant if I >> didn't write that. > > No, that's relevant if you want to understand the code. I will concede that some people do need to know that, in order to understand the code. But others won't. Sucks to be the former. Evolution. Survival of the fittest. I learned that in grade school. > [rest of stupid stuff unread] Because you have no response to industrial strength, 100%, truth. That one hit too close to home?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-18 14:15 +0100 |
| Message-ID | <r4t6uc$c5k$1@news.albasani.net> |
| In reply to | #72366 |
>>> Even if I did not write the code, >>> for (auto &rectangle:container) >>> draw(rectangle); >>> Tells me everything I need to know, without the visual noise of >>> whether "container" is a set or a vector. >> You need to know it. > I can decide for myself what I need to know. You can't if you really want to understand the code. > I will concede that some people do need to know that, in order to > understand the code. > But others won't. If you're involved in the development of the code you need to know it. > Because you have no response to industrial strength, 100%, truth. Industrial strength tends to be more readable. What you suggest is less readable.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-18 10:13 -0400 |
| Message-ID | <cone.1584540814.629044.99994.1004@monster.email-scan.com> |
| In reply to | #72367 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes: >>>> Even if I did not write the code, >>>> for (auto &rectangle:container) >>>> draw(rectangle); >>>> Tells me everything I need to know, without the visual noise of whether >>>> "container" is a set or a vector. > >>> You need to know it. > >> I can decide for myself what I need to know. > > You can't if you really want to understand the code. That's just your own limitation, but you are assuming that everyone else shares the same limited capacity to understand code. That is not the case. >> I will concede that some people do need to know that, in order to understand >> the code. >> But others won't. > > If you're involved in the development of the code you need to know it. > >> Because you have no response to industrial strength, 100%, truth. > > Industrial strength tends to be more readable. > What you suggest is less readable. It's less readable to you, and you won't understand it. I'm sorry to hear that. Someone else, who can read the code, will be happy to help you, if needed.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-18 15:45 +0100 |
| Message-ID | <r4tc6t$e1$1@news.albasani.net> |
| In reply to | #72370 |
>> You can't if you really want to understand the code. > That's just your own limitation, but you are assuming that everyone else > shares the same limited capacity to understand code. That is not the case. There's no limitation on my side. It's simply impossible to understand the code without the underlying container. So you have to find the definition or declaration of the container, which might be superfluous work if there would be a concrete type-definition. > It's less readable to you, ... No, to everyone. No one has a crystal ball to gues the type of the container.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-18 11:36 -0400 |
| Message-ID | <cone.1584545763.768592.106569.1004@monster.email-scan.com> |
| In reply to | #72372 |
[Multipart message — attachments visible in raw view] — view raw
Bonita Montero writes:
>>> You can't if you really want to understand the code.
>
>> That's just your own limitation, but you are assuming that everyone else
>> shares the same limited capacity to understand code. That is not the case.
>
> There's no limitation on my side.
But you just admitted to one. You freely admit that you can't understand any
code that uses a C++ container until you figure out what the container is.
That's a major limitation of one's ability to understand C++ code.
> It's simply impossible to understand
> the code without the underlying container.
For you, it is. Others don't share that limitation. I can understand it. So
pretty much everyone else.
> So you have to find the
> definition or declaration of the container, which might be superfluous
> work if there would be a concrete type-definition.
No, you don't. You don't need to know what the container is when doing
for (const auto &v:container)
{
if (v == 0)
{
++number_of_zeroes;
}
}
If you don't understand what this does, without looking up what container
is, that's only because you don't know C++ very well.
This is a typical question given to a candidate for a C++ developer job, and
if you can't explain what this does, it is unlikely that you will get the
job. You admit that you have absolutely no clue what this does.
I'm sorry to hear that.
>
>> It's less readable to you, ...
>
> No, to everyone.
No, just you.
> No one has a crystal ball to gues the type of the container.
Noone really needs to know the type of the container, in this instance.
Can I suggest some good C++ books, for you?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-18 17:59 +0100 |
| Message-ID | <r4tk1l$f5l$1@news.albasani.net> |
| In reply to | #72373 |
>> 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.
> for (const auto &v:container)
> {
> if (v == 0)
> {
> ++number_of_zeroes;
> }
> }
v can be a type castable to an integer.
> Noone really needs to know the type of the container, in this instance.
But in most other instances.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web