What if size argument for std::vector::resize is equal to the current size?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}

Reading the manual about vector::resize http://www.cplusplus.com/reference/vector/vector/resize/

It only says what happens if the size is greater or smaller, but does not say what happens if it's equal. Is it guaranteed that on equal size it will not reallocate the array and invalidate the iterators?

I wanted to avoid one branch and handle only 2 cases (>= or <) instead of 3 (< or > or ==), but if resizing to same size is undefined, then i will have to check that case too.

asked Nov 23 '18 at 13:12

Youda008

484517

Given the info in the part "Exception safety", you can safely assume there is no reallocation on resize with the size being equal the the current size of the vector.

– Croolman
Nov 23 '18 at 13:19

The std::vector<> class is a template class, so you have the source code on your computer. You could look for yourself. Or you could write a test program and debug that. Or look at the assembler code that is generated. Or make a vector of a class that prints information when the copy constructor and/or the move constructor is called, and then see what happens. Besides that, I'm pretty sure that this case is checked in the vector's implementation and nothing is done then.

– Rene
Nov 23 '18 at 13:25

Don't read cplusplus.com, it's known to be wrong on several occassions.

– n.m.
Nov 23 '18 at 13:28

@n.m. note that in this case also cppreference is not clear on iterator invalidation. It has a note that "Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, ..." but its not clearly states what iterators are invalidated in general

– user463035818
Nov 23 '18 at 13:30

2

If "same-size resizing" had any effect at all, it would be time for the entire C++ committee and the language implementers to retire.

– molbdnilo
Nov 23 '18 at 14:18

add a comment |

Reading the manual about vector::resize http://www.cplusplus.com/reference/vector/vector/resize/

I wanted to avoid one branch and handle only 2 cases (>= or <) instead of 3 (< or > or ==), but if resizing to same size is undefined, then i will have to check that case too.

asked Nov 23 '18 at 13:12

Youda008

484517

Given the info in the part "Exception safety", you can safely assume there is no reallocation on resize with the size being equal the the current size of the vector.

– Croolman
Nov 23 '18 at 13:19

The std::vector<> class is a template class, so you have the source code on your computer. You could look for yourself. Or you could write a test program and debug that. Or look at the assembler code that is generated. Or make a vector of a class that prints information when the copy constructor and/or the move constructor is called, and then see what happens. Besides that, I'm pretty sure that this case is checked in the vector's implementation and nothing is done then.

– Rene
Nov 23 '18 at 13:25

Don't read cplusplus.com, it's known to be wrong on several occassions.

– n.m.
Nov 23 '18 at 13:28

@n.m. note that in this case also cppreference is not clear on iterator invalidation. It has a note that "Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, ..." but its not clearly states what iterators are invalidated in general

– user463035818
Nov 23 '18 at 13:30

2

If "same-size resizing" had any effect at all, it would be time for the entire C++ committee and the language implementers to retire.

– molbdnilo
Nov 23 '18 at 14:18

add a comment |

Reading the manual about vector::resize http://www.cplusplus.com/reference/vector/vector/resize/

I wanted to avoid one branch and handle only 2 cases (>= or <) instead of 3 (< or > or ==), but if resizing to same size is undefined, then i will have to check that case too.

asked Nov 23 '18 at 13:12

Youda008

484517

Reading the manual about vector::resize http://www.cplusplus.com/reference/vector/vector/resize/

I wanted to avoid one branch and handle only 2 cases (>= or <) instead of 3 (< or > or ==), but if resizing to same size is undefined, then i will have to check that case too.

c++ vector containers dynamic-memory-allocation

asked Nov 23 '18 at 13:12

Youda008

484517

asked Nov 23 '18 at 13:12

Youda008

484517

asked Nov 23 '18 at 13:12

Youda008

484517

asked Nov 23 '18 at 13:12

Youda008

484517

asked Nov 23 '18 at 13:12

Youda008

484517

Given the info in the part "Exception safety", you can safely assume there is no reallocation on resize with the size being equal the the current size of the vector.

– Croolman
Nov 23 '18 at 13:19

