4 ms·

Current C++ standard draft it hosted at https://eel.is/c++draft/ https://eel.is/c++draft/, at this time this is the draft for C++23. For earlier C++ standard v

Current C++ standard draft it hosted at https://eel.is/c++draft/ 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 https://github.com/timsong-cpp/cppwp . The paid ISO standardized version is supposedly not meaningfully different. Relevant parts of the standard (C++20): * pop_back: https://timsong-cpp.github.io/cppwp/n4868/containers#tab:container.seq.opt-row-11 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.specifications-3.3 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 https://en.cppreference.com . edit: In this case https://en.cppreference.com/w/cpp/container/vector/pop_back https://en.cppreference.com/w/cpp/container/vector/pop_back is super clear. Basically everything you want to know about the function in three sentences: > Removes the last element of the container. Calling pop_back on an empty container results in undefined behavior. Iterators and references to the last element, as well as the end() iterator, are invalidated.

mattgreenrocks 4y ago
I'm guessing that ChatGPT answered the query based off of implementation-specific details, rather than the standard itself. There's a dark irony in the fact that programmers do this all the time.
- planede 4y ago
  No implementation that I know of throws an exception here.
  - mattgreenrocks 4y ago
    I stand corrected. It sounded like something that would be done in debug mode by some STL implementations.
    - planede 4y ago
      In debug mode libstdc++ and libc++ aborts the program with a diagnostic message. This should not be an exception that can be caught, and it rightfully isn't.
      - pjmlp 4y ago
        They aren't the only implementations around.
        planede 4y ago
        OK, here is MS STL: https://github.com/microsoft/STL/blob/main/stl/inc/vector#L1700 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. EA STL: https://github.com/electronicarts/EASTL/blob/master/include/EASTL/vector.h#L1075 https://github.com/electronicarts/EASTL/blob/master/include/... Default assertion handler seems to set up a debug break point: https://github.com/electronicarts/EASTL/blob/29a805e4d83d7dd1d8fb03f303b132cc8c0a51c9/source/assert.cpp#L84 https://github.com/electronicarts/EASTL/blob/29a805e4d83d7dd... Macro defined somewhere here: https://github.com/electronicarts/EASTL/blob/76d6842d5d833c032a9ac39df5499190b6bec7b3/include/EASTL/internal/config.h#L612 https://github.com/electronicarts/EASTL/blob/76d6842d5d833c0... Does not seem to throw, but a lot of this is user-configurable. I'm sure I still didn't cover all implementations. You are free to point out a single one that throws on pop_back. Or just ask ChatGPT which implementation throws.
  - AnimalMuppet 4y ago
    So it's ChatGPT confidently making stuff up. Lovely.
mr_00ff00 4y ago
Is there a reason some sort of check wasn’t added to pop_back() implementation? Seems like it would be easy to implement and undefined behavior is not something that backwards compatibility forces you to keep.
- wizofaus 4y ago
  Because the basic principle of C/C++ is to not force the coder to have to pay for checks it mightn't need. Which in some contexts makes sense - for application development, probably not.
- fooker 4y ago
  pop_back() is internally just changing a single index. Now, adding a check is adding several other operations, including a conditional branch. This is fairly bad for performance. So the C++ way is that you write the check yourself if your code requires it.
  - mike_hock 4y ago
    .. on a vector of trivial types. If we have to call a non-trivial destructor for the item being removed, the check stops being significant. Then there can't be a pop without a push or some other operation that filled the vector, and that operation necessarily has the checks and branches to allocate more space if necessary. The compiler should also be smart enough to branch forward to the throw so the branch predictor assumes not taken by default, so this is still cheap af. This is "fairly bad" for performance maybe 1% of the time. For the other 99%, you'd make pop_back check and throw and keep the unchecked version as pop_back_fast or something like that. That's what a sane API would look like.
    - fooker 4y ago
      >If we have to call a non-trivial destructor for the item being removed, the check stops being significant. This is a complicated cost model which compilers usually avoid. >The compiler should also be smart enough. It isn't. > That's what a sane API would look like. Awesome, there is nothing stopping you from creating your own functions which add this check.
