Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
llvm-project
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
-
fast_float
Fast and exact implementation of the C++ from_chars functions for number types: 4x to 10x faster than strtod, part of GCC 12 and WebKit/Safari
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
carbon-lang
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
-
Current C++ standard draft it hosted at https://eel.is/c++draft/, at this time this is the draft for C++23.
For earlier C++ standard versions the final drafts before ISO standardization are hosted at https://github.com/timsong-cpp/cppwp . The paid ISO standardized version is supposedly not meaningfully different.
Relevant parts of the standard:
* pop_back: https://timsong-cpp.github.io/cppwp/n4868/containers#tab:con... "Preconditions: a.empty() is false."
* Meaning of "precondition": https://timsong-cpp.github.io/cppwp/n4868/library#structure....
Reading the standard can be quite a challenge. The standard tries to not repeat itself, which often means that you don't get your answer in a self-contained paragraph, but you have to hunt down cross-references and definitions.
As a C++ language reference I highly recommend https://en.cppreference.com .
> I don't have a copy of the standard at hand, can anyone quote the relevant section?
The C++ (draft) standard is on GitHub! [0] Compiling it needs Perl and some LaTeX packages, but is reasonably straightforwards otherwise. In addition, links to specific draft standards can be found on cppreference [1].
But anyways, in the first C++20 post-publication draft (N4868), the wording you're interested in is in multiple sections. Section 22.2.3 Sequence Containers [sequence.reqmts] has Table 78: Optional sequence container operations [tab:container.seq.opt] (starting on page 815), which states that a precondition of pop_back() is that empty() returns false. Section 16.3.2.4 Detailed Specifications [structure.specifications] (page 481) states:
> Preconditions: the conditions that the function assumes to hold whenever it is called; violation of any preconditions results in undefined behavior.
Therefore, calling pop_back() on an empty vector results in undefined behavior.
> Is this something that in practice is implemented in different (exception-throwing) ways?
Based on a quick glance at the major implementations (libc++ 15.0.7 at [2], MSVC at [3], libstdc++ at [4]), it looks like asserts are used. Whether those result in exceptions probably depends on whether the asserts are compiled in in the first place and how they are implemented, but it's definitely not a guaranteed exception.
[0]: https://github.com/cplusplus/draft
[1]: https://en.cppreference.com/w/cpp/links
[2]: https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/lib...
[3]: https://github.com/llvm/llvm-project/blob/8dfdcc7b7bf66834a7...
[4]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3...
> I don't have a copy of the standard at hand, can anyone quote the relevant section?
The C++ (draft) standard is on GitHub! [0] Compiling it needs Perl and some LaTeX packages, but is reasonably straightforwards otherwise. In addition, links to specific draft standards can be found on cppreference [1].
But anyways, in the first C++20 post-publication draft (N4868), the wording you're interested in is in multiple sections. Section 22.2.3 Sequence Containers [sequence.reqmts] has Table 78: Optional sequence container operations [tab:container.seq.opt] (starting on page 815), which states that a precondition of pop_back() is that empty() returns false. Section 16.3.2.4 Detailed Specifications [structure.specifications] (page 481) states:
> Preconditions: the conditions that the function assumes to hold whenever it is called; violation of any preconditions results in undefined behavior.
Therefore, calling pop_back() on an empty vector results in undefined behavior.
> Is this something that in practice is implemented in different (exception-throwing) ways?
Based on a quick glance at the major implementations (libc++ 15.0.7 at [2], MSVC at [3], libstdc++ at [4]), it looks like asserts are used. Whether those result in exceptions probably depends on whether the asserts are compiled in in the first place and how they are implemented, but it's definitely not a guaranteed exception.
[0]: https://github.com/cplusplus/draft
[1]: https://en.cppreference.com/w/cpp/links
[2]: https://github.com/llvm/llvm-project/blob/llvmorg-15.0.7/lib...
[3]: https://github.com/llvm/llvm-project/blob/8dfdcc7b7bf66834a7...
[4]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3...
This makes sense for integers but betware floating point from_chars - libc++ still doesn't implement it and libstdc++ implements it by wrapping locale-dependent libc functions which involves temporarily changing the thread locale and possibly memory allocation to make the passed string 0-terminated. IMO libstdc++'s checkbox "solution" is worse than not implementing it at all - user's are better off using Lemire's API-compatible fast_float implementation [0].
[0] https://github.com/fastfloat/fast_float
Current C++ standard draft it hosted at https://eel.is/c++draft/, at this time this is the draft for C++23.
For earlier C++ standard versions the final drafts before ISO standardization are hosted at https://github.com/timsong-cpp/cppwp . The paid ISO standardized version is supposedly not meaningfully different.
Relevant parts of the standard:
* pop_back: https://timsong-cpp.github.io/cppwp/n4868/containers#tab:con... "Preconditions: a.empty() is false."
* Meaning of "precondition": https://timsong-cpp.github.io/cppwp/n4868/library#structure....
Reading the standard can be quite a challenge. The standard tries to not repeat itself, which often means that you don't get your answer in a self-contained paragraph, but you have to hunt down cross-references and definitions.
As a C++ language reference I highly recommend https://en.cppreference.com .
I don't not think that English isn't difficult to parse.
I agree completely that it's all about the code you write. You can write nice C++ that is easy to understand, easy to debug, and that you can be quite certain is bug free.
Something like Rust appears to eliminate one class of bugs, but then people still write bugs. Just look at the Rust language issue tracker on GitHub [1].
Fundamentally, you cannot get around the need for good code design. Any useful programming language will always have the ability to mishandle data.
[1] https://github.com/rust-lang/rust/issues
I don't think it's C++'s fault necessarily. The C/C++ ecosystem seems to attract more of a certain type of developer who will tell you to just "get good" at the language so you van decipher their code and use it without a billion memory bugs, but the language doesn't specify any of it.
It's easy to point out an example of unreadable code in any language because every language has their weird programmers. If you stick to modern tools with strict linting and good design, you can write perfectly readable C++ code.
I don't use C++ often, but I find the code over at https://github.com/SerenityOS/serenity to be more legible than many large code bases in other languages.
Unfortunately, it's also C++ code. Most of the weakest parts of C++ come from its close association with C.
When asking why some people like Rust over C++, I think not enough weight is given here: Rust got to not worry about decades of legacy C stuff seeping in. If Rust isn't your jam -- and I get why it wouldn't be -- there are some initiatives starting now from within the C++ community to shed the C legacy with a new language that feels a lot more like modern C++. Herb Sutter's cppfront[0] and Carbon[1] are examples.
But I don't think it makes sense to dismiss this criticism just because the author happens to like Rust. These C idioms continue to be valid and reasonably widely used in C++.
[0]: https://github.com/hsutter/cppfront
OK, here is MS STL:
https://github.com/microsoft/STL/blob/main/stl/inc/vector#L1...
Whatever _STL_VERIFY does, pop_back can't throw, as it's marked noexcept.