Is std::string guaranteed not to give back memory spontaneously?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
6
down vote

favorite
2












Is it guaranteed by the standard that std::string will not give back allocated memory spontaneously if re-sized to a smaller size?



In other words:



std::string str = "Some quite long string, which needs a lot of memory";
str = "";
str = "A new quite long but smaller string"; // Guaranteed to not result in a heap allocation?


I ask because i'm depending on this to avoid heap fragmentation.






c++ language-lawyer heap-memory stdstring







share|improve this question























  • Not sure about the overloads, but; wouldn't it result in a new string, and hence reallocating the full string?
    – Stefan
    24 mins ago










  • if the new string allocation is less than the previous allocation, no allocation occurs. If the new string requires more allocation than the current, a reallocation occurs. Similar to a std::vector.
    – Samer Tufail
    22 mins ago










  • Strings reuse their buffers when assigned to shorter strings, so in your program there is only one allocation for the string. Unfortunately I can't find conveniently any citation from the standard on mobile
    – Fureeish
    20 mins ago










  • Even if a string did "give back memory spontaneously", that is insufficient to avoid heap fragmentation. A string uses an allocator (by default, an object of type std::allocator<char>, but that can be changed) to allocate and deallocate memory, and the allocator may use a lower-level mechanism again (e.g. variants of operators new and delete) to actually allocate and deallocate. If any of those steps elect to not release memory to the lower-level layer, there is potential impact on heap fragmentation.
    – Peter
    7 mins ago














up vote
6
down vote

favorite
2












Is it guaranteed by the standard that std::string will not give back allocated memory spontaneously if re-sized to a smaller size?



In other words:



std::string str = "Some quite long string, which needs a lot of memory";
str = "";
str = "A new quite long but smaller string"; // Guaranteed to not result in a heap allocation?


I ask because i'm depending on this to avoid heap fragmentation.






c++ language-lawyer heap-memory stdstring







share|improve this question























  • Not sure about the overloads, but; wouldn't it result in a new string, and hence reallocating the full string?
    – Stefan
    24 mins ago










  • if the new string allocation is less than the previous allocation, no allocation occurs. If the new string requires more allocation than the current, a reallocation occurs. Similar to a std::vector.
    – Samer Tufail
    22 mins ago










  • Strings reuse their buffers when assigned to shorter strings, so in your program there is only one allocation for the string. Unfortunately I can't find conveniently any citation from the standard on mobile
    – Fureeish
    20 mins ago










  • Even if a string did "give back memory spontaneously", that is insufficient to avoid heap fragmentation. A string uses an allocator (by default, an object of type std::allocator<char>, but that can be changed) to allocate and deallocate memory, and the allocator may use a lower-level mechanism again (e.g. variants of operators new and delete) to actually allocate and deallocate. If any of those steps elect to not release memory to the lower-level layer, there is potential impact on heap fragmentation.
    – Peter
    7 mins ago












up vote
6
down vote

favorite
2









up vote
6
down vote

favorite
2






2





Is it guaranteed by the standard that std::string will not give back allocated memory spontaneously if re-sized to a smaller size?



In other words:



std::string str = "Some quite long string, which needs a lot of memory";
str = "";
str = "A new quite long but smaller string"; // Guaranteed to not result in a heap allocation?


I ask because i'm depending on this to avoid heap fragmentation.






c++ language-lawyer heap-memory stdstring







share|improve this question















Is it guaranteed by the standard that std::string will not give back allocated memory spontaneously if re-sized to a smaller size?



In other words:



std::string str = "Some quite long string, which needs a lot of memory";
str = "";
str = "A new quite long but smaller string"; // Guaranteed to not result in a heap allocation?


I ask because i'm depending on this to avoid heap fragmentation.






c++ language-lawyer heap-memory stdstring




c++ language-lawyer heap-memory stdstring






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 4 mins ago

























asked 27 mins ago









Martin G

8,75555058