The std::vector<> class is a template class, so you have the source code on your computer. You could look for yourself. Or you could write a test program and debug that. Or look at the assembler code that is generated. Or make a vector of a class that prints information when the copy constructor and/or the move constructor is called, and then see what happens. Besides that, I'm pretty sure that this case is checked in the vector's implementation and nothing is done then.

– Rene
Nov 23 '18 at 13:25

Don't read cplusplus.com, it's known to be wrong on several occassions.

– n.m.
Nov 23 '18 at 13:28

@n.m. note that in this case also cppreference is not clear on iterator invalidation. It has a note that "Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, ..." but its not clearly states what iterators are invalidated in general

– user463035818
Nov 23 '18 at 13:30

2

If "same-size resizing" had any effect at all, it would be time for the entire C++ committee and the language implementers to retire.

– molbdnilo
Nov 23 '18 at 14:18

add a comment |

Given the info in the part "Exception safety", you can safely assume there is no reallocation on resize with the size being equal the the current size of the vector.

– Croolman
Nov 23 '18 at 13:19

The std::vector<> class is a template class, so you have the source code on your computer. You could look for yourself. Or you could write a test program and debug that. Or look at the assembler code that is generated. Or make a vector of a class that prints information when the copy constructor and/or the move constructor is called, and then see what happens. Besides that, I'm pretty sure that this case is checked in the vector's implementation and nothing is done then.

– Rene
Nov 23 '18 at 13:25

Don't read cplusplus.com, it's known to be wrong on several occassions.

– n.m.
Nov 23 '18 at 13:28

@n.m. note that in this case also cppreference is not clear on iterator invalidation. It has a note that "Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, ..." but its not clearly states what iterators are invalidated in general

– user463035818
Nov 23 '18 at 13:30

2

If "same-size resizing" had any effect at all, it would be time for the entire C++ committee and the language implementers to retire.

– molbdnilo
Nov 23 '18 at 14:18

Given the info in the part "Exception safety", you can safely assume there is no reallocation on resize with the size being equal the the current size of the vector.

– Croolman
Nov 23 '18 at 13:19

The std::vector<> class is a template class, so you have the source code on your computer. You could look for yourself. Or you could write a test program and debug that. Or look at the assembler code that is generated. Or make a vector of a class that prints information when the copy constructor and/or the move constructor is called, and then see what happens. Besides that, I'm pretty sure that this case is checked in the vector's implementation and nothing is done then.

– Rene
Nov 23 '18 at 13:25

Don't read cplusplus.com, it's known to be wrong on several occassions.

– n.m.
Nov 23 '18 at 13:28

@n.m. note that in this case also cppreference is not clear on iterator invalidation. It has a note that "Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, ..." but its not clearly states what iterators are invalidated in general

– user463035818
Nov 23 '18 at 13:30

If "same-size resizing" had any effect at all, it would be time for the entire C++ committee and the language implementers to retire.

– molbdnilo
Nov 23 '18 at 14:18

add a comment |

5 Answers
5

active

oldest

votes

This is probably just an error in the linked reference. The standard says following:

void resize(size_type sz);

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

Since sz - size() is 0 in your case, it doesn't do anything.

answered Nov 23 '18 at 13:28

Zereges

3,82711540

add a comment |

From [vector]

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

In the case that size() == sz it inserts 0 elements into the sequence, which is the same as doing nothing.

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

add a comment |

Now, probably most implementations are sufficiently intelligent about the case where nothing needs to be done and will literally do nothing.

But I am asking myself, you are intending to call resize, why are you holding iterators anyway? Basically, you should never hold iterators for any longer time, especially when containers may get resized. Just write your algorithms in ways that don't need to hold iterators over the resize point.

I am guessing wildly here, but maybe you are not using the right container and more context about what you are trying to achieve may result in a more useful answer.

answered Nov 23 '18 at 13:25

rioki

4,16442448

add a comment |

It seems like you're asking if iterators will be invalidated when resize(size()) is called. The answer is no, iterators will not be invalidated. Probably very little will happen at all, but certainly not iterator invalidation, because that only happens when the storage has to be reallocated, which would never happen if the resize is a no-op.

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

add a comment |

-1

std::vector<> implementation:

