[dxp 34]

8 часов назад, xvr сказал:

Неправильное правило - reinterpret вообще применять нельзя. Это очень опасное средство - оно полностью отключает всяческий контроль за тем что и куда преобразовывается. reinterpret в программе это признак некоректного использования базовых типов языка (т.е. хакерство в чистом виде).

10 часов назад, yes сказал:

Для  чего же в языке это оставили тогда? И как вы будете обходить ситуацию: вот хранится  адрес некой структуры данных во внешней SPI флешке, вы его читаете оттуда числом. Как теперь его в адрес преобразовать?

[xvr 12]

7 hours ago, dxp said:

Для  чего же в языке это оставили тогда?

Для того, что бы програмист при желании мог выстрелить себе в ногу 🙂

7 hours ago, dxp said:

И как вы будете обходить ситуацию: вот хранится  адрес некой структуры данных во внешней SPI флешке, вы его читаете оттуда числом. Как теперь его в адрес преобразовать?

Вот для этого reinterpret_cast подходит, но это и есть тот самый хак 🙂

И явный признак того, что что то спроектированно не так - как внутренняя адресная информация оказалась на внешнем носителе? И что будет, если в процессе развития ПО этот адрес изменится, как его синхронизировать с внешней SPI?

А если это адрес не внутри ПО, то почему он именно адрес, а не просто число? Ну и т.д.

 

[dxp 34]

Да это ж просто пример, ни к чему придираться к условиям. Они могут быть вполне другими. Например: внешнее устройство размещает какие-то данные в общей памяти (через расшаренную шину), потом по какому-то каналу мечет адрес (хоть тот же UART), прилетает пакет, в котором та же чиселка - адрес, по которому надо это данные взять и обработать. Таких ситуаций можно придумать бесконечное количество, всё зависит от конкретных условий и задания. И никак тут без reinterpret_cast<>() не обойтись.

Претензия наподобие как предъявляют к goto -- де, моветон и суксь. Но раз оставили в языке, значит для чего-то надо. И действительно есть одна ситуация, когда все остальные варианты уступают как минимум в производительности. Просто надо средствами пользоваться правильно, только и всего.

[yes 5]

16 hours ago, xvr said:

Неправильное правило - reinterpret вообще применять нельзя. Это очень опасное средство - оно полностью отключает всяческий контроль за тем что и куда преобразовывается. reinterpret в программе это признак некоректного использования базовых типов языка (т.е. хакерство в чистом виде).

Для всего

 

такое впечатление, что мне надо попробовать на С++ привести порожденный класс к базовому 🙂 upd -то есть наоборот

я не уверен, но, по-моему, static cast такое не позволяет

но на С++ я уже давно чего-то большего мелких патчей не писал, могу и путать (про реинтерпрет помню...)

[xvr 12]

4 hours ago, yes said:

static cast такое не позволяет

Позволяет. Любые приведения в рамках иерархии классов, за исключением приведения от виртуального базового (в случае множественного наследования) к потомку - тут нужен dynamic_cast<>

Но это крайне редкий случай (мягко выражаясь)

4 hours ago, dxp said:

И никак тут без reinterpret_cast<>() не обойтись.

Все эти задания и условия обладают одной общей чертой - они работают напрямую с сырым представлением данных в памяти, и оперируют на уровне бинарных образов, а не на урвне абстракций С++. Именно для этого reinterpret_cast и оставили. Для работы с стандартными С++ абстракциями иго применять КРАЙНЕ не рекомендуется. И не столько потому, что это запутывает программу (как в случае goto), а потому что вы легко можете разрушить модель данных в которой работает С++ программа, и получить самые неожиданные эффекты.

Если же вы применяете reinterpret_cast не для доступа к нижнему уровню, то нужно ОЧЕНЬ ХОРОШО понимать, что именно вы делаете и как это соотносится с тем, что ожидает компилятор.

PS. Хороший пример такого применения reinterpret_cast - приведение плавающей точки к целому для работы с битовым представлением плавучки. С++ такого сервиса не представляет, более того, он вообще не специфицирует как представленна плавучка. Т.е. вы можете наделать совершенно любых чисел, которые могут вообще поставить в известное положение всю исполняющую систему С++.

4 hours ago, dxp said:

Просто надо средствами пользоваться правильно, только и всего.

Согласен на все 100%. Осталось утрясти границы 'правильно' по отношению к reinterpret_cast<>

Я бы сформулировал так - если вы не уверены, какой именно *_cast вам нужен, это точно НЕ reinterpret_cast<>. Применение reinterpret_cast - это всегда последний и единственный вариант.

[dxp 34]

