Orthodox C++ (2016)

> Reporting normal errors to the caller, as opposed to exceptional errors. The distinction between normal errors and exceptional errors is kind of nebulous, but it boils down to normal errors being those that the immediate caller would be interested in, and everything else is exceptional.

...

> So to answer your question, exceptions are misused when they communicate relevant errors within the same level of abstraction, such as an open() function throwing a FileNotFoundException.

I think your thoughts feel a little bit jumbled here, possibly because you're oversimplifying things too much. Whether a caller would be interested in an exception doesn't really determine whether it should be an exception or an error code. For example, std::regex_error and std::format_error are very much of interest to the callers of the APIs that throw them (e.g., because the patterns user-provided and the callers expect potential failures) but that doesn't mean they shouldn't be exceptions. Or, for example, the only entity ever really interested in an std::out_of_range exception is the caller (say, catching it around a call like std::accumulate(i, j, [&](const auto& key) { return container.at(key); })).

You're right that those things all matter in a lot of cases, but the line isn't really drawn like that. IMO, the truth is that whether an exception should be raised vs. an error returned is really not so easy to pin down to a single factor. The things you mentioned matter, but so do run-time, compile-time, and development-time costs. The reason FileNotFoundException is better left as an error vs. an exception isn't so much that it's an expected error condition (in fact, some callers might expect it and others not), but because of the performance characteristics callers generally expect. You don't want disproportionate performance impact to those who need to open potentially non-existent files. If C++ exceptions were as cheap to throw as to avoid, then that would tip the balance significantly.

>std::regex_error and std::format_error are very much of interest to the callers of the APIs that throw them (e.g., because the patterns user-provided and the callers expect potential failures) but that doesn't mean they shouldn't be exceptions

Most commonly, regexes and format string are passed from program data, not user input, so in the majority of cases I don't think it's correct to say that errors are an expected situation. Programmer error is definitely not something that can be handled at the call site, so it makes for a prime candidate to be signaled by an exception.

>Or, for example, the only entity ever really interested in an std::out_of_range exception is the caller (say, catching it around a call like std::accumulate(i, j, [&](const auto& key) { return container.at(key); })).

Why would you write exception handling code around that call instead of ensuring before the call that the indices are valid? If you did ensure that and an exception was still thrown, that's the kind of situation that the caller is not able to resolve, so why would it be interested in the exception? What could it possibly do to recover once it's been proven that the vector was changed concurrently?

>If C++ exceptions were as cheap to throw as to avoid, then that would tip the balance significantly.

No, I don't agree. Sorry for not making my position clearer. What I said previously assumes that you don't have any additional constraints beyond designing the best error handling possible. If you have technical reasons to avoid exceptions (they're too expensive, you're about to cross an FFI boundary, etc.) then that's a reason to stay away from them. I think you should use exceptions up to as much as I said. To use your metaphor, my argument is the floor under the plate of reasons to use exceptions, and the balance can only tip in the other direction.

It is still quite hard for me to take this seriously as a belief.

> Ok now you're really out of your depth here.

I don't think so. As you found, the consensus is that this sort of thing is a terrible idea. The O(1) complexity looks good superficially but your actual performance is miserable.

> I don't know the details though.

Raymond Chen has a pretty good explanation of the three implementations of std::deque, like he did for their std::string but Raymond's goal is to help you do forensics, he's not here to tell us which data structures are a good idea. https://devblogs.microsoft.com/oldnewthing/20230810-00/?p=10... might work, or, given Microsoft, it might already be dead by the time you click it.

The thing C++ programmers tend to expect (though perhaps not you) is Rust's std::collections::VecDeque - the growable array type again but used as backing for a ring buffer.

This type has amortized O(1) push and pop at both ends, I assume since you didn't like the amortized growth of Vec / std::vector you'll feel the same way but that's what most programmers actually want from such a type - in use as a queue it won't repeatedly cycle allocations so long as the size is constrained, because it's a ring buffer. If you actually know the needed size up front the overhead from this structure, which can grow, versus a structure which can't grow, is a single integer for the capacity.

But as you saw, std::deque is... not that. STL wasn't able to explain what it's for when I asked him, so, if anybody knows it apparently doesn't include the people maintaining the C++ standard library implementations.

> Or take it from someone else if you would

I think the trouble here is that you've misconstrued this entire part of the conversation. I was gesturing at std::deque because it's terrible, and your response, that it's terrible, isn't a rebuttal as I think you're expecting. We agree on that, std::deque is terrible, our disagreement seems to be that you think a slightly different terrible data structure would be a good idea somehow and I do not.