8,75555058











  • Not sure about the overloads, but; wouldn't it result in a new string, and hence reallocating the full string?
    – Stefan
    24 mins ago










  • if the new string allocation is less than the previous allocation, no allocation occurs. If the new string requires more allocation than the current, a reallocation occurs. Similar to a std::vector.
    – Samer Tufail
    22 mins ago










  • Strings reuse their buffers when assigned to shorter strings, so in your program there is only one allocation for the string. Unfortunately I can't find conveniently any citation from the standard on mobile
    – Fureeish
    20 mins ago










  • Even if a string did "give back memory spontaneously", that is insufficient to avoid heap fragmentation. A string uses an allocator (by default, an object of type std::allocator<char>, but that can be changed) to allocate and deallocate memory, and the allocator may use a lower-level mechanism again (e.g. variants of operators new and delete) to actually allocate and deallocate. If any of those steps elect to not release memory to the lower-level layer, there is potential impact on heap fragmentation.
    – Peter
    7 mins ago
















  • Not sure about the overloads, but; wouldn't it result in a new string, and hence reallocating the full string?
    – Stefan
    24 mins ago










  • if the new string allocation is less than the previous allocation, no allocation occurs. If the new string requires more allocation than the current, a reallocation occurs. Similar to a std::vector.
    – Samer Tufail
    22 mins ago










  • Strings reuse their buffers when assigned to shorter strings, so in your program there is only one allocation for the string. Unfortunately I can't find conveniently any citation from the standard on mobile
    – Fureeish
    20 mins ago










  • Even if a string did "give back memory spontaneously", that is insufficient to avoid heap fragmentation. A string uses an allocator (by default, an object of type std::allocator<char>, but that can be changed) to allocate and deallocate memory, and the allocator may use a lower-level mechanism again (e.g. variants of operators new and delete) to actually allocate and deallocate. If any of those steps elect to not release memory to the lower-level layer, there is potential impact on heap fragmentation.
    – Peter
    7 mins ago















Not sure about the overloads, but; wouldn't it result in a new string, and hence reallocating the full string?
– Stefan
24 mins ago




Not sure about the overloads, but; wouldn't it result in a new string, and hence reallocating the full string?
– Stefan
24 mins ago












if the new string allocation is less than the previous allocation, no allocation occurs. If the new string requires more allocation than the current, a reallocation occurs. Similar to a std::vector.
– Samer Tufail
22 mins ago




if the new string allocation is less than the previous allocation, no allocation occurs. If the new string requires more allocation than the current, a reallocation occurs. Similar to a std::vector.
– Samer Tufail
22 mins ago












Strings reuse their buffers when assigned to shorter strings, so in your program there is only one allocation for the string. Unfortunately I can't find conveniently any citation from the standard on mobile
– Fureeish
20 mins ago




Strings reuse their buffers when assigned to shorter strings, so in your program there is only one allocation for the string. Unfortunately I can't find conveniently any citation from the standard on mobile
– Fureeish
20 mins ago












Even if a string did "give back memory spontaneously", that is insufficient to avoid heap fragmentation. A string uses an allocator (by default, an object of type std::allocator<char>, but that can be changed) to allocate and deallocate memory, and the allocator may use a lower-level mechanism again (e.g. variants of operators new and delete) to actually allocate and deallocate. If any of those steps elect to not release memory to the lower-level layer, there is potential impact on heap fragmentation.
– Peter
7 mins ago




Even if a string did "give back memory spontaneously", that is insufficient to avoid heap fragmentation. A string uses an allocator (by default, an object of type std::allocator<char>, but that can be changed) to allocate and deallocate memory, and the allocator may use a lower-level mechanism again (e.g. variants of operators new and delete) to actually allocate and deallocate. If any of those steps elect to not release memory to the lower-level layer, there is potential impact on heap fragmentation.
– Peter
7 mins ago












2 Answers
2






active

oldest

votes

















up vote
7
down vote













No guarantee whatsoever:




[string.capacity]/7



Effects: Alters the length of the string designated by *this as follows:



(7.1) If n <= size(), the function replaces the string designated by *this with a string of length n whose elements are a copy of the initial elements of the original string designated by *this.

(7.2) If n > size(), the function replaces the string designated by *this with a string of length n whose first size() elements are a copy of the original string designated by *this, and whose remaining elements are all initialized to c.




The emphasized part show that the Committee let the implementation choose freely between an invalidating operation and a more conservative one.






