Hacker News Reader

Comment by ynik | Hacker News Reader

asan/ubsan are great for finding language-level undefined behavior. But apart from some functions like memcpy that asan is hooking, they cannot find library-level undefined behavior such as the pop_back() on the empty vector. (That's an inline function inside a template, there's no way asan could hook this!)

I recommend using `-D_GLIBCXX_ASSERTIONS` in addition to `-fsanitize=undefined,address`. This will enable some cheap assertions in libstdc++ that catch stuff like the invalid pop_back() call. In fact it might not be a bad idea to keep these assertions enabled in release builds! (There is also `-D_GLIBCXX_DEBUG` which enables even more assertions, but some of those are expensive)

View on HN

Meta: when you ask chatgpt what happens when you do pop_back() on an empty vector, it confidently claims std::out_of_range will be thrown. It will even 'cite' the standard with a plausible explanation of what will happen (essentially, it says that a prereq is that empty() == false, and that it depends on what erase() throws). https://cplusplus.com/reference/vector/vector/pop_back/ and other sources I can find say undefined behavior. I don't have a copy of the standard at hand, can anyone quote the relevant section? Is this something that in practice is implemented in different (exception-throwing) ways?

> Is this something that in practice is implemented in different (exception-throwing) ways?

I don't think so. Even when enabling debugging mode, a precondition failure would cause an abort, not an exception to be thrown.

God help us if people start trying to use an overconfident chatbot to replace documentation :(.

Maybe. To be fair, I had the same opinion yesterday. This morning I decided to take a real look at how I could use chatgpt to augment my programming, and once I started with it with an open mind, I now think it's going to take away much of the drudgery I have come to loathe so much about programming. I used to like delving into libraries and frameworks and learning all their details - I thought that was what 'learning about programming' was. Now, 20 years later, I hate those aspects with a passion - having to look up the idiosyncrasies of a function call again, because there are dozens of ways of using it but all slightly different, or piecing together another dull specific use case. This morning I had chatgpt generate 4 fully fledged functions for me, each doing a highly specific task that would have taken maybe 20 or 30 minutes each to piece together the specific API's, and one of them using a Python package I had never used before, didn't know of and would have had to read the getting started tutorial before I could have used it on my own. Then all I had to do was write the glue to call those functions in the right order and with the right arguments and boom that was it. Plus the code was more elaborate and coherent than it would have been had I have to do it manually.

One example is not a guarantee, but the experience made my day, and probably my week. Which is why the pop_back() thing made me worry :)

> This morning I had chatgpt generate 4 fully fledged functions for me, each doing a highly specific task that would have taken maybe 20 or 30 minutes each to piece together the specific API's, and one of them using a Python package I had never used before, didn't know of and would have had to read the getting started tutorial before I could have used it on my own. Then all I had to do was write the glue to call those functions in the right order and with the right arguments and boom that was it.

“Boom that was it” _if_ you blindly trust ChatGPT to generate correct code. If you don’t (and IMO you shouldn’t), “it worked for me today” isn’t sufficient to decide whether you can trust it.

You should go to the documentation of that package, judge whether ChatGPT used it correctly (and yes, that involves looking up the idiosyncrasies of function calls), judge whether you trust that package, evaluate its license, etc.