Благодарю за лекцию, но с чего вы взяли, что кто-то предлагал ломать систему типов С++ этими кастами? Я лишь возражал против утверждения, что reinterpret_cast совсем не нужен:

21 час назад, xvr сказал:

reinterpret вообще применять нельзя

Нужен. Именно для низкого уровня.

 

51 минуту назад, xvr сказал:

Я бы сформулировал так - если вы не уверены, какой именно *_cast вам нужен, это точно НЕ reinterpret_cast<>. Применение reinterpret_cast - это всегда последний и единственный вариант.

Консенсус.

static_cast тоже небезопасная штука -- если привести указатель на объект базового класса к указателю на потомка, то работать будет до тех пор, пока не вздумается вылезти за пределы определения базового класса. Т.е. полная ответственность точно так же на программисте. И тоже надо хорошенько подумать, нет ли ошибки проектирования, что приходится преобразовывать тип хоть и static_cast.

Собственно, вот этот безобразный внешний вид плюсовых кастов таким и сделали, чтобы их было хорошо видно в коде -- чтобы потенциально опасные места выделялись.

[xvr 12]

21 hours ago, dxp said:

Я лишь возражал против утверждения, что reinterpret_cast совсем не нужен:

Пардон, я не имел в виду, что он не нужен. Я имел в виду, что его не надо применять - он опасен. Но если хорошо понимаешь, что делаешь, то можно 🙂 

Обычно у людей, которые действительно хорошо понимают, что делают, вопросов такого рода (применять - не применять) не возникает - они и так это всё хорошо знают.

[krux 8]

зачем эту муть было городить в SV если ее можно было решить в С++?

натянули еще тень через плетень через reinterpret_cast.  Жаль что не через void **

зашибись что вы такие умные и "все знаете"

кто во всем этом потом после вас разбираться будет? Похоронить весь этот кусок после вашего ухода из конторы??

 

[krux 8]

вот ничего после вашей дискуссии не осталось, один только

" void ** "

и обсасывание насколько корректно его использовать

одно дело в 1974 а второе дело в 2023

и то насколько какой-нибудь питон "разбаловал" кодеров

[andrew_b 14]

10 hours ago, krux said:

кто во всем этом потом после вас разбираться будет? Похоронить весь этот кусок после вашего ухода из конторы??

Будут поминать тихим (а может, и не тихим) матерным словом.

[one_eight_seven 3]

On 7/10/2023 at 11:06 AM, yes said:

вот код, чтобы проиллюстрировать
ну я то как раз и хотел посмотреть, получится ли мне как-то путем статического кастанья - преобразовать объект chilg к указателю на grand_child (прошу не смеяться, но вдруг бы вышло, как в С++)

Вот тут сразу виден подход и не тестировщика, и не верификатора.

Смотрите

• динамическое приведение типов осуществляет проверку и, если это возможно, то приводит тип
• Статическое приведение приводит тип.

Соответственно, разница в поведении, как вы хотите её проверить будет только там, где динамическое приведение типа  обнаружит несовместимость.

А как вы проверяете? Конечно же как дизайнер - только идеальный случай. Вы создаёте объекты совместимых типов, а кастуете ссылки на них (handle), и кастуете к правильным типам. То есть, заранее создаёте совместимость типов. Тип самого объекта обеспечивается фабрикой, а ссылку вы кастуете, и проверяете только ту часть, которая 'приводит тип'. Не стоит ожидаеть разных результатов от одинаковых действий.

 

Попробуйте убрать переопределение типов фабрикой и сделайте даункаст, и понаблюдайте.

Изменено 15 июля, 2023 пользователем one_eight_seven

[jcxz 184]

В 11.07.2023 в 17:30, xvr сказал:

Хороший пример такого применения reinterpret_cast - приведение плавающей точки к целому для работы с битовым представлением плавучки. С++ такого сервиса не представляет

Нагородили надуманных "проблем" на пустом месте...

Такое совершенно спокойно предоставляет не то что си++, но даже простой си - без проблем. Посредством тривиального union.

[Arlleex 131]

1 час назад, jcxz сказал:

Такое совершенно спокойно предоставляет не то что си++, но даже простой си - без проблем. Посредством тривиального union.

Си - да, в C++ это уже UB.

[yes 5]

On 7/16/2023 at 12:09 AM, one_eight_seven said:

Вот тут сразу виден подход и не тестировщика, и не верификатора.

не работает, я вроде бы написал выше.

захотелось мне достать protected поля из VIP-а. (upd: уже за одно это меня бы не взяли в верификаторы 🙂 но это мне нужно было чтобы понять какие-то нюансы работы ВИПа)
то есть, кроме как через фабрику, SV не дает другой возможности. в отличие от C++