void resize(size_type __new_size)

{

    if (__new_size > size())

        _M_default_append(__new_size - size());

    else if (__new_size < size())

        _M_erase_at_end(this->_M_impl._M_start + __new_size);

}

So, as expected: It does nothing.

Edit:

Taken from my RHEL server, g++ and C++ library package version 5.3.

edited Nov 23 '18 at 13:35

answered Nov 23 '18 at 13:27

Rene

1,8761617

thats one possible implementation (you should give a reference where you took it from btw), but you cannot conclude that every implementation has to behave like that only because this one does

– user463035818
Nov 23 '18 at 13:28

Unfortunately, my code will be compiling for several different architectures with different compilers, i cannot rely on what i can find in headers on my current computer.

– Youda008
Nov 23 '18 at 15:46

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

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53447386%2fwhat-if-size-argument-for-stdvectorresize-is-equal-to-the-current-size%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

5 Answers
5

active

oldest

votes

5 Answers
5

active

oldest

votes

This is probably just an error in the linked reference. The standard says following:

void resize(size_type sz);

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

Since sz - size() is 0 in your case, it doesn't do anything.

answered Nov 23 '18 at 13:28

Zereges

3,82711540

add a comment |

This is probably just an error in the linked reference. The standard says following:

void resize(size_type sz);

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

Since sz - size() is 0 in your case, it doesn't do anything.

answered Nov 23 '18 at 13:28

Zereges

3,82711540

add a comment |

This is probably just an error in the linked reference. The standard says following:

void resize(size_type sz);

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

Since sz - size() is 0 in your case, it doesn't do anything.

answered Nov 23 '18 at 13:28

Zereges

3,82711540

This is probably just an error in the linked reference. The standard says following:

void resize(size_type sz);

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

Since sz - size() is 0 in your case, it doesn't do anything.

answered Nov 23 '18 at 13:28

Zereges

3,82711540

answered Nov 23 '18 at 13:28

Zereges

3,82711540

answered Nov 23 '18 at 13:28

Zereges

3,82711540

answered Nov 23 '18 at 13:28

Zereges

3,82711540

add a comment |

From [vector]

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

In the case that size() == sz it inserts 0 elements into the sequence, which is the same as doing nothing.

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

add a comment |

From [vector]

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

In the case that size() == sz it inserts 0 elements into the sequence, which is the same as doing nothing.

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

add a comment |

From [vector]

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

In the case that size() == sz it inserts 0 elements into the sequence, which is the same as doing nothing.

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

From [vector]

Effects: If sz < size(), erases the last size() - sz elements from the sequence. Otherwise, appends sz - size() default-inserted elements to the sequence.

In the case that size() == sz it inserts 0 elements into the sequence, which is the same as doing nothing.

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

answered Nov 23 '18 at 13:30

Caleth

18.8k22142

add a comment |

Now, probably most implementations are sufficiently intelligent about the case where nothing needs to be done and will literally do nothing.

I am guessing wildly here, but maybe you are not using the right container and more context about what you are trying to achieve may result in a more useful answer.

answered Nov 23 '18 at 13:25

rioki

4,16442448

add a comment |

Now, probably most implementations are sufficiently intelligent about the case where nothing needs to be done and will literally do nothing.

I am guessing wildly here, but maybe you are not using the right container and more context about what you are trying to achieve may result in a more useful answer.

answered Nov 23 '18 at 13:25

rioki

4,16442448

add a comment |

Now, probably most implementations are sufficiently intelligent about the case where nothing needs to be done and will literally do nothing.

I am guessing wildly here, but maybe you are not using the right container and more context about what you are trying to achieve may result in a more useful answer.

answered Nov 23 '18 at 13:25

rioki

4,16442448

Now, probably most implementations are sufficiently intelligent about the case where nothing needs to be done and will literally do nothing.

I am guessing wildly here, but maybe you are not using the right container and more context about what you are trying to achieve may result in a more useful answer.

answered Nov 23 '18 at 13:25

rioki

4,16442448

answered Nov 23 '18 at 13:25

rioki

4,16442448

answered Nov 23 '18 at 13:25

rioki

4,16442448

answered Nov 23 '18 at 13:25

