, дальше уже просто лень стало. Это все писалось в самые первые дни, полторы недели назад. Там и почти каждоразовые пояснения о том, что речь не про чистый и незамутненный "C++ вообще", а сугубо про конкретные реализации, платформы и даже компиляторы.
Только первые три написаны до того, как появилось ваше предложение использовать (&r != nullptr) и развязался основной спор. И в этих первых трех сообщениях нет ничего про привязку к Visual C++, только общие фразы про какое-то "практическое программирование" (как будто ваши оппоненты здесь занимаются чем-то другим). Оная привязка появляется только в сообщении http://rsdn.org/forum/cpp/8501114
Здравствуйте, Евгений Музыченко, Вы писали:
R>>неудачно выбрали форум и тему. Здесь НЕ обсуждаются "КОНКРЕТНЫЫЕ ПОДОЗРИТЕЛЬНЫЕ СИТУАЦИИ".
ЕМ>Из чего это следует?
ну, как-бы, для этого отдельный форум есть, cpp.applied называется
Здравствуйте, rg45, Вы писали:
R>по-твоему, я живу не в реальном мире, а в каком-то вымышленном?
Вы с коллегой живете в мире, где любое отступление от Высокого Стандарта автоматически считается тяжким грехом, независимо от его целей и результатов. Это нечто вроде убеждения "даже малейшая ложь позорна и недопустима, говорить и писать всегда нужно только чистую правду".
R>И в реальных проектах никогда не участвовал?
Возможно, Вы с коллегой преимущественно участвовали в таких проектах, где на первом месте применимость на любой платформе и с любым компилятором, а остальное менее важно.
Вообще, Вы с ним демонстрируете не инженерный, а чисто математический подход: "вот здесь может появиться бесконечность, а значит, что решение ни к черту не годится". И по барабану, что та бесконечность может появиться лишь при достаточно редком сочетании условий, а для большинства повседневных задач решение отлично подходит.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>неудачно выбрали форум и тему. Здесь НЕ обсуждаются "КОНКРЕТНЫЫЕ ПОДОЗРИТЕЛЬНЫЕ СИТУАЦИИ".
ЕМ>Из чего это следует?
Здравствуйте, Евгений Музыченко, Вы писали:
М>Вы с коллегой живете в мире, где любое отступление от Высокого Стандарта автоматически считается тяжким грехом, независимо от его целей и результатов. Это нечто вроде убеждения "даже малейшая ложь позорна и недопустима, говорить и писать всегда нужно только чистую правду".
Здравствуйте, rg45, Вы писали:
R>откуда у тебя уверенность что ТВОИ граничные условия подходят всем
У каждого граничные условия свои. Уметь их определять — часть профессиональной квалификации при использовании C++. Еще не так давно это предполагалось по умолчанию, этого не требовалось оговаривать явно.
R>ты несешь их в обсуждение, отвязаныое даже от конкретных платформ осей и компиляторов, не то что от какой-то твоей специфики.
Обсуждаемые проблемы регулярно возникают на любой платформе, под любой осью, и в достаточно широком ряде задач. Их можно решать только традиционными методами — анализом, моделированием, копанием в логах, трассировкой в отладчике, прикручиванием санитайзеров (там, где они есть), а можно добавить еще и то, что не совсем соответствует стандартам — если в итоге оно поможет сэкономить время и нервы. Вот каждый для себя и решит, что ему важнее — поймать баг завтра-послезавтра, или поиметь проблемы из-за UB когда-нибудь (а возможно, и не поймать вовсе).
ЕМ>У каждого граничные условия свои. Уметь их определять — часть профессиональной квалификации при использовании C++. Еще не так давно это предполагалось по умолчанию, этого не требовалось оговаривать явно.
Во-первых, кого волнуют здесь ТВОИ граничные условия. Во-вторых, ты пишешь говнокод — даже в СВОИХ граничных условиях, потому что не имеешь никаких гарантий работоспособоности своих программ. Разработка методом тыка, как обезьяна палкой в лужу. Потом сидишь годами на одном компиляторе, не смея даже поднять версию, чтоб не посыпался годами нагроможденный говнокод. Впрочем, это я тоже уже задолбался писать.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>·>В плюсах нет никаких способов делать такие проверки. Единственное что возможно — ptr != nullptr. ЕМ>Кому нужны "чистые плюсы" без связи с конкретной платформой — хоть непосредственно, хоть через библиотеки? Делать расчеты, задавая данные в командной строке абстрактной консоли?
Закладываться на конкретную платформу и UB, а не на "чистые плюсы" — хождение по минному полю. Кусок кода ВНЕЗАПНО может начать работать по-другому из-за того что ты немного поменял ключи компиляции, проапгрейдил минорную версию компилятора и т.п.
ЕМ>·>Зато конкретные среды особенно в дебаг-сборках это делают на ура — валят в отладчик или сыплют коредампы. ЕМ>Обычно они это делают не раньше, чем произойдет фактическое обращение по невалидному указателю или ссылке. Если б те среды гарантировали, что любая попытка преобразовать нулевой указатель в ссылку будет обнаружена "на месте", а любые невалидные указатели/ссылки будут обнаружены при входе в функцию/блок, где они используются, у меня б не возникало надобности делать это руками.
Твои манипуляции руками тоже ничего не гарантируют.
ЕМ>>>а конструкцию (&ref != nullptr) приводил исключительно в качестве примера. ЕМ>·>Примера чего? ЕМ>Того, как на практике можно обнаружить ошибки, по Стандарту влекущие UB.
Тут ведь как... можно обнаружить, а ведь можно и не обнаружить.
ЕМ>·>Не очень понял, что может быть потеряно. ЕМ>Предыстория взаимодействия между различными компонентами кода — как моего, так и внешнего.
Писать логи?
ЕМ>·>Попробуй переписать код. ЕМ>Как именно? Представляете себе, например, как фильтры DirectShow взаимодействуют с диспетчером графов и другими фильтрами?
Я не в курсе DirectShow, можешь привести пример, поглядим.
ЕМ>Что там нужно "переписать", чтобы исключить возможность порчи своей/чужой памяти в любой момент?
Добавим &ref != nullptr и это исключит возможнось порчи памяти. Да?!
ЕМ>·>Да любой код можно запустить 100500 раз, тесты называется. ЕМ>Угу. А как при очередном запуске обеспечить точное повторение путей выполнения всего кода?
Запустить весь test pack?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>меня обсуждение этих вопросов привлекает только для одного — насколько я могу извлечь для себя полезного в плане практического приближения к реальной цели минимально глючной программы без достижения нереальной цели (полного избавления от UB), желательно оставаясь в рамках C/C++. N>Насколько я понимаю EM, он хочет ровно того же (хоть и на другой платформе). Пусть поправит, если не так.
Именно так.
Вообще, на мой взгляд, C++ в последнее время отчаянно пытаются сделать "языком для математиков", программирование на котором состоит в "аккуратной записи алгоритма средствами языка согласно его спецификации". Смысла в этом я не вижу никакого: тем, кто так программирует, C++ совершенно не нужен, им гораздо лучше подойдут более другие языки. А тем, кто привык использовать универсальность и мощность языка в сочетании с компактностью, а главное — предсказуемостью порождаемого кода, эта тенденция все чаще ставит палки в колеса.
Здравствуйте, ·, Вы писали:
·>Закладываться на конкретную платформу и UB, а не на "чистые плюсы" — хождение по минному полю. Кусок кода ВНЕЗАПНО может начать работать по-другому из-за того что ты немного поменял ключи компиляции, проапгрейдил минорную версию компилятора и т.п.
Вот вы тоже не понимаете, а это совсем другое у него все работает, потому что, цитата
, "я работаю в основном с MS VC++ — это производственный компилятор, который делает прежде всего оправданные оптимизации" И так на протяжении уже не одного десятилетия. Что же может пойти не так? (тут был сарказм, если что).
ЕМ>Именно так.
ЕМ>Вообще, на мой взгляд, C++ в последнее время отчаянно пытаются сделать "языком для математиков", программирование на котором состоит в "аккуратной записи алгоритма средствами языка согласно его спецификации". Смысла в этом я не вижу никакого: тем, кто так программирует, C++ совершенно не нужен, им гораздо лучше подойдут более другие языки. А тем, кто привык использовать универсальность и мощность языка в сочетании с компактностью, а главное — предсказуемостью порождаемого кода, эта тенденция все чаще ставит палки в колеса.
Ты сейчас похож на Shmj — рассуждаешь о предмете, о котором имеешь весьма отдаленное представление. Ты осиль сперва азбуку, хотя бы, потом приходи, обсудим. А так... ну что с тобой можно обсуждать конструктивно, когда у тебя что ни высказывание, то мрак и невежество? Тебе дали молоток, ты даже не в курсе, за какой конец хвататься.
— это ясно показывает твой текущий уровень. При этом все вокруг плохие и виноват кто угодно, только не ты. Извини, цензурных слов для оценок не находится.
--
Не можешь достичь желаемого — пожелай достигнутого.
У меня нет под рукой этого компилятора, чтобы проверить его предметно. Если он умеет хотя бы явно предупреждать, что собирается выбрасывать такие проверки, то уже хорошо — значит, такой компилятор не годится для подобных применений. Если ему можно объяснить, что ничего такого выбрасывать не надо — еще лучше. Ну а если он всегда сам решает, что делать, то это скорее компилятор для "математических" применений языка и демонстраций приемов оптимизации, многим такой не подойдет в принципе.
и по сути выбрасывает ее?
ЕМ>У меня нет под рукой этого компилятора, чтобы проверить его предметно.
Незнание законов не освобождает от ответственности. Не слыхал о таком принципе? Хлебать будешь полным лаптем. Что ты уже и делаешь, собственно — боязнь обновления компилятора и компиляций в Release — это все не на пустом же месте возникло.
--
Не можешь достичь желаемого — пожелай достигнутого.
Вот тут бы и задать вопрос — а почему не сводится? Какую цель преследует компилятор — максимально сохранить логику программы, задуманную ее автором, или максимально наказать автора за любые нарушения Стандарта?
ЕМ>>я не знаю, что именно он у Вас выкинул (или, наоборот, что добавил).
S>Ну вот видите какая она, эта самая, сука реальность. Вам кажется, что следовало бы. А clang просто послал вас с пешее эротическое с тем, что вам кажется.
В данном случае он послал не меня, а Вас. Ну а все-таки, что за код он сделал в результате?
S>Все, что было в наличии вам было предъявлено.
Вы предъявили только результат работы программы (отсутствие выводимого сообщения). Посредством чего это получилось, я не знаю.
S>Поэтому где-то (вроде msvc++) вы можете видеть то, что вам кажется "нулевыми ссылками". А в других компиляторах можете и не увидеть.
Верно. Ну так я всегда изучаю особенности компиляторов перед тем, как применить сколько-нибудь нестандартные решения, и обоснованно полагаю, что грамотные программисты делают так же. Если кто-то применяет описанные приемы, не понимая, как они работают в конкретных реализациях, то он тупо нарушает правила лишь ради того, чтобы их нарушить.
, "я работаю в основном с MS VC++ — это производственный компилятор, который делает прежде всего оправданные оптимизации" И так на протяжении уже не одного десятилетия. Что же может пойти не так? (тут был сарказм, если что).
У этих людей еще хватает наглости кидать предъявы, что это я нафлудил
Здравствуйте, so5team, Вы писали:
S>вы себя вели так, как будто нулевые ссылки разрешены в языке C++ (вообще, безотносительно к особенностям конкретных компиляторов).
Нет, это Вы меня так читали, старательно пропуская все, что я об этом говорил.
S>>>OK, а вот это кривой код или нет: return i == 0 ? nullptr : new std::string{std::to_string(i)};
ЕМ>>Это просто некорректный код.
S>Что в нем некорректного?
То, что он может возвращать нулевой указатель, из которого соседняя функция без проверки сделает ссылку. Корректный код такого не допускает.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот тут бы и задать вопрос — а почему не сводится? Какую цель преследует компилятор — максимально сохранить логику программы, задуманную ее автором, или максимально наказать автора за любые нарушения Стандарта?
В этой теме не эти вопросы обсуждаются. Ты занялся бы самообразованием что ли, вместо того, чтобы сводить любое обсуждение к обсуждению "плохого языка", "плохого компилятора" и "плохих разработчиков компиляторов".
--
Не можешь достичь желаемого — пожелай достигнутого.