share|improve this answer






















  • Op wasn't using resize, but assigning multiple literals
    – Caleth
    34 secs ago

















up vote
4
down vote













CPP reference states that assignment from a pointer-to-char




Replaces the contents with those of null-terminated character string pointed to by s as if by *this = basic_string(s), which involves a call to Traits::length(s).




This "as if" actually boils down to an rvalue assignment, so the following scenario is quite possible:



  1. A fresh temporary string is created.

  2. This string steals its contents as via assignment to an rvalue reference.





share|improve this answer






















  • cppreference is usually reliable, but the quoted statement implies that there is a guaranteed buffer replacement, which is bollocks. Other than that it's a good conceptual model. But it's just marginally simpler than the standard's description, quoted in YSC's answer, which would therefore be preferable.
    – Cheers and hth. - Alf
    7 mins ago







  • 1




    @Cheersandhth.-Alf cppreference is paraphrasing the standard [string.cons]
    – Caleth
    1 min ago










  • @Cheersandhth.-Alf Well its written in the C++17 standard at § 24.3.2.2 27 YSC's answer is about using resize().
    – Galik
    1 min ago











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',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
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%2f52495704%2fis-stdstring-guaranteed-not-to-give-back-memory-spontaneously%23new-answer', 'question_page');

);

Post as a guest

















2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
7
down vote













No guarantee whatsoever:




[string.capacity]/7



Effects: Alters the length of the string designated by *this as follows:



(7.1) If n <= size(), the function replaces the string designated by *this with a string of length n whose elements are a copy of the initial elements of the original string designated by *this.

(7.2) If n > size(), the function replaces the string designated by *this with a string of length n whose first size() elements are a copy of the original string designated by *this, and whose remaining elements are all initialized to c.




The emphasized part show that the Committee let the implementation choose freely between an invalidating operation and a more conservative one.






share|improve this answer






















  • Op wasn't using resize, but assigning multiple literals
    – Caleth
    34 secs ago














up vote
7
down vote













No guarantee whatsoever:




[string.capacity]/7



Effects: Alters the length of the string designated by *this as follows:



(7.1) If n <= size(), the function replaces the string designated by *this with a string of length n whose elements are a copy of the initial elements of the original string designated by *this.

(7.2) If n > size(), the function replaces the string designated by *this with a string of length n whose first size() elements are a copy of the original string designated by *this, and whose remaining elements are all initialized to c.




The emphasized part show that the Committee let the implementation choose freely between an invalidating operation and a more conservative one.






share|improve this answer






















  • Op wasn't using resize, but assigning multiple literals
    – Caleth
    34 secs ago












up vote
7
down vote










up vote
7
down vote









No guarantee whatsoever:




[string.capacity]/7



Effects: Alters the length of the string designated by *this as follows:



(7.1) If n <= size(), the function replaces the string designated by *this with a string of length n whose elements are a copy of the initial elements of the original string designated by *this.

(7.2) If n > size(), the function replaces the string designated by *this with a string of length n whose first size() elements are a copy of the original string designated by *this, and whose remaining elements are all initialized to c.




The emphasized part show that the Committee let the implementation choose freely between an invalidating operation and a more conservative one.






share|improve this answer














No guarantee whatsoever:




[string.capacity]/7



Effects: Alters the length of the string designated by *this as follows:



(7.1) If n <= size(), the function replaces the string designated by *this with a string of length n whose elements are a copy of the initial elements of the original string designated by *this.

(7.2) If n > size(), the function replaces the string designated by *this with a string of length n whose first size() elements are a copy of the original string designated by *this, and whose remaining elements are all initialized to c.




The emphasized part show that the Committee let the implementation choose freely between an invalidating operation and a more conservative one.







share|improve this answer














share|improve this answer



share|improve this answer








edited 17 mins ago

























answered 23 mins ago









YSC

17.1k33986




17.1k33986











  • Op wasn't using resize, but assigning multiple literals
    – Caleth
    34 secs ago
















  • Op wasn't using resize, but assigning multiple literals
    – Caleth
    34 secs ago















Op wasn't using resize, but assigning multiple literals
– Caleth
34 secs ago




Op wasn't using resize, but assigning multiple literals
– Caleth
34 secs ago












up vote
4
down vote













