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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-13 00:13 +0100 |
| Subject | Structured binding considered harmful |
| Message-ID | <r4efnn$f41$1@dont-email.me> |
Here is one exemple of "structured binding" from the paper of Filipek:
int main() {
// Initialize a map table.
const std::map<std::string, int> mapCityPopulation {
{ "Beijing", 21'707'000 },
{ "London", 8'787'892 },
{ "New York", 8'622'698 }
};
for (auto&[city, population] : mapCityPopulation)
std::cout << city << ": " << population << '\n';
}
Within the for statement the variables "city" and "population" will be
bound automatically to the corresponding fields of the map.
Cute isn't it?
Before, in the old times, you would have to write:
(I cite the book of Filipek page 29)
<quote>
Consider a function that returns two results in a pair:
std::pair<int, bool> InsertElement(int el) { ... }
You can write:
auto ret = InsertElement(...)
And then refer to ret.first or ret.second. However, referring to values
as .first or .second is also not expressive - you can easily confuse the
names, and it’s hard to read.
<end quote>
Yes, maybe is not "expressive". There is an easy work around though, as
Filipek shows:
<quote>
Alternatively you can leverage std::tie which will unpack the tuple/pair
into local variables:
int index { 0 };
bool flag { false };
std::tie(index, flag) = InsertElement(10);
Such code might be useful when you work with std::set::insert which
returns std::pair:std::set<int> mySet;
std::set<int>::iterator iter;
bool inserted { false };
std::tie(iter, inserted) = mySet.insert(10);
if (inserted)
std::cout << "Value was inserted\n";
As you see, such a simple pattern - returning several values from a
function - requires several lines of code.
<end quote>
Yes, several lines of code that is easily read by anyone and by existing
tools.
And here awe arrive at the essence of why C++ is going into endless
complexity: a desire to have "cute" constructs and save some seconds to
the programmer typing the new code in.
Nothing will be said about the need to reprogram all tools that read C++
code to accept the new stuff, the need to figure out all ramifications
of the new construct, etc etc.
Because the consequences are terrible when you do not have a 1 to 1
correspondence between the names in the bracket enclosed list, and the
class whose fields will be "bound" to those names.
Even WORST:
What happens when the class is modified to have a new field?
All the structured binding constructs have to be modified to add the new
field, and if you miss one crashes and bugs will inevitably happen.
All of this is not necessary using the old syntax that was more verbose
but MUCH SAFER and robust.
MINDLESS COMPLXITY FOR COMPLEXITY's SAKE, with no improvement to
anything useful.
All the tools have to be rewritten to accomodate this nonsense, what is
not easy since you have to get the definition of the class object that
can be anywhere else, in another header file or whatever!
What is the end result?
A new useless construct has been added to the language that serves no
purpose other than saving some seconds when typing C++.
GREAT!
[toc] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2020-03-13 00:46 -0700 |
| Message-ID | <ade309c1-cb5a-4375-8474-9781b6bc3ff6@googlegroups.com> |
| In reply to | #72243 |
> Even WORST: > > What happens when the class is modified to have a new field? Presumably that new field has some meaning that should not be neglected up-front. > All the structured binding constructs have to be modified And for some this is actually a feature, because without extremely costly review of existing code, the compiler will *automatically* tell you where are all the places that might require your attention. If neglecting the new field in any given place would result in a bug, you have all such potential places reported to you for free. This is a similar reasoning to the capability of detecting that switch statements become incomplete when the new enumeration value is added to the enum type definition. Interestingly: Some people believe that having the "default" branch makes their code robust to such changes. Others believe that it is the capability to detect *statically* that existing switch statements became incomplete and require attention makes their code even more robust. Of course, there will be concrete examples for either way, but that's why it is good to have a choice *at the call site*. So, if you want your code to be "robust" by making it indifferent to newly added fields, write your code that way. But if you want your code to be "robust" by making it auto-detect structural changes and get your attention to potential problems, then write your code the other way. I don't claim that any of these two definitions of "robust" is better, but I've seen real cases to support either one. And I think that your actual problem is that you were given a choice. :-) > All the tools have to be rewritten to accomodate Yes, this is a disadvantage of introducing new features to the language. But not all tools need to be rewritten - only those that want to stay competitive on the market. Or you also have a choice of standardizing on a smaller language subset, to stay with existing tools - this possibility was already discussed. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-14 09:10 +0100 |
| Message-ID | <r4i3hh$iui$1@dont-email.me> |
| In reply to | #72256 |
Le 13/03/2020 à 08:46, Maciej Sobczak a écrit : >> All the structured binding constructs have to be modified > And for some this is actually a feature, because without extremely costly review of existing code, the compiler will*automatically* tell you where are all the places that might require your attention. If neglecting the new field in any given place would result in a bug, you have all such potential places reported to you for free. But the old way of writing it in C++14 doesn't have those pitfalls! Even if you add 30 new fields, since the binding is done "manually" it will continue to work unmodified. You just declare two new variables and assign to them the values of the fields you want! WHY this "enhancement" if the old way is more robust? THAT is my point!!! Here we have a new way of doing the same thing that is in many cases WORST as the current one and will be added anyway, making an already very complex language EVEN MORE COMPLEX! And THAT was my point!
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-03-13 09:40 -0700 |
| Message-ID | <074fb5ce-6ad4-4434-9edf-36d7f3b583d4@googlegroups.com> |
| In reply to | #72243 |
On Friday, 13 March 2020 01:14:10 UTC+2, jacobnavia wrote:
> Here is one exemple of "structured binding" from the paper of Filipek:
>
> int main() {
> // Initialize a map table.
> const std::map<std::string, int> mapCityPopulation {
> { "Beijing", 21'707'000 },
> { "London", 8'787'892 },
> { "New York", 8'622'698 }
> };
>
> for (auto&[city, population] : mapCityPopulation)
> std::cout << city << ": " << population << '\n';
> }
>
> Within the for statement the variables "city" and "population" will be
> bound automatically to the corresponding fields of the map.
>
> Cute isn't it?
No, doesn't compile, since necessary #includes are missing.
Someone posting this trash in anything-goes-newsgroup is fine,
but if it is really in book then burn it and use "Filipek" like
mild profanity.
The constructs like you seem to imply do not compile as well.
Try:
std::string city;
int population;
for (std::bind(city, population) : mapCityPopulation)
std::cout << city << ": " << population << '\n';
It does not parse, syntax error. Also you do not really post
what you would like to see so I'm confused what is your
suggestion.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-14 09:05 +0100 |
| Message-ID | <r4i38r$hr4$1@dont-email.me> |
| In reply to | #72268 |
Le 13/03/2020 à 17:40, Öö Tiib a écrit :
> On Friday, 13 March 2020 01:14:10 UTC+2, jacobnavia wrote:
>> Here is one exemple of "structured binding" from the paper of Filipek:
>>
>> int main() {
>> // Initialize a map table.
>> const std::map<std::string, int> mapCityPopulation {
>> { "Beijing", 21'707'000 },
>> { "London", 8'787'892 },
>> { "New York", 8'622'698 }
>> };
>>
>> for (auto&[city, population] : mapCityPopulation)
>> std::cout << city << ": " << population << '\n';
>> }
>>
>> Within the for statement the variables "city" and "population" will be
>> bound automatically to the corresponding fields of the map.
>>
>> Cute isn't it?
>
> No, doesn't compile, since necessary #includes are missing.
Yes, I missed the includes. Here they are:
#include <map>
#include <iostream>
#include <string>
> Someone posting this trash in anything-goes-newsgroup is fine,
> but if it is really in book then burn it and use "Filipek" like
> mild profanity.
>
You make a mountain out of a simple c ut/paste error.
> The constructs like you seem to imply do not compile as well.
> Try:
>
> std::string city;
> int population;
> for (std::bind(city, population) : mapCityPopulation)
> std::cout << city << ": " << population << '\n';
>
> It does not parse, syntax error. Also you do not really post
> what you would like to see so I'm confused what is your
> suggestion.
I would say the compiler have to parse that by using the right
standard... Maybe you didn't se the standard to C++20
In any case you did NOT answer my question, since you can't apparently.
Or you did not see it whatever. Here is it AGAIN:
WHAT IS THE PURPOSE OF THIS "ENHANCEMENT"?
Why it is so important that you HAVE to add it to an already unbearible
complex language?
Why can't the old way of writing that code be maintained SIMPLIFYING the
language?
THAT was my point that you did not even mention!
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-03-14 03:19 -0700 |
| Message-ID | <7b2a19bf-30f9-418c-ad86-33d44c3b1926@googlegroups.com> |
| In reply to | #72281 |
On Saturday, 14 March 2020 10:05:58 UTC+2, jacobnavia wrote:
> Le 13/03/2020 à 17:40, Öö Tiib a écrit :
> > On Friday, 13 March 2020 01:14:10 UTC+2, jacobnavia wrote:
> >> Here is one exemple of "structured binding" from the paper of Filipek:
> >>
> >> int main() {
> >> // Initialize a map table.
> >> const std::map<std::string, int> mapCityPopulation {
> >> { "Beijing", 21'707'000 },
> >> { "London", 8'787'892 },
> >> { "New York", 8'622'698 }
> >> };
> >>
> >> for (auto&[city, population] : mapCityPopulation)
> >> std::cout << city << ": " << population << '\n';
> >> }
> >>
> >> Within the for statement the variables "city" and "population" will be
> >> bound automatically to the corresponding fields of the map.
> >>
> >> Cute isn't it?
> >
> > No, doesn't compile, since necessary #includes are missing.
>
> Yes, I missed the includes. Here they are:
>
> #include <map>
> #include <iostream>
> #include <string>
>
>
> > Someone posting this trash in anything-goes-newsgroup is fine,
> > but if it is really in book then burn it and use "Filipek" like
> > mild profanity.
> >
>
> You make a mountain out of a simple c ut/paste error.
Mea culpa. I just tried to mimic back your unmerciful style when
discussing a tool. Lets try a bit more calmly?
>
> > The constructs like you seem to imply do not compile as well.
> > Try:
> >
> > std::string city;
> > int population;
> > for (std::bind(city, population) : mapCityPopulation)
> > std::cout << city << ": " << population << '\n';
> >
> > It does not parse, syntax error. Also you do not really post
> > what you would like to see so I'm confused what is your
> > suggestion.
>
> I would say the compiler have to parse that by using the right
> standard... Maybe you didn't se the standard to C++20
It can't compile, it is syntax error in C++20. Range based for is:
for ( range_declaration : range_expression ) loop_statement
Call of function template std::bind is not a declaration.
I just had to point it out since majority of your post contained
such blunders.
> In any case you did NOT answer my question, since you can't apparently.
> Or you did not see it whatever. Here is it AGAIN:
>
> WHAT IS THE PURPOSE OF THIS "ENHANCEMENT"?
Sorry, I lost question in the pile of rant that felt incorrect. My
eyes are just accustomed to notice defects and in defective stuff
my mind stops searching any meaning.
I see no purpose of that particular enchantment. I continue writing:
for (auto const& e : mapCityPopulation)
std::cout << e.first << ": " << e.second << '\n';
When navigating within iterated element is too repetitive, verbose
and/or abstract (it isn't in that toy example but can be) then
I name these using local variables:
for (auto const& e : mapCityPopulation) {
char const* city = e.first.c_str();
int population = e.second;
std::cout << city << ": " << population << '\n';
}
I do same in every other place in code where something looks too
repetitive, verbose and/or abstract so it hurts readability.
> Why it is so important that you HAVE to add it to an already unbearible
> complex language?
My guess is that it is perhaps sabotage of wormtongues from monster
software companies with task to deteriorate the language to non-
useful. I disliked the language changes in C++17 as well. But I may
be wrong.
> Why can't the old way of writing that code be maintained SIMPLIFYING the
> language?
>
> THAT was my point that you did not even mention!
World is what it is. For me it is more important what we,
programmers can do to mitigate the issues. Actual market for
C++ has been in serious raise (in my experience) but skilled
specialists are hard to find and so half of people programming in
it can't actually comprehend it.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-03-15 11:08 +0000 |
| Message-ID | <slrnr6s357.1r7q.grahn+nntp@frailea.sa.invalid> |
| In reply to | #72284 |
On Sat, 2020-03-14, Öö Tiib wrote: > On Saturday, 14 March 2020 10:05:58 UTC+2, jacobnavia wrote: ... >> Why it is so important that you HAVE to add it to an already unbearible >> complex language? > > My guess is that it is perhaps sabotage of wormtongues from monster > software companies with task to deteriorate the language to non- > useful. I disliked the language changes in C++17 as well. But I may > be wrong. My coworker, who (unlike me) hangs around on HackerNews, understand it as a kind of pressure. Within a company, people lobby for doing the next project in $pet_language, because it has $feature which would be useful. So they grow C++ so it can stay competitive. Sounds more likely than a conspiracy. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-03-15 09:46 -0700 |
| Message-ID | <686ab0c9-a610-4c2c-bf41-29eaadacfd1a@googlegroups.com> |
| In reply to | #72301 |
On Sunday, 15 March 2020 13:08:34 UTC+2, Jorgen Grahn wrote: > On Sat, 2020-03-14, Öö Tiib wrote: > > On Saturday, 14 March 2020 10:05:58 UTC+2, jacobnavia wrote: > ... > >> Why it is so important that you HAVE to add it to an already unbearible > >> complex language? > > > > My guess is that it is perhaps sabotage of wormtongues from monster > > software companies with task to deteriorate the language to non- > > useful. I disliked the language changes in C++17 as well. But I may > > be wrong. > > My coworker, who (unlike me) hangs around on HackerNews, understand it > as a kind of pressure. Within a company, people lobby for doing the > next project in $pet_language, because it has $feature which would be > useful. So they grow C++ so it can stay competitive. > > Sounds more likely than a conspiracy. Big part of the language features that C++11 added were vital performance improvements, others were syntax sugar (often added bordering on broken) and only very few were security and or safety features. I remember discussions how safety features like override and final were planned to be added uglified to maximum. I can live without using syntax sugar features so did not care that standards make those broken but safety and performance features I care about. However C++17 took to break performance feature constexpr (by making it undetectable) and safety feature enum class (by adding more undefined behaviors into it). Then I built impression that it is sabotage.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-03-15 19:27 +0100 |
| Message-ID | <r4ls2r$8lc$1@dont-email.me> |
| In reply to | #72304 |
On 15.03.2020 17:46, Öö Tiib wrote: > [snap]. However C++17 took to break performance feature constexpr > (by making it undetectable) and safety feature enum class (by adding > more undefined behaviors into it). Then I built impression that > it is sabotage. Which undefined behaviors for enums? What I recall is the opposite, that the introduction of `std::bool` forced a cleanup where now all enumerator values that fit within the underlying type are kosher also formally. If they have undermined the language in yet another direction it's, well, disconcerting. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-03-15 15:15 -0700 |
| Message-ID | <87y2s1qn6p.fsf@nosuchdomain.example.com> |
| In reply to | #72306 |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> On 15.03.2020 17:46, Öö Tiib wrote:
>> [snap]. However C++17 took to break performance feature constexpr
>> (by making it undetectable) and safety feature enum class (by adding
>> more undefined behaviors into it). Then I built impression that
>> it is sabotage.
>
> Which undefined behaviors for enums?
>
> What I recall is the opposite, that the introduction of `std::bool`
> forced a cleanup where now all enumerator values that fit within the
> underlying type are kosher also formally.
What is "std::bool"? (Since bool is a keyword, the grammar would have
to be updated just to allow that.)
> If they have undermined the language in yet another direction it's,
> well, disconcerting.
--
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 | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-03-16 05:23 +0100 |
| Message-ID | <r4muvi$79l$1@dont-email.me> |
| In reply to | #72307 |
On 15.03.2020 23:15, Keith Thompson wrote: > "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >> On 15.03.2020 17:46, Öö Tiib wrote: >>> [snap]. However C++17 took to break performance feature constexpr >>> (by making it undetectable) and safety feature enum class (by adding >>> more undefined behaviors into it). Then I built impression that >>> it is sabotage. >> >> Which undefined behaviors for enums? >> >> What I recall is the opposite, that the introduction of `std::bool` >> forced a cleanup where now all enumerator values that fit within the >> underlying type are kosher also formally. > > What is "std::bool"? (Since bool is a keyword, the grammar would have > to be updated just to allow that.) Sorry, I meant to type `std::byte`. The perils of having a brain with low level automation of things like typing up what I was thinking, when higher levels have moved on to other things. If Odin & his brothers had meant for us to type on QWERTY keyboards they would have equipped Ask and Embla with seven fingers on each hand. The time is long overdue for more rational input equipment. I particularly liked the 80's idea of a little thingy with five buttons that you pressed in combinations. You could even have it in your wallet and type unseen. If you were not afraid of the impression it could give. >> If they have undermined the language in yet another direction it's, >> well, disconcerting. - Alf
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-03-16 05:54 +0100 |
| Message-ID | <r4n0qb$dpv$1@dont-email.me> |
| In reply to | #72311 |
On 16.03.2020 05:23, Alf P. Steinbach wrote: > On 15.03.2020 23:15, Keith Thompson wrote: >> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>> On 15.03.2020 17:46, Öö Tiib wrote: >>>> [snap]. However C++17 took to break performance feature constexpr >>>> (by making it undetectable) and safety feature enum class (by adding >>>> more undefined behaviors into it). Then I built impression that >>>> it is sabotage. >>> >>> Which undefined behaviors for enums? >>> >>> What I recall is the opposite, that the introduction of `std::bool` >>> forced a cleanup where now all enumerator values that fit within the >>> underlying type are kosher also formally. >> >> What is "std::bool"? (Since bool is a keyword, the grammar would have >> to be updated just to allow that.) > > Sorry, I meant to type `std::byte`. > > The perils of having a brain with low level automation of things like > typing up what I was thinking, when higher levels have moved on to other > things. If Odin & his brothers had meant for us to type on QWERTY > keyboards they would have equipped Ask and Embla with seven fingers on > each hand. The time is long overdue for more rational input equipment. > > I particularly liked the 80's idea of a little thingy with five buttons > that you pressed in combinations. You could even have it in your wallet > and type unseen. If you were not afraid of the impression it could give. Oh dang it happened again. I ordered typing of "pocket", not "wallet". >>> If they have undermined the language in yet another direction it's, >>> well, disconcerting. > > > - Alf
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-03-16 00:20 -0700 |
| Message-ID | <db7958f5-95a7-413d-a140-060c444a1694@googlegroups.com> |
| In reply to | #72306 |
On Sunday, 15 March 2020 20:27:51 UTC+2, Alf P. Steinbach wrote: > On 15.03.2020 17:46, Öö Tiib wrote: > > [snap]. However C++17 took to break performance feature constexpr > > (by making it undetectable) and safety feature enum class (by adding > > more undefined behaviors into it). Then I built impression that > > it is sabotage. > > > Which undefined behaviors for enums? > > What I recall is the opposite, that the introduction of `std::bool` > forced a cleanup where now all enumerator values that fit within the > underlying type are kosher also formally. Yes, seems that the resulting broken std::byte of C++17 caused them to fix enums in C++20.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-13 23:08 -0400 |
| Message-ID | <cone.1584155318.443830.189635.1004@monster.email-scan.com> |
| In reply to | #72243 |
[Multipart message — attachments visible in raw view] — view raw
jacobnavia writes: > Even WORST: > > What happens when the class is modified to have a new field? > All the structured binding constructs have to be modified to add the new > field, and if you miss one crashes and bugs will inevitably happen. Bullshit. The code will fail to compile. And after fixing every return value, you'll go back to your happy place. Even decades-old Makefiles will automatically recompile everything that pulls in the modified declaration, recompiling everything, and having your compiler tell you everything you need to fix. Please read a good C++ book, and try it yourself, before spewing this nonsense again.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-14 08:59 +0100 |
| Message-ID | <r4i2tk$frj$1@dont-email.me> |
| In reply to | #72276 |
Le 14/03/2020 à 04:08, Sam a écrit : > jacobnavia writes: > >> Even WORST: >> >> What happens when the class is modified to have a new field? >> All the structured binding constructs have to be modified to add the >> new field, and if you miss one crashes and bugs will inevitably happen. > > Bullshit. > > The code will fail to compile. And after fixing every return value, > you'll go back to your happy place. > I said: All the structured binding constructs have to be modified Then you say: Bullshit and in the next sentence you confirm what I have said. > The code will fail to compile. And after fixing every return value, > you'll go back to your happy place. And you seem to ignore the contradiction! Too much C++ affects reasoning capacity? Or is it simply that ypu are answering out of "C++ nationalism", i.e Trump's "My country right or wrong". as "My computer language right or wrong" As most other answers to my critique, you just seem to be touched emotionally and your answers are emotional: "spewing nonsense", etc. Keep calm. We aren't speaking about your mother or about your country. We are diuscussing a computer language feature. That's all. Breath deeply and now answer me: Why is this new construct necessary? Wasn't the old way of writing them easier and more robust? THAT was my question. Please answer it.
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-14 10:09 -0400 |
| Message-ID | <cone.1584194973.872992.198672.1004@monster.email-scan.com> |
| In reply to | #72280 |
[Multipart message — attachments visible in raw view] — view raw
jacobnavia writes: > Le 14/03/2020 à 04:08, Sam a écrit : >> jacobnavia writes: >> >>> Even WORST: >>> >>> What happens when the class is modified to have a new field? >>> All the structured binding constructs have to be modified to add the new >>> field, and if you miss one crashes and bugs will inevitably happen. >> >> Bullshit. >> >> The code will fail to compile. And after fixing every return value, you'll >> go back to your happy place. >> > > > I said: > > All the structured binding constructs have to be modified > > Then you say: > > Bullshit > > and in the next sentence you confirm what I have said. You're still full of bullshit. The bullshit part is the one that says "and if you miss one crashes and bugs will inevitably happen". That's the bullshit. The reality is that if you miss one, the code won't compile, at all. Try to learn C++, one of these days, ok? > > The code will fail to compile. And after fixing every return value, > > you'll go back to your happy place. > > And you seem to ignore the contradiction! You don't understand, Einstein. The code will fail to compile. If it can't compile, it can't "crash" and cause "bugs" to "inevitably happen". > Wasn't the old way of writing them easier and more robust? No, it wasn't. If you suddenly figured out that a function or a method needed to return two or more discrete values, instead of one, the new way is faster, less typing, and less error-prone. > THAT was my question. Please answer it. I just did: you're still full of bullshit.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-14 18:32 +0100 |
| Message-ID | <r4j4fs$qk1$1@dont-email.me> |
| In reply to | #72289 |
Le 14/03/2020 à 15:09, Sam a écrit :
> You're still full of bullshit. The bullshit part is the one that says
> "and if you miss one crashes and bugs will inevitably happen".
>
> That's the bullshit.
Dear Sam:
I am referring to the page 35 of
<https://drive.google.com/file/d/1W0Em5ioHiBdIG3LeXqpwla4wcPxvOBKq/view?usp=sharing>
In that page we have the description of the general interface of
structurezd binding with some arbitrary class, that he calls UserEntry.
<quote>
class UserEntry {
public:
void Load() { }
std::string GetName() const { return name; }
unsigned GetAge() const { return age; }
private:
std::string name;
unsigned age { 0 };
size_t cacheEntry { 0 }; // not exposed
};
<end quote>
We have here then a class with 3 fields, "name", "age", and another
called "cacheEntry" that is NOT EXPOSED to the structured binding interface.
To be able to specify in a "structured binding" the alias for the fields
you have to define (nothing less than ) 3 things:
1: get<N>,
2: std::tuple_size and
3: std::tuple_element
Here is an exemple:
<quote>
// with if constexpr:
template <size_t I> auto get(const UserEntry& u) {
if constexpr (I == 0) return u.GetName();
else if constexpr (I == 1) return u.GetAge();
}
namespace std {
template <> struct tuple_size<UserEntry>:integral_constant<size_t,2> {};
template <> struct tuple_element<0,UserEntry> { using type = std::string; };
template <> struct tuple_element<1,UserEntry> { using type=unsigned; };
}
<end quote>
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, since if you add a field
at the beginning, it will become the zeroeth field of course.
Will it compile?
Well, if you insert a std::string at the beginning it WILL COMPILE since
the type of the first field is unchaged: it was std::string and REMAINS
std::string.
Now, let me make two remarks here:
1: We are speaking of just syntactic sugar for avoiding using two new
variables and some typing... To avoid that you type MUCH MORE NOW since
you have to define those 3 items I mentioned above and that is surely a
LOT of more typing.
2: Note that the names are "bound" to the fields of an anonymous object
created by the compiler? They are (excuse for this) what we would write in C
#define name tmp.name
#define age tmp.age
where the "tmp" is a name give,n by the compiler and invisible to the
program as written.
Is that name captured by a lambda expression?
Since you told me I do not know C++ I will leave to you the answer to
that question, since you obviously know more C++ than me.
Coming back to the problem at hand, we see that to save a trivial typing
(Mr Tib proposed it in this thread)
for (auto const& e : mapCityPopulation) {
char const* city = e.first.c_str();
int population = e.second;
std::cout << city << ": " << population << '\n';
}
there is more to type and figure out, and a complex interface of several
templates and definitions needs to be constructed!
What has been gained by adding this enormous complexity?
That is my question, that remains. I hope that I answered yours:
YES, THE CODE WILL SILENTLY COMPILE WRONG STUFF.
Q.E.D
[toc] | [prev] | [next] | [standalone]
| From | Sam <sam@email-scan.com> |
|---|---|
| Date | 2020-03-14 18:33 -0400 |
| Message-ID | <cone.1584225189.853398.8962.1004@monster.email-scan.com> |
| In reply to | #72295 |
[Multipart message — attachments visible in raw view] — view raw
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,
Which will now be a completely different class, and this will guarantee a
compilation error, until this is fixed.
A new field will change the size of the tuple binding.
This means that all existing code that uses structured bindings for these
values from the function that returns it, like:
auto &[name, age]=some_function_that_returns_UserEntry();
If and when a third field gets added to this UserEntry, and gets exposed via
structured bindings, this specific binding will now FAIL. Guaranteed. No
chance of miscompilation. Even if the name field is now index #1, and age is
index #2 and the new field is the same data type as name, and index 0.
So, there are now at least two different reasons why this will cause a
compilation error, and why the original claim is still 100% bullshit.
> since if you add a field at the
> beginning, it will become the zeroeth field of course.
>
> Will it compile?
No.
> Well, if you insert a std::string at the beginning it WILL COMPILE since the
> type of the first field is unchaged: it was std::string and REMAINS
> std::string.
None of the existing structured bindings will compile. They're all binding
two elements, instead of three.
Fail.
But what about pre-C++17 code that uses `std::get` to bind individual
elements?
Well, as the old joke goes: "Doctor, it hurts when I move my arm this way".
"Well, don't move your arm this way, then".
With a
auto &[value1, value2]=
structured binding, you are guaranteed a compilation failure when a new
binding gets added or removed. That's one preventative measure that's the
simplest solution. Use structured bindings this way, and any new bindings is
a guaranteed compilation failure.
Now, what about code that uses "std::get<>" indexes directly? Perhaps you
were only aware of the std::get<>-based version of structured bindings, and
you weren't aware of this, C++17 structured bindings?
That's ok. A reliable solution is still simple. Let's say you wanted, for
whatever reason, for a new std::string to take place of the existing
std::string name that std::get<0> gives you, in this situation.
Of course, the easiest solution is to return the new value as std::get<2>, a
new binding. But let's say you're stubborn and want to add a new one as
std::get<0> and shift the rest. And you want to guarantee a compilation
error?
Well, since you haven't yet written any new code that will use this new
field, you just declare one that's guaranteed to miscompile with any code
that uses the existing std::get<0> in any observable way:
class surname_t {
public:
surname_t(const surname_t &)=delete;
surname_t &operator=(const surname_t &)=delete;
};
Now, define this as your new std::get<0> binding. Compile the end result,
and have your compiler find all the existing usage of std::get<0> for you to
fix. It's going to be a bit difficult to assign it to a std::string. Even
with
auto name=std::get<0>(object);
Whatever subsequent code uses it next will fail. At some point, anything
that expects a std::string here will not find it. Only if this name isn't
used anywhere will let this slip through. But who cares, in that case.
It also seems to me that defining a
template <size_t I> auto get(const UserEntry& u) {
// …
}
is not required. One can simply declare a
template <size_t I> auto get(const UserEntry& u);
and then simply specialize it:
template<> auto get<(size_t)0>(const UserEntry &u)
{
return u.getName();
}
and so on, for the rest.
Now, one can easily respecialize that one as get<1>, leaving get<0>
completely unspecified, and thusly find all existing code that refers to it.
This will guarantee that no references to std::get<0> from existing code
will remain.
Now, you may find some existing code, perhaps something that uses
std::apply, that will now completely fail. But it'll need changing in any
case, to handle the new binding properly, so you can temporarily stub it
out, and put it back when the binding is completed.
And once now the existing code compiles, you've proven that you have no code
that uses the former std::get<0>, as a std::string, or anything else, so now
you're free to bind std::get<0> to an actual, new, std::string, with no
possibility of overlooking some existing reference.
But, even better, you should take this as an opportunity to find every
existing instance of direct usage of std::get<> (since std::get<1> of age,
that was getting an int before, will now be seeing a std::string, and fail),
and replace them with proper structured bindings:
auto &[surname, name, age]=whatever().
I would expect every modern compiler to completely optimize away whichever of
these are not actually used, so they come as cost-free, and future additions
to the structurally-bound class will not require a wrapper class, like this.
> Since you told me I do not know C++ I will leave to you the answer to that
> question, since you obviously know more C++ than me.
Yes, it does seem that I do. I have done precisely things of this nature
safely, and with 0 resulting defects. You just have to understand that these
kinds of breaking API changes should be done in a way that guarantees a
compilation error from any existing code that needs to change, and then have
the compiler find every occurence that needs changing, for you.
It is not difficult to cause a C++ compilation error in existing code. One
of the easiest things to do, in C++.
It is true that you just can't rebind, in this specific example, of
std::get<0> directly to std::string, and rely on the human factor to hunt
down all existing usage of it. You have to force a compilation error, and
have the compiler do it for you. That's what you will need to do, and if it
takes any amount of effort to do it, you make sure that the next time you
have to do it, it won't take much effort at all.
Now, perhaps you can prove that you know more than me here, and think of
some situation where a stub wrapper like this will not cause a compilation
error, but will still have observable changes. But, I'm pretty sure I can
come up with something that will also force a compilation error, in that
case.
> What has been gained by adding this enormous complexity?
The need to avoid declaring a bunch of helper classes, for one. Structured
bindings are not simply about declaring specialization of std::get. It's
much more than that. For example, if one needs to have a function or a
method return two discrete values, no need to declare a new helper class,
just a
std::tuple<int, const char *> so_long()
{
return {42, "And thanks for all the fish"};
}
And then simply get two natural objects from
auto [answer, mostly_harmless] = so_long();
Suddenly, it now becomes much easier for functions to actually return two,
or more, objects, without wearing out one's keyboard.
And by following this model, if so_long() ever needs to return three values,
just do it, and your C++ compiler will find all callers, guaranteed.
> That is my question, that remains. I hope that I answered yours:
>
> YES, THE CODE WILL SILENTLY COMPILE WRONG STUFF.
Sorry. That's still 100% bullshit. It is not difficult to prove that no
existing code will "compile wrong stuff". Not if you actually know C++, and
know how to use it correctly. Now, can you please pay attention, when
someone's teaching you C++?
If you'd like to prove me wrong, give me an example of an existing
structured binding, its existing usage, in some way, and tell me to rebind
the usage to a different one, and I'm confident I'll find a way to change
the binding, temporarily, to make the existing usage ill-formed, and not
compilable.
Nobody ever claimed that rebinding an existing structured binding can be
done in one step, with guaranteed error-free results. Just that there's
always a way to find all existing usage of structured bindings, and force a
compilation error until it's fixed to use the new binding, even a temporary
one, a wrapper of some sorts, that can be quickly dropped after all existing
code is converted.
In my experience, the worst case scenario is where I had to force a
compilation error twice: once in all existing code that used structured
bindings, converting it to temporary scaffolding; and a second time after
the temporary scaffolding gets removed, and the new structured binding gets
put in place.
But there's always a guaranteed way to get a compilation failure, and not
"SILENTLY COMPILE WRONG STUFF" (see, I can use the CAPS LOCK key too).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-03-15 17:50 +0100 |
| Message-ID | <r4lmbv$b7h$1@news.albasani.net> |
| In reply to | #72243 |
> What happens when the class is modified to have a new field? That's not different than with a single type you're iterating through changes. So where's the problem ?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-03-16 00:11 +0100 |
| Message-ID | <r4mcne$j8h$1@dont-email.me> |
| In reply to | #72305 |
Le 15/03/2020 à 17:50, Bonita Montero a écrit :
>> What happens when the class is modified to have a new field?
>
> That's not different than with a single type you're
> iterating through changes. So where's the problem ?
In this code
for (auto const& e : mapCityPopulation) {
char const* city = e.first.c_str();
int population = e.second;
std::cout << city << ": " << population << '\n';
}
Forget for a moment that map has two fields and assume a general class.
When this assignment is written as such, only the fields needed are
accessed.
No assumptions are done about the other fields of the class.
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.
Instead of accessing just what you need, you end up accessing ALL the
class since you create an anonymous object to which "bindings" are done.
All that unnecessary machinery just to give you
MORE SYNTACTIC SUGAR.
C++ has enough of that. Do you really need to add more? For an end
result that is more complex to write and maintain?
What has been gained with all that machinery?
You have to write your "get" templates that receive the index of the
field, the specification template for the number of fields in the
claass, all that stuff!
Using the more verbose but simpler code if any irrelevant field is
addded to the class you do not access it and your code is inmune to
those changes!
You see the problem now?
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web