На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (42) « Первая ... 39 40 [41] 42   ( Перейти к последнему сообщению )  
> Инициализировать или не инициализировать , it's the question
    Цитата applegame @
    Что такое "васрать"?


    Означает среднюю степень умиротворенности. Японцы бы это выразили бы следующим образом: "Будь безмятежным как цветок лотоса в озере подле горы Фудзияма". Ну в общем, где-то как-то так.
      Цитата JoeUser @
      Означает среднюю степень умиротворенности. Японцы бы это выразили бы следующим образом: "Будь безмятежным как цветок лотоса в озере подле горы Фудзияма". Ну в общем, где-то как-то так.

      Да? А я подумал было, что это когда вас очень много. :)
        Цитата Flex Ferrum @
        И вот именно здесь нужно ещё раз перечитать Крайзера, который как раз и говорит о том, что детерминированное неправильное поведение хуже недетерминированного.

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

        Добавлено
        Цитата Qraizer @
        Отнюдь. Я никогда не против пояснить неосвещённый момент в рассуждениях.

        Пояснишь это?
        Цитата OpenGL @
        Цитата Qraizer @
        Проблема не в "поймать", а в "заметить, что оно неправильное". Это алгоритмическая ошибка, а не ошибка реализации. Поэтому анализировать нужно не код, который перед глазами, и который достаточно просто видеть, а алгоритм, который либо описан в документации, и его ещё надо сопоставить с кодом, либо его ещё надо восстановить по коду, что ещё сложнее.

        Это я понял. Непонятно, почему int a; без инициализации при её необходимости - ошибка реализации, а то же самое, но с дефолтовой неверной инициализацией - ошибка алгоритма.
          Цитата OpenGL @
          Непонятно, почему int a; без инициализации при её необходимости - ошибка реализации, а то же самое, но с дефолтовой неверной инициализацией - ошибка алгоритма.
          Да вроде бы так мне думается:
          1.Если 2 случай ("с дефолтовой неверной инициализацией - ошибка алгоритма"), то это означает, что алгоритм был написан на языке, в коем есть инит по умолчанию такой-то, и этот инит не попал в задуманное - явная ош.алгоритма.
          2.Если 1 случай ("int a; без инициализации при её необходимости - ошибка реализации"), то алгоритм был написан в порядке (ибо инита нет в языке), а вот инит был нужен - именно конкретная реализация пострадала, т.е. с ошибкой сделана.
            Цитата Славян @
            не попал в задуманное - явная ош.алгоритма

            Извини - бред! Инт не обязан быть в начале алгоритма определен. Он может (ИМЕЕТ ПРАВО) быть определен только в процессе обсчета. Крайний и очень крайний вариант - мы в процессе обсчета не нашли нужного значения - в этом случае мы можем:

            1) Не парится и вернуть значение (которое было при инициализации)
            2) А можем вернуть его же в ветке else/break

            Вопрос не принципа, вопрос реализации. Но, повторяюсь, "а давайте заранее зафигачим нули в место хранение" - это бред! Ну или обоснуйте "почему нули", а не "единицы"???!
              Цитата JoeUser @
              Извини - бред! Инт не обязан быть в начале алгоритма определен. Он может (ИМЕЕТ ПРАВО) быть определен только в процессе обсчета.
              Непонятно мне, где бред то? Итак, в случае №2 алгоритм был написан на языке, где есть инит по умолчанию. То, что его можно определить в момент обсчёта - это такая-то реализация алгоритма, как и определение в начале. Важно, что его надо определить и он был определён. Но вот не попал в нужное - косяк алгоритма.
                Цитата MyNameIsIgor @
                — Otherwise, if the object to which the glvalue refers contains an invalid pointer value (3.7.4.2, 3.7.4.3),
                the behavior is implementation-defined.

                — Otherwise, if T is a (possibly cv-qualified) unsigned character type (3.9.1), and the object to which
                the glvalue refers contains an indeterminate value (5.3.4, 8.5, 12.6.2), and that object does not have
                automatic storage duration or the glvalue was the operand of a unary & operator or it was bound to a
                reference, the result is an unspecified value.57

                — Otherwise, if the object to which the glvalue refers contains an indeterminate value, the behavior is
                undefined.

                — Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.
                3 [ Note: See also 3.10.—end note ]

                Что-то это, не совсем понятно - а из какого документа ты это взял? Ни в N3937 (последняя ревизия перед официальным принятием C++14), ни в N4567 (последний драфт) такой оговорки нет. В 8.5 есть оговорка про UB в случае indeterminative value, но это касается возникновения IV в процессе вычислений.
                Сообщение отредактировано: Flex Ferrum -
                  Цитата applegame @
                  Твоя аргументация сводится к
                  Цитата Qraizer @
                  Ну если васрать, то static_cast<> вам в помощь.
                  и
                  Цитата Qraizer @
                  Но тестеры на тёмной стороне, и просто обожают UB, не знал?
                  Ну если ты имеешь ровно такие же предпочтения к принятию аргументов, как и MyNameIsIgor, склонность к чему, увы, заметна, хоть и далеко не в такой степени ещё. Иначе как объяснить пропуск мимо ушей глаз вот этого:
                  Цитата Qraizer @
                  Trivia 2. Заранее хочу обратить внимание ещё на один факт. В любом решении этих вопросов всё равно будет присутствовать человеческий фактор. Его не избежать. Никак. Ситуация прямо такая же, как если бы рассматривался вопрос о поведении программиста, получившего какой-нибудь conversion from "int" to "short" may lose significant bits. Все мы прекрасно понимаем, что банальный static_cast<>, затыкающий рот компилятору, не всегда является правильным решением.
                  Ты этого не прочитал? Или проигнорировал? А теперь ещё раз подумай, "ну да" или не "ну да". Так что нечего удивляться невежливому ответу.
                  Что касается моих аргументов, их можно не принимать, я не обижусь. Тогда будь добр привести свои. Я, в отличие от некоторых тут присутствующих, их не игнорирую. Если это аргументы, конечно. А что касается тестирования, то этого вопроса касались тут несколько тем, и они дали мне понимание, что в этой сфере у меня конкурентов тут нет. Поэтому игнор :blush: авторитетного мнения выглядит, мягко говоря, некрасиво.

                  Добавлено
                  Цитата OpenGL @
                  Вот именно, что только говорит. Аргументов за это я не увидел - всё, что было, являлось просто заявлениями, ниоткуда не следующими.
                  Я по-твоему должен был прочитать лекцию по тестированию? Увы, этого я делать не буду. А примеры приводил.
                    Цитата MyNameIsIgor @
                    Нет, T x = T{} требует move-constructible.

                    С чего бы это? :blink: :blink: :blink:
                    user posted image
                      Цитата OpenGL @
                      Пояснишь это?
                      Цитата OpenGL @
                      Цитата Qraizer @
                      Проблема не в "поймать", а в "заметить, что оно неправильное". Это алгоритмическая ошибка, а не ошибка реализации. Поэтому анализировать нужно не код, который перед глазами, и который достаточно просто видеть, а алгоритм, который либо описан в документации, и его ещё надо сопоставить с кодом, либо его ещё надо восстановить по коду, что ещё сложнее.

                      Это я понял. Непонятно, почему int a; без инициализации при её необходимости - ошибка реализации, а то же самое, но с дефолтовой неверной инициализацией - ошибка алгоритма.
                      Потому что даже тесты выполняют над сущностями операции, на основании итогов которых делают выводы. std::string объект, и операции над ним выполняются его же средствами, а значит их результат над ним неинициализированным суть такое же UB, т.е. ничего не доказывают. А int не объект, и операции над ним выполняются внешними по отношению к нему средствами, результат которых никогда не UB. Поэтому когда речь заходит об объектах, их "приходится" инициализировать всегда, даже если ещё нечем.
                      Сообщение отредактировано: Qraizer -
                        Цитата Qraizer @
                        Ну если ты имеешь ровно такие же предпочтения к принятию аргументов, как и MyNameIsIgor, склонность к чему, увы, заметна, хоть и далеко не в такой степени ещё. Иначе как объяснить пропуск мимо ушей глаз вот этого:
                        Цитата Qraizer @ Вчера, 06:49
                        Trivia 2. Заранее хочу обратить внимание ещё на один факт. В любом решении этих вопросов всё равно будет присутствовать человеческий фактор. Его не избежать. Никак. Ситуация прямо такая же, как если бы рассматривался вопрос о поведении программиста, получившего какой-нибудь conversion from "int" to "short" may lose significant bits. Все мы прекрасно понимаем, что банальный static_cast<>, затыкающий рот компилятору, не всегда является правильным решением.
                        Ты этого не прочитал? Или проигнорировал? А теперь ещё раз подумай, "ну да" или не "ну да". Так что нечего удивляться невежливому ответу.
                        Что касается моих аргументов, их можно не принимать, я не обижусь. Тогда будь добр привести свои. Я, в отличие от некоторых тут присутствующих, их не игнорирую. Если это аргументы, конечно. А что касается тестирования, то этого вопроса касались тут несколько тем, и они дали мне понимание, что в этой сфере у меня конкурентов тут нет. Поэтому игнор :blush: авторитетного мнения выглядит, мягко говоря, некрасиво.
                        Я не понимаю твоей цитаты про человеческий фактор. Точнее саму цитату понимаю, но не понимаю, как она должна помогать твоей аргументации. Поэтому я ее принял к сведению и все. Может вместо того, чтобы лезть в бутылку просто попробовать изъясняться яснее, без туманных намеков?
                        Касаемо твоей цитаты. Надо ли из нее сделать вывод, что полезность/вредность инициализации по умолчанию или ее отсутствия в конечном итоге решается человеческим фактором? Ну типа, одному человеку оно поможет, а другому помешает.

                        Добавлено
                        Цитата Qraizer @
                        Потому что даже тесты выполняют над сущностями операции, на основании итогов которых делают выводы. std::string объект, и операции над ним выполняются его же средствами, а значит их результат над ним неинициализированным суть такое же UB, т.е. ничего не доказывают. А int не объект, и операции над ним выполняются внешними по отношению к нему средствами, результат которых никогда не UB. Поэтому когда речь заходит об объектах, их "приходится" инициализировать всегда, даже если ещё нечем.
                        Внешние средства, внутренние средства... это какая-то порочная классификация. Почему операцию сложения двух int'ов ты приписал к неким "внешним операциям"? Опять человеческий фактор?
                          Цитата applegame @
                          Я не понимаю твоей цитаты про человеческий фактор. Точнее саму цитату понимаю, но не понимаю, как она должна помогать твоей аргументации. Поэтому я ее принял к сведению и все. Может вместо того, чтобы лезть в бутылку просто попробовать изъясняться яснее, без туманных намеков?

                          Эммм... Ну смотри. Компилятор выдаёт массу диагностики на подозрительные действия программиста. Ну, там, не всегда корректные приведения, вызовы и т. п. В том числе на использование неициализированных переменных. Есть такой варнинг, да. Он обращает внимание программиста на то, что тот, возможно, что-то сделал не так. Программист приходит в нужное место кода и думает - а как правильно. Мейерс теперь предлагает этот варнинг подавить раз и навсегда. И (о боже!) диагностика потенциальных косяков, выдаваемая компилятором или санитайзером, исчезнет. И это - в разы хуже, чем бенифит от дефолтного нуля в целочисленной переменной.
                            Цитата Flex Ferrum @
                            Эммм... Ну смотри. Компилятор выдаёт массу диагностики на подозрительные действия программиста. Ну, там, не всегда корректные приведения, вызовы и т. п. В том числе на использование неициализированных переменных. Есть такой варнинг, да. Он обращает внимание программиста на то, что тот, возможно, что-то сделал не так. Программист приходит в нужное место кода и думает - а как правильно. Мейерс теперь предлагает этот варнинг подавить раз и навсегда. И (о боже!) диагностика потенциальных косяков, выдаваемая компилятором или санитайзером, исчезнет. И это - в разы хуже, чем бенифит от дефолтного нуля в целочисленной переменной.
                            Ну а если человек создал переменную типа std::string и забыл ее инициализировать нужным значением отличным от пустой строки. Выдаст ли компилятор предупреждение? И чем хуже неверно инициализированная по умолчанию строка от неверно инициализированного по умолчанию int? Типа что дозволено Юпитеру классу, не дозволено быку простому типу?
                            Сообщение отредактировано: applegame -
                              Цитата Qraizer @
                              Потому что даже тесты выполняют над сущностями операции, на основании итогов которых делают выводы. std::string объект, и операции над ним выполняются его же средствами, а значит их результат над ним неинициализированным суть такое же UB, т.е. ничего не доказывают. А int не объект, и операции над ним выполняются внешними по отношению к нему средствами, результат которых никогда не UB. Поэтому когда речь заходит об объектах, их "приходится" инициализировать всегда, даже если ещё нечем.

                              Я не вижу, как бы это отвечало на мой вопрос.
                              Цитата Flex Ferrum @
                              Эммм... Ну смотри. Компилятор выдаёт массу диагностики на подозрительные действия программиста. Ну, там, не всегда корректные приведения, вызовы и т. п. В том числе на использование неициализированных переменных. Есть такой варнинг, да. Он обращает внимание программиста на то, что тот, возможно, что-то сделал не так. Программист приходит в нужное место кода и думает - а как правильно. Мейерс теперь предлагает этот варнинг подавить раз и навсегда. И (о боже!) диагностика потенциальных косяков, выдаваемая компилятором или санитайзером, исчезнет. И это - в разы хуже, чем бенифит от дефолтного нуля в целочисленной переменной.

                              Иначе говоря - был косяк, для решения косяка придумали костыль, теперь косяк предлагают исправить, и - о ужас - теперь наш костыль перестанет работать. По мне так не очень большая проблема.
                                Цитата Flex Ferrum @
                                Что-то это, не совсем понятно - а из какого документа ты это взял? Ни в N3937 (последняя ревизия перед официальным принятием C++14), ни в N4567 (последний драфт) такой оговорки нет. В 8.5 есть оговорка про UB в случае indeterminative value, но это касается возникновения IV в процессе вычислений.

                                Я взял из 3797, потому что ни 3937 (это сам Стандарт, а не черновик), ни 3936 со странички комитета мне не давали слить без пароля. В итоге нашёл 3936 на github.
                                Да, действительно перенесли в 8.5/12 с хорошим примером
                                ExpandedWrap disabled
                                  int f(bool b) {
                                    unsigned char c;
                                    unsigned char d = c; // OK, d has an indeterminate value
                                    int e = d; // undefined behavior
                                    return b ? d : 0; // undefined behavior if b is true
                                  }

                                Не знаю, что вы имеете в виду под IV, но данный пример показывает то же, что и мой.
                                Цитата Flex Ferrum @
                                С чего бы это?

                                Я было хотел объяснить. Но потом подумал, что необходимый документ у вас имеется, так что идите почитайте про отличия
                                ExpandedWrap disabled
                                  T x;
                                  T x{};
                                  T x = {};
                                  T x = T{};

                                Когда вернётесь, мы поговорим о том, кто тут кому какие истории рассказывает. Надеюсь, к тому моменту вы сможете переписать ваш пример так, чтобы он требовал только default-constructible.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (42) « Первая ... 39 40 [41] 42 


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