Someone coming from a garbage-collected programming language does not expect memory to be freed anytime soon at all.
-----Ursprüngliche Nachricht-----
Von: Simon Schröder via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mi 08.10.2025 07:03
Betreff: Re: [std-proposals] Proposal: Clarifying or Deprecating clear() in STL containers
An: std-proposals@lists.isocpp.org;
CC: Simon Schröder <dr.simon.schroeder@gmail.com>;
First of all, we don‘t ever break existing code willy-nilly. .clear() already has a meaning and it will not change. C++ is meant for high performance and it is a good thing that .clear() does not free the memory. (At least when it is reused.) std::vector has shrink_to_fit() to (maybe) free the memory after a call to .clear(). But, even this is not really necessary as there is the well-known swap-trick to immediately free the memory of a vector. Sure, this is not intuitive for someone coming from a different programming language, but it is expected knowledge (depending on the field where C++ is used) of an experienced C++ programmer.On Oct 7, 2025, at 10:12 PM, Jerome Saint-Martin via Std-Proposals <std-proposals@lists.isocpp.org> wrote:MotivationIn the Standard Template Library (STL), theclear()function is defined for containers likestd::vector,std::deque, and others. Its behavior is functionally equivalent to:container.erase(container.begin(), container.end());It removes all elements from the container, reducing itssize()to zero, but does not release memory (capacity remains unchanged), nor does it reset values. This leads to a subtle redundancy in the API:clear()is essentially a shorthand for a full-rangeerase().ObservationWhileclear()is widely used and syntactically convenient, it introduces a semantic ambiguity. Many developers — especially those new to C++ — assumeclear()“resets” the container’s values. In reality, it destroys the elements, not reinitializes them.This confusion is compounded by the fact thatclear()does not offer anything beyond whaterase(begin(), end())already provides.Too Much Progress Kills the ProgressIn the early days of programming, we usederase(begin(), end())like our ancestors used silex to make fire. It was precise, intentional, and part of the craft. Then cameclear()— a smoother, more modern tool. But in simplifying, we may have blurred its purpose. Today, we have expressive tools likeresize(n, val), ranges, and lambdas.Proposal
Option A (radical):
Deprecate or removeclear()from STL containers where it is strictly equivalent toerase(begin(), end()) reclaimclear()for a more meaningful role — resetting vector values to a default value, likeresize(n, val)does — and leterase(begin(), end())remain the sharp silex in our toolbox. Option B (soft): Clarify in the standard documentation thatclear()is a semantic alias forerase(begin(), end()), and does not reset values or release memory.
std::co_proposers :: Jérôme Saint-Martin and friend Beg Copilot--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals-- Std-Proposals mailing list Std-Proposals@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals