Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+1
catch (Exception &exception)
{
Application->ShowException(&exception);
}
catch (...)
{
try
{
throw Exception("");
}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
}https://github.com/greatis/Anti-WebMiner/blob/master/AntiWebMiner.cpp#L23
Запостил: 
MAKAKA,
13 Сентября 2020
Follow us!
finally для бедных.
А не в петухоне чем?
Кусок на жопе-то остаётся, а не отваливается.
> Потому что не всегда имеется возможность в методе правильно обработать исключение — надо пробрасывать его выше и позволить вызывающей стороне произвести обработку (или пробросить еще выше, если она тоже не знает как его обработать), следовательно блок catch присутствует далеко не везде, где есть блок try.
А вот всякие ресурсы подчистить в случае возникновения исключения необходимо сразу же, т.к. это является деталью реализации и вызвающая сторона о них ничего не знает.
От себя скажу лишь то, что по-моему так писать систему - это антипаттерн. Потому что клиент не должен ничего знать о внутренностях интерфейса.
Не случится багор, если в конструкторе вылезет исключение? Если вылезет, то какой-то Stream у меня не закроется, например. С ручным new/delete я хотя бы уверен, что вызову деструктор и почищю за собой.
А если он реализован некорректно - с new будет только хуже.
Деструктор на недоконструированном объекте звать нельзя. Это UB. Всё что успело создаться (родительские классы, поля, локалки и т.п.) и так само размотается, не надо туда лезть руками.
А ручной delete тебе не на чем будет звать, кстати. new ведь тебе ничего не вернёт при исключении в конструкторе.
Если тебе от какой-то либы достались не RAII'шные ресурсы, заверни каждый из них в отдельную RAII'шную обёртку и убедись, что твой деструктор и мувающие методы не бросают исключений. Почему отдельную? Потому что иначе ты заблудишься в лесу из траев.
В общем-то и всё. Дальше ты можешь юзать эти обёртки в любых кобенациях и течь.
А если под лочкой или чем-то подобным удалять не хочется - можно мувнуть за скоуп лочки.
RAII вполне предсказуемо и контролируемо, в отличие от GC. Оно никогда не триггерится "само по себе".
Нет.
Царь объяснял уже.
SLAB/SLOB аллокатор. Причём RAII на эту парадигму прекрасно ложится, а скорость аллокаций/деаллокаций такая же как на стеке.
годно
Ну как бы это уже всё усложняет, что вот допустим кто-то говорит
- А давайте такое запилим, что если переменная выходит из скоупа, то автоматом вызываем деструктор
- Ну ок, давайте
- А вот если надо чтоб этот деструктор вызывался не по завершению скоупа, а потом, давайте сделаем чтоб мувать можно было, и тогда деструктор уже вызовется при окончании скоупа для той мувнутой хрени
- Ну ок, давайте
- А давайте чтоб еще какая-то поебень, ну например http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1144r4.html
....
и вот так вроде бы исходно простая и понятная хуйня обрастает всякими взаимосвязями с другми слоями поебеней, которые говностандартизаторы в крестоговно добавляют https://habr.com/ru/post/484380/
и это уже становится не так просто.
Если же оставаться на базовом уровне, что вот когда хуйня за скоуп выходит - вызываем такую-то функцию, то это вообще ничем не примечательная хрень, и говорить о ней как о некоторой важной фиче я считаю глупо. Такое и на сишке накостылить можно
> RAII вполне предсказуемо и контролируемо, в отличие от GC. Оно никогда не триггерится "само по себе".
Так-то если взять ограниченый вариант GC, ну типа просто тупой рефкаунтер, без всякой заумной хрени с поиском циклов, то там тоже все довольно предсказуемо и контролируемо.
>Такое и на сишке накостылить можно
Неправда же. ОЧЕНЬ сложно отследить выход за скоуп. Всякие goto, гетигп, бряки.
Даже в «простой» сишке регулярно возникают проблемы, вписали в длинный метод гетигп забыли goto CLEANUP добавить и ресурсы уже не чистятся. Одноразвратники опять торжествуют.
>то это вообще ничем не примечательная хрень
Ага, а как же. Именно поэтому a variably modified type такая особенная фигня, из-за которой в стандарте пришлось добавить исключение для goto.
Ну на самом-то деле нихуя такого сверхсложного нет. Проверяем все goto, return, break, longjmp-ы на предмет того, что от них хуйня выходит за скоуп, если выходит, то перед ними освобождаем хуйню. Можно какой-нибудь говнопрепроцессор под это запросто приспособить, хотя и гнутое расширение есть готовое https://govnokod.ru/25526 и еще какая-то поебень без гнутого расширения есть https://govnokod.ru/24517 хотя там вместо обычного return надо какую-то хуйню писать, так что это говно
Кстати вот https://ideone.com/lpT99r реальный пример, когда RAII в крестоговне ломается через гнутое расширение
> Именно поэтому VLA такая особенная фигня, из-за которой в стандарте пришлось добавить исключение для goto.
Просто надо использовать alloca(), и никакие VLA нахуй не нужны
Всегда уважал вас как борца за эстетику кода.
Но вот это:
ЁБАНЫЙ ВЫРВИГЛАЗЫЙ ПИЗДЕЦ!
На этом фоне даже крестопарашная std::дрисня не выглядит такой уж жуткой.
std::map<std::string, it>
Обычно эту поебень через макроговно заворачивают. Там я специально показал это в первозданном виде.
Вот например такой вариант можно представить:
А может ещё сильнее в марко завернуть, чтобы получилась логически завершенная конструкция, типа такой:
AUTO_ALLOC(char *, x , my_free, 42);
https://github.com/Snaipe/libcsptr
https://govnokod.ru/26951
АААААААААА!!!
Слова не лалки, но Царя.
(неистово жмёт кнопку плюс один)
https://govnokod.ru/13162#comment180985
https://govnokod.ru/13183#comment182345
Ну ты что, посмотри как в жабе или питоне сраный try/with боготворят. А это как раз самая базовая форма, даже каскадить на поля структур не умеет, в отличие от крестов.
Старый джавист песенку спел
Как хорошо с GC жить
Как хорошо вручную вот так писать
А лучше всех ему -- получающему зарплату за количество сторочек в проекте старому джависту
Так и сейчас городят.
try~with не работает для многих ресурсов, как например лочки или сёмафоры.
вижу, что нет
ну какие питушки-то а
не знаю как еще более по русски сказать
https://github.com/xetorthio/jedis/issues/500
2013. Проблема:
>I'm also proposing Jedis class to implement java.lang.Closeable interface to take advantage of Java 7 'try with resources' feature and to provide a transparent and cleaner object returning to the pool mechanism.
2014. Решение:
>try (Jedis jedis = pool.getResource()) {}
>Jedis was accessed from a pool. Jedis should be returned to the pool.
>Instead the connection is closed.
>This makes it impossible to use Jedis in a try-with-resource without closing it.
2015. Итог:
>This issue was closed by won't fix. But notice that #909 and 6701b07 have merged to use close() instead of returnResource() or returnBrokenResource() after 3.0.0-SNAPSHOT.
>The latest usage is following. Make sure everybody knows about that smiley
Какой try-with-resource )))
Какие питушки )))
С риал тайм аргументами не согласен по причинам изложенным бормандом.
А RAII питушня, потому что сцуко неявная. И потому не trivially reallocatable.
Потому вектор питухов там не мувается нормально reallocом, а на каждой питушне нужен конструктор+деструктор.
Вообще raiiшные замашки и в Сишке есть, начались они с С99.
Там, ЕМНИП можно сделать goto за VLA и стек порвать.
При K&R такой хуйни не было.
Раньше ведь в сишке в силу простоты можно было прыгать свитчом и goto в произовольное место функции.
Попробовать впрыгнуть в блок за аллокацию, чтобы они освободило массив, не аллоцируя его на стеке.
В крестовой парадигме это delete без new.
Правда компиляторы гады умные, там надо поебаться чтобы это говнище скомпилилось.
А вот c alloca всё просто, так это вообще счастье и удача.
Её пидорасит даже от простого инлайна.
https://govnokod.ru/26809#comment561177
Это ж Сишка. Там ничего автоматически не разрушается.
Только переменные на стеке.
> Законно вообще вот так делать?
Я когда-то давно читал хороший пример про вещи в отеле.
https://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope/6445794
You rent a hotel room. You put a book in the top drawer of the bedside table and go to sleep. You check out the next morning, but "forget" to give back your key. You steal the key!
A week later, you return to the hotel, do not check in, sneak into your old room with your stolen key, and look in the drawer. Your book is still there. Astonishing!
How can that be? Aren't the contents of a hotel room drawer inaccessible if you haven't rented the room?
Well, obviously that scenario can happen in the real world no problem. There is no mysterious force that causes your book to disappear when you are no longer authorized to be in the room. Nor is there a mysterious force that prevents you from entering a room with a stolen key.
The hotel management is not required to remove your book. You didn't make a contract with them that said that if you leave stuff behind, they'll shred it for you. If you illegally re-enter your room with a stolen key to get it back, the hotel security staff is not required to catch you sneaking in. You didn't make a contract with them that said "if I try to sneak back into my room later, you are required to stop me." Rather, you signed a contract with them that said "I promise not to sneak back into my room later", a contract which you broke.
In this situation anything can happen. The book can be there -- you got lucky. Someone else's book can be there and yours could be in the hotel's furnace. Someone could be there right when you come in, tearing your book to pieces. The hotel could have removed the table and book entirely and replaced it with a wardrobe. The entire hotel could be just about to be torn down and replaced with a football stadium, and you are going to die in an explosion while you are sneaking around.
Переменная, это просто какое-то место в стеке или значение в регистре.
А конец функции только сдвигает esp.
>Только переменные на стеке.
Я выше был некорректен. Даже значения в стековом массиве обычно не чистятся, а остаются.
Данные есть где-то за пределами esp, однако они недоступны програмно, если заранее не украсть указатель.
>они все еще живут до конца функции
Тогда бы данный код переполнял стек, аллоцируя 42*100500 интов.
А это деталь реализации или часть стандарта?
Гарантируется ли мне, что на любой архитектуре всегда стек подвинут только при выходе из функции, то есть если я создал переменную в блоке if(){}, то она всегда доступна до конца функции
Автоматические переменные (кроме VLA) живут до конца блока.
Раньше в Сишке такой хуйни не было: туда не ходи, то не делай.
http://c0x.coding-guidelines.com/6.8.6.1.html#:~:text=A%20goto%20statemen t%20is%20not,scope%2C%20however%2C%20is% 20permitted.
http://www.cyberguru.ru/sources/cpp-builder/classes-vcl/klass-tfilestream-ponyatie-potoka-vcl.html
Х.з., я не смотрел код, мне обычно лень ссылки открывать, только комменты читаю.
Но MFC, VCL и winapi я чую за километр. Этот запах невозможно забыть.
Запах особый:
В булочной пахнет
Тестом и сдобой.
Мимо столярной
Идёшь мастерской, –—
Стружкою пахнет
И свежей доской.
Пахнет маляр
Скипидаром и краской.
Пахнет стекольщик
Оконной замазкой.
Куртка шофёра
Пахнет бензином.
Блуза рабочего –—
Маслом машинным.
Пахнет кондитер
Орехом мускатным.
Доктор в халате –—
Лекарством приятным.
Рыхлой землёю,
Полем и лугом
Пахнет крестьянин,
Идущий за плугом.
Рыбой и морем
Пахнет рыбак.
Только безделье
Не пахнет никак.
Сколько ни душится
Лодырь богатый,
Очень неважно
Он пахнет, ребята!
On Error выглядит благодатью на фоне обилия анскильного try~catch бойлерплейта и goвняно-rustовых проверочек
Зато бойлерплейта в коде получается меньше, из-за отсутствия вложенности.