New iterator requirements
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I noticed that most if not all containers now require their ::iterator type to satisfy LegacySomethingIterator instead of SomethingIterator.
For example, std::vector<>::iterator now requires:
iteratorLegacyRandomAccessIterator
This seems to be the same for most of the other containers, all requiring their iterators to go from SomethingIterator to LegacySomethingIterator.
There are also the "new" requirements that took the names of the old requirements, such as RandomAccessIterator, why were these added? It seems to me that the new variants just shadow the legacy variants, no differences.
Why were new ones created in the first place, their requirements look the same to me. Why don't the new ones just replace the old requirements instead of right now having 2 different names for them (e.g. RandomAccessIterator and LegacyRandomAccessIterator)?
c++ c++-concepts c++20
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
add a comment |
I noticed that most if not all containers now require their ::iterator type to satisfy LegacySomethingIterator instead of SomethingIterator.
For example, std::vector<>::iterator now requires:
iteratorLegacyRandomAccessIterator
This seems to be the same for most of the other containers, all requiring their iterators to go from SomethingIterator to LegacySomethingIterator.
There are also the "new" requirements that took the names of the old requirements, such as RandomAccessIterator, why were these added? It seems to me that the new variants just shadow the legacy variants, no differences.
Why were new ones created in the first place, their requirements look the same to me. Why don't the new ones just replace the old requirements instead of right now having 2 different names for them (e.g. RandomAccessIterator and LegacyRandomAccessIterator)?
c++ c++-concepts c++20
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
1
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
Dec 29 '18 at 16:41
add a comment |
I noticed that most if not all containers now require their ::iterator type to satisfy LegacySomethingIterator instead of SomethingIterator.
For example, std::vector<>::iterator now requires:
iteratorLegacyRandomAccessIterator
This seems to be the same for most of the other containers, all requiring their iterators to go from SomethingIterator to LegacySomethingIterator.
There are also the "new" requirements that took the names of the old requirements, such as RandomAccessIterator, why were these added? It seems to me that the new variants just shadow the legacy variants, no differences.
Why were new ones created in the first place, their requirements look the same to me. Why don't the new ones just replace the old requirements instead of right now having 2 different names for them (e.g. RandomAccessIterator and LegacyRandomAccessIterator)?
c++ c++-concepts c++20
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
I noticed that most if not all containers now require their ::iterator type to satisfy LegacySomethingIterator instead of SomethingIterator.
For example, std::vector<>::iterator now requires:
iteratorLegacyRandomAccessIterator
This seems to be the same for most of the other containers, all requiring their iterators to go from SomethingIterator to LegacySomethingIterator.
There are also the "new" requirements that took the names of the old requirements, such as RandomAccessIterator, why were these added? It seems to me that the new variants just shadow the legacy variants, no differences.
Why were new ones created in the first place, their requirements look the same to me. Why don't the new ones just replace the old requirements instead of right now having 2 different names for them (e.g. RandomAccessIterator and LegacyRandomAccessIterator)?
c++ c++-concepts c++20
c++ c++-concepts c++20
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
edited Dec 29 '18 at 15:32
Will Vousden
25.3k86486
25.3k86486
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
asked Dec 29 '18 at 15:15
Sombrero ChickenSombrero Chicken
24.9k33381
24.9k33381
1
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
Dec 29 '18 at 16:41
add a comment |
1
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
Dec 29 '18 at 16:41
1
1
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
Dec 29 '18 at 16:41
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
Dec 29 '18 at 16:41
add a comment |
1 Answer
1
active
oldest
votes
These are not new things, hence the term "legacy". This is simply how the cppreference site chooses to reconcile the fact that C++20 will have two different things that are both "concepts" called "RandomAccessIterator".
Pre-C++20, a "concept" was just a set of requirements in the standard that represented the behavior expected of certain template parameters. In C++20, with concepts becoming an actual language feature, that needed to shift. The problem is that the Ranges concept of "RandomAccessIterator" is not the same as the old-style "concept" of "RandomAccessIterator".
Since C++ considers them both to be "concepts" (though only the newer one is a concept in the language sense), they would both have the same page name on the Wiki. And MediaWiki doesn't really allow that.
So the maintainers of the site settled on using "Legacy" to differentiate them. Note that the actual standard doesn't use this "Legacy" prefix.
Note that the C++20 standard does have a prefix for the older concepts: "Cpp17". So the old concept would be "Cpp17RandomAccessIterator". That was not deemed appropriate for Cppreference for obvious reasons.
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
Haha that's funny. I actually edited out that part. My initial post had another question asking if the standard uses the term LegacyIterator but then I thought to myself it has to be because cppreference is always very standard compliant. Guess not in this case, thanks :)
– Sombrero Chicken
Dec 29 '18 at 15:37
6
@SombreroChicken The standard uses "Cpp17" as the prefix instead, but I don't want to document a C++98 component as requiring a Cpp17Thingamabob.
– T.C.
Dec 30 '18 at 21:39
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53970756%2fnew-iterator-requirements%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
These are not new things, hence the term "legacy". This is simply how the cppreference site chooses to reconcile the fact that C++20 will have two different things that are both "concepts" called "RandomAccessIterator".
Pre-C++20, a "concept" was just a set of requirements in the standard that represented the behavior expected of certain template parameters. In C++20, with concepts becoming an actual language feature, that needed to shift. The problem is that the Ranges concept of "RandomAccessIterator" is not the same as the old-style "concept" of "RandomAccessIterator".
Since C++ considers them both to be "concepts" (though only the newer one is a concept in the language sense), they would both have the same page name on the Wiki. And MediaWiki doesn't really allow that.
So the maintainers of the site settled on using "Legacy" to differentiate them. Note that the actual standard doesn't use this "Legacy" prefix.
Note that the C++20 standard does have a prefix for the older concepts: "Cpp17". So the old concept would be "Cpp17RandomAccessIterator". That was not deemed appropriate for Cppreference for obvious reasons.
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
Haha that's funny. I actually edited out that part. My initial post had another question asking if the standard uses the term LegacyIterator but then I thought to myself it has to be because cppreference is always very standard compliant. Guess not in this case, thanks :)
– Sombrero Chicken
Dec 29 '18 at 15:37
6
@SombreroChicken The standard uses "Cpp17" as the prefix instead, but I don't want to document a C++98 component as requiring a Cpp17Thingamabob.
– T.C.
Dec 30 '18 at 21:39
add a comment |
These are not new things, hence the term "legacy". This is simply how the cppreference site chooses to reconcile the fact that C++20 will have two different things that are both "concepts" called "RandomAccessIterator".
Pre-C++20, a "concept" was just a set of requirements in the standard that represented the behavior expected of certain template parameters. In C++20, with concepts becoming an actual language feature, that needed to shift. The problem is that the Ranges concept of "RandomAccessIterator" is not the same as the old-style "concept" of "RandomAccessIterator".
Since C++ considers them both to be "concepts" (though only the newer one is a concept in the language sense), they would both have the same page name on the Wiki. And MediaWiki doesn't really allow that.
So the maintainers of the site settled on using "Legacy" to differentiate them. Note that the actual standard doesn't use this "Legacy" prefix.
Note that the C++20 standard does have a prefix for the older concepts: "Cpp17". So the old concept would be "Cpp17RandomAccessIterator". That was not deemed appropriate for Cppreference for obvious reasons.
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
Haha that's funny. I actually edited out that part. My initial post had another question asking if the standard uses the term LegacyIterator but then I thought to myself it has to be because cppreference is always very standard compliant. Guess not in this case, thanks :)
– Sombrero Chicken
Dec 29 '18 at 15:37
6
@SombreroChicken The standard uses "Cpp17" as the prefix instead, but I don't want to document a C++98 component as requiring a Cpp17Thingamabob.
– T.C.
Dec 30 '18 at 21:39
add a comment |
These are not new things, hence the term "legacy". This is simply how the cppreference site chooses to reconcile the fact that C++20 will have two different things that are both "concepts" called "RandomAccessIterator".
Pre-C++20, a "concept" was just a set of requirements in the standard that represented the behavior expected of certain template parameters. In C++20, with concepts becoming an actual language feature, that needed to shift. The problem is that the Ranges concept of "RandomAccessIterator" is not the same as the old-style "concept" of "RandomAccessIterator".
Since C++ considers them both to be "concepts" (though only the newer one is a concept in the language sense), they would both have the same page name on the Wiki. And MediaWiki doesn't really allow that.
So the maintainers of the site settled on using "Legacy" to differentiate them. Note that the actual standard doesn't use this "Legacy" prefix.
Note that the C++20 standard does have a prefix for the older concepts: "Cpp17". So the old concept would be "Cpp17RandomAccessIterator". That was not deemed appropriate for Cppreference for obvious reasons.
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
These are not new things, hence the term "legacy". This is simply how the cppreference site chooses to reconcile the fact that C++20 will have two different things that are both "concepts" called "RandomAccessIterator".
Pre-C++20, a "concept" was just a set of requirements in the standard that represented the behavior expected of certain template parameters. In C++20, with concepts becoming an actual language feature, that needed to shift. The problem is that the Ranges concept of "RandomAccessIterator" is not the same as the old-style "concept" of "RandomAccessIterator".
Since C++ considers them both to be "concepts" (though only the newer one is a concept in the language sense), they would both have the same page name on the Wiki. And MediaWiki doesn't really allow that.
So the maintainers of the site settled on using "Legacy" to differentiate them. Note that the actual standard doesn't use this "Legacy" prefix.
Note that the C++20 standard does have a prefix for the older concepts: "Cpp17". So the old concept would be "Cpp17RandomAccessIterator". That was not deemed appropriate for Cppreference for obvious reasons.
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
edited Dec 30 '18 at 23:56
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
answered Dec 29 '18 at 15:29
Nicol BolasNicol Bolas
293k34483660
293k34483660
Haha that's funny. I actually edited out that part. My initial post had another question asking if the standard uses the term LegacyIterator but then I thought to myself it has to be because cppreference is always very standard compliant. Guess not in this case, thanks :)
– Sombrero Chicken
Dec 29 '18 at 15:37
6
@SombreroChicken The standard uses "Cpp17" as the prefix instead, but I don't want to document a C++98 component as requiring a Cpp17Thingamabob.
– T.C.
Dec 30 '18 at 21:39
add a comment |
Haha that's funny. I actually edited out that part. My initial post had another question asking if the standard uses the term LegacyIterator but then I thought to myself it has to be because cppreference is always very standard compliant. Guess not in this case, thanks :)
– Sombrero Chicken
Dec 29 '18 at 15:37
6
@SombreroChicken The standard uses "Cpp17" as the prefix instead, but I don't want to document a C++98 component as requiring a Cpp17Thingamabob.
– T.C.
Dec 30 '18 at 21:39
Haha that's funny. I actually edited out that part. My initial post had another question asking if the standard uses the term LegacyIterator but then I thought to myself it has to be because cppreference is always very standard compliant. Guess not in this case, thanks :)
– Sombrero Chicken
Dec 29 '18 at 15:37
Haha that's funny. I actually edited out that part. My initial post had another question asking if the standard uses the term LegacyIterator but then I thought to myself it has to be because cppreference is always very standard compliant. Guess not in this case, thanks :)
– Sombrero Chicken
Dec 29 '18 at 15:37
6
6
@SombreroChicken The standard uses "Cpp17" as the prefix instead, but I don't want to document a C++98 component as requiring a Cpp17Thingamabob.
– T.C.
Dec 30 '18 at 21:39
@SombreroChicken The standard uses "Cpp17" as the prefix instead, but I don't want to document a C++98 component as requiring a Cpp17Thingamabob.
– T.C.
Dec 30 '18 at 21:39
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53970756%2fnew-iterator-requirements%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
Dec 29 '18 at 16:41