Does the C++ standard require operator != must be provided for a given iterator type?












0















The C++17 standard 27.2.1.8 says:




An iterator j is called reachable from an iterator i if and only if
there is a finite sequence of applications of the expression ++i that
makes i == j.




That is to say, any conforming iterator type must provide operator ==.



However, I find nothing about operator != is a requirement for iterator types.



Does the C++ standard require operator != must be provided for a given iterator type?










share|improve this question




















  • 3





    "That is to say, any conforming iterator type must provide operator ==." That's not where the requirement for operator== is spelled out. Requirements tend to be in tables.

    – Nicol Bolas
    Nov 28 '18 at 3:44


















0















The C++17 standard 27.2.1.8 says:




An iterator j is called reachable from an iterator i if and only if
there is a finite sequence of applications of the expression ++i that
makes i == j.




That is to say, any conforming iterator type must provide operator ==.



However, I find nothing about operator != is a requirement for iterator types.



Does the C++ standard require operator != must be provided for a given iterator type?










share|improve this question




















  • 3





    "That is to say, any conforming iterator type must provide operator ==." That's not where the requirement for operator== is spelled out. Requirements tend to be in tables.

    – Nicol Bolas
    Nov 28 '18 at 3:44
















0












0








0








The C++17 standard 27.2.1.8 says:




An iterator j is called reachable from an iterator i if and only if
there is a finite sequence of applications of the expression ++i that
makes i == j.




That is to say, any conforming iterator type must provide operator ==.



However, I find nothing about operator != is a requirement for iterator types.



Does the C++ standard require operator != must be provided for a given iterator type?










share|improve this question
















The C++17 standard 27.2.1.8 says:




An iterator j is called reachable from an iterator i if and only if
there is a finite sequence of applications of the expression ++i that
makes i == j.




That is to say, any conforming iterator type must provide operator ==.



However, I find nothing about operator != is a requirement for iterator types.



Does the C++ standard require operator != must be provided for a given iterator type?







c++ iterator standards semantics typetraits






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 28 '18 at 4:16







xmllmx

















asked Nov 28 '18 at 3:34









xmllmxxmllmx

13.9k988212




13.9k988212








  • 3





    "That is to say, any conforming iterator type must provide operator ==." That's not where the requirement for operator== is spelled out. Requirements tend to be in tables.

    – Nicol Bolas
    Nov 28 '18 at 3:44
















  • 3





    "That is to say, any conforming iterator type must provide operator ==." That's not where the requirement for operator== is spelled out. Requirements tend to be in tables.

    – Nicol Bolas
    Nov 28 '18 at 3:44










3




3





"That is to say, any conforming iterator type must provide operator ==." That's not where the requirement for operator== is spelled out. Requirements tend to be in tables.

– Nicol Bolas
Nov 28 '18 at 3:44







"That is to say, any conforming iterator type must provide operator ==." That's not where the requirement for operator== is spelled out. Requirements tend to be in tables.

– Nicol Bolas
Nov 28 '18 at 3:44














1 Answer
1






active

oldest

votes


















6














See C++17 [input.iterators]/2 Table 95 "Input iterator requirements".



Input iterators require that a != b is valid and behaves the same as !(a == b) if the latter is valid. Link to cppreference.com summary



Output iterators do not need to support either operation.






share|improve this answer


























  • It looks like it's table 95 in n4659, which is supposed to be the same as the C++17 standard except minor editorial changes. Is that a typo, or did "minor editorial changes" really change the numbering by 19 places? Also, here's a link to the relevant part of an HTML version of n4659.

    – Daniel H
    Nov 28 '18 at 4:23













  • @DanielH thanks, I'd accidentally loaded up a later draft

    – M.M
    Nov 28 '18 at 4:27











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
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53511718%2fdoes-the-c-standard-require-operator-must-be-provided-for-a-given-iterator%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









6














See C++17 [input.iterators]/2 Table 95 "Input iterator requirements".