Can it also generate unit tests for you to prove the functions work as expected? Obviously those unit tests need to be something a quick glance at will confirm are actually usefully verifying expected behaviour (of course, there are circumstances that's nigh on impossible to do even with the most carefully handcrafted tests).

Amen.

Chatbot moves in mysterious ways.

I mean it's fine if you can double-check what it tells you quickly, it's just pretty bad with something like C++ because when it gives you something wrong the program may or may not tell you about it. For example, what it might be good for is "what are the parameters to this 6-argument function that plots a rectangle on the screen", because that's something you can confirm really easily and there are no real consequences to getting it wrong. On the other hand, someone sent me a screenshot of how ChatGPT was really helpful in figuring out how reader-writer locks work, and it told them "you can use pthread_rwlock_trywrlock to upgrade a reader lock to a writer lock" :/

They're using it to replace "search on stack overflow, cut and paste, does it work?"

> if

* when

https://supabase.com/blog/chatgpt-supabase-docs Already on HN

The technique they’re using is much less error prone due to the nature of the prompt.

When a prompt is “analytic” in nature, that is contains the facts required for the output, like “convert this following box score into an entertaining account of the baseball game it describes”, it works rather well.

When the prompt is “synthetic” in nature, when it doesn’t have the facts in the prompt, like “based on that same box score, provide some direct quotes from the broadcasters”, it does not reliably provide factual responses.

Doesn't see any worse than asking HN. :P

> God help us if people start trying to use an overconfident chatbot to replace documentation :(.

A chat bot looks like a great help to parse through huge volumes of documentation.

If the chatbot built around the docs outputs garbage, that is a telltale sign that the documentation was garbage to start with.

Just because people started developing clever chatbots that misfire, let's not fool ourselves into believing documentation was a solved problem and all docs were squeaky clean.

Poor output from a chat bot indicating poor documentation would make sense if the chat bot could limit itself to authoritative information from the documentation, but that's not how these models operate. I'm not even sure how you could make them work that way because if you trained them solely on the documentation, they wouldn't be able to operate in a conversational manner.

You can tune ChatGPT with custom data.

This is, AFAIK, not a task for fine tuning--which is more like trying to get a certain kind of style-but maybe a task for "semantic search". I watched this video a few days ago, and at least vaguely recommend it: https://youtu.be/9qq6HTr7Ocw

Here is the documentation that you consider unclear

>If the container is not empty, the function never throws exceptions (no-throw guarantee). Otherwise, it causes undefined behavior.

ChatGPT failed at basic regurgitation.

This is, at best, clumsily worded, because it requires that the reader hold two negatives simultaneously. "If the container is not empty, the function never throws"

How about this:

If the container is empty the function causes undefined behaviour. Otherwise it never throws exceptions (no-throw guarantee).

We avoided having to hold two negatives, and we also put the thing you need to care about up front where it's more likely to be noticed.

The function never throws, whether empty or not. So, skip the "otherwise".

It's not called "Undefined except we promise it can't possibly throw" behaviour.

> If the chatbot built around the docs outputs garbage, that is a telltale sign that the documentation was garbage to start with.

That’s not how the chat bot works. This particular chat bot can be trained on a bunch of documents and still tell you something that contradicts the facts that are clear to a human in one of the said documents.

It’s a known phenomenon called “hallucination” and this actually gives the chat bot, to some extent, it’s ability to imitate creativity (to put it simply).

edit: typo

That would very much be the Warhammer 40k machine spirit - the operator would only do what they can to appease it, and even the spirit wouldn't know how or why something did or didn't work.

> 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...

> Compiling it needs Perl

this was something that I thought must be a joke at first... a text document that needs ... Perl ... to be read. This does make sense considering the context is C++ though.

The C++ standard is a LaTeX document, not a plain text document. Perl is needed for latexmk [0], which isn't strictly necessary but greatly simplifies the process of compiling LaTeX.

[0]: https://mg.readthedocs.io/latexmk.html

You've just been pointed at github. Which hosts git repositories. Which is used to keep track of changes to source files, not published build artifacts.

For future reference, lots of other git-hosted projects also require the user to supply build tools to produce the finished product. Sometimes these are programs known as "compilers", but frequently other programs like "parser generators" or "text formatters" are needed too. Or scripting languages (like perl) to help tie the build process together.

Might be worth keeping in mind if you ever need to interact with git (or github) again.

You do know that GitHub has an entire section for each repository called "Releases" right? In fact, you can setup a free pipeline to generate these release for you.

Might be worth keeping in mind if you ever need to interact with git (or github) again.

What a snide, unhelpful, and rude remark. This is in the context of a textual language standard, it was reasonable to not consider it something that needs additional steps to view. Fine that it does, but your reply is ridiculous, to suggest that someone talking about the C++ standard doesn't know what a compiler is.

The final standard document is neither a "text" document, nor do you need Perl to "read" it.

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 (C++20):

* 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 .

edit:

In this case 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.

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.

No implementation that I know of throws an exception here.

I stand corrected. It sounded like something that would be done in debug mode by some STL implementations.

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.

They aren't the only implementations around.

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.

EA STL: 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/29a805e4d83d7dd...

Macro defined somewhere here: 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.

So it's ChatGPT confidently making stuff up. Lovely.

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.

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.

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.

.. 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.

>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.

> It isn't.

It definitely is. Go try it on godbolt.

> Awesome, there is nothing stopping you from creating your own functions which add this check.

Thanks for your amazing insight.

STL is lacking? Nothing is stopping us from writing our own functions.

STL is garbage? Nothing is stopping us from writing our own replacement.

The whole language is garbage? Nothing is stopping us from creating a new one from scratch.

Really, you've found the solution to everything.

pop_back() implementations have checks, but they're opt-in (and how to opt-in is specific to each implementation).

This is just how C++ works: performance over safety, safety is semi-possible but requires a bunch of opt-ins. And the parts needed for safe C++ aren't standardized, so good luck if you're using multiple compilers.

The standard does not require it.

I was thinking just the same as a bunch of you. If I were implementing a container class, I would include this check. Probably some do. It can't be relied on.

Because alternative makes it not much better or safer. It could throw an exception when vector is empty (or return an error in whatever other way) - you will catch the exception and then do what, try to pop_back() again or what exactly can you do? You are at very bad odds to continue with the program when such a fundamental issue pops up in your program so I guess you can only terminate the process?

There is no generally meaningful way to recover from an error condition like this, which in its nature is a logical mistake in your code. And that's the reason why I think std::vector won't throw an exception but will give you an opt-in to terminate the process through the assert.

I think it's not about the performance, although it can be argued, but it's more fundamental code design problem.

> or what exactly can you do?

Crash. Crashing is a million times better than undefined behaviour, which can and often does include carrying on computing with incorrect data.

And which is what I already mentioned? And something that standard library already can do for you so I'm not sure about the point you're trying to make.

Also, aborting the program is not something you can universally apply. For some it works well for others not so much. Most recent example being the rust in the kernel which, well, tries to take this sort of a purist approach, however, real world doesn't work that way.

> As a C++ language reference I highly recommend 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.

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.

True enough, as a language implementer I prefer to do things exactly.

When I asked ChatGPT "In C++, what happens when you call pop_back() on an empty vector?" I got the answer:

> When you call pop_back() on an empty vector in C++, it leads to undefined behavior. The C++ standard does not specify what should happen in this scenario. Attempting to remove an element from an empty container is an error and can cause the program to crash or produce incorrect results. To avoid this issue, you should always check the size of the vector before calling pop_back() or use other methods such as empty() to determine if the vector is empty.

Do you remember how you phrased your question? Maybe it's just luck it got it right for me or maybe it's the order of the terms in my question.

Here's my exact chat log:

    what happens when you do pop_back() on an empty vector in C++?

    In C++, when you call the pop_back() function on an empty vector, it will result in an std::out_of_range exception being thrown. The exception indicates that an element cannot be removed from an empty vector, as there is nothing to remove. To prevent the exception, it is recommended to check the size of the vector before calling pop_back(), to ensure that the vector is not empty.

    can you quote the relevant C++ standard on that?

    Sure! Here is the relevant excerpt from the C++ Standard (C++20, ISO/IEC 14882:2020):

    quote the relevant passage from the standard

    Here is the relevant excerpt from the C++ Standard (C++20, ISO/IEC 14882:2020):

    23.6.11 Vector data members [vector.data]

    -1- The member function pop_back() shall have no effect if the vector is empty.

    23.6.6 Vector capacity [vector.capacity]

    -1- void pop_back();
        Requires: empty() == false.
        Effects: If size() > 0, caller shall call erase(end() - 1).
        Throws: Nothing unless erase() throws an exception.

    21.5.5.5 vector<T>::pop_back() [vector.pop_back]

    -1- Removes the last element in the vector.
        Complexity: Constant time.
        Throws: Nothing unless erase() throws an exception.

Pretty interesting output. Some notes from a cursory glance/crosscheck against the first post-C++20 draft [0]:

It gets the ISO/IEC number correct [1]. However, the sections are wrong

- Section 23.6 is about stream iterators. Sections 23.6.6 and 23.6.11 do not exist.

- Section 21.5.5 is a synopsis of the <cuchar> header. Section 21.5.5.5 does not exist

- Section [vector.data] exists and is numbered 22.3.11.4. It only describes the data() function.

- Section [vector.capacity] exists and is numbered 22.3.11.3. It describes the capacity(), reserve(), shrink_to_fit(), swap(), and resize() functions.

- pop_back() is generally described in Table 78 (Section 22.2.3 Sequence Containers, [sequence.reqmts]), and is expanded upon for std::vector in Section 22.3.11.5 Modifiers [vector.modifiers].

The wording is not correct either.

- Searching "shall have no effect" returns no hits (though I'm searching in a PDF, so maybe the search just misses it?).

- The standard wording for pop_back() in general is: "Effects: Destroys the last element. Preconditions: a.empty() is false". The Standard says nothing about exceptions.

- For std::vector specifically, the Standard says "Effects: Invalidates iterators and references at or after the point of the erase. Throws: Nothing unless an exception is thrown by the assignment operator or move assignment operator of T. Complexity: The destructor of T is called the number of times equal to the number of the elements erased, but the assignment operator of T is called the number of time equal to the number of elements in the vector after the erased elements."

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n48...

[1]: https://www.iso.org/standard/79358.html

Interestingly, here's what I get when I feed it your exact question:

    In C++, what happens when you call pop_back() on an empty vector?

    When you call pop_back() on an empty vector in C++, an std::out_of_range exception is thrown. The pop_back() function removes the last element of a vector and it is undefined behavior to call it on an empty vector. Attempting to do so will result in the exception being thrown.

So it basically claims both that an exception is thrown, and that it's undefined behavior. At least in this case, one would know something is up.

I asked it again (in a new context) and got a partially right answer as well:

> In C++, calling pop_back() on an empty vector results in an undefined behavior. An std::vector is a dynamic array that grows and shrinks automatically. pop_back() function is used to remove the last element of the vector. But if there are no elements in the vector, calling pop_back() will result in an error. Therefore, it is advisable to always check if the vector is empty before calling pop_back().

I wonder what sort of scores we would be seeing for each of these series of tokens (including those returned for roel_v). Is the aggregate score (for lack of a better term) higher for the initial reply I saw greater than the scores for these other replies?

> when you ask chatgpt what happens

Big mistake. I asked chatgpt to summarize the plot of 2001. It replied with Hal locked Dave inside the Discovery and wouldn't open the pod bay doors to let him out.

Answers about code is similarly very plausible, but subtly and completely wrong.

AFAIK `_GLIBCXX_DEBUG` alters ABI to the library, it should be only used with a libstdc++ and all other components compiled with the same flag. Debug iterators, and all that jazz. MSVC users are probably not surprised.

`_GLIBCXX_ASSERTIONS` does not alter ABI.

From https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...

> Undefined by default. When defined, compiles user code using the debug mode.

"user code" here seems to indicate it's safe for libstdc++ users to define without worrying about ABI changes. If there were compatibility concerns, I'd expect that to be described in the documentation link above.

A strong distinction between _GLIBCXX_DEBUG and _GLIBCXX_ASSERTIONS is that the latter tries not to change the big-O complexity of operations when defined.

very technically defining _GLIBCXX_DEBUG in different ways across translation units violates the ODR, so it is UB. In practice this is expected to work with GCC[1] and the and the macro is ABI safe.

[1] if you are unlucky the function might not be inlined and an instantiantion form another translation unit that was compiled with the assert disabled might be picked up and the assert not fire.

Well, if we are nitpicking here, defining _GLIBCXX_ASSERTIONS in different ways across translation units also potentially violates ODR, as some inline functions or function templates get different definitions in different translation units.

This still can have undesired effects. An inline function can end up not being inlined in two such translation units, and depending on how the linker resolves the weak symbols you might get diagnostics in a TU where you didn't enable it or the other way around. But this manifestation is arguably much more benign than the ones you get for changing the layout of some classes.

edit:

In general ABI stability is not ODR stability. You can break ODR and retain ABI stability. You can't even add a non-virtual member function to a class without breaking ODR, but in most if not all ABIs this is fine.

The standard of course does not acknowledge the existence of "benign" ODR breaks, or the existence of an ABI.

It's not documented well.

If you follow the link to debug mode, one of the features is:

> Safe iterators: Iterators keep track of the container whose elements they reference, so errors such as incrementing a past-the-end iterator or dereferencing an iterator that points to a container that has been destructed are diagnosed immediately.

Now, this still doesn't say anything about ABI. But in non-debug mode std::vector iterator is essentially a pointer. In debug mode it needs to hold more state to implement iterator invalidation detection and whatnot. So its layout and object representation change, breaking ABI.

> asan/ubsan are great for finding language-level undefined behavior. But apart from some functions like memcpy that asan is hooking, they cannot find library-level undefined behavior such as the pop_back() on the empty vector. (That's an inline function inside a template, there's no way asan could hook this!)

no, libstdc++ is at least partly instrumented with explicit asan support : https://gcc.gnu.org/legacy-ml/libstdc++/2017-07/msg00014.htm... so fsanitize should be able to catch it (and after checking, definitely does: https://gcc.godbolt.org/z/rjadKvPTs)

That's a special case due to an empty vector using nullptr, and thus causing language-level UB when doing pointer arithmetic with a nullptr.

If you add an element to the vector and then remove it twice, asan will no longer find any problem: https://gcc.godbolt.org/z/MbPhWv8vn

ahhh just double checked and it is hidden behind a macro for libstdc++... see: https://gcc.godbolt.org/z/e7Wj163PM

Interesting, I wasn't aware of that one. I think `-D_GLIBCXX_ASSERTIONS` is more appropriate for catching this bug, but `-D_GLIBCXX_SANITIZE_VECTOR` seems useful for cases like this: https://gcc.godbolt.org/z/EjrdoTYPs

This is really the main problem with "safe modern C++": to get actual safety you need dozens of weird implementation-specific opt-ins and there's no good way to learn that these even exist.

So, if following the recommended C++ practices of mostly using std containers, ASan and UBSan are mostly useless?

containers are not thread safe though, so the thread safe sanitizer will be useful there.

ASAN and UBSAN are supposed to be handled by containers internally with RAII if they're used correctly, I still turn on both ASAN and UBSAN to catch bugs, it does not hurt.

As shown in the article, the following code invokes UB in user code, and is not directly detected by ASAN or UBSAN:

  std::vector<int> c;
  c.pop_back(); //pop_back() on empty vector is UB, per the library documentation
  int j = c[0]; //also UB, not sure if would be detected

This code is fully RAII compliant, but wrong.

It only takes a tiny effort to prove your ignorance with the exact example you gave. https://gcc.godbolt.org/z/x4sbTWxrY

  ASM generation compiler returned: 0
  Execution build compiler returned: 0
  Program returned: 0
    /opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_vector.h:1320:2: runtime error: applying non-zero offset 18446744073709551612 to null pointer
    /opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_vector.h:1124:34: runtime error: reference binding to null pointer of type 'value_type'
    /app/example.cpp:7:14: runtime error: load of null pointer of type 'value_type'

As someone coming from Java, why is pop_back undefined behavior?

An error or noop is something I expect, but undefined behavior?

It presumably allows the implementation to be a tiny bit faster, by avoiding a compare and branch for the empty case.

I suppose it causes an integer underflow and tryies to in-place destruct in an empty buffer?

The std::vector class is somewhat inconsistent about safety and maps a lot of it's operations directly to unsafe, raw array access. The C++ STL contains a lot of historical baggage and design inconsistencies.

For instance, while std::vector has an `at(index)` method, that does proper bounds checking and throws an exception if the index is out of range, it also has an overloaded `operator []` that mimics array syntax that will happily write out of bounds, trashing the heap.

STL was designed to have no overhead over the corresponding C code. If push_back (and all other functions) had an extra check even when it was guaranteed non-empty by construction, it would have been a non-starter for many users.

Consider that it took many years for compilers to reach the near zero overhead for STL as it is, removing precondition checks would have been beyond the ability of many compilers 20 years ago, and it still challenging today.

Of course the actual overhead went down since and today we expect code to be more robust by default, but the original design principles were different. If you want safety by default, check your compiler documentation and compile with lightweight assertions enabled even in release builds.

This makes sense for std::vector::operator[], but not for pop_back and push_back - as those don't have any equivalent for a C array. Instead, it's just another example of C++ optimizing for speed as opposed to correctness.

The equivalent C code is what you would write inline to do a pop_back on an array. You can't write a fast pop_back for std::vector if it didn't provide one by default as the fields you would need to manipulate are private.

And yes, it is indeed an instance of C++ optimizing for speed, which is exactly what I said.

std::vector exposes the exact same API as a C array, in terms of being able to write an external pop_back() function, since C arrays only expose the ability to access a particular element - no more, no less (and std::vector::resize() can be used instead of realloc() if that is desired).

The equivalent of of std vector is an array+size+capacity field. pop_back would litterally be capacity--. resize has overhead as it needs to handle resize up as well as down.

Sure, and I'm saying in C you could write:

  struct stack {
    int[] elems;
    int len, cap;
  };

  int pop_back(struct stack *x) {
    elem = x->elems[x->len - 1];
    x->len--;
    return elem;
  }

while in C++ you could have written:

  struct stack {
    std::vector elems;
    int len, cap;
  };

  int pop_back(stack& x) {
    elem = x[x.len - 1];
    x.len--;
    return elem;
  }

If you wanted C-style speed, with no safety.

that is not valid c. and in valid c++ (which this isn't) you would not need those two integer values.

There are some minor syntax errors - I should have written `int *elems` instead of `int[] elems`, and I forgot to declare `int elem` instead. Apart from these nitpicks, it's completely valid C.

As for C++, the <int> is missing on the std::vector, the elem variable is again not declared, and instead of x[...] it should have been x.elems[...]. Otherwise working valid C++. And yes, the `cap` is not really required, we could use x.elems.size() instead.

> pop_back would litterally be capacity--.

Minor nit: I think you meant 'size--'

ouch, yes of course

Java is memory safe, at a runtime cost (sometimes that cost is trivial, sometimes it isn't). It will insert a check every time you do a pop.

C++ is not. It's a precondition of calling pop_back() that the vector is not empty. It will not insert a runtime check - it leaves you to decide whether one is needed.

Your C++ toolchain will probably have an option to make (usually debug) builds check and complain if you actually call pop_back() on an empty vector.

So is Rust, and never did I hear a peep about `pop` is too slow better call unsafe.

typically, c++ library functions do not use a possibly expensive check if the caller could have performed it themselves, should they have wished to. in this case, the caller could have tested if the container was empty before calling the function.

Because in c++ we assume the programmer doesn't make logic mistakes, and optimize for speed instead. A novice programmer can add assert() as needed.

To use a car analogy - We removed seatbelts to go faster, just don't make mistakes while driving.

I'm not a novice programmer (close to 15 year in total) and I still make mistakes.

¯\_(ツ)_/¯ Maybe I'm just stupid

I had more bugs pop up from people calling front() on an empty vector than from direct out of range bounds. I guess people are more cautious when they are manipulating indices than when calling a method that takes 0 arguments?

Debug asserts are nice, but not sufficient when the code path causing the empty vec is only encountered by a production user from a different country at 2am. Enabling the asserts in release mode will at least prevent undefined behaviour and malevolent users from harming the system, but the best interface is the one that returns an optional, so as to make the "vector was empty" case explicit. That way it has a higher chance to be considered by the authors of the code or their reviewers.

Well, front() returns a reference. std::optional can't hold references. The closest you get is a plain pointer, with a null pointer for an empty container.

Other languages allow to return `Option<&T>`. That's what I'm using these days.

I suppose a raw ptr is what I would use on C++ to model that case though, yes.

Yeah, for some reason `std::optional<T&>` is cursed and can't get through standardization. People can't decide what should happen on assignment.

I guess a raw pointer is good enough an approximation in that case, it is just annoying that suddenly you can no longer use an optional because your type is a reference

pop_back on an empty container is a programmer error.

A pop_back defined as noop would only leave the program in a slightly more defined state, but quite likely you can't really reason about the behavior of the program after. And implementations would not be allowed to diagnose the erroneous pop_back at runtime.

IMO if pop_back had a defined behavior, it should be immediate termination of the program, with a diagnostic message. The standard does this for some erroneous behaviors, like failing to join or detach a thread before destruction, failing to catch an exception in various contexts or throwing an exception during stack unwinding.

Undefined behavior already allows the behavior of terminating the program with a diagnostic message, and some implementation provide options to have this behavior. It might not be very discoverable though, which is a pity. It would be nice if some higher level build tools provided easier options for "fortifying" C and C++ code, but I doubt that there are options that uniformly apply across compilers and standard library implementations.

It's C++. Its goal is speed over all else. So it tries to carve out space for where the optimizer can assume lots of things are true. Since they don't use anything like Hoare logic they have to get their assertions from somewhere else, inferring them as follows (among other things):

Undefined behavior just means that the specification does not say what will happen--so you can't rely on it as a user.

The upside is that the compiler (and the compiler writers) can assume that places where the undefined behavior would occur in your program cannot be reached in practice--and thus optimize your program better.

STL, which these containers are part of, is famously speed-optimized. STL (like C++) was designed for speed first (if at all possible then zero-cost abstractions) and thus does very little error checking on its own.

Also, C++ is compiled ahead of time--so whatever optimizations it wants to make it has to do BEFORE it starts the program. That means it cannot adapt to the concrete runtime circumstances on the fly (like Java can) and so they have to keep even the worst case runtime down in everything they do.

If they did check whether the thing is empty beforehand then that would cause a slowdown (at least that's the idea--better measure it), mostly because now there would be a branch in the first place. Hence they avoid doing that.

Yet we get stuff like std::regex, the speeding train of regular expression parser engines.

My theory is the compiler maintainers don't themselves use 90% of the language features they implement. So they can't begin to care how well they work for people writing other types of software.

> STL, which these containers are part of, is famously speed-optimized. STL (like C++) was designed for speed first (if at all possible then zero-cost abstractions) and thus does very little error checking on its own.

Only kinda? A bunch of the containers then make other promises or leak details that prohibit meaningful optimizations. An extra branch in std::vector::pop_back() is such a pointless savings compared to, say, that std::map is basically mandatory red-black tree or that std::unordered_map must store elements in a linked list to preserver iterators across removals.

Like almost none of the containers in the STL are "fast" at this point. std::vector is probably about the best, but even it is missing small-size optimizations (and that's ignoring the hair-brained bool specialization that then breaks everything)

I had once assumed std::unordered_map was from the original Standard Template Library (which pre-dates C++ standardization), but turns out (I was told in a r/cpp thread) it's more modern. In 1998 std::unordered_map would have been an excusable design mistake, domain experts knew in 1998 that's a sub-optimal design for this dict / hashmap structure - but you could suppose perhaps they were not on the committee. In 2011 it's not an excusable mistake, better structures are widely known in academic and in industry - it was an unforced error.

The more closely I look at it, the more I'm convinced that unsafety wasn't an inadvertent and undesirable consequence of a "must go fast" mindset in standard C++, unsafety was the whole point. It makes me think about that speech by Susan Sarandon's Rick & Morty character, Dr Wong.

Dr Wong: "I have no doubt that you would be bored senseless by therapy, the same way I'm bored when I brush my teeth and wipe my ass, because the thing about repairing, maintaining, and cleaning is; it's not an adventure. There's no way to do it so wrong you might die."

Software Engineering is an engineering discipline, it is not supposed to be an adventure. Programming C++ is an adventure, you can do it so wrong you might die. We should stop paying people to go on an adventure, let them do that exclusively on their free time if they want.

hash_map was indeed part of the original STL, but was not standardized in C++98. It was still widely available, in slightly incompatible forms, as an extension. In C++11 it was standardized with only minor changes (and renamed).

The address-preserving property, which precludes an optimal implementation, was considered important to be a near drop-in replacement of std::map.

Because unlike Java, which is designed to bore you to death, C++ is designed to gaslight you into madness.

I don't really see how one could make it a real no-op, and an error would imply that pop_back would look like

    if(empty()) { /* some error handling mechanism */ }
    ... rest of the code ...

and every added branch adds some minimal but non zero cost

However really often this is a case you actually care about, and so if you don't capture it in pop you end up asking a predicate. I have a whole bunch of Rust code that does:

  while let Some(thing) = container.pop() { /* ... */ }

There is indeed a branch, that pop function might return None - but when it does our while loop exits, the container is empty and we're done. My guess is that the idiomatic C++ here checks !empty() for the loop and then calls pop() on the container if it's not empty so in these cases we're doing the same work except we made it more error prone.

Also, it did still catch a problem in the second scenario, it just didn't conveniently point to the right line. +1 on _GLIBXCXX_{ASSERTION,DEBUG}.

According to https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_u... there's a D_GLIBCXX_DEBUG_BACKTRACE that will show a backtrace for the line number too

Reply on news.ycombinator.com