Здравствуйте, netch80, Вы писали:
N>К моменту моего вступления в эту ветку EM уточнил смысл и контекст данного утверждения.
А ты себя считаешь точкой осчета любого обсуждения, в которое ты в ступаешь что ли? В таком случае, у меня для тебя плохи новости. Налицо все признаки землепуповости.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
N>>К моменту моего вступления в эту ветку EM уточнил смысл и контекст данного утверждения.
R>А ты себя считаешь точкой осчета любого обсуждения, в которое ты в ступаешь что ли?
Это значит, что и до этого уже было достаточно данных.
R> В таком случае, у меня для тебя плохи новости. Налицо все признаки землепуповости.
У тебя — чрезмерного употребления средств (мне уже неважно, какого характера), расширяющих сознание.
Здравствуйте, rg45, Вы писали:
N>>Вы нафлудили столько, и столько бродили вокруг, что найти там что-то нереально. N>>Лучше просить уточнения по новой. Спасибо за ответ.
R>Нафлудил не больше, чем твой дружок.
Ну значит я про средства расширения сознания не ошибся — ты уже приписал Евгения к моим "дружкам".
N>>Проверяются конкретные подозрительные ситуации, вызванные нарушениями в коде, который далеко, давно и в другом месте. Конкретный метод проверки платформенно-зависим. Здесь и тут — именно так. Абстракции интересны только в том смысле, чтобы обойти их ограничения.
R>В таком случае вы со своим приятелем неудачно выбрали форум и тему. Здесь НЕ обсуждаются "КОНКРЕТНЫЫЕ ПОДОЗРИТЕЛЬНЫЕ СИТУАЦИИ".
В этой подветке он начал, вы продолжили вместе.
Формальное соответствие, здесь это cpp или cpp.applied, или вообще что-то абстрактное, меня действительно не интересовало, всё равно постоянно смешивают.
Здравствуйте, netch80, Вы писали:
N>Ну значит я про средства расширения сознания не ошибся — ты уже приписал Евгения к моим "дружкам".
Я говорю о том, как это выглядит. И судя по тому, как тебя это цепляет, не очень-то и ошибся.
N>В этой подветке он начал, вы продолжили вместе. N>Формальное соответствие, здесь это cpp или cpp.applied, или вообще что-то абстрактное, меня действительно не интересовало, всё равно постоянно смешивают.
Это опять вранье. Я устал уже давать ссылки, ХЗ, что там у тебя вместо сознания.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, netch80, Вы писали:
N>Вы нафлудили столько, и столько бродили вокруг, что найти там что-то нереально. N>Лучше просить уточнения по новой. Спасибо за ответ.
А вообще, это прелестно, я считаю: "не читал, но осуждаю, но виноват в этом не я"
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Нет, он совершенно верно понял суть, в то время как Вы с коллегой, фанатично упершись в голый формализм, никак от него не отлипните, находя в моих утверждениях вовсе не тот смысл, что в них вложен, и никакие пояснения не помогают.
Ну а ты чего притих? Только "плюсики" шлепаешь. Почуял надежное плечо, что ли?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, cppguard, Вы писали:
C>Если нужно передать владение указателем, то передают unique_ptr, если указатель без владения — сам указатель. Но почему во втором случае не передавать ссылку? Вопрос навеян кодовой базой LLVM и другими открытыми проектами.
Мое ИМХО, что const T* [= nullptr] может использоваться как необязательный входной параметр,
а T* [= nullptr] может использоваться как необязательный входной/выходной или только выходной параметр.
Соответственно, T или const T& — это обязательный входной параметр, а T& — обязательный входной/выходной или только выходной параметр
Идеи с возвратом туплов мне не близки. Теперь можно кидать помидоры.
Здравствуйте, Basil2, Вы писали:
B>Это как раз и есть извращение, причем двойное (что конвертить указатель в ссылку
Если объект создается (статически, автоматически, динамически) на одном из верхних уровней, а на всех нижних пребывает в неизменности — какой смысл тащить его указателем по всем нижним уровням?
B>что разыменовывать без проверки)
Проверки на что именно? Если на нуль, то это имеет смысл лишь там, где по логике допускается нуль в качестве особого случая. Если на валидность, то именно за это на меня тут и спустили собак.
B>
Если функция возвращает кортеж, то неплохо бы посмотреть, какой код на это генерится. В варианте с make_tuple VC++ генерит чудовищный код, и только оптимизация способна превратить его во вменямый.
B>
B>const Point p = GetPoint();
B>
Когда элементы логически связаны между собой — конечно, удобнее возвращать объект.
Здравствуйте, Marty, Вы писали:
M>надо проверять указатели перед тем, как ты из них ссылки делаешь.
Надо. Но несовершенство разума может привести к тому, что где-то эти проверки могут быть забыты.
M>А если данные указатели протухают в произвольный момент времени, то даже постоянная проверка не особо поможет
Не особо, но как-то поможет. Вообще, проверок много не бывает, лишь бы они не съедали слишком много ресурсов. Я бы хотел как можно больше предупреждений от компилятора, и как можно больше автоматических проверок в run time. Но — полностью управляемых, а не только "уровень 1-4" или "включить все — отключить все".
M>
M>if (isValidPtr(ptr))
M> doSomething(ptr); // тут может быть уже инвалид
M>
У меня такое бывало, когда внешний компонент, передавший мне указатель на блок, вскоре освобождал его из-за ошибки у меня или у себя. Регулярные проверки помогали поймать это до того, как "размоется" предыстория. Без них пришлось бы писать и разгребать сотни мегабайт (а то и гигабайты) логов.
Здравствуйте, ·, Вы писали:
·>В плюсах нет никаких способов делать такие проверки. Единственное что возможно — ptr != nullptr.
Кому нужны "чистые плюсы" без связи с конкретной платформой — хоть непосредственно, хоть через библиотеки? Делать расчеты, задавая данные в командной строке абстрактной консоли?
·>Зато конкретные среды особенно в дебаг-сборках это делают на ура — валят в отладчик или сыплют коредампы.
Обычно они это делают не раньше, чем произойдет фактическое обращение по невалидному указателю или ссылке. Если б те среды гарантировали, что любая попытка преобразовать нулевой указатель в ссылку будет обнаружена "на месте", а любые невалидные указатели/ссылки будут обнаружены при входе в функцию/блок, где они используются, у меня б не возникало надобности делать это руками.
ЕМ>>а конструкцию (&ref != nullptr) приводил исключительно в качестве примера.
·>Примера чего?
Того, как на практике можно обнаружить ошибки, по Стандарту влекущие UB.
ЕМ>> в тот момент, когда произойдет фактическое обращение, часть предыстории может быть потеряна.
·>Не очень понял, что может быть потеряно.
Предыстория взаимодействия между различными компонентами кода — как моего, так и внешнего.
·>Попробуй переписать код.
Как именно? Представляете себе, например, как фильтры DirectShow взаимодействуют с диспетчером графов и другими фильтрами? Что там нужно "переписать", чтобы исключить возможность порчи своей/чужой памяти в любой момент?
·>Да любой код можно запустить 100500 раз, тесты называется.
Угу. А как при очередном запуске обеспечить точное повторение путей выполнения всего кода?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кому нужны "чистые плюсы" без связи с конкретной платформой — хоть непосредственно, хоть через библиотеки? Делать расчеты, задавая данные в командной строке абстрактной консоли?
Разработчики и пользователи FFMPEG и ImageMagic, и пр., и пр., смотрят на вас с недоумением.
и ссылки и цитаты с которых все началось. И убежден в том, что если бы Евгения не приложили фейсом о стандарт, никаких подробностей о целях проверок и привязки к конкретному семейству компиляторов никто бы и не узнал.
, дальше уже просто лень стало. Это все писалось в самые первые дни, полторы недели назад. Там и почти каждоразовые пояснения о том, что речь не про чистый и незамутненный "C++ вообще", а сугубо про конкретные реализации, платформы и даже компиляторы. Если Штирлиц и после этого наивно продолжал считать, что дискуссия не выходит за рамки "языка вообще", то ему ли обвинять кого-то в тупости?
S>Затем, чтобы читатели подобного спора отдавали себе отчет о том, что есть стандарт языка, а есть вещи за рамками этого стандарта.
Об этом было сказано в самом начале. Каюсь, не сообразил написать это пять раз большими буквами, выделив полями, жирным и отдельным цветом. Был лучшего мнения об умственных способностях как нынешних, так и будущих читателей.
S>Такое понимание важно, например, для портирования кода на другие платформы (а то и просто на другой компилятор или новую версию того же компилятора). Неприятные сюрпризы с такими вещами могут случиться и без UB, а уж с UB так вообще ничего нельзя знать точно.
И об этом я несколько раз писал явно. Но, блин, опять забыл про выделение — полагал, что это самоочевидно.
