История изменений
Исправление hateyoufeel, (текущая версия) :
Где-то секунды полторы после выбора из главного меню.
И это типа быстро? Полторы секунду чтобы консольку открыть? srsly?
Потому что только в этом случае мы имеем принципиальный выбор между надежностью и скоростью.
Нет, выбор куда интереснее.
Это как раз вопрос, который я вам и задал, но на который вы не стали отвечать
Сорян, тут тред интересный, я его пропустил.
ведь выбор же простой:
либо проверки на каждое обращение и тогда прощай производительность,
либо отсутствие проверок и тогда потенциальная запись за эту самую границу.
Но там, где производительность все еще имеет значение, то какой выход?
У тебя проблемы в рассуждениях, на которые я указал выше. В C++ лишь очень небольшая часть кода вызывает львиное количество ошибок при работе с памятью. При этом, утверждение, что, дескать, это всё сделано ради конской производительности, нужно ещё доказать, потому что зачастую производительностью там не пахнет.
Как я уже показал выше, при грамотной работе с массивами, о которых ты тут писал, лишних проверок практически не возникнет. Тем более, что перед глазами у нас есть пример Rust, на котором уже написано достаточно много кода, показывающего схожую с C++ производительность даже без использования unsafe{}.
Сколько у тебя горячих мест в среднем проекте, где прямо кровь из носа нужна скорость случайного доступа к массиву? Готов предположить, что это очень нечастая ситуация и такого кода не больше 2% от общего числа. А значит, можно ручками оптимизировать конкретно этот код, а в остальном включить автомагические проверки и перестать страдать уже.
В принципе, тут та же ситуация что и с UB: куча сишных шизофреников пишут, что мол UB нужно для таких-то там мегаоптимизаций, но пруфов что без UB оптимизации невозможны почему-то нету, а с выключением многих случаев UB через флаги компилятора и расширения почему-то ничего тормозить не начинает (больше обычного, я имею ввиду). Короче, типичная ситуация «диды страдали и нам завещали».
Исправление hateyoufeel, :
Где-то секунды полторы после выбора из главного меню.
И это типа быстро? Полторы секунду чтобы консольку открыть? srsly?
Потому что только в этом случае мы имеем принципиальный выбор между надежностью и скоростью.
Нет, выбор куда интереснее.
Это как раз вопрос, который я вам и задал, но на который вы не стали отвечать
Сорян, тут тред интересный, я его пропустил.
ведь выбор же простой:
либо проверки на каждое обращение и тогда прощай производительность,
либо отсутствие проверок и тогда потенциальная запись за эту самую границу.
Но там, где производительность все еще имеет значение, то какой выход?
У тебя проблемы в рассуждениях, на которые я указал выше. В C++ лишь очень небольшая часть кода вызывает львиное количество ошибок при работе с памятью. При этом, утверждение, что, дескать, это всё сделано ради конской производительности, нужно ещё доказать, потому что зачастую производительностью там не пахнет.
Как я уже показал выше, при грамотной работе с массивами, о которых ты тут писал, лишних проверок практически не возникнет. Тем более, что перед глазами у нас есть пример Rust, на котором уже написано достаточно много кода, показывающего схожую с C++ производительность даже без использования unsafe{}.
Сколько у тебя горячих мест в среднем проекте, где прямо кровь из носа нужна скорость случайного доступа к массиву? Готов предположить, что это очень нечастая ситуация и такого кода не больше 2% от общего числа. А значит, можно ручками оптимизировать конкретно этот код, а в остальном включить автомагические проверки и перестать страдать уже.
В принципе, тут та же ситуация что и с UB: куча сишных шизофреников пишут, что мол UB нужно для таких-то там мегаоптимизаций, но пруфов что без UB оптимизации невозможны почему-то нету, а с выключением многих случаев UB через флаги компилятора и расширения почему-то ничего тормозить не начинает (больше обычного, я имею ввиду).
Исходная версия hateyoufeel, :
Где-то секунды полторы после выбора из главного меню.
И это типа быстро? Полторы секунду чтобы консольку открыть? srsly?
Потому что только в этом случае мы имеем принципиальный выбор между надежностью и скоростью.
Нет, выбор куда интереснее.
Это как раз вопрос, который я вам и задал, но на который вы не стали отвечать
Сорян, тут тред интересный, я его пропустил.
ведь выбор же простой:
либо проверки на каждое обращение и тогда прощай производительность,
либо отсутствие проверок и тогда потенциальная запись за эту самую границу.
Но там, где производительность все еще имеет значение, то какой выход?
У тебя проблемы в рассуждениях, на которые я указал выше. В C++ лишь очень небольшая часть кода вызывает львиное количество ошибок при работе с памятью. При этом, утверждение, что, дескать, это всё сделано ради конской производительности, нужно ещё доказать, потому что зачастую производительностью там не пахнет.
Как я уже показал выше, при грамотной работе с массивами, о которых ты тут писал, лишних проверок практически не возникнет. Тем более, что перед глазами у нас есть пример Rust, на котором уже написано достаточно много кода, показывающего схожую с C++ производительность даже без использования unsafe{}.
Сколько у тебя горячих мест в среднем проекте, где прямо кровь из носа нужна скорость случайного доступа к массиву? Готов предположить, что это очень нечастая ситуация и такого кода не больше 2% от общего числа. А значит, можно ручками оптимизировать конкретно этот код, а в остальном включить автомагические проверки и перестать страдать уже.