stack.peek для пустого стека вызывает сегфолт, а в дебаг-режиме ошибку Assert

_NODISCARD reference top() noexcept(noexcept(c.back())) /* strengthened */ {
        return c.back();
    }

Мама дорогая. Какой идиот это кодил..

Исключения используются там, где они могут возникнуть по логике работы кода из-за внешних причин. А у тебя речь про баг в коде. Хотя я не знаю что за шаблон stack, но наверно где-то прописано что так делать нельзя. Ассерт тому подтверждение. Если ставить везде проверки - код медленнее работает.

Открой для себя .NET 7.0 и не мучайся

Если ставить везде проверки - код медленнее работает.

Он уже и так медленнее работает: из-за лишней косвенная адресации (через поле c и и сам объект stack)

И в универе учили: проверяйте граничные условия! Не инкапсулируйте уязвимости в классе. Если вы проектируйте класс с undefined behaviour, значит, вы двоечник.

В C++ не принято платить за то чем не пользуются, поэтому в контейнерах нет проверок на диапазон индекса, соответственно не от куда и исключения кидать. В дебаге есть дополнительный ассерт, потому что это дебаг. Всё логично.

Граничные условия должны проверяться в твоём коде, а не в библиотечном.

Граничные условия должны проверяться в твоём коде, а не в библиотечном.

Бред.

В C++ не принято платить за то чем не пользуются

Проблема в том, что С++ не предоставляет мне никаких удобных средств, если я хочу платить микроскопической потерей производительности за лишние проверки.

При работе с файлами делаются проверки. Чем стеки хуже файлов? :)

Бред

Давай-ка ты со своим опытом программирования на уровне универа не будешь такими словами бросаться, ты просто себя выставляешь ламером.

Почему это должно проверяться в твоём коде:

• В своём коде ты можешь знать что стек непустой, и не делать проверки.
• Если ты не знаешь пустой ли стек, ты можешь сделать проверку, это во-первых, будет явный и очевидный код, во-вторых быстрый, по сравнению с попыткой взять элемент и ловлей исключения.

Проблема в том, что С++ не предоставляет мне никаких удобных средств если я хочу платить микроскопической потерей производительности за лишние проверки.

Тогда ты выбрал не тот язык. C++ выбирают как раз за то что он позволяет не платить за лишние проверки. И нет, она не микроскопическая - какой-нибудь tight loop где ты просто берёшь int из контейнера (один indirection) добавление проверки и целого бранча просадит, даже несмотря на предикшон.

Если для критична производительность, я вообще не выберу C++ с STL. То есть кресты это ни рыба, ни мясо.

Ты не знаешь языка, поэтому не можешь обоснованно делать такой выбор и такие выводы.

В своём коде ты можешь знать что стек непустой, и не делать проверки.

Это глубоко ошибочный подход. Проверки делать обязательно и делать это должен класс стека. Стек должен гарантировать консистентность своего состояния, иначе он ничем не отличается от тупого указателя.

А тут вообще пустой объект возвращается. Типа сегфолт не комильфо, давайте хоть что-то возвратим :)

std::map<int, MyClass2> mp;
    std::cout << mp[3].x;

Файл это внешний объект, его может запороть глупый юзер вне контроля твоей программы. Или может диск износиться и дать i/o error, что тоже штатная ситуация. А стек в памяти и запороть его можно только специально подключившись отладчиком.

А, там at можно использовать. Но почему-то в стеке аналогичных методов нет. Степанов ниасилил что-то более логичное сворганить

Тут почти согласен. В большинстве случаев писать лучше на Си.

Ваще круто. stack::peek сегфолт, map::[] пустой объект (что на самом деле еще хуже)

Это глубоко ошибочный подход. Проверки делать обязательно и делать это должен класс стека. Стек должен гарантировать консистентность своего состояния, иначе он ничем не отличается от тупого указателя.

В каких-то языках может быть и должен, в C++ он должен никаких проверок не делать. И нет, в стеке нет указателя, это адаптор, он не вводит лишнего индирекшона.

А тут вообще пустой объект возвращается. Типа сегфолт не комильфо, давайте хоть что-то возвратим :)

operator[] создаёт элемент мапы при его отсутствии и возвращает ссылку на существующий/созданный элемент. Читайте cppreference хотя бы.

Сделай свой STL.

Какой идиот это кодил..

Смотри что в стандарте написано: https://eel.is/c++draft/stack#defn

reference         top()             { return c.back(); }
const_reference   top() const       { return c.back(); }

Походу идиот это ты, а не тот кто кодил. Кто кодил, тот выполнил т.з. на 100%

Проблема в том, что С++ не предоставляет мне никаких удобных средств, если я хочу платить микроскопической потерей производительности за лишние проверки.

