Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.144.151.106] |
|
Страницы: (42) « Первая ... 39 40 [41] 42 ( Перейти к последнему сообщению ) |
Сообщ.
#601
,
|
|
|
Означает среднюю степень умиротворенности. Японцы бы это выразили бы следующим образом: "Будь безмятежным как цветок лотоса в озере подле горы Фудзияма". Ну в общем, где-то как-то так. |
Сообщ.
#602
,
|
|
|
Цитата JoeUser @ Означает среднюю степень умиротворенности. Японцы бы это выразили бы следующим образом: "Будь безмятежным как цветок лотоса в озере подле горы Фудзияма". Ну в общем, где-то как-то так. Да? А я подумал было, что это когда вас очень много. |
Сообщ.
#603
,
|
|
|
Цитата Flex Ferrum @ И вот именно здесь нужно ещё раз перечитать Крайзера, который как раз и говорит о том, что детерминированное неправильное поведение хуже недетерминированного. Вот именно, что только говорит. Аргументов за это я не увидел - всё, что было, являлось просто заявлениями, ниоткуда не следующими. Добавлено Пояснишь это? Цитата OpenGL @ Цитата Qraizer @ Проблема не в "поймать", а в "заметить, что оно неправильное". Это алгоритмическая ошибка, а не ошибка реализации. Поэтому анализировать нужно не код, который перед глазами, и который достаточно просто видеть, а алгоритм, который либо описан в документации, и его ещё надо сопоставить с кодом, либо его ещё надо восстановить по коду, что ещё сложнее. Это я понял. Непонятно, почему int a; без инициализации при её необходимости - ошибка реализации, а то же самое, но с дефолтовой неверной инициализацией - ошибка алгоритма. |
Сообщ.
#604
,
|
|
|
Цитата OpenGL @ Да вроде бы так мне думается:Непонятно, почему int a; без инициализации при её необходимости - ошибка реализации, а то же самое, но с дефолтовой неверной инициализацией - ошибка алгоритма. 1.Если 2 случай ("с дефолтовой неверной инициализацией - ошибка алгоритма"), то это означает, что алгоритм был написан на языке, в коем есть инит по умолчанию такой-то, и этот инит не попал в задуманное - явная ош.алгоритма. 2.Если 1 случай ("int a; без инициализации при её необходимости - ошибка реализации"), то алгоритм был написан в порядке (ибо инита нет в языке), а вот инит был нужен - именно конкретная реализация пострадала, т.е. с ошибкой сделана. |
Сообщ.
#605
,
|
|
|
Цитата Славян @ не попал в задуманное - явная ош.алгоритма Извини - бред! Инт не обязан быть в начале алгоритма определен. Он может (ИМЕЕТ ПРАВО) быть определен только в процессе обсчета. Крайний и очень крайний вариант - мы в процессе обсчета не нашли нужного значения - в этом случае мы можем: 1) Не парится и вернуть значение (которое было при инициализации) 2) А можем вернуть его же в ветке else/break Вопрос не принципа, вопрос реализации. Но, повторяюсь, "а давайте заранее зафигачим нули в место хранение" - это бред! Ну или обоснуйте "почему нули", а не "единицы"???! |
Сообщ.
#606
,
|
|
|
Цитата JoeUser @ Непонятно мне, где бред то? Итак, в случае №2 алгоритм был написан на языке, где есть инит по умолчанию. То, что его можно определить в момент обсчёта - это такая-то реализация алгоритма, как и определение в начале. Важно, что его надо определить и он был определён. Но вот не попал в нужное - косяк алгоритма. Извини - бред! Инт не обязан быть в начале алгоритма определен. Он может (ИМЕЕТ ПРАВО) быть определен только в процессе обсчета. |
Сообщ.
#607
,
|
|
|
Цитата 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 в процессе вычислений. |
Сообщ.
#608
,
|
|
|
Цитата applegame @ Ну если ты имеешь ровно такие же предпочтения к принятию аргументов, как и MyNameIsIgor, склонность к чему, увы, заметна, хоть и далеко не в такой степени ещё. Иначе как объяснить пропуск мимо Цитата Qraizer @ Ты этого не прочитал? Или проигнорировал? А теперь ещё раз подумай, "ну да" или не "ну да". Так что нечего удивляться невежливому ответу.Trivia 2. Заранее хочу обратить внимание ещё на один факт. В любом решении этих вопросов всё равно будет присутствовать человеческий фактор. Его не избежать. Никак. Ситуация прямо такая же, как если бы рассматривался вопрос о поведении программиста, получившего какой-нибудь conversion from "int" to "short" may lose significant bits. Все мы прекрасно понимаем, что банальный static_cast<>, затыкающий рот компилятору, не всегда является правильным решением. Что касается моих аргументов, их можно не принимать, я не обижусь. Тогда будь добр привести свои. Я, в отличие от некоторых тут присутствующих, их не игнорирую. Если это аргументы, конечно. А что касается тестирования, то этого вопроса касались тут несколько тем, и они дали мне понимание, что в этой сфере у меня конкурентов тут нет. Поэтому игнор авторитетного мнения выглядит, мягко говоря, некрасиво. Добавлено Цитата OpenGL @ Я по-твоему должен был прочитать лекцию по тестированию? Увы, этого я делать не буду. А примеры приводил. Вот именно, что только говорит. Аргументов за это я не увидел - всё, что было, являлось просто заявлениями, ниоткуда не следующими. |
Сообщ.
#610
,
|
|
|
Цитата OpenGL @ Потому что даже тесты выполняют над сущностями операции, на основании итогов которых делают выводы. std::string объект, и операции над ним выполняются его же средствами, а значит их результат над ним неинициализированным суть такое же UB, т.е. ничего не доказывают. А int не объект, и операции над ним выполняются внешними по отношению к нему средствами, результат которых никогда не UB. Поэтому когда речь заходит об объектах, их "приходится" инициализировать всегда, даже если ещё нечем. Пояснишь это? Цитата OpenGL @ Цитата Qraizer @ Проблема не в "поймать", а в "заметить, что оно неправильное". Это алгоритмическая ошибка, а не ошибка реализации. Поэтому анализировать нужно не код, который перед глазами, и который достаточно просто видеть, а алгоритм, который либо описан в документации, и его ещё надо сопоставить с кодом, либо его ещё надо восстановить по коду, что ещё сложнее. Это я понял. Непонятно, почему int a; без инициализации при её необходимости - ошибка реализации, а то же самое, но с дефолтовой неверной инициализацией - ошибка алгоритма. |
Сообщ.
#611
,
|
|
|
Цитата Qraizer @ Я не понимаю твоей цитаты про человеческий фактор. Точнее саму цитату понимаю, но не понимаю, как она должна помогать твоей аргументации. Поэтому я ее принял к сведению и все. Может вместо того, чтобы лезть в бутылку просто попробовать изъясняться яснее, без туманных намеков?Ну если ты имеешь ровно такие же предпочтения к принятию аргументов, как и MyNameIsIgor, склонность к чему, увы, заметна, хоть и далеко не в такой степени ещё. Иначе как объяснить пропуск мимо ушей глаз вот этого: Цитата Qraizer @ Вчера, 06:49 Trivia 2. Заранее хочу обратить внимание ещё на один факт. В любом решении этих вопросов всё равно будет присутствовать человеческий фактор. Его не избежать. Никак. Ситуация прямо такая же, как если бы рассматривался вопрос о поведении программиста, получившего какой-нибудь conversion from "int" to "short" may lose significant bits. Все мы прекрасно понимаем, что банальный static_cast<>, затыкающий рот компилятору, не всегда является правильным решением. Ты этого не прочитал? Или проигнорировал? А теперь ещё раз подумай, "ну да" или не "ну да". Так что нечего удивляться невежливому ответу. Что касается моих аргументов, их можно не принимать, я не обижусь. Тогда будь добр привести свои. Я, в отличие от некоторых тут присутствующих, их не игнорирую. Если это аргументы, конечно. А что касается тестирования, то этого вопроса касались тут несколько тем, и они дали мне понимание, что в этой сфере у меня конкурентов тут нет. Поэтому игнор авторитетного мнения выглядит, мягко говоря, некрасиво. Касаемо твоей цитаты. Надо ли из нее сделать вывод, что полезность/вредность инициализации по умолчанию или ее отсутствия в конечном итоге решается человеческим фактором? Ну типа, одному человеку оно поможет, а другому помешает. Добавлено Цитата Qraizer @ Внешние средства, внутренние средства... это какая-то порочная классификация. Почему операцию сложения двух int'ов ты приписал к неким "внешним операциям"? Опять человеческий фактор? Потому что даже тесты выполняют над сущностями операции, на основании итогов которых делают выводы. std::string объект, и операции над ним выполняются его же средствами, а значит их результат над ним неинициализированным суть такое же UB, т.е. ничего не доказывают. А int не объект, и операции над ним выполняются внешними по отношению к нему средствами, результат которых никогда не UB. Поэтому когда речь заходит об объектах, их "приходится" инициализировать всегда, даже если ещё нечем. |
Сообщ.
#612
,
|
|
|
Цитата applegame @ Я не понимаю твоей цитаты про человеческий фактор. Точнее саму цитату понимаю, но не понимаю, как она должна помогать твоей аргументации. Поэтому я ее принял к сведению и все. Может вместо того, чтобы лезть в бутылку просто попробовать изъясняться яснее, без туманных намеков? Эммм... Ну смотри. Компилятор выдаёт массу диагностики на подозрительные действия программиста. Ну, там, не всегда корректные приведения, вызовы и т. п. В том числе на использование неициализированных переменных. Есть такой варнинг, да. Он обращает внимание программиста на то, что тот, возможно, что-то сделал не так. Программист приходит в нужное место кода и думает - а как правильно. Мейерс теперь предлагает этот варнинг подавить раз и навсегда. И (о боже!) диагностика потенциальных косяков, выдаваемая компилятором или санитайзером, исчезнет. И это - в разы хуже, чем бенифит от дефолтного нуля в целочисленной переменной. |
Сообщ.
#613
,
|
|
|
Цитата Flex Ferrum @ Ну а если человек создал переменную типа std::string и забыл ее инициализировать нужным значением отличным от пустой строки. Выдаст ли компилятор предупреждение? И чем хуже неверно инициализированная по умолчанию строка от неверно инициализированного по умолчанию int? Типа что дозволено Эммм... Ну смотри. Компилятор выдаёт массу диагностики на подозрительные действия программиста. Ну, там, не всегда корректные приведения, вызовы и т. п. В том числе на использование неициализированных переменных. Есть такой варнинг, да. Он обращает внимание программиста на то, что тот, возможно, что-то сделал не так. Программист приходит в нужное место кода и думает - а как правильно. Мейерс теперь предлагает этот варнинг подавить раз и навсегда. И (о боже!) диагностика потенциальных косяков, выдаваемая компилятором или санитайзером, исчезнет. И это - в разы хуже, чем бенифит от дефолтного нуля в целочисленной переменной. |
Сообщ.
#614
,
|
|
|
Цитата Qraizer @ Потому что даже тесты выполняют над сущностями операции, на основании итогов которых делают выводы. std::string объект, и операции над ним выполняются его же средствами, а значит их результат над ним неинициализированным суть такое же UB, т.е. ничего не доказывают. А int не объект, и операции над ним выполняются внешними по отношению к нему средствами, результат которых никогда не UB. Поэтому когда речь заходит об объектах, их "приходится" инициализировать всегда, даже если ещё нечем. Я не вижу, как бы это отвечало на мой вопрос. Цитата Flex Ferrum @ Эммм... Ну смотри. Компилятор выдаёт массу диагностики на подозрительные действия программиста. Ну, там, не всегда корректные приведения, вызовы и т. п. В том числе на использование неициализированных переменных. Есть такой варнинг, да. Он обращает внимание программиста на то, что тот, возможно, что-то сделал не так. Программист приходит в нужное место кода и думает - а как правильно. Мейерс теперь предлагает этот варнинг подавить раз и навсегда. И (о боже!) диагностика потенциальных косяков, выдаваемая компилятором или санитайзером, исчезнет. И это - в разы хуже, чем бенифит от дефолтного нуля в целочисленной переменной. Иначе говоря - был косяк, для решения косяка придумали костыль, теперь косяк предлагают исправить, и - о ужас - теперь наш костыль перестанет работать. По мне так не очень большая проблема. |
Сообщ.
#615
,
|
|
|
Цитата Flex Ferrum @ Что-то это, не совсем понятно - а из какого документа ты это взял? Ни в N3937 (последняя ревизия перед официальным принятием C++14), ни в N4567 (последний драфт) такой оговорки нет. В 8.5 есть оговорка про UB в случае indeterminative value, но это касается возникновения IV в процессе вычислений. Я взял из 3797, потому что ни 3937 (это сам Стандарт, а не черновик), ни 3936 со странички комитета мне не давали слить без пароля. В итоге нашёл 3936 на github. Да, действительно перенесли в 8.5/12 с хорошим примером 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 @ С чего бы это? Я было хотел объяснить. Но потом подумал, что необходимый документ у вас имеется, так что идите почитайте про отличия T x; T x{}; T x = {}; T x = T{}; Когда вернётесь, мы поговорим о том, кто тут кому какие истории рассказывает. Надеюсь, к тому моменту вы сможете переписать ваш пример так, чтобы он требовал только default-constructible. |