Input iterators require that a != b is valid and behaves the same as !(a == b) if the latter is valid. Link to cppreference.com summary



Output iterators do not need to support either operation.






share|improve this answer


























  • It looks like it's table 95 in n4659, which is supposed to be the same as the C++17 standard except minor editorial changes. Is that a typo, or did "minor editorial changes" really change the numbering by 19 places? Also, here's a link to the relevant part of an HTML version of n4659.

    – Daniel H
    Nov 28 '18 at 4:23













  • @DanielH thanks, I'd accidentally loaded up a later draft

    – M.M
    Nov 28 '18 at 4:27
















6














See C++17 [input.iterators]/2 Table 95 "Input iterator requirements".



Input iterators require that a != b is valid and behaves the same as !(a == b) if the latter is valid. Link to cppreference.com summary



Output iterators do not need to support either operation.






share|improve this answer


























  • It looks like it's table 95 in n4659, which is supposed to be the same as the C++17 standard except minor editorial changes. Is that a typo, or did "minor editorial changes" really change the numbering by 19 places? Also, here's a link to the relevant part of an HTML version of n4659.

    – Daniel H
    Nov 28 '18 at 4:23













  • @DanielH thanks, I'd accidentally loaded up a later draft

    – M.M
    Nov 28 '18 at 4:27














6












6








6







See C++17 [input.iterators]/2 Table 95 "Input iterator requirements".



Input iterators require that a != b is valid and behaves the same as !(a == b) if the latter is valid. Link to cppreference.com summary



Output iterators do not need to support either operation.






share|improve this answer















See C++17 [input.iterators]/2 Table 95 "Input iterator requirements".



Input iterators require that a != b is valid and behaves the same as !(a == b) if the latter is valid. Link to cppreference.com summary



Output iterators do not need to support either operation.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 28 '18 at 4:26

























answered Nov 28 '18 at 3:40









M.MM.M

106k11119242




106k11119242













  • It looks like it's table 95 in n4659, which is supposed to be the same as the C++17 standard except minor editorial changes. Is that a typo, or did "minor editorial changes" really change the numbering by 19 places? Also, here's a link to the relevant part of an HTML version of n4659.

    – Daniel H
    Nov 28 '18 at 4:23













  • @DanielH thanks, I'd accidentally loaded up a later draft

    – M.M
    Nov 28 '18 at 4:27



















  • It looks like it's table 95 in n4659, which is supposed to be the same as the C++17 standard except minor editorial changes. Is that a typo, or did "minor editorial changes" really change the numbering by 19 places? Also, here's a link to the relevant part of an HTML version of n4659.

    – Daniel H
    Nov 28 '18 at 4:23













  • @DanielH thanks, I'd accidentally loaded up a later draft

    – M.M
    Nov 28 '18 at 4:27

















It looks like it's table 95 in n4659, which is supposed to be the same as the C++17 standard except minor editorial changes. Is that a typo, or did "minor editorial changes" really change the numbering by 19 places? Also, here's a link to the relevant part of an HTML version of n4659.

– Daniel H
Nov 28 '18 at 4:23







It looks like it's table 95 in n4659, which is supposed to be the same as the C++17 standard except minor editorial changes. Is that a typo, or did "minor editorial changes" really change the numbering by 19 places? Also, here's a link to the relevant part of an HTML version of n4659.

– Daniel H
Nov 28 '18 at 4:23















@DanielH thanks, I'd accidentally loaded up a later draft

– M.M
Nov 28 '18 at 4:27





@DanielH thanks, I'd accidentally loaded up a later draft

– M.M
Nov 28 '18 at 4:27




















draft saved

draft discarded




















































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.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53511718%2fdoes-the-c-standard-require-operator-must-be-provided-for-a-given-iterator%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

Contact image not getting when fetch all contact list from iPhone by CNContact

count number of partitions of a set with n elements into k subsets

A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks