Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+3
#include <stdio.h>
#include <string.h>
#include "s_gets.h"
#define SIZE 30
void revers(char *);
int main(){
char str[SIZE];
s_gets(str, SIZE);
revers(str);
puts(str);
return 0;
}
void revers(char * str){
int size_ = strlen(str) - 1;
char tmp;
for(int i = size_; i >= 0; i--){
tmp = str[i];
str[i] = str[size_ - i];
str[size_ - i] = tmp;
}
}
https://ru.stackoverflow.com/questions/1173617/Изменения-строки-в-функции
> Собственно задание заключается в написании функции, которая заменяет содержимое указанной строки этой же строкой, но с обратным порядком следования символов. Почему строка не переворачивается?
Какой багор )))
Запостил: 
OCETuHCKuu_nemyx,
03 Сентября 2020
Follow us!
Ну он и переодел: носок с левой ноги надел на правую, а с правой – на левую
(и обратно, если я верно прочитал код)
З.Ы. Учись юзать отладчик или логи писать.
А что там кроме bad_alloc в конструкторе может быть?
Да, на топлевле удобно иметь кетч. Дождаться деструкторов, нормально залогировать ошибку и тогда уже сдохнуть. Без него просто выведет what() из экцепшена в stderr и terminate().
Майки, кстати, этим страдают в комовских обёртках. Хотя ошибку освобождения памяти надо ещё умудриться вызвать.
В нормальном коде вообще исключений быть не должно, во всяком случае в нормальном языке, лол. Исключение же это всегда бага
Если у тебя в языке легковесные исключения, то в чём проблема их использования?
Да даже если и не легковесные
Тогда их надо делать checked, а это довольно неудобно, джависты вон страдают.
А не чекд эксепшен для логики это пиздец, потому что не понятно что откуда и когда вылетет.
Самое нормальное это возвращать резулт (наверное это называется "монада") и потом его паттеринг матчить
- сорта говна
псведоко
Предложи более красивый вариант решения
?
Я ебал такое
клиент может потом сам матчить нужный ему эррор
Клиенту вернулся эксепшн, который на его уровне не обрабатывается, он должен его прокинуть выше, в итоге у меня весь код обвешан Result'ами, не, ну его нахуй
Зацени
И что поменялось?
Вот проблему "обвешан трай кетчем" я понимаю.
Вместо
я вынужден писать
Причем даже если я не хочу ее обрабатывать, я все равно обязан ее ловить.
Такой вариант как askUserAndReadFileDirty с чекд исключениями не сделать
А у тебя вообще получается типа такого: в Йаже исключения говно, потому они везде говно
А это не так
> умненький программист не забудет поймать нужные исключения
- ты ж сам написал, что в котлине никто не может заставить тебя ничего ловить, так котлин всё же говно или?
На самом деле это значит
Result<PizdecType, Exception>
А потом клиент класса должен сидеть, и разбирать что именно пришло (или не разбиратьь, если не интересно).
В нашем варианте ты всегда должен указывать ошибку (кстати, это может быть и не исключение вовсе)
Было бы удобно иметь упрощенный синтаксис типа Result<PizdecType> где второй параметр это неявно Exception
>ты ж сам написал, что в котлине никто не может заставить тебя ничего лови
В котлине нет чекд ичключений: слово throws там нет (есть только для интеропа с жабой).
Так что использовать исключения для логики там вообще никак нельзя. Никто не заставляет тебя их ловить.
Ты сделал
var = vend()
А потом в продакшене у тебя упало "no enough funds".
и ты такой: "ой, а вот еще оказывается как могло быть, а я не подумал"
- у тебя то же самое будет, если метод бросает несколько не связанных между собой типов исключений
Ну короч, мы уже по третьему кругу пошли. А ты кроме котлина и жабы что-то знаешь ещё?
Подтверждаю, такова специфика срачей про исключения на ГК. Возникают рагулярно, имеют зацикленный характер.
Добрый вечер.
Верно.
>А ты кроме котлина и жабы что-то знаешь ещё?
во всех остальных кроме жабы известных мне языках исколючения не чекд. Сегодня я узнал, что в свифте они в некотором роде чекд)
В языках со статической типизацией строить логику на не чекд исключения плохо по причинам, которые я уже несколько раз описал: не существует способа статически проверить, что ты осмысленно отказался от проверки исключения или обработал его.
В C# вместо исключений иногда используют out параметры (в джаве и котлине так нельзя).
Так себе способ:
В скриптушне логику строят иногда на исключениях (в джанге например) но там это пофиг: один хуй cpython ничего не проверяет "статически".
Давай я перефразирую свое утверждение:
В языках со статической типизацией, где компилятор проверяет код, и где нет чекд исключений (то есть это НЕ свифт и не джава) исключения не должны использоваться для нормального програм флоу, а должны только для ошибок в программах и оборудовании.
При выборе между резалтом с матчингом и чекд исключениям я отдаю предпочтение первому, потому что я вижу там больше сахара и больше гибкости, однако по уровню надежности решение свифта и решение с резалтом примерно одинаковы.
Если бы я писал на свифте, я бы конечно использовал его исключения с throws
ну в общем я к тому, что если к тебе прилетел исключень, то всё ОЧЕ плохо, и сдохнуть тут записав корку вполне допустимо.
Другой вопрос, что если ты демон, то тебе надо куда-то лог писнуть
К примеру, кривого клиента можно просто дропнуть, поймав исключение от парсера пакетов. Всю прогу было бы глупо убивать из-за такой мелочи. А обрабатывать эту исключительную ситуацию по-сишному на каждом уровне - нафиг надо.
Лучше тогда возвращать код ошибки или указатель на структуру с данными, который может быть NULL если там ошибка.
Да и код выглядит симпатичнее и не создает ненужных скобочек, если проверять код ошибки.
Исключения нельзя забыть поймать, в худшем случае прога в терминейт уйдёт. А вот код возврата или нулл забыть обработать вполне возможно.
Проблему можно решить чекдами, но ты же и сам прекрасно знаешь почему это плохо
Кстати, где они есть крмое джавы?
Какие в сраку чекды.
Возьми Свифт. Если функция бросает исключение, то её надо пометить как throws. Если ты её зовёшь внутри функции, которая сама НЕ бросает исключения, то такой вызов нужно обработать явно (у тебя три варианта на выбор, два хороших один харам).
Да, ты не указываешь список возможных исключений, но для этого есть дока, зато без обработки ты никуда не уйдёшь
"помечать функции, которые throws" это чекд эксепшены в джаве
Расскажи подробнее как в свифте, кстати
Я ж написал, как в свифте :)
Конкретизируй
>(у тебя три варианта на выбор, два хороших один харам
Алсо, заметь: тебя заставляют все таки как-то реагировать на исключения, да?
А в С++ нет. Обычно лучше когда компилятор следит за корректностью кода все таки
2) позвать с try?, где в случае исключения вернётся nil
3) (в большинстве случаев хуёвый вариант) сделать try!, который подавит необходимость проверять ошибку, линтер по умолчанию такое не пропускает
Ты просто сказал, что в «нормальном языке исключений быть не должно», на мой взгляд, это утверждение безосновательно.
Резалт есть и в Свифте, но это ж теорема Эскобара, да и нужен он имхо только для того, чтобы в замыканиях использовать, потому что замыкания это
не будем о грустном
Функция возвращает тебе Result, у которого ты можешь:
1) проверить, что он success, и тогда взять результат
3) явно потребовать результат (если он не sucess, то всё упадет, ты сам дурак)
Варианта "2" (вернуть null если не success) у нас нет, но может стоит добавить)
Такой вариант кажется мне более удобным, чем исключения.
Впрочем, выбора у нас нет: в котлине нельзя никого заставить ничего ловить
Если среди них есть какие-то интересные, которые может захотеться обработать, то они обычно в доке перечислены. Если вернуться к сишке, то ты ведь не все варианты errno в каждой функции обрабатываешь. Ты обычно смотришь в доку и выбираешь пару-тройку. Либо тупо пробрасываешь всё подряд наверх, с чем исключения автоматически справляются.
Ты всем свом функциям пишешь noexcept, или явно перечисляешь все возможные исключения?
В сишке с интами тоже сделано не айс, но там я точно отличаю ошибку от не ошибки
Но лучше всего резулт и матчинг, как я выше написал
Компилятор не заставляет меня ничего ловить, я могу тупо проигнорить ошибку по причине распиздяйства, и всё упадет.
А в случае с матчинтгом я должен сделать это явно
Ты ведь не делаешь в своём result отдельный enum под каждую функцию? Который содержит только те коды, которые она может вернуть. А скорее всего юзаешь один на всех.
Ты всем свом функциям явно пишешь noexcept, или явно перечисляешь все возможные исключения, которые в теории может захотеть поймать пользователь?
Перефразирую на результ коды - ты всем функциям перечисляешь все возможные варианты кодов, которые может захотеть обработать юзер?
Это багор.
> ты всем функциям перечисляешь все возможные варианты кодов
В сишечке? нет, но я явно пишу какой код SUCCESS.
Забыть проверить результат тоже можно, но это реже случается, чем забыть проверить исключения.
Но я не защищаю сишечку, я пожалуй даже соглашусь что С++ исключения лучше сишных результов (во всяком случае у меня нет четкого мнения).
Я сообщаю вам, что лучше всех результ и матчинг. Там ты обязан проверить факт ошибки или явно от этого отказаться
Не бросил исключения - success. Бросил исключение - не success. Всё просто.
Никто никуда особо не смотрит. noexcept'ы это в основном намёк на то, что эту функцию можно безопасно юзать в деструкторах, при перемещении и ещё в нескольких местах. Остальной код всегда готов к пролёту исключения.
А твой матчинг засирает код проверками, не относящимися к логике. Это тот же самый чекед, только покороче. При этом, в отличие от чекеда, ты даже не знаешь какие там ошибки могут быть то. Иначе придётся ваять отдельный енум с ошибками на каждую функцию, а это боль.
Именно это я и называю засиранием кода. Это абсолютно те же самые чекед экцепшены, только подсахаренные немножко чтобы скобок и траев поменьше писать.
>Именно это я и называю засиранием кода.
>. Это абсолютно те же самые чекед
Это примерно как сказать "слово auto это абсолютно тоже самое, что и явное указание типа и засирает код, толь дело питон".
Я уже привел пример того, что явный отказ можно сделать с помощью .success.
Можно сократить это до одной буквы, и будет еще проще
А зачем? Ты же даже в своих примерах не посмотрел, какую ошибку ты ловишь. Что-то там поймал, завернул и выбросил дальше.
Я знаю, что я получил ошибку, и могу дальше от этого отталкиваться. Могу посмотреть, какая ошибка. Могу не смотреть.
Важно, что прилетела ошибка, которую функция явно вернула.
На выбор я могу
1. сказать "мне плевать на ошибку, ее никогда не будет, а если будет то падай"
2. сказать "если ошибка, то сделай то-то"
3. сказать "если ошибка такая-то то.."
Причем выбрать я должен явно. А не бегать потом "ох блядь, оказывается эта функция могла ошибку кинуть, интересно как, я этого не ждал"
Признайся, как часто ты смотришь.
Вот всяко же тупо на рефлексах добавляете эти mapIfError и successOr не читая. Как то же явное подтверждение удаления файла в фаре, которое все на рефлексах энтером скипают.
Ну вот и с исключениями точно так же. Если я задумался о какой-то ошибке, которую полезно было бы обработать для удобства юзера, я пойду и почитаю что мне там могут вбросить. Если мне похуй - я не буду читать, catch all поймает, RAII всё лишнее закроет.
Если это является частью логики, то смотрю.
Например, если мне пользователь передал имя файла, то я могу сообшить ему почему нет доступа к файлу
А если это имя файла зашито в програме, и файл там должен быть (потому что часть дистрибутива) то я делаю successOr
>Если я задумался о какой-то ошибке
Проблема в том, что компилятор не заставляет тебя задумываться "а может ли тут быть ошибка".
Есть функция "GetPetuh()", и ты сможешь узнать о том, что она вообще может кинуть исключение только если
* ты об этом задумался
* ты почитал доку
* автор не мудак, и написал доку
В случае же с резалтом у тебя тупо ничего не скомпилируется, пока ты явно не выберешь стратегию обработки ошибок.
Эффект примерно как и от чекд, но с гораздо меньшим количеством говна.
Компилятор должен пинать программиста, иначе программист что-нить забудет
Вот! Не компилятор тебя пинает, а условие задачи!
Если в задаче не требуется что-то особым образом обрабатывать (тот самый файл из дистриба), то ты на рефлексах не читая воткнёшь политику по-умолчанию. Тебе похуй какую ошибку там возвращают и возвращают ли вообще.
> может кинуть исключение
Прими на веру, что любая функция в крестах может что-то кинуть. Любая. Кроме редких исключительных случаев, которые помечены как noexcept. Но они для особых ситуаций так помечены, а не для твоей логики.
Поэтому, если задача требует подавить или завернуть что-то от группы функций - лови всё, не ошибёшься.
Если нужно конкретное исключение - ну тут да, надо надеяться на доку. Но и с результами тебе могут generic хуйню вернуть по которой ничего не понятно.
Да, кидает. Если тебе нужно какие-то конкретные ошибки по-особому обработать - ну тут только на список в доке надежда.
Откуда знаешь?
А printf кидает?
А GetLength()?
А
?
А что будет, если вчера не кидала, а сегодня кидает? Я перекомпилируюсь, и ничего не замечу
Так можно и до кока с агдой докатиться. Нужен какой-то разумный баланс, чтобы статические проверки ловили реальные проблемы, которые в коде встречаются часто и имеют хуёвые последствия.
От пропущенной проверки на нулл или еррор код в сишном коде ты получишь UB. Это происходит часто и заканчивается очень плохо. Поэтому исключения или твой матчинг приносят очень много пользы по сравнению с их отсутствием.
От непойманного исключения юзер в большинстве случаев просто увидит "неизвестную ошибку" вместо более полезного сообщения. Поэтому матчинг приносит не так много пользы по сравнению с исключениями.
Зависит от статистики на самом деле. Если это один багрепорт в год, а затыкать конпелятор придётся на каждом вызове функции, то я бы выбрал багрепорт.
Ну ок, если механизм решает реальную проблему - я не против.
(в одном языке, который я не буду называть, это обошли на уровне собственно языка)
А что бы мне дал компилятор, если у меня обновятся системные зависимости?
Чувак обновил себе ось на телефоне, ему от вендора прилетела новая версия некого фреймворка, теперь пока я не перекомпилирую приложение, то предыдущая версия должна просто крашиться?
Это немножко не так работает
Хорошо, когда язык позволяет хендлить такие ситуации. А, если нет, то у тебя такая же жопа, как с новыми исключениями. Компилятор не волшебник, будь добр, почитай доку и адаптируй
это недопустимая ситуация со стороны мейнтейнеров библиотеки.
можно добавлять только новые фичи, и если появился новый енум, его значение должно обозначать то, чего раньше в принципе не было.
Добавление - не всегда breaking change
А тебе надо реагировать и на то, и на то
Добавление в енум тоже очень часто пидорасит логику, поэтому это почти всегда breaking change. Я сам на это много раз налетал. Даже буквально на днях, лол.
И так, у нас есть два вида енума:
* Frozen. Мы гарантируем, что в него никогда не будет добавлен новый элемент.
* Open. Мы НЕ гарантируем такого.
Для frozen программист обязан(!!) либо проверить ВСЕ варианты либо ЯВНО сделать default. Если он этого не сделает -- будет ошибка компиляции (ну пока ворнинг, но в будущем будет ошибка).
Для unknown программист обязан(!!) обработать случай неизвестного ему значения.
Для этого он обязан добавить defaullt.
Причем default бывает двух видов:
* обычный default значит "я готов нормально обработать все не описанные значения, как новые, так и те, которые я просто не указал"
* unknown default значит "я хочу обработать все значения, но если добавятся новые значения, то я не хочу падать, но хочу ворнинг при компиляции"
При добавлении нового значения я получу ворнинг если будет unknown, и после перекомпиляции увижу проблему, и добавлю значение, но до этой поры я все еще буду работать.
Звучит логично. Свифтовцы вообще молодцы, хочу такое в котлине.
- а где ты прочитал про ворнинг?
Вроде в Свифте switch must be exhaustive это всегда ошибка компиляции
Since the proposal was accepted months after it was written, the rollout plan turned out to be a little too aggressive. Therefore, in Swift 5 the diagnostic for omitting @unknown default: or @unknown case _: will only be a warning
У фрозен буде ошибка?
Но и свитч по обычному энаму без всяких модификаторов не взлетит, если все варианты не рассмотрены или нет default
error: switch must be exhaustive
note: add missing case: '.three'
Но некоторые стайл-гайды рекомендуют явно указывать все варианты энама и дефолт в данном случае не использовать
Но старые бинари с новыми всё равно мешать нельзя, даже если проверка в конпеляторе. Тут только версию бампать и говорить, что обратной совместимости больше нет.
Ну почему. Вот есть у меня SDK 1.0 и SDK 1.1, в котором какие-то новые интерфейсы или методы добавили. Прога, которую я собирал под 1.0 вполне будет работать под 1.1.
Но если представить, что она работает верно, то ее функционал не изменился: она как слала письма этим двоим, так и шлет. Её функционал не изменился.
SpokNochi.HRUSHA -> sendToHrusha(); pacifyUser(),
SpokNochi.STEPASHKA -> sendToStepashka(); pacifyUser()
}
Насчет вербозности - у меня бы там был либо враппер, либо отдельная система нотификаций по ивентам, но не писать же ее тут всю блэт
во-вторых вопрос появления каркуши по-прежнему неясен. если он запускает конечную программу, то её там по-прежнему нет, потому что как она попадет в программу, которая не знала о символе компайл-тайм?
если это промежуточная библиотека, то тут вопрос, почему конечный продукт использует нерабочие зависимости
Да ну хорош увиливать уже. Мы про техническую корректность, а не про продуктовый уровень. Продуктовый уровень вообще не знает про библиотеки-хуеки.
> * ввел пользователь (при вводе значения, отсутствующего в enum, выдается ошибка: SpokNochi.fromString(string))
Пользователь пытается вызвать несуществующий функционал программы
> * пришла по сети
Аналогично
> пользователь выбрал из выпадаюещго меню, которое предлагает библиотека
Вообще да, но я ни разу не видел, чтобы библиотека моделей строила за меня выпадающее меню.
удалять депрекейт ты можешь только на смене мажорной версии как раз по причине этого
Если обработка каждого поля обязательна - да.
Если добавляется идентификатор новой операции, которую может выполнять сервер - нет.
Для информации
result.successOrDie
P.S: Мне всегда было занятно, как ты, Ильяс, дуришь людей, ведЯ диалоги С САМИМ СОБОЙ.
Я не вижу тут временных файлов
> В большинстве прог похер, конечно.
отож
Чем отличается "нормально залогировать" от "what() из экцепшена в stderr"?
Если ты демон, то я понимаю. А если ты комманд лайн, то не понимаю.
Кстати, это же заморочки вашего кресторантайма? Я думал, будет просто падение програмы в кору/доктор вацон
Кстати, с возвращением. Сегодня четвертое сентября две тысячи двадцатого года, пятница. Температура воздуха - +25, солнечно.
только ничего не выиграешь, т.к. тебе надо tmp менять на каждой итерации, ты ошибочно предположил, что только при инициализации цикла
а раз надо на каждой итерации, то что экономить собрался? строки кода? значит, в другом месте их проиграешь
и да, int хуевый тип для хранения "размера"
а схема tmp = a; a = b; b = tmp; не для каждого типа Т адекватна (оптимальна или вообще компилируема)
именно поэтому алгоритмы в стл используют using std::swap; swap(a, b);
в надежде, что ты перегрузишь, компилятор найдет в твоем неймспейсе, или не найдет, тогда в std:: найдет
а это выглядит как хуета
> int хуевый тип для хранения "размера"
- это к ОПу
Лично для меня твой пост выглядит как бред психбольного. ничего личного.