rioki

4,16442448

add a comment |

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

add a comment |

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

add a comment |

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

answered Nov 23 '18 at 13:19

John Zwinck

155k17181299

add a comment |

-1

std::vector<> implementation:

void resize(size_type __new_size)

{

    if (__new_size > size())

        _M_default_append(__new_size - size());

    else if (__new_size < size())

        _M_erase_at_end(this->_M_impl._M_start + __new_size);

}

So, as expected: It does nothing.

Edit:

Taken from my RHEL server, g++ and C++ library package version 5.3.

edited Nov 23 '18 at 13:35

answered Nov 23 '18 at 13:27

Rene

1,8761617

thats one possible implementation (you should give a reference where you took it from btw), but you cannot conclude that every implementation has to behave like that only because this one does

– user463035818
Nov 23 '18 at 13:28

Unfortunately, my code will be compiling for several different architectures with different compilers, i cannot rely on what i can find in headers on my current computer.

– Youda008
Nov 23 '18 at 15:46

add a comment |

-1

std::vector<> implementation:

void resize(size_type __new_size)

{

    if (__new_size > size())

        _M_default_append(__new_size - size());

    else if (__new_size < size())

        _M_erase_at_end(this->_M_impl._M_start + __new_size);

}

So, as expected: It does nothing.

Edit:

Taken from my RHEL server, g++ and C++ library package version 5.3.

edited Nov 23 '18 at 13:35

answered Nov 23 '18 at 13:27

Rene

1,8761617

thats one possible implementation (you should give a reference where you took it from btw), but you cannot conclude that every implementation has to behave like that only because this one does

– user463035818
Nov 23 '18 at 13:28

Unfortunately, my code will be compiling for several different architectures with different compilers, i cannot rely on what i can find in headers on my current computer.

– Youda008
Nov 23 '18 at 15:46

add a comment |

-1

std::vector<> implementation:

void resize(size_type __new_size)

{

    if (__new_size > size())

        _M_default_append(__new_size - size());

    else if (__new_size < size())

        _M_erase_at_end(this->_M_impl._M_start + __new_size);

}

So, as expected: It does nothing.

Edit:

Taken from my RHEL server, g++ and C++ library package version 5.3.

edited Nov 23 '18 at 13:35

answered Nov 23 '18 at 13:27

Rene

1,8761617

std::vector<> implementation:

void resize(size_type __new_size)

{

    if (__new_size > size())

        _M_default_append(__new_size - size());

    else if (__new_size < size())

        _M_erase_at_end(this->_M_impl._M_start + __new_size);

}

So, as expected: It does nothing.

Edit:

Taken from my RHEL server, g++ and C++ library package version 5.3.

edited Nov 23 '18 at 13:35

answered Nov 23 '18 at 13:27

Rene

1,8761617

edited Nov 23 '18 at 13:35

answered Nov 23 '18 at 13:27

Rene

1,8761617

answered Nov 23 '18 at 13:27

Rene

1,8761617

answered Nov 23 '18 at 13:27

Rene

1,8761617

thats one possible implementation (you should give a reference where you took it from btw), but you cannot conclude that every implementation has to behave like that only because this one does

– user463035818
Nov 23 '18 at 13:28

Unfortunately, my code will be compiling for several different architectures with different compilers, i cannot rely on what i can find in headers on my current computer.

– Youda008
Nov 23 '18 at 15:46

add a comment |

thats one possible implementation (you should give a reference where you took it from btw), but you cannot conclude that every implementation has to behave like that only because this one does

– user463035818
Nov 23 '18 at 13:28

Unfortunately, my code will be compiling for several different architectures with different compilers, i cannot rely on what i can find in headers on my current computer.

– Youda008
Nov 23 '18 at 15:46

thats one possible implementation (you should give a reference where you took it from btw), but you cannot conclude that every implementation has to behave like that only because this one does

– user463035818
Nov 23 '18 at 13:28

Unfortunately, my code will be compiling for several different architectures with different compilers, i cannot rely on what i can find in headers on my current computer.

– Youda008
Nov 23 '18 at 15:46

add a comment |

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

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Argthtjtr