CPP reference states that assignment from a pointer-to-char




Replaces the contents with those of null-terminated character string pointed to by s as if by *this = basic_string(s), which involves a call to Traits::length(s).




This "as if" actually boils down to an rvalue assignment, so the following scenario is quite possible:



  1. A fresh temporary string is created.

  2. This string steals its contents as via assignment to an rvalue reference.





share|improve this answer






















  • cppreference is usually reliable, but the quoted statement implies that there is a guaranteed buffer replacement, which is bollocks. Other than that it's a good conceptual model. But it's just marginally simpler than the standard's description, quoted in YSC's answer, which would therefore be preferable.
    – Cheers and hth. - Alf
    7 mins ago







  • 1




    @Cheersandhth.-Alf cppreference is paraphrasing the standard [string.cons]
    – Caleth
    1 min ago










  • @Cheersandhth.-Alf Well its written in the C++17 standard at § 24.3.2.2 27 YSC's answer is about using resize().
    – Galik
    1 min ago















up vote
4
down vote













CPP reference states that assignment from a pointer-to-char




Replaces the contents with those of null-terminated character string pointed to by s as if by *this = basic_string(s), which involves a call to Traits::length(s).




This "as if" actually boils down to an rvalue assignment, so the following scenario is quite possible:



  1. A fresh temporary string is created.

  2. This string steals its contents as via assignment to an rvalue reference.





share|improve this answer






















  • cppreference is usually reliable, but the quoted statement implies that there is a guaranteed buffer replacement, which is bollocks. Other than that it's a good conceptual model. But it's just marginally simpler than the standard's description, quoted in YSC's answer, which would therefore be preferable.
    – Cheers and hth. - Alf
    7 mins ago







  • 1




    @Cheersandhth.-Alf cppreference is paraphrasing the standard [string.cons]
    – Caleth
    1 min ago










  • @Cheersandhth.-Alf Well its written in the C++17 standard at § 24.3.2.2 27 YSC's answer is about using resize().
    – Galik
    1 min ago













up vote
4
down vote










up vote
4
down vote









CPP reference states that assignment from a pointer-to-char




Replaces the contents with those of null-terminated character string pointed to by s as if by *this = basic_string(s), which involves a call to Traits::length(s).




This "as if" actually boils down to an rvalue assignment, so the following scenario is quite possible:



  1. A fresh temporary string is created.

  2. This string steals its contents as via assignment to an rvalue reference.





share|improve this answer














CPP reference states that assignment from a pointer-to-char




Replaces the contents with those of null-terminated character string pointed to by s as if by *this = basic_string(s), which involves a call to Traits::length(s).




This "as if" actually boils down to an rvalue assignment, so the following scenario is quite possible:



  1. A fresh temporary string is created.

  2. This string steals its contents as via assignment to an rvalue reference.






share|improve this answer














share|improve this answer



share|improve this answer








edited 19 mins ago









lubgr

7,22021441




7,22021441










answered 22 mins ago









bipll

7,1721821




7,1721821











  • cppreference is usually reliable, but the quoted statement implies that there is a guaranteed buffer replacement, which is bollocks. Other than that it's a good conceptual model. But it's just marginally simpler than the standard's description, quoted in YSC's answer, which would therefore be preferable.
    – Cheers and hth. - Alf
    7 mins ago







  • 1




    @Cheersandhth.-Alf cppreference is paraphrasing the standard [string.cons]
    – Caleth
    1 min ago










  • @Cheersandhth.-Alf Well its written in the C++17 standard at § 24.3.2.2 27 YSC's answer is about using resize().
    – Galik
    1 min ago

















  • cppreference is usually reliable, but the quoted statement implies that there is a guaranteed buffer replacement, which is bollocks. Other than that it's a good conceptual model. But it's just marginally simpler than the standard's description, quoted in YSC's answer, which would therefore be preferable.
    – Cheers and hth. - Alf
    7 mins ago







  • 1




    @Cheersandhth.-Alf cppreference is paraphrasing the standard [string.cons]
    – Caleth
    1 min ago










  • @Cheersandhth.-Alf Well its written in the C++17 standard at § 24.3.2.2 27 YSC's answer is about using resize().
    – Galik
    1 min ago
