ассерты можно включить и для релизного режима сборки…

Ты не понимаешь что такое исключительная ситуация и когда уместны исключения. Если хочешь обрабатывать пустой контейнер через исключения, то скорее всего тебе нужно вырвать руки.

Если для критична производительность, я вообще не выберу C++ с STL. То есть кресты это ни рыба, ни мясо.

Вы не котиков не любите, Вы их готовить не умеете.

Кто кодил, тот выполнил т.з. на 100%

Значит, идиот тот, кто ставил т.з. А обезьяны повторяют. И считают это нормальным :)

Ты не понимаешь что такое исключительная ситуация и когда уместны исключения

Причем тут уместны или неуместны? Есть абстрактный тип данных стек. И нам плевать, как он там внутри устроен. Мы ожидаем не сегфолта, а нормального исключения, как во всех нормальных языках/библиотеках.

Ну словишь ты это исключение, дальше что? Ты продолжишь выполнять код заново(неудавшуюся задачу) ? Очевидно, что будет г, а автор говнокодер. Здесь нужно падать и писать логику на случай пустого стэка. Так чем тогда не подходит сегфолт?

Ну словишь ты это исключение, дальше что? Ты продолжить выполнять код заново? Очевидно, что будет г, а автор говнокодер.

Позволю себе лирическое отступление. На заре моей профессиональной карьеры была очень популярна CORBA, и в частности VisiBroker. Так вот, там был известный глитч когда массивы больше 64k тупо корраптились при пересылке. Знаете какой код я в какой-то момент увидел (в codebase довольно уважаемой конторы, спешу заметить)? «Массивчик больше 64k - зазиповать нахрен». Что произойдёт если ужатый message всё ещё не влезает в 64k - автора не сильно волновало.

К чему я. Стенания и подход ТС мне это очень сильно напоминают…

Здесь нужно падать

Это уже вызывающий код должен решать, падать или не падать, а просто подавить исключение (показав ошибку пользователю, записать ее в лог и т.д. и т.п.) и выполняться дальше. Но peek, pop и т.д. должны выбрасывать исключение, а не сегфолтиться, кэп.

отталкиваясь от такой реализации можно тривиально сделать ту, которую вы хотите. А отталкиваясь от той, которую вы хотите, можно сделать такую какая есть?

Писатели стандарта с++ намеренно делают его как можно более уродливым и, как сейчас модно говорить, кринжовым, чтобы на нем писало как можно меньше человек и чтобы он наконец упокоился с миром. Но мыши не сдаются! Кактус еще не доеден!

Показываю один раз.

https://godbolt.org/z/xM993vG3d

#include <stdexcept>
#include <vector>
#include <stack>

#include <gtest/gtest.h>

template <typename ... Ts>
struct CheckedVec : public std::vector<Ts...> {
    using base = std::vector<Ts...>;

    decltype(auto) back() {
        if (this->empty())
        {
            throw std::runtime_error{ "back(): empty" };
        }
        return base::back();
    }

    decltype(auto) pop_back() {
        if (this->empty())
        {
            throw std::runtime_error{ "pop_back(): empty" };
        }
        return base::pop_back();
    }
};


TEST(CheckedStack, Throws) {
    std::stack<int, CheckedVec<int>> stack;
    ASSERT_THROW(stack.pop(), std::runtime_error);
    ASSERT_THROW(stack.top(), std::runtime_error);
}

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

Вывод:

[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from CheckedStack
[ RUN      ] CheckedStack.Throws
[       OK ] CheckedStack.Throws (0 ms)
[----------] 1 test from CheckedStack (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 1 test.

Но peek, pop и т.д. должны выбрасывать исключение, а не сегфолтиться, кэп.

Нет, не должны.

Есть абстрактный тип данных стек.

Есть конкретный шаблонный класс std::stack<...>

И нам плевать, как он там внутри устроен.

В С++ – не плевать. Стек это адаптер к указанному параметром контейнеру, ведущий себя так же, как этот контейнер.

я вообще не выберу C++ с STL

И что же вы выберете?

Косвенная адресация, а особенно косвенная адресация по фиксированным смещениям на несколько байт, даже если не окажется заинлайнена и выпилена (а стек это шаблонный класс, и поэтому инлайн происходит почти всегда), в любом случае является более дешевой, чем один if, для вычисления которого, кстати, придется совершить еще один доступ к памяти с косвенной адресацией. Не говоря уже про выброс исключения.

Экономия на спичках в ущерб безопасности. Переключение контекста занимает в разы больше времени.

в C++ исключения ублюдочные, поэтому их не особо пихали в STL. Чтобы оправдать это непотребство, для дурачков провозгласили принцип «не платим за то, что не используем».

Это C++, он сегфолтится, это нормально. Бери Rust.

Используй Qt.