- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
#include <iostream>
#include <map>
int main()
{
std::string name;
std::map<int, int> m = { {1, 1}, {2, 2} };
m.erase(m.end());
std::cout << "Kokoko " << m[1] << std::endl;
}-
C++ / Говнокод #27462
+1
На моем проекте уходит в бесконечный цикл.
Запостил:
YpaHeLI_,
08 Июня 2021
Follow us!
Лолшто.
Кстати, вы будете семяца, но про это даже прямо на цппрейференс написано
The iterator pos must be valid and dereferenceable. Thus the end() iterator (which is valid, but is not dereferenceable) cannot be used as a value for pos.
Уранец наверное пытался сделать UB, и посмотреть, что будет
Прямо как про лом и унитаз в поезде...
ну правда методы придется переделать, чтобы они удаляли по указатель включительно
Правда это тоже было бы мерзко
В паскале из-за этого приходилось писать "от 0 до -1" уводя индексы в минус, угу. Ну или if'ы лепить, чтобы пустой кейс отдельно обрабатывать.
З.Ы. Короче сишный вариант -- это меньшее зло, как мне кажется.
Я вполне верю, что сишный вариант взяли не с потолка, а потому что были какие-то проблемы, но сам по себе он тоже не оч хороший, пушо вводит понятие "неразыменовываеемымымымй указатель", а потом уранцы вон код пишут
Дык конструкция языка просто заметёт эту проблему под ковёр. В реализации этой конструкции один хуй будет или if или end < begin.
Тлен и безысходность.
>Тлен и безысходность.
ладно, убедили. Эскобар.jpg
Пустой интервал ничем не отличается от любых других. Да ещё и длину считать легко, всего одно вычитание. Просто юзай end() по назначению и будет тебе счастье.
А вот один "особый случай" показал нам Уранец.
А ещё можно местами поменять begin() и end(). Тоже "смешно" будет.
он совершенно искренне думает, что должен получиться пустой интервал, а получился UB
Да и вообще в целом нельзя написать такой код, который разыменовывает любой указатель, потому что они могут быть неразыменовываемыми
Так что сишкино решение тоже не идеально
А кто говорит, что оно идеально? Просто меньшее из джвух зол.
В джаве пустой итератор тебя тоже экцепшоном ёбнет, кстати, если ты полезешь к нему в next().
Эта перегрузка принимает не интервал, а итератор. Ожидать, что функция, которая удаляет ровно один элемент, в каких-то случаях не будет ничего удалять... несколько рисковано.
А это естественная концепция, кстати. Иначе на пустом интервале тебе придётся запретить begin(). Вообще. Потому что его там тоже не разыменовать.
[0, -1] тогда уж, как в паскале делали. Но это выглядит как говно, особенно с точки зрения ма-те-ма-ти-ки.
Читаемость паскалевого стиля тоже сомнительна..
а потому что надо было послать нахуй математику, знаковый size с точки зрения математики и здравого смысла тоже говно, но все едят, потому что кампутиру так проще
В С++ не едят. Поэтому, если пользуешься стандартной либой, приходится или использовать беззнаковый тип или отключать варнинги о нарушении сегрегации по знаковому признаку.
Получится вполне себе нормальное число, даже стандарт не нарушится
См. https://abseil.io/tips/171 .
А вот если речь идет НЕ об интах, а например о енумах или указателях на класс (см паттер Null object), то конечно они кал, бо срать в домен костылями не комильфо
Но разумеется optional лучше всегда
По-хорошему это -5 и нормальные числа должны быть в разных ветвях ADT, чтобы типизация вообще ну никак не давала смешать их между собой или забыть обработать какой-то кейс: Error -5 но Size 42. Но нормальных ADT в мейнстримных языках нет, только костыли в духе optional.
З.Ы. А для скриптушни похуй, конечно. Там и так про типы никто не парится.
Для примера выше, ``AccountBalance`` вообще не мог бы быть signed.
Плохо, что там -5, и плохо что от валидного баланса к ошибке можно перейти простой арифметической операцией
Но я видел код, где люди ищут в сообщении об ошибке подстроку, и строят на этом логику.
И да: сообщение это локализованное.
Так что ERROR как -1 не так и страшны
Технический овердрафт смотрит на тебя с непоняманием...
Будет забавно, если чел перебрал на 5 рублей и теперь его банк-клиент крашится с ошибкой access denied потому что -5.
Потому что если может быть, то ты сам описал, что будет))
Это может быть баланс на счету в Интернет магазине. Там отрицательных значений быть не может (магазины в кредит не торгуют)
Есть еще мой "любимый" вид ошибки как в COM HRESULT, где в четырехбайтный инт упаковали severity и facility
Глупые программы выдают его как обычное число, потом у тебя ошибка "2147500037"
Лолшто.
а что, можно купить в интернет магазине что-то, уйти в минус, и потом через месяц загасить долг?
https://en.wikipedia.org/wiki/HRESULT#HRESULT_format
> Die Generic
какие прононсы )))
(К сожалению запаттернняшить и обмонадить это в крестах не получится, только вот такие вот ифы...).
В джаве дураки придумали хуёвый Optional и он выглядит как говно
Единственный нормальный способ обработки ошибок это такая манда, которую паттернмачишь, и из нее вылазит либо ошибка, либо результат
Любой код, где надо писать
похож на Go
не понимаю, почему это не завезли в мейнстрим. Даже кокотлиновцы обосрались
Кстати, checked исключения, в принципе, очень похожи на монадическую обработку ошибок -- ты либо паттерн-няшишь ошибку через try либо она форвардится дальше (при этом у тебя в типе функции это явно указано).
Потому у нас в проекте в случайных кусках кода то тут, то там расставлены catch, которые ловят всякие разные исключения.
Где увидели ошибку в логах, туда и воткнули catch.
Checked исключения в джаве действительно решали эту проблему, но они были настолько отвратительными (и тяжелыми, если стек трейс не отключить), что ими никто не пользовался.
Котлиновцы еще умеют возвращать null в случае ошибки (null safety это проверяет), но саму ошибку ты не вернешь.
Мне советовали юзать вот
https://arrow-kt.io/docs/0.10/patterns/error_handling/#either
но поскольку это не в стандартной библиотеке, то разумеется нигде и неиспользуется
Потом они завезли вот
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/
но тут ошибкой может быть только Throwable, что (имхо) тупо
Да сойдёт, наверное... Тебе же с джавой интегрироваться всё-таки. Может понадобиться дальше прокинуть как исключение.
С другой стороны без монад явная обработка ошибок нахуй не нужна. Привет, го.
Я могу хотеть вернуть строку ошибкой, нафиг мне ее заворачивать:)
У нас для котлина был напилен свой sealed class, который можно было паттернматчить
Ты получаешь абстрактрный Result<Petuh, Error> и матчишь его.
Он либо наследник Error, либо Petuh.
В бинарном поиске если итерироваться по полуоткрытому с конца интервалу то всегда искомое значение != верхней границе и меньше кейсов нужно обработать
https://pbs.twimg.com/media/E3WKlxLWEAImmtr?format=jpg&name=900x900