WalterBright 4y ago
> As a C++ language reference I highly recommend https://en.cppreference.com https://en.cppreference.com I'd be careful about such re-formulations of the Standard. When I was adding printf format checking to the D compiler, I discovered there were subtle discrepancies in the description of exactly how printf behaves. I went back to using the Standard.
- planede 4y ago
  I generally agree. But sometimes it's very hard to navigate the standard. Sometimes I look things up in cppreference, and then find corresponding wording in the standard itself. And surely the stakes are different when you are writing a compiler compared to just using the language. As a user if you are not sure about certain parts of the language then you are free to steer away from those parts. As an implementer, you are not free to not implement parts of the standard.
  - WalterBright 4y ago
    True enough, as a language implementer I prefer to do things exactly.

mattgreenrocks 4y ago

I'm guessing that ChatGPT answered the query based off of implementation-specific details, rather than the standard itself. There's a dark irony in the fact that programmers do this all the time.

planede 4y ago
No implementation that I know of throws an exception here.
- mattgreenrocks 4y ago
  I stand corrected. It sounded like something that would be done in debug mode by some STL implementations.
  - planede 4y ago
    In debug mode libstdc++ and libc++ aborts the program with a diagnostic message. This should not be an exception that can be caught, and it rightfully isn't.
    - pjmlp 4y ago
      They aren't the only implementations around.
      - planede 4y ago
        OK, here is MS STL: https://github.com/microsoft/STL/blob/main/stl/inc/vector#L1700 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. EA STL: https://github.com/electronicarts/EASTL/blob/master/include/EASTL/vector.h#L1075 https://github.com/electronicarts/EASTL/blob/master/include/... Default assertion handler seems to set up a debug break point: https://github.com/electronicarts/EASTL/blob/29a805e4d83d7dd1d8fb03f303b132cc8c0a51c9/source/assert.cpp#L84 https://github.com/electronicarts/EASTL/blob/29a805e4d83d7dd... Macro defined somewhere here: https://github.com/electronicarts/EASTL/blob/76d6842d5d833c032a9ac39df5499190b6bec7b3/include/EASTL/internal/config.h#L612 https://github.com/electronicarts/EASTL/blob/76d6842d5d833c0... Does not seem to throw, but a lot of this is user-configurable. I'm sure I still didn't cover all implementations. You are free to point out a single one that throws on pop_back. Or just ask ChatGPT which implementation throws.
- AnimalMuppet 4y ago
  So it's ChatGPT confidently making stuff up. Lovely.

mr_00ff00 4y ago

Is there a reason some sort of check wasn’t added to pop_back() implementation? Seems like it would be easy to implement and undefined behavior is not something that backwards compatibility forces you to keep.

wizofaus 4y ago
Because the basic principle of C/C++ is to not force the coder to have to pay for checks it mightn't need. Which in some contexts makes sense - for application development, probably not.
fooker 4y ago
pop_back() is internally just changing a single index. Now, adding a check is adding several other operations, including a conditional branch. This is fairly bad for performance. So the C++ way is that you write the check yourself if your code requires it.
- mike_hock 4y ago
  .. on a vector of trivial types. If we have to call a non-trivial destructor for the item being removed, the check stops being significant. Then there can't be a pop without a push or some other operation that filled the vector, and that operation necessarily has the checks and branches to allocate more space if necessary. The compiler should also be smart enough to branch forward to the throw so the branch predictor assumes not taken by default, so this is still cheap af. This is "fairly bad" for performance maybe 1% of the time. For the other 99%, you'd make pop_back check and throw and keep the unchecked version as pop_back_fast or something like that. That's what a sane API would look like.
  - fooker 4y ago
    >If we have to call a non-trivial destructor for the item being removed, the check stops being significant. This is a complicated cost model which compilers usually avoid. >The compiler should also be smart enough. It isn't. > That's what a sane API would look like. Awesome, there is nothing stopping you from creating your own functions which add this check.

WalterBright 4y ago

> As a C++ language reference I highly recommend https://en.cppreference.com https://en.cppreference.com I'd be careful about such re-formulations of the Standard. When I was adding printf format checking to the D compiler, I discovered there were subtle discrepancies in the description of exactly how printf behaves. I went back to using the Standard.

planede 4y ago
I generally agree. But sometimes it's very hard to navigate the standard. Sometimes I look things up in cppreference, and then find corresponding wording in the standard itself. And surely the stakes are different when you are writing a compiler compared to just using the language. As a user if you are not sure about certain parts of the language then you are free to steer away from those parts. As an implementer, you are not free to not implement parts of the standard.
- WalterBright 4y ago
  True enough, as a language implementer I prefer to do things exactly.