1. Си / Говнокод #26918

    +3

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    #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

    Комментарии (164) RSS

    • Бабушка Карлсона говорила: "Переодень носки, Карлсончик, переодень носки..."
      Ну он и переодел: носок с левой ноги надел на правую, а с правой – на левую
      (и обратно, если я верно прочитал код)
      Ответить
    • Собственно данная постановка задачи формулируется следующим образом: задание заключается в написании функции, то есть процедуры, возвращающей значение, на ЯП С++, которая модифицирует путем замены содержимое указанной пользователем компьютерной программы строки, то есть последовательности символов, заканчивающейся нулем, этой же самой, то есть исходной, строкой, но с обратным порядком следования однобайтовых символов типа char в строке. Почему строка не переворачивается?
      Ответить
      • Потому что ты успел перевернуть её и туда и обратно.

        З.Ы. Учись юзать отладчик или логи писать.
        Ответить
        • std::cout << "Реверсю... пожалуйста подождите\n";
          
          try {
              std::string cpp_str(str);
              std::reverse(std::begin(cpp_str), std::end(cpp_str));
          } catch (...) {
              std::cerr << "неизвестная ошибка реверса, обратитесь к системному администратору!\n";
              return 1;
          }
          
          std::cout << "Пореверсил, проверяй)))\a\n";
          Ответить
          • сам-то проверь, всё ли хорошо
            Ответить
          • > неизвестная

            А что там кроме bad_alloc в конструкторе может быть?
            Ответить
            • зачем вообще ловить тут исключение?
              Ответить
              • Чтобы деструкторы отработали. За необработанные исключения рантайм слишком жёстко прогу убивает.
                Ответить
                • что плохого в убийстве этой проги? если у тебя bad_alloc, но наверное у тебя серьезные проблемы уже

                  алсо, я верно понимаю, что любой код с конструктором всегда надо оборачивать на топлевеле в кетч?
                  Ответить
                  • Какие-нибудь временные файлы не удалятся. В большинстве прог похер, конечно.

                    Да, на топлевле удобно иметь кетч. Дождаться деструкторов, нормально залогировать ошибку и тогда уже сдохнуть. Без него просто выведет what() из экцепшена в stderr и terminate().
                    Ответить
                    • пока программист не догадается кинуть исключение из деструктора - тогда будет наплевать на топлевел
                      Ответить
                      • > кинуть исключение из деструктора

                        Майки, кстати, этим страдают в комовских обёртках. Хотя ошибку освобождения памяти надо ещё умудриться вызвать.
                        Ответить
                        • Кинул в тебя исключением, проверь.
                          Ответить
                        • Приведи реальный пример, когда возникает ошибка освобождения.
                          Ответить
                          • Когда ты кучу закорраптил или сам уже освободил блок. В нормальном коде - никогда.
                            Ответить
                            • Хрю
                              Ответить
                            • >В нормальном коде - никогда.
                              В нормальном коде вообще исключений быть не должно, во всяком случае в нормальном языке, лол. Исключение же это всегда бага
                              Ответить
                              • Почему это?

                                Если у тебя в языке легковесные исключения, то в чём проблема их использования?

                                Да даже если и не легковесные
                                Ответить
                                • Использовать -- в смысле строить на них логику?
                                  Тогда их надо делать checked, а это довольно неудобно, джависты вон страдают.

                                  А не чекд эксепшен для логики это пиздец, потому что не понятно что откуда и когда вылетет.

                                  Самое нормальное это возвращать резулт (наверное это называется "монада") и потом его паттеринг матчить
                                  Ответить
                                  • > возвращать резулт и потом его паттеринг матчить
                                    - сорта говна
                                    Ответить
                                    • Совершенно нет. Возвращение результата заставляет программиста проверять, что ошибки нет, либо явно отказыватьсяот проверки (как чекд исключения), но при этом не засирает код.

                                      псведоко

                                      val fileRes = openFile()
                                      when fileRes 
                                        is File -> fileRes.write('a')
                                        is Error -> log.err(fileRes.errorMessage)


                                      Предложи более красивый вариант решения
                                      Ответить
                                      • То есть ты мне предлагаешь писать на языке с сигнатурами типа

                                        func myFun() -> Data|DbException|RequiredFieldException|UnauthorizedAccessException
                                        ?

                                        Я ебал такое
                                        Ответить
                                        • Да нет, просто
                                          func myFun() -> Result<Success:Data, Error:SomeError>

                                          клиент может потом сам матчить нужный ему эррор
                                          Ответить
                                          • Говорю ж, сорта говна

                                            Клиенту вернулся эксепшн, который на его уровне не обрабатывается, он должен его прокинуть выше, в итоге у меня весь код обвешан Result'ами, не, ну его нахуй
                                            Ответить
                                            • Для этого есть сахар, позволяющий сделать проверку и вернуть наверх ошибку, завернув ее если нужно в соответствущий резулт

                                              Зацени
                                              fun askUserAndReadFileGood(): Result<Data, TopLevelException> {
                                                val file = askUser()
                                                return readDataFromFile(file).mapIfError { TopLevelException((it)) }
                                              }
                                              
                                              fun askUserAndReadFileDirty(): Data {
                                                val file = askUser()
                                                return readDataFromFile(file).successOr("This error will be thrown, app will die")
                                              }
                                              
                                              fun readDataFromFile(file: File): Result<Data, FileNotFoundException> {
                                              
                                              }
                                              Ответить
                                              • в итоге у меня весь код обвешан Result'ами

                                                И что поменялось?
                                                Ответить
                                                • Я не понимаю проблемы "обвешан резултами".
                                                  Вот проблему "обвешан трай кетчем" я понимаю.

                                                  Вместо
                                                  return readDataFromFile()

                                                  я вынужден писать
                                                  try {
                                                  return readDataFromFile()
                                                  } catch (FileNotFoundException ex) {
                                                   throw TopLevelException(ex)
                                                  }

                                                  Причем даже если я не хочу ее обрабатывать, я все равно обязан ее ловить.

                                                  Такой вариант как askUserAndReadFileDirty с чекд исключениями не сделать
                                                  Ответить
                                                  • Проблема в том, что я хочу, чтобы сигнатура функции была как можно проще, а с Резалтом так не выходит.

                                                    А у тебя вообще получается типа такого: в Йаже исключения говно, потому они везде говно

                                                    А это не так
                                                    Ответить
                                                    • Ну ты должен как-то сообщить компилятору, что ты можешь вернуть ошибку, так что сигнатура будет всегда страдать.

                                                      Или ты тоже считаешь, что компилятор ничего проверять не должен, и пускай умненький программист сам не забудет почитать доку, и поймать нужные исключения?

                                                      >в Йаже исключения говно, потому они везде говно
                                                      Бизнес логика на исключениях практически везде говно, но про свифт я вот почитаю чуть попожжа, и скажу)
                                                      Ответить
                                                      • Я пишу throws, а не Result<PizdecType, OhuetException>

                                                        > умненький программист не забудет поймать нужные исключения

                                                        - ты ж сам написал, что в котлине никто не может заставить тебя ничего ловить, так котлин всё же говно или?
                                                        Ответить
                                                        • >Я пишу throws, а не Result<PizdecType, OhuetException>

                                                          На самом деле это значит

                                                          Result<PizdecType, Exception>

                                                          А потом клиент класса должен сидеть, и разбирать что именно пришло (или не разбиратьь, если не интересно).

                                                          В нашем варианте ты всегда должен указывать ошибку (кстати, это может быть и не исключение вовсе)

                                                          Было бы удобно иметь упрощенный синтаксис типа Result<PizdecType> где второй параметр это неявно Exception


                                                          >ты ж сам написал, что в котлине никто не может заставить тебя ничего лови

                                                          В котлине нет чекд ичключений: слово throws там нет (есть только для интеропа с жабой).

                                                          Так что использовать исключения для логики там вообще никак нельзя. Никто не заставляет тебя их ловить.

                                                          Ты сделал
                                                          var = vend()
                                                          А потом в продакшене у тебя упало "no enough funds".
                                                          и ты такой: "ой, а вот еще оказывается как могло быть, а я не подумал"
                                                          Ответить
                                                          • > Result<PizdecType, Exception>

                                                            - у тебя то же самое будет, если метод бросает несколько не связанных между собой типов исключений

                                                            Ну короч, мы уже по третьему кругу пошли. А ты кроме котлина и жабы что-то знаешь ещё?
                                                            Ответить
                                                            • > Ну короч, мы уже по третьему кругу пошли.
                                                              Подтверждаю, такова специфика срачей про исключения на ГК. Возникают рагулярно, имеют зацикленный характер.

                                                              Добрый вечер.
                                                              Ответить
                                                              • Добрый вечер, gost
                                                                Ответить
                                                              • давай, вливайся
                                                                ты за исключения, за резулт с матчингом или за что?
                                                                Ответить
                                                                • А можно быть за
                                                                  result, err := getResult();
                                                                  ?
                                                                  Ответить
                                                                  • зависит от того, можешь ли ты обратиться к result если err не пустой.
                                                                    Ответить
                                                            • >- у тебя то же самое будет, если метод бросает несколько не связанных между собой типов исключений

                                                              Верно.

                                                              >А ты кроме котлина и жабы что-то знаешь ещё?
                                                              во всех остальных кроме жабы известных мне языках исколючения не чекд. Сегодня я узнал, что в свифте они в некотором роде чекд)

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

                                                              В C# вместо исключений иногда используют out параметры (в джаве и котлине так нельзя).
                                                              Так себе способ:
                                                              int number;
                                                              if (Int32.TryParse(value, out number)) 
                                                              {
                                                              // У нас число
                                                              } else //ну ты понел


                                                              В скриптушне логику строят иногда на исключениях (в джанге например) но там это пофиг: один хуй cpython ничего не проверяет "статически".

                                                              Давай я перефразирую свое утверждение:

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

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

                                                              Если бы я писал на свифте, я бы конечно использовал его исключения с throws
                                                              Ответить
                              • Бага, но может быть и не моя. Кривой запрос от клиента пришёл и т.п.
                                Ответить
                                • нефиг пускать в свое адресное пространство всяких пидорасов)

                                  ну в общем я к тому, что если к тебе прилетел исключень, то всё ОЧЕ плохо, и сдохнуть тут записав корку вполне допустимо.

                                  Другой вопрос, что если ты демон, то тебе надо куда-то лог писнуть
                                  Ответить
                                  • Что плохого то? Крестовые исключения - это ж не SEH и не сигналы. Это вполне детерминированная хуйня, которая возникает только её явно вбросили в коде.

                                    К примеру, кривого клиента можно просто дропнуть, поймав исключение от парсера пакетов. Всю прогу было бы глупо убивать из-за такой мелочи. А обрабатывать эту исключительную ситуацию по-сишному на каждом уровне - нафиг надо.
                                    Ответить
                                    • Исключения в крестах же не чекд, так что выразить через API тот факт, что их будут кидать, довольно сложно. А значит их могут забыть поймать.

                                      Лучше тогда возвращать код ошибки или указатель на структуру с данными, который может быть NULL если там ошибка.

                                      Да и код выглядит симпатичнее и не создает ненужных скобочек, если проверять код ошибки.
                                      Ответить
                                      • > забыть поймать

                                        Исключения нельзя забыть поймать, в худшем случае прога в терминейт уйдёт. А вот код возврата или нулл забыть обработать вполне возможно.
                                        Ответить
                                        • Если я вижу функцию "GetSomething()", то я обычно сразу проверяю, что она вернет. А вот догадаться, что какая-то функция вдруг может кинуть исключение -- сложно.

                                          Проблему можно решить чекдами, но ты же и сам прекрасно знаешь почему это плохо
                                          Ответить
                                          • Бери языки, в которых надо явно помечать функции, которые throws (я не про жабу)
                                            Ответить
                                            • Это чекды, и все их ненавидят.

                                              Кстати, где они есть крмое джавы?
                                              Ответить
                                              • Ээ

                                                Какие в сраку чекды.

                                                Возьми Свифт. Если функция бросает исключение, то её надо пометить как throws. Если ты её зовёшь внутри функции, которая сама НЕ бросает исключения, то такой вызов нужно обработать явно (у тебя три варианта на выбор, два хороших один харам).

                                                Да, ты не указываешь список возможных исключений, но для этого есть дока, зато без обработки ты никуда не уйдёшь
                                                Ответить
                                                • >Какие в сраку чекды.

                                                  "помечать функции, которые throws" это чекд эксепшены в джаве

                                                  Расскажи подробнее как в свифте, кстати
                                                  Ответить
                                                  • В смысле

                                                    Я ж написал, как в свифте :)

                                                    Конкретизируй
                                                    Ответить
                                                    • вот про это расскажи
                                                      >(у тебя три варианта на выбор, два хороших один харам

                                                      Алсо, заметь: тебя заставляют все таки как-то реагировать на исключения, да?

                                                      А в С++ нет. Обычно лучше когда компилятор следит за корректностью кода все таки
                                                      Ответить
                                                      • 1) обернуть вызов в do try catch
                                                        2) позвать с try?, где в случае исключения вернётся nil
                                                        3) (в большинстве случаев хуёвый вариант) сделать try!, который подавит необходимость проверять ошибку, линтер по умолчанию такое не пропускает

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

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

                                                        не будем о грустном
                                                        Ответить
                                                        • Это похоже на то, что я предлагаю с резултом (у нас в котлине есть такой самописный резулт)

                                                          Функция возвращает тебе Result, у которого ты можешь:
                                                          1) проверить, что он success, и тогда взять результат
                                                          3) явно потребовать результат (если он не sucess, то всё упадет, ты сам дурак)

                                                          Варианта "2" (вернуть null если не success) у нас нет, но может стоит добавить)

                                                          Такой вариант кажется мне более удобным, чем исключения.
                                                          Впрочем, выбора у нас нет: в котлине нельзя никого заставить ничего ловить
                                                          Ответить
                                          • Любая функция, не помеченная как noexcept, может кинуть исключение. Как минимум bad_alloc какой-нибудь.

                                            Если среди них есть какие-то интересные, которые может захотеться обработать, то они обычно в доке перечислены. Если вернуться к сишке, то ты ведь не все варианты errno в каждой функции обрабатываешь. Ты обычно смотришь в доку и выбираешь пару-тройку. Либо тупо пробрасываешь всё подряд наверх, с чем исключения автоматически справляются.
                                            Ответить
                                            • >Любая функция, не помеченная как noexcept, может кинуть исключение.

                                              Ты всем свом функциям пишешь noexcept, или явно перечисляешь все возможные исключения?

                                              В сишке с интами тоже сделано не айс, но там я точно отличаю ошибку от не ошибки

                                              Но лучше всего резулт и матчинг, как я выше написал

                                              Компилятор не заставляет меня ничего ловить, я могу тупо проигнорить ошибку по причине распиздяйства, и всё упадет.
                                              А в случае с матчинтгом я должен сделать это явно
                                              Ответить
                                              • Нахуя перечислять все возможные исключения? Перечисляю интересные, которые может захотеться обработать.

                                                Ты ведь не делаешь в своём result отдельный enum под каждую функцию? Который содержит только те коды, которые она может вернуть. А скорее всего юзаешь один на всех.
                                                Ответить
                                                • Ок, перефразирую


                                                  Ты всем свом функциям явно пишешь noexcept, или явно перечисляешь все возможные исключения, которые в теории может захотеть поймать пользователь?
                                                  Ответить
                                                  • Да. Но таких исключений очень мало. Большинство - это как runtime error в джаве, на содержание которых всем насрать кроме каких-то catch all обработчиков.

                                                    Перефразирую на результ коды - ты всем функциям перечисляешь все возможные варианты кодов, которые может захотеть обработать юзер?
                                                    Ответить
                                                    • Ну вот смотри: ты явно каждой функции пишешь noexcept, а пользователь вынужден это проверять. Если он забудет сделать catch функции без noexcept, то всё скомпилируется.
                                                      Это багор.

                                                      > ты всем функциям перечисляешь все возможные варианты кодов
                                                      В сишечке? нет, но я явно пишу какой код SUCCESS.
                                                      Забыть проверить результат тоже можно, но это реже случается, чем забыть проверить исключения.

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

                                                      Я сообщаю вам, что лучше всех результ и матчинг. Там ты обязан проверить факт ошибки или явно от этого отказаться
                                                      Ответить
                                                      • > какой код SUCCESS

                                                        Не бросил исключения - success. Бросил исключение - не success. Всё просто.

                                                        Никто никуда особо не смотрит. noexcept'ы это в основном намёк на то, что эту функцию можно безопасно юзать в деструкторах, при перемещении и ещё в нескольких местах. Остальной код всегда готов к пролёту исключения.

                                                        А твой матчинг засирает код проверками, не относящимися к логике. Это тот же самый чекед, только покороче. При этом, в отличие от чекеда, ты даже не знаешь какие там ошибки могут быть то. Иначе придётся ваять отдельный енум с ошибками на каждую функцию, а это боль.
                                                        Ответить
                                                        • >Никто никуда особо не смотрит.
                                                          Тогда как они узнают какие ошибки ловить?

                                                          >А твой матчинг засирает код проверками

                                                          нет, если у тебя достаточно сахара
                                                          https://govnokod.xyz/_26918/#comment-555907

                                                          Никто не зставляет тебя ничего проверять, ты можешь отказаться от проверки, но ты должен сделать это явно.
                                                          readDataFromFile(file).success

                                                          Тут ты явно говориш: "мне результат, а иначе пускай всё упадет"
                                                          Ответить
                                                          • > явно

                                                            Именно это я и называю засиранием кода. Это абсолютно те же самые чекед экцепшены, только подсахаренные немножко чтобы скобок и траев поменьше писать.
                                                            Ответить
                                                            • Явное лучше неявного, потому что позволяет избегать ошибок.

                                                              >Именно это я и называю засиранием кода.
                                                              >. Это абсолютно те же самые чекед

                                                              Это примерно как сказать "слово auto это абсолютно тоже самое, что и явное указание типа и засирает код, толь дело питон".

                                                              Я уже привел пример того, что явный отказ можно сделать с помощью .success.
                                                              Можно сократить это до одной буквы, и будет еще проще
                                                              Ответить
                                                          • > Тогда как они узнают какие ошибки ловить?

                                                            А зачем? Ты же даже в своих примерах не посмотрел, какую ошибку ты ловишь. Что-то там поймал, завернул и выбросил дальше.
                                                            Ответить
                                                            • >Ты же даже в своих примерах не посмотрел, какую ошибку ты ловишь.

                                                              Я знаю, что я получил ошибку, и могу дальше от этого отталкиваться. Могу посмотреть, какая ошибка. Могу не смотреть.
                                                              Важно, что прилетела ошибка, которую функция явно вернула.

                                                              На выбор я могу
                                                              1. сказать "мне плевать на ошибку, ее никогда не будет, а если будет то падай"
                                                              2. сказать "если ошибка, то сделай то-то"
                                                              3. сказать "если ошибка такая-то то.."

                                                              Причем выбрать я должен явно. А не бегать потом "ох блядь, оказывается эта функция могла ошибку кинуть, интересно как, я этого не ждал"
                                                              Ответить
                                                              • > могу посмотреть

                                                                Признайся, как часто ты смотришь.

                                                                Вот всяко же тупо на рефлексах добавляете эти mapIfError и successOr не читая. Как то же явное подтверждение удаления файла в фаре, которое все на рефлексах энтером скипают.

                                                                Ну вот и с исключениями точно так же. Если я задумался о какой-то ошибке, которую полезно было бы обработать для удобства юзера, я пойду и почитаю что мне там могут вбросить. Если мне похуй - я не буду читать, catch all поймает, RAII всё лишнее закроет.
                                                                Ответить
                                                                • >Признайся, как часто ты смотришь.
                                                                  Если это является частью логики, то смотрю.

                                                                  Например, если мне пользователь передал имя файла, то я могу сообшить ему почему нет доступа к файлу

                                                                  А если это имя файла зашито в програме, и файл там должен быть (потому что часть дистрибутива) то я делаю successOr

                                                                  >Если я задумался о какой-то ошибке
                                                                  Проблема в том, что компилятор не заставляет тебя задумываться "а может ли тут быть ошибка".

                                                                  Есть функция "GetPetuh()", и ты сможешь узнать о том, что она вообще может кинуть исключение только если
                                                                  * ты об этом задумался
                                                                  * ты почитал доку
                                                                  * автор не мудак, и написал доку

                                                                  В случае же с резалтом у тебя тупо ничего не скомпилируется, пока ты явно не выберешь стратегию обработки ошибок.

                                                                  Эффект примерно как и от чекд, но с гораздо меньшим количеством говна.

                                                                  Компилятор должен пинать программиста, иначе программист что-нить забудет
                                                                  Ответить
                                                                  • > Если это является частью логики, то смотрю.

                                                                    Вот! Не компилятор тебя пинает, а условие задачи!

                                                                    Если в задаче не требуется что-то особым образом обрабатывать (тот самый файл из дистриба), то ты на рефлексах не читая воткнёшь политику по-умолчанию. Тебе похуй какую ошибку там возвращают и возвращают ли вообще.

                                                                    > может кинуть исключение

                                                                    Прими на веру, что любая функция в крестах может что-то кинуть. Любая. Кроме редких исключительных случаев, которые помечены как noexcept. Но они для особых ситуаций так помечены, а не для твоей логики.

                                                                    Поэтому, если задача требует подавить или завернуть что-то от группы функций - лови всё, не ошибёшься.

                                                                    Если нужно конкретное исключение - ну тут да, надо надеяться на доку. Но и с результами тебе могут generic хуйню вернуть по которой ничего не понятно.
                                                                    Ответить
                                                                    • >Вот! Не компилятор тебя пинает, а условие задачи!

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

                                                                      >Прими на веру, что любая функция в крестах может что-то кинуть. Любая.

                                                                      Тогда я не понимаю как мне узнать кидает она что-то, что нужно ловить, или что не нужно.

                                                                      Вот есть функция "Pay()" в классе "Bill". Откуда я знаю что она кидает или не кидает исключение? Только из доки?

                                                                      И где гарантия, что она не начнет кидать что-то завтра?
                                                                      Вчера она молча ничего не делала, если денег нет, а сегодня стала кидать "шорт оф фундс".

                                                                      Вчера я вообще про это не думал.
                                                                      А сегодня перекомпилировал, и всё работает. А семантика изменилась.

                                                                      Поменять возвращаемое значение она не может (упадет компиляция) а вдруг начать кидать чот-то может.

                                                                      Какая-то прямо скриптушня по уровню безопасности.
                                                                      Ответить
                                                                      • > кидает или не кидает исключение

                                                                        Да, кидает. Если тебе нужно какие-то конкретные ошибки по-особому обработать - ну тут только на список в доке надежда.
                                                                        Ответить
                                                                        • >Да, кидает.
                                                                          Откуда знаешь?
                                                                          А printf кидает?
                                                                          А GetLength()?
                                                                          А
                                                                          getAddPendingUnlockDeviceRequestAndCheckUnlockStatusDeviceRequestAndRemoveUnlockDeviceRequest()

                                                                          ?

                                                                          А что будет, если вчера не кидала, а сегодня кидает? Я перекомпилируюсь, и ничего не замечу
                                                                          Ответить
                                                                          • Ну что значит не кидала? Сигнализировала об ошибке другим способом (возвращала пустую строку или нулл), а потом вдруг перестала это делать и перешла на исключения? Ну так и имя вместо фамилии можно вернуть и твоя система это не поймает.
                                                                            Ответить
                                                                            • Раньше такой ошибки быть не могло, а потом поменялась логика, и такая ошибка стала возможной.

                                                                              Я -- автор функции. Что мне делать?
                                                                              Ответить
                                                                              • Бери да бросай. Те, кто хотел обрабатывать ошибки, следовали принципу "любая функция бросает исключения" и обработали её. Те, кому было похуй - не обработали и у них она просто зафорвардится дальше по стеку.
                                                                                Ответить
                                                                                • >ледовали принципу "любая функция бросает исключения"
                                                                                  и каждую функицю заворачивали в try catch чтоли?

                                                                                  Сравним со свифтом (в пизду джаву, ее никто не любит)
                                                                                  Там я бы добавил throws, иу них бы не скомпилировались
                                                                                  Им пришлос бы или явно заткнуть ошибку, или обработать ее

                                                                                  Разве это не лучше?

                                                                                  --------
                                                                                  Если что-то можно выразить статически, то лучше выразить это статически. Чтобы это мог проверить компилятор. Чтобы код можно было статически валидировать. Если это добавляет бойлерплейт, то значит нужно такой сахар сделать, чтобы его было по минимуму.
                                                                                  Например auto позволяет уменьшить бойлерплейт но сохарнить стат типизацию.
                                                                                  Мои резулты позволяют уменьшить бойлерплейт (на мой вкус) но сохранить валидацию обработки ошибок
                                                                                  Статическую валидацию
                                                                                  Ответить
                                                                                  • Если они хотели обрабатывать ошибки от конкретных функций - да, заворачивали их в трай. Если им было похуй и хотелось просто зафорвардить ошибку выше - вообще ничего не делали.
                                                                                    Ответить
                                                                                  • > Если что-то можно выразить статически, то лучше выразить это статически.

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

                                                                                    От пропущенной проверки на нулл или еррор код в сишном коде ты получишь UB. Это происходит часто и заканчивается очень плохо. Поэтому исключения или твой матчинг приносят очень много пользы по сравнению с их отсутствием.

                                                                                    От непойманного исключения юзер в большинстве случаев просто увидит "неизвестную ошибку" вместо более полезного сообщения. Поэтому матчинг приносит не так много пользы по сравнению с исключениями.
                                                                                    Ответить
                                                                                    • >реальные проблемы, которые в коде встречаются часто и имеют хуёвые последствия.

                                                                                      У меня были реальные проблемы. Мы резулт свой запилили не на пустом месте, а именно потому, что хотели заставить клиента API что-то внятное сделать с ошибкой.

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

                                                                                      У меня вот была, и от нее хочется наручников и плёт максимально строгого компилятора.

                                                                                      Если бы мы не сделали резулт, то питухи кидали бы рантайм исключения и не документировали бы их (потому что никто нкиогда не пишет доки!) или вообще возвращали бы null (а ошибка бы терялась)

                                                                                      >От непойманного исключения юзер в большинстве случаев просто увидит "неизвестную ошибку

                                                                                      Ну лучше же узнать об ошибке во время компиляции, чем от пользователя, верно?
                                                                                      Ответить
                                                                                      • > чем от пользователя

                                                                                        Зависит от статистики на самом деле. Если это один багрепорт в год, а затыкать конпелятор придётся на каждом вызове функции, то я бы выбрал багрепорт.

                                                                                        Ну ок, если механизм решает реальную проблему - я не против.
                                                                                        Ответить
                                                                              • Ты брал энам из библиотеки, там раньше было 12 значений, а теперь вдруг стало 14. Что тебе делать?

                                                                                (в одном языке, который я не буду называть, это обошли на уровне собственно языка)
                                                                                Ответить
                                                                                • Это плохо, и лучше бы тебя заставляли проверять все варианты.

                                                                                  Кстати, в котлине в IDE есть инспекция для тго, что бы ты или все проверил, или сделал else (defualt).

                                                                                  В хорошем матчинге тебя компилятор заставил бы проверить все значения
                                                                                  Ответить
                                                                                  • Ты так говоришь "в котлине", как будто ее не существует для любого языка с enum
                                                                                    Ответить
                                                                                  • Эм.

                                                                                    А что бы мне дал компилятор, если у меня обновятся системные зависимости?
                                                                                    Ответить
                                                                                    • Ты должен перекомпилироваться ровно с тем SDK, с которым ты хочешь рабоатть в рантайме.

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

                                                                                      С таким же успехмо в рантайме вообще может этого енума не оказаться.

                                                                                      Кстати, вот товарищ тоже этого хочет для sealed classes:
                                                                                      https://youtrack.jetbrains.com/issue/KT-12380

                                                                                      Было бы охуенно
                                                                                      Ответить
                                                                                      • Ну то есть

                                                                                        Чувак обновил себе ось на телефоне, ему от вендора прилетела новая версия некого фреймворка, теперь пока я не перекомпилирую приложение, то предыдущая версия должна просто крашиться?

                                                                                        Это немножко не так работает

                                                                                        Хорошо, когда язык позволяет хендлить такие ситуации. А, если нет, то у тебя такая же жопа, как с новыми исключениями. Компилятор не волшебник, будь добр, почитай доку и адаптируй
                                                                                        Ответить
                                                                                        • > то предыдущая версия должна просто крашиться
                                                                                          Нет конечно. Должна остаться и старая, и новая версия библиотеки.

                                                                                          В старой версии библиотеки метод принимал два параметра, а в новой три. Нужно две версии библиотеки, иначе нихуя не взлетит. Или два метода: старый и новый, ну и два класса тоже соответственно

                                                                                          >А, если нет, то у тебя такая же жопа, как с новыми исключениями.

                                                                                          Совершенно верно. И это грустно.
                                                                                          Ответить
                                                                                          • > В старой версии библиотеки метод принимал два параметра, а в новой три.

                                                                                            это недопустимая ситуация со стороны мейнтейнеров библиотеки.

                                                                                            можно добавлять только новые фичи, и если появился новый енум, его значение должно обозначать то, чего раньше в принципе не было.
                                                                                            Ответить
                                                                                            • почему недопустимая? Методы депрекейтяд, удаляют итд.

                                                                                              С енумом тоже самое: если ты добавил новое значение, которое человек не умеет обрабатывать, то у него просто не выберется ветка, и всё упадет. Так пусть лучше сразу упадет с криком "не верный енум", чем упадет потом потому что кодфлоу нарушен
                                                                                              Ответить
                                                                                              • Удаление - всегда breaking change

                                                                                                Добавление - не всегда breaking change

                                                                                                А тебе надо реагировать и на то, и на то
                                                                                                Ответить
                                                                                                • Добавление тоже очень часто breaking change. Вот добавлю я метод в интерфейс, для которого ты делал реализацию.

                                                                                                  Добавление в енум тоже очень часто пидорасит логику, поэтому это почти всегда breaking change. Я сам на это много раз налетал. Даже буквально на днях, лол.
                                                                                                  Ответить
                                                                                                  • >Добавление в енум тоже очень часто пидорасит логику,
                                                                                                    и-мен-но!

                                                                                                    Это ровно то, что я показал в своем примере
                                                                                                    Ответить
                                                                                                  • У нас в колхозе это в теории решается или при помощи @optional в конкретной сигнатуре протокола, или про помощи default implementation.
                                                                                                    Ответить
                                                                                                • Добавление в енум это брекинг.

                                                                                                  Смотри:
                                                                                                  enum class SpokNochi {HRUSHA, STEPASHKA}
                                                                                                  
                                                                                                  fun mail(to:SpokNochi) {
                                                                                                    when(to) {
                                                                                                      SpokNochi.HRUSHA -> sendToHrusha()
                                                                                                      SpokNochi.STEPASHKA -> sendToStepashka()
                                                                                                    }
                                                                                                    println("Письмо вашему любимому персонажу спокойной ночи малыши отправлено")
                                                                                                  }


                                                                                                  И тут внезапно завезли Каркушу.

                                                                                                  Программа стала работать НЕВЕРНО: она стала врать, что письмо отправлено. А оно не отправлено. И это пиздец.

                                                                                                  Как же быть?

                                                                                                  1. Заставить пользователя всегда делать else. Но тогда вы же сами меня с говном съедите за засирание кода ненужным else. Особенно смешно, если я рядом определил enum, и тут же вынужден писать else для того, чего никогда не будет.

                                                                                                  2. Заставлять енум всегда быть экзастив или иметь else.
                                                                                                  Тогда код без Каруши не скомпилируется.
                                                                                                  Или перечисляй явно всех, или пиши else
                                                                                                  Ответить
                                                                                                  • А default для кого придумали?
                                                                                                    Ответить
                                                                                                    • default это тоже самое, что else.
                                                                                                      Мысленно поменяй в моем комменте слово "else" на "default"
                                                                                                      Ответить
                                                                                                      • Почитай в общем ради интереса про @frozen enums в Свифте. Интересно твоё мнение
                                                                                                        Ответить
                                                                                                        • Почитал, и мне очень понравилось.

                                                                                                          И так, у нас есть два вида енума:
                                                                                                          * 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

                                                                                                                enum Test {
                                                                                                                	case one
                                                                                                                	case two
                                                                                                                	case three
                                                                                                                }
                                                                                                                
                                                                                                                func test(val: Test) {
                                                                                                                	switch val {
                                                                                                                		case .one: 
                                                                                                                			print("one")
                                                                                                                		case .two:
                                                                                                                			print("two")
                                                                                                                	}
                                                                                                                }


                                                                                                                error: switch must be exhaustive
                                                                                                                note: add missing case: '.three'
                                                                                                                Ответить
                                                                                                                • Понятно. Но можно вместо .three добавить default, да?

                                                                                                                  В общем это хорошо
                                                                                                                  Ответить
                                                                                                                  • Можно.

                                                                                                                    Но некоторые стайл-гайды рекомендуют явно указывать все варианты энама и дефолт в данном случае не использовать
                                                                                                                    Ответить
                                                                                                  • > не сконпелируется

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

                                                                                                      Я не имею права скомпилитваться с SDK 1.0 и ожидать, что я буду работать с Runtime 3.0, если там явно не сделана обратная совместимость

                                                                                                      В моем примере каркушу нужно добавлять в SpokNochi2, либо требовать от всех перекомпиляции с новой SDK, как модули ядра у прыщей
                                                                                                      Ответить
                                                                                                      • > никогда нельзя мешать

                                                                                                        Ну почему. Вот есть у меня SDK 1.0 и SDK 1.1, в котором какие-то новые интерфейсы или методы добавили. Прога, которую я собирал под 1.0 вполне будет работать под 1.1.
                                                                                                        Ответить
                                                                                                        • Если добавили новые интерфейсы не порушив обратной совместимости, то да

                                                                                                          А если добавили каркушу, то ее порушили.
                                                                                                          Это тоже самое, что сломать ABI. Считайте значения енума частью ABI
                                                                                                          Ответить
                                                                                                  • Программа не работает неверно, она написана неверно. Она пишет подтверждение не после операции, а всегда.

                                                                                                    Но если представить, что она работает верно, то ее функционал не изменился: она как слала письма этим двоим, так и шлет. Её функционал не изменился.
                                                                                                    Ответить
                                                                                                    • Ну а как бы ты написал?
                                                                                                      Ответить
                                                                                                      • {
                                                                                                        SpokNochi.HRUSHA -> sendToHrusha(); pacifyUser(),
                                                                                                        SpokNochi.STEPASHKA -> sendToStepashka(); pacifyUser()
                                                                                                        }
                                                                                                        Ответить
                                                                                                        • тоесть мало того, что бойлерплейт и вынос строчки (!) в отдельную функцию (и эти люди смеются над вербозностью резулта!), так еще и в случае добавления Каркушки программа будет просто молча ничего не делать?
                                                                                                          Збс
                                                                                                          Ответить
                                                                                                          • Откуда возьмется каркуша, если программа о ней ничего не знает?

                                                                                                            Насчет вербозности - у меня бы там был либо враппер, либо отдельная система нотификаций по ивентам, но не писать же ее тут всю блэт
                                                                                                            Ответить
                                                                                                            • >Откуда возьмется каркуша,
                                                                                                              Видимо ты забыл, с чего начался тред.

                                                                                                              Программу скомпилировали без каркуши. А запускают ее с новой версией либы, где каркуша уже есть.

                                                                                                              Программа работает неверно. Потому что добавление каркуши в енум это брекинг чендж.
                                                                                                              Я пытался это показать.
                                                                                                              Это такой же брекинг чендж, как семантику метода поменять.
                                                                                                              Ответить
                                                                                                              • программа сохраняет заявленный функционал
                                                                                                                Ответить
                                                                                                                • Нет, не сохраняет. В инструкции к программе на написано, что она может "молча ничего не делать"
                                                                                                                  Ответить
                                                                                                                  • программа продолжает работать с двумя педрилами. поддержки третьей не заявлено.
                                                                                                                    Ответить
                                                                                                                    • пользователю от этого ни горячо, ни холодно. Он запустил программу, и она молча ничего не сделала. Она не работает. С таким же успехом она могла упасть.
                                                                                                                      Ответить
                                                                                                                      • во-первых мы сейчас не про продуктовые требования. ты прыгаешь на другой уровень.

                                                                                                                        во-вторых вопрос появления каркуши по-прежнему неясен. если он запускает конечную программу, то её там по-прежнему нет, потому что как она попадет в программу, которая не знала о символе компайл-тайм?

                                                                                                                        если это промежуточная библиотека, то тут вопрос, почему конечный продукт использует нерабочие зависимости
                                                                                                                        Ответить
                                                                                                                        • >ты прыгаешь на другой уровень.
                                                                                                                          Я на том же самом уровне: в общем случае невозможно обеспечить корректную работу программы при добавлении записи в enum. Добавление записи в енум это брейкинг чендж в общем случае

                                                                                                                          >во-вторых вопрос появления каркуши по-прежнему неясен.

                                                                                                                          Программа скомпилирована с версией 1.0, где ее не было.
                                                                                                                          А запускается с версией 2.0, где она есть.

                                                                                                                          Откуда взялось значение?
                                                                                                                          На выбор:
                                                                                                                          * ввел пользователь (при вводе значения, отсутствующего в enum, выдается ошибка: SpokNochi.fromString(string))
                                                                                                                          * пришла по сети
                                                                                                                          * пользователь выбрал из выпадаюещго меню, которое предлагает библиотека
                                                                                                                          Ответить
                                                                                                                          • > Я на том же самом уровне: в общем случае невозможно обеспечить корректную работу программы при добавлении записи в enum.

                                                                                                                            Да ну хорош увиливать уже. Мы про техническую корректность, а не про продуктовый уровень. Продуктовый уровень вообще не знает про библиотеки-хуеки.

                                                                                                                            > * ввел пользователь (при вводе значения, отсутствующего в enum, выдается ошибка: SpokNochi.fromString(string))
                                                                                                                            Пользователь пытается вызвать несуществующий функционал программы

                                                                                                                            > * пришла по сети
                                                                                                                            Аналогично

                                                                                                                            > пользователь выбрал из выпадаюещго меню, которое предлагает библиотека
                                                                                                                            Вообще да, но я ни разу не видел, чтобы библиотека моделей строила за меня выпадающее меню.
                                                                                                                            Ответить
                                                                                                                            • > техническую корректность, а не про продуктовый уровень.

                                                                                                                              Мне неизвестны такие понятия. Программа либо работает в соответствии с ТЗ, либо нет.
                                                                                                                              Если она нарушает ТЗ (не важно -- падает или молча ничего не делает) то значит она сломана.



                                                                                                                              В инструкции к программе сказано: "Пользователь вводит имя персонажа. Если пользователь вводит неверные данные, то он должен получить сообщение об ошибке". В примере с enum он его не получает.
                                                                                                                              Программа ведет себя неверно. Она сломана.

                                                                                                                              Если бы она упала в рантайме, то было бы даже лучше, чем просто ничего не сделала
                                                                                                                              Ответить
                                                                                                                              • Она работает согласно ТЗ. Шлет сообщения двум заявленным там адресатам. С функционалом не произошло вообще ничего.
                                                                                                                                Ответить
                                                                                                                                • Видимо, ты не до конца прочитал ТЗ.
                                                                                                                                  Еще раз повторю эту часть

                                                                                                                                  Если пользователь вводит неверные данные, то он должен получить сообщение об ошибке.
                                                                                                                                  Ответить
                                                                                              • именно потому что ты рушишь даунстримные проекты

                                                                                                удалять депрекейт ты можешь только на смене мажорной версии как раз по причине этого
                                                                                                Ответить
                                                                                                • Всё верно. Добавлять новые поля в енум -- тоже только на мажорной версии.
                                                                                                  Ответить
                                                                                                  • Смотря что за енум.
                                                                                                    Если обработка каждого поля обязательна - да.
                                                                                                    Если добавляется идентификатор новой операции, которую может выполнять сервер - нет.
                                                                                                    Ответить
                                                                                            • Это вполне допустимая ситуация. Инкрементишь мажорную версию либы, ломаешь всё что можно сломать и оставляешь старую копию сайд-бай-сайд для старого софта.
                                                                                              Ответить
                                                                                  • В крестах тоже проверяется обработка енумов в свиче. Но если проверял ифами - ну ССЗБ.
                                                                                    Ответить
                                                                                    • ворнинг будет если я не все проверю?
                                                                                      Ответить
                                                                                      • Да, будет ворнинг если не все варианты енума обработаны.
                                                                                        Ответить
                                                      • https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html

                                                        Для информации
                                                        Ответить
                                      • Плюс постоянные проверки засирают код гораздо больше чем пара-тройка мест, где реально ловят и обрабатывают исключения.
                                        Ответить
                                        • От проверок можно отказываться:

                                          result.successOrDie
                                          Ответить
                                          • в «PHP» используется оператор ->, да и or die нужно писать раздельно, если не ошибаюсь: result->success or die();
                                            Ответить
                      • показать все, что скрытоИсключил тебя, проверь.


                        P.S: Мне всегда было занятно, как ты, Ильяс, дуришь людей, ведЯ диалоги С САМИМ СОБОЙ.
                        Ответить
                    • >Какие-нибудь временные файлы не удалятся
                      Я не вижу тут временных файлов

                      > В большинстве прог похер, конечно.
                      отож

                      Чем отличается "нормально залогировать" от "what() из экцепшена в stderr"?
                      Если ты демон, то я понимаю. А если ты комманд лайн, то не понимаю.

                      Кстати, это же заморочки вашего кресторантайма? Я думал, будет просто падение програмы в кору/доктор вацон
                      Ответить
      • Ты поменял местами первое и последнее, а потом последнее и первое
        Ответить
        • Лучше всего если там нечетное количество символов. Тогда средний дважды свапнулся сам с собой.
          Ответить
    • инью, а ты можешь блокануть рака по айпи? Опять пол ГК засрал гной
      Ответить
    • А можно ли писать так?

      for(int i = size_, char tmp = str[i]; i >= 0; i--)
      Ответить
      • Нет, тип должен быть один.
        Ответить
        • for(int i = size_, tmp = str[i]; i >= 0; i--)
          Ответить
          • Я сделал:
            typedef union {
                size_t razmer;
                char   symbol;
            } kokokontainer;
            
            #define size__ size_.razmer
            #define i_ i.razmer
            #define tmp_ tmp.symbol
            
            void revers(char * str){
                for(kokokontainer size_ = {.razmer = strlen(str) -1}, i = {.razmer = size__}, tmp; i_ >= 0; i_--){
                    tmp_ = str[i_];
                    str[i_] = str[size__ - i_];
                    str[size__ - i_] = tmp_;
                }
            }
            Ответить
      • ну ты можешь в тупл засунуть 2 переменных разного типа (кресты давно умеют)
        только ничего не выиграешь, т.к. тебе надо tmp менять на каждой итерации, ты ошибочно предположил, что только при инициализации цикла
        а раз надо на каждой итерации, то что экономить собрался? строки кода? значит, в другом месте их проиграешь

        и да, int хуевый тип для хранения "размера"
        а схема tmp = a; a = b; b = tmp; не для каждого типа Т адекватна (оптимальна или вообще компилируема)
        именно поэтому алгоритмы в стл используют using std::swap; swap(a, b);
        в надежде, что ты перегрузишь, компилятор найдет в твоем неймспейсе, или не найдет, тогда в std:: найдет
        Ответить
        • А, ну да. Тогда надо было бы писать

          for(int i = size_, char tmp = str[i]; i >= 0; i--, tmp = str[i])


          а это выглядит как хуета

          > int хуевый тип для хранения "размера"
          - это к ОПу
          Ответить
    • показать все, что скрытоРыба моя, уже в которй раз ты постишь топики на сях, самодовольно заканчивая их с постскриптумом 'какой багор)))'. Не приходило ли тебе в головочку, что не все знают сях? Ты бы хоть на паскаль перевёл, сделал одолжение, уважил народ.

      Лично для меня твой пост выглядит как бред психбольного. ничего личного.
      Ответить

    Добавить комментарий