На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (15) [1] 2 3 ...  14 15 все  ( Перейти к последнему сообщению )  
> Легальный около Цэ++ шный холивар
    Вобщем тема для пользователей исключительно Цэ++

    Регламент

    1) Спорим обо все, что касается или должно касаться Цэ++
    2) Любые темы сводим к возможностям Цэ++
    3) Если модератор "снесет" тему из раздела Цэ++, ожидайте наплыв прогеров на васике. Лично я забью на нее.

    Ожидаемый профит

    Что и как обсуждаемое можно реализовать средствами Цэ++, что можно и нужно заменить "своими"средствами. Ньюбы, типа меня, поучаться. Профи смогут реализовать интересные идеи в жысть. Одна просьба к модерам, пресекать терки типа:

    - ты прогаешь на Цэ++?
    - нет, пока только на ассемблере
    - фуууу!!! как это низко

    ... ну естественно, если тема улетит в "корзину", внезапно :D пойму, возможности - такие возможности :D

    Для затравочки ... контрактное программирование

    В языке D это - не библиотечная часть языка. Это часть языка. Суть. Функция и метод класса могут "обещать" предсказуемое поведение на входе и выходе. В случае наследования контракты работают по принципу "или". Иными словами, если контракт базового класса не выполняется - начинает обсчитываться контракт производного класса. Из книжки Александреску:
    Цитата
    Другими словами, in-контракты комбинируются с использованием дизъюнкции в сочетании с коротким замыканием: точно один контракт должен выполниться, и контракт предка пробуется первым. Таким образом, исключается вероятность того, что контракт потомка труднее удовлетворить, чем контракт предка. С другой стороны, потомок предоставляет второй шанс пройти тест предусловия, не пройденный в первый раз.


    Язык Цэ++, равно как и язык D, требует "базы" - соответствия типов. Это можно считать "контрактом" высшего порядка. Далее более :P Ваше отношение? Будете ли вы в продакшен-коде оставлять assert-ы? Считаете ли нужным генерировать исключения а-ля ExceptionAssertIn или ExceptionAssertOut?
      Тема не конкретна, базара ожидается много всякого; прошу сразу двинуть сие в холивары. :blush:
        Так и знал. Но надеялся :lol:
          Цитата JoeUser @
          Будете ли вы в продакшен-коде оставлять assert-ы?
          Я их вообще не использую и не советую. assert() суть тяжёлое наследие детства C/C++.

          M
          P.S. Славян, для меня желание ТС важнее, если оно не противоречит Правилам. В холивары тема переедет, если вы все в совокупности, не исключая ТС, сделаете её неудовлетворяющей Правилам. К тому же я вижу основной недостаток холиваров в том, что там не требуется тематики. JoeUser же рассчитывает на тематический спор, посему флуда попрошу воздерживаться. В целом не вижу причин не оставить пока тему здесь.
            Цитата Qraizer @
            Я их вообще не использую и не советую. assert() суть тяжёлое наследие детства C/C++.
            Понеслась! Чем вам не нравятся ассерты? Для обрабатываемых ошибок - используем исключения, для необрабатываемых - ассерты.
              applegame, а почему для всего не использовать исключения?

              Добавлено
              JoeUser, контракты даже предлагали включить в C++. В плане теории можно прочесть о них у Бертрана Майера, он придумал Design by contract. Но идёт все это от т.н. "троек" Хоара, чёрт знает когда описанных :)
                applegame, как бы так покороче... исключения как раз для необрабатываемых, а обрабатываемые и так обработаны.
                  Цитата D_KEY @
                  JoeUser, контракты даже предлагали включить в C++. В плане теории можно прочесть о них у Бертрана Майера, он придумал Design by contract. Но идёт все это от т.н. "троек" Хоара, чёрт знает когда описанных

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

                  Добавлено
                  Предлагаю следующую тему "множественное наследование vs примеси" ;)
                  Плюсы, минусы ....
                    Цитата Qraizer @
                    applegame, как бы так покороче... исключения как раз для необрабатываемых, а обрабатываемые и так обработаны.


                    Ни разу не согласен. Для чего придумали блок кэтч? Для последующей ловли, и возможно корректной обработки исключительной ситуации, как следствие - возможного нормального исполнения программы. Ассерты же - это финиш с посмертным выбросом инфы. Так что, скорее наоборот.
                      Цитата JoeUser @
                      Ассерты же - это финиш с посмертным выбросом инфы.
                      Кто тебе мешает ассерт поймать?
                        Цитата amk @
                        Цитата JoeUser @
                        Ассерты же - это финиш с посмертным выбросом инфы.
                        Кто тебе мешает ассерт поймать?

                        Это как, и главное зачем?
                          Цитата JoeUser @
                          Это как, и главное зачем?
                          Да тем же catch'ем. Насколько помню, accept в C++ просто генерирует исключение. которое, как и любое другое можно перехватить и обработать.
                          А зачем? Так это тебе самому виднее, зачем тебе отладочную проверку перехватывать захотелось.
                          Кстати, в релизе accept'ы не компилируются.
                            Цитата amk @
                            Кто тебе мешает ассерт поймать?
                            Зачем его ловить? Ассерт следует использовать в случаях, когда возникла ошибка, которую невозможно обработать, кроме как написать предсмертную записку (в моей смерти прошу винить того-то) и совершить сепукку.
                            Цитата D_KEY @
                            applegame, а почему для всего не использовать исключения?
                            Можно, конечно, и исключения использовать, но мне такой подход не нравится. Объясню на реальном примере.
                            У меня в проекте с некоторой периодичностью происходит обновление неких метаданных предоставлямых третьей стороной в виде JSON-а по протоколу HTTPS. Эта третья сторона имеет дурную привычку иногда выдавать 503 ошибку или вместо JSON-а отдавать пустую страницу или внезапно в JSON-е обнаруживаются какие-то новые поля или исчезают старые. Обновление метаданных не критично, желательно, но можно и со старыми продолжать успешно работать. У меня это все завернуто в один блок try/catch, ловящий все исключения (а там их может быть несколько видов), так как мне совсем не принципиально почему обломилось обновление, то-ли HTTP-ошибки, то ли JSON-кривой или вовсе обрыв соединения. Во всех случаях информация об ошибке пишется в лог, а приложение продолжает работать как обычно. Но в том же блоке есть несколько инвариантов, которые обрабатываются именно ассертами с падением. Сначала приложение гоняется в дебаг-версии, отлавиливаются и исправляются все ассерты, после чего делаем релиз из которого уже ненужные ассерты автоматически выбрасываются. ИМХО, удобно.
                            Сообщение отредактировано: applegame -
                              Ассерты нужны для тех случаев, которые в теории никогда не должны случаться, а если все-таки случились, то это 100% баг в коде и надо крэшиться с дампом. Например:
                              ExpandedWrap disabled
                                class vector
                                {
                                  ...
                                  item& operator[](size_t index)
                                  {
                                    assert((index < m_itemCount) && "Invalid index");
                                    return m_items[index];
                                  }
                                };
                              Сообщение отредактировано: Pacific -
                                Цитата Pacific @
                                Ассерты нужны для тех случаев, которые в теории никогда не должны случаться, а если все-таки случились, то это 100% баг в коде и надо крэшиться с дампом.
                                Ну совсем крэшиться, полагаю нехорошо. Надо бы перехватить, выдать вменяемое сообщение для конечного пользователя и культурно завершиться.
                                Конкретно в моем случае можно крэшиться, так как конечный пользователь - это я сам :)
                                Сообщение отредактировано: applegame -
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (15) [1] 2 3 ...  14 15 все


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0691 ]   [ 16 queries used ]   [ Generated: 28.03.24, 17:12 GMT ]