New iterator requirements
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:
iterator
LegacyRandomAccessIterator
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
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:
iterator
LegacyRandomAccessIterator
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
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
1 hour ago
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:
iterator
LegacyRandomAccessIterator
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
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:
iterator
LegacyRandomAccessIterator
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 2 hours ago
Will Vousden
24.6k86186
24.6k86186
asked 2 hours ago
Sombrero Chicken
23.2k33076
23.2k33076
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
1 hour ago
add a comment |
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
1 hour ago
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
1 hour ago
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
1 hour ago
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.
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
2 hours ago
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.
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
2 hours ago
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.
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
2 hours ago
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.
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.
answered 2 hours ago
Nicol Bolas
282k33464640
282k33464640
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
2 hours ago
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
2 hours ago
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
2 hours ago
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
2 hours ago
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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
Note that the old and new iterator requirements do have some differences: Why aren't ranges' algorithms compatible with std's iterators?
– cpplearner
1 hour ago