cppreference is usually reliable, but the quoted statement implies that there is a guaranteed buffer replacement, which is bollocks. Other than that it's a good conceptual model. But it's just marginally simpler than the standard's description, quoted in YSC's answer, which would therefore be preferable.
– Cheers and hth. - Alf
7 mins ago





cppreference is usually reliable, but the quoted statement implies that there is a guaranteed buffer replacement, which is bollocks. Other than that it's a good conceptual model. But it's just marginally simpler than the standard's description, quoted in YSC's answer, which would therefore be preferable.
– Cheers and hth. - Alf
7 mins ago





1




1




@Cheersandhth.-Alf cppreference is paraphrasing the standard [string.cons]
– Caleth
1 min ago




@Cheersandhth.-Alf cppreference is paraphrasing the standard [string.cons]
– Caleth
1 min ago












@Cheersandhth.-Alf Well its written in the C++17 standard at § 24.3.2.2 27 YSC's answer is about using resize().
– Galik
1 min ago





@Cheersandhth.-Alf Well its written in the C++17 standard at § 24.3.2.2 27 YSC's answer is about using resize().
– Galik
1 min ago


















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52495704%2fis-stdstring-guaranteed-not-to-give-back-memory-spontaneously%23new-answer', 'question_page');

);

Post as a guest
































































Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

Image
Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote -3 down vote favorite Say, for example I have worked in the following companies, Company A => 2010 - 2011 Company B => 2011 - 2012 Company C => 2012 - Till Date Company D => Have offer Now assume Company D is asking to submit documents from my second last employer. So from the list of companies given, which company would be qualified as second last employer? software-industry employer share | improve this question asked Aug 10 '14 at 5:16 Rajaprabhu Aravindasamy 559 1 6 13 closed as off-topic by Jim G., jmort253 ♦ Aug 11 '14 at 1:58 This question appears to be off-topic. The users who voted to close gave this specific reason: "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address...
Read more

List of Gilmore Girls characters

Image
The season three cast—(Back row): Lane, Michel, Paris, Emily, Richard, Sookie, Miss Patty, Kirk; Front row: Jess, Luke, Lorelai, Rory, Dean This is a list of characters for the comedy-drama television series Gilmore Girls . Contents 1 Main characters 1.1 Lorelai Gilmore 1.2 Rory Gilmore 1.3 Sookie St. James 1.4 Lane Kim 1.5 Michel Gerard 1.6 Luke Danes 1.7 Emily Gilmore 1.8 Richard Gilmore 1.9 Paris Geller 1.10 Dean Forester 1.11 Jess Mariano 1.12 Kirk Gleason 1.13 Jason Stiles 1.14 Logan Huntzberger 2 Major recurring characters 2.1 Christopher Hayden 2.2 Jackson Belleville 2.3 Mrs. Kim 2.4 Tristin DuGray 2.5 Max Medina 2.6 Taylor Doose 2.7 Dave Rygalski 2.8 Marty 3 Recurring characters 3.1 Stars Hollow 3.2 Chilton 3.3 Yale 3.4 Other 4 Notable guest stars 5 Unseen characters 6 Notes 7 References Main characters Actor Character Appearances Season 1 Season 2 Season 3 Season 4 Season 5 Season 6 Season 7 A Year in the Life Lauren Graham Lorelai Gilmore...
Read more

Confectionery

Image
Prepared foods made with a lot of sugar or other cabohydrates "Sweetmeat" redirects here. For the racehorse, see Sweetmeat (horse). Not to be confused with Sweetbread. This Kransekake is a traditional Scandinavian baker's confection. Confectionery is the art of making confections , which are food items that are rich in sugar and carbohydrates. Exact definitions are difficult. [1] In general, though, confectionery is divided into two broad and somewhat overlapping categories, bakers' confections and sugar confections. [2] Bakers' confectionery, also called flour confections , includes principally sweet pastries, cakes, and similar baked goods. Sugar confectionery includes candies ( sweets in British English), candied nuts, chocolates, chewing gum, bubble gum, pastillage, and other confections that are made primarily of sugar. In some cases, chocolate confections (confections made of chocolate) are treated as a separate category, as are sugar-free versions of ...
Read more