Дорого ли приведение указателей?

Я не встретил эту тему в инете(именно про указатели, а не просто типы), но если она есть, дайте ссылку. На сколько дорога операция приведения указателя в стиле СИ? К примеру, есть два класса, один наследует другой. Дорого ли приведение указателя из указателя на родительский класс на указатель на дочерний? Я знаю, что указатель—это обычный int, который система принимает за адрес в памяти. Переменная, содержащая в себе указатель на объект представляет из себя int со значением вида 0x7f84a41000c0. Тогда, по идее, это не дорого для процессора. Я прав?

0

Dimgo2, прав Все эти типы переменных, указатели на разные типы важны для компилятора.
Чтобы сформировать правильный код и не допустить синтаксических ошибок программиста.

1

Тяжело ли приведение типов в стиле Си? Есть ли что-то легче для процессора?

0

Dimgo2, а процессору-то какая разница? Отработает все, что ему "подсунут"
В чем сомнения-то? Это программисту должно быть тяжело, если приходится приводить типы.
Приведение - это же не какие-то преобразования, а просто указание компилятору считать данные или адрес на данные
чем-то другим. Код не увеличивается ни на команду! Разве что, например, байт увеличивается до двойного слова или наоборот.
Если одного размера, так вообще ничего не меняется.

1

Проблема в том, что создаю сложную иерархию классов. Вкратце, нужно создать два класса, которые должны быть "одним типом".
Или создаю один класс(class Num), от которого наследуются другие(Unknown, Integer), или создаю структуру Num с указателями на Unknown и Integer. Проблема в том, что в случаи наследования, приходится часто приводить указатели для того, чтобы получить члены класса, а в случае со структурой код становится грязным.

0

Сообщение от Dimgo2 Дорого ли приведение указателя из указателя на родительский класс на указатель на дочерний?

Dimgo2, это не делается в силе С (reinterpret_cast<>). Тут применяют static_cast<> или dynamic_cast<> в зависимости от того, какая стоит задача. Дело в том, что указатель базового может показывать на наследника и если нужна вся его функциональность то лучше динамически кастить и проверять успех. Но бывыают случаи когда нужно кастить статически и обращаться к известным базовому методам без проверок. Тогда static_cast<>.

Добавлено через 8 минут

Сообщение от Dimgo2 На сколько дорога операция приведения указателя в стиле СИ?

Простые приведения безвредны. Они летают и стонут , но это понты (имхо). Всё делается во время компиляции (кроме полиморфных приведений, но о них уже сказано).

1

Сообщение от IGPIGP в силе С (reinterpret_cast<>)

Приведение в стиле Си является reinterpret_cast в последнюю очередь.

1

Сообщение от DrOffset Приведение в стиле Си является reinterpret_cast в последнюю очередь.

Я не силён в тонкостях. И речь была не о таких тонкостях. Исходя из вопроса. DrOffset, ваше односложное

Сообщение от DrOffset в последнюю очередь.

смущает. Я бесспорно признаю ваш приоритет, но никогда (или по крайней мере стараюсь) не ставлю целью меряться толщиной учебника. Могу например навскидку:

Сообщение от Язык программирования С++. 4-е, специальная ред. 2002 Б.Страуструп стр.171 6.2.7. Явное преобразование типов стр.172 последний абзац С++ унаследовал от С форму записи (T)e, означающую любое преобразование, которое может быть выражено комбинацией static_cast, reinterpret_cast и constant_cast, для получения типа T из выражения e...

Я согласен, что reinterpret_cast это лишь часть зла. Но в контексте вопроса я не увидел это существенным. А писать целые странцы лишь чтобы не нарваться на чьё то замечание... Может и надо. Иначе потом придётся.

0

Сообщение от IGPIGP А писать целые странцы лишь чтобы не нарваться на чьё то замечание...

Вы слишком драматизируете. Мое замечание было не для вас, а для ТС. Который грешным делом мог подумать, что каст в Си стиле равен reinterpret_cast безусловно.

Добавлено через 5 минут
На самом же деле, он может являться и static_cast и const_cast и их комбинацией, в зависимости от контекста использования. reinterpret_cast он будет являться только если ничего из вышеперечисленного применить не удалось.
В учебнике, который вы цитируете, скорее всего не совсем корректный перевод. Вот вам первоисточник:
http://eel.is/c++draft/expr.compound#expr.cast-4

The conversions performed by (4.1) a const_­cast, (4.2) a static_­cast, (4.3) a static_­cast followed by a const_­cast, (4.4) a reinterpret_­cast, or (4.5) a reinterpret_­cast followed by a const_­cast,

Как видите, reinterpret_­cast рассматривается в последнюю очередь, о чем я и сказал.

0

Сообщение от DrOffset Вы слишком драматизируете. Мое замечание было не для вас, а для ТС. Который грешным делом мог подумать, что каст в Си стиле равен reinterpret_cast безусловно.

Ничуть. У меня нигде не сказано что это одно и то же самое. Это может быть эквивалентно. Но односложность реплики смутила, повторяю.

Сообщение от DrOffset Как видите, reinterpret_­cast рассматривается в последнюю очередь, о чем я и сказал.

Форма высказывания и важность уточнения не вызывают сомнения. У меня более старое издание, я думаю. Вот совсем не старый Липман Язык программирования С++. Базовый курс. (2018 Москва, СПб, Киев) Глава 4.11.3 Явные преобразования, подраздел Приведение типов в старом стиле стр 225.

В зависимости от используемых типов, приведение старого стиля срабатывает аналогично операторам const_­cast, static_­cast ИЛИ reinterpret_­cast. В случаях, где используются операторы static_­cast или const_­cast, преобразование типа позволяет осуществить аналогичное преобразование, что и соответствующий оператор приведения. Но если ни один из подходов недопустим, то приведение старого стиля срабатывает аналогично оператору reinterpret_cast. Например, используя старую форму записи старого стиля, можно получить тот же результат, что и с использованием reinterpret_cast.

Далее пример с приведением указателя int* в указатель char*. То есть, речь идёт о приоритете выбора преобразования где самым жестким и мощным (включающим все попытки при получении неудачи в подборе более легальных правил преобразования соответствующим предыдущим операторам) является reinterpret_cast. То есть, говоря кратко, его упоминание в скобках наиболее краткая форма того что я и хотел сказать. Если бы я стал упоминать все по порядку, то и пришлось бы переписать главу из любой перечисленной книжки. Это небольшие главы - по 1-2 страницы.
То есть, раздел - минное поле. Скажешь слова - жди беды.
А между тем, приведение типов при наследовании, - даже одиночном, - достаточно непростая тема. И это то что возможно интересует ТС. Но тут уж я бы отвечал, на конкретные вопросы, конечно. Стоимость преобразования указателей при наследовании, достаточно обширно выглядит.

0

Сообщение от Dimgo2 Я знаю, что указатель—это обычный int

воу-воу-воу! Это не так. Указатель это целочисленный тип, да. Но не конкретно int. Более того, в некоторых случаях даже на одной машине разные указатели могут быть разного размера.

Сообщение от Dimgo2 К примеру, есть два класса, один наследует другой. Дорого ли приведение указателя из указателя на родительский класс на указатель на дочерний?

Тут дело скорее не в указателе (как вы сами сказали, это просто число), а в наследовании классов. Если у класса есть виртуальные методы, то есть те, которые перекрываются методами потомка, в классе используется виртуальная таблица методов (вот тут в терминоголии могу наврать, надеюсь меня поправят), и вызов метода пройдет в два этапа: переход на таблицу, а потом из нее на реальный метод. И вот здесь уже может быть потеря производительности. Плюс при наследовании может быть нужно определить реальный тип потомка из родительского указателя, это тоже не решается на этапе компиляции, а значит отнимет какое-то время.
То есть само по себе приведение указателей бесплатное. Но вот доступ к объекту по указателю может оказаться чуть дороже, чем ожидалось.

1

Сообщение от Dimgo2 Я знаю, что указатель—это обычный int, который система принимает за адрес в памяти

COKPOWEHEU, ТС неточно выразился в надежде на понимание. Если под

Сообщение от Dimgo2 обычный int, который система принимает за адрес в памяти

понимать как целое (без знак наверное) то понятно о чём он говорит. Но в основном я с вами согласен. Размер может отличаться не толька в зависимости от платформы. Насколько я помню стандарт не гарантирует равенства размера указателя на void размеру указателя на int (и др.). Но это не влияет на вопросы связанные с полиморфным наследованием. Не вникая в тонкости реализации можно полагаться на общее мнение о том, что RTTI дорогая процедура, а dynamic_cast<> - один из способов выяснения по RTTI.

0

Сообщение от IGPIGP ТС неточно выразился в надежде на понимание.

Я-то понял что ТС имел в виду, но за такой его формулировкой может стоять пробел в понимании, именно поэтому я расписал про представление указателей более подробно.

Сообщение от IGPIGP Не вникая в тонкости реализации можно полагаться на общее мнение о том, что RTTI

Ну да, сам термин RTTI это "не вникая в тонкости"

1

Сообщение от COKPOWEHEU Указатель это целочисленный тип, да.

???

Сообщение от https://timsong-cpp.github.io/cppwp/n4659/basic.fundamental#7 Types bool, char, char16_­t, char32_­t, wchar_­t, and the signed and unsigned integer types are collectively called integral types. A synonym for integral type is integer type.

0

rat0r, а в чем вопрос-то? Указатель это целое число, хранящее номер ячейки памяти. Размер указателя может быть в общем случае любым (ближе всего будет size_t пожалуй).
integer type != int

0

Сообщение от COKPOWEHEU а в чем вопрос-то?

Откуда ты берёшь то, что вещаешь.

Сообщение от COKPOWEHEU Указатель это целое число, хранящее номер ячейки памяти.

Цитату можно?

Сообщение от COKPOWEHEU integer type != int

Гениально!!! Об этом и написано в https://timsong-cpp.github.io/... damental#7

0

Сообщение от rat0r Откуда ты берёшь то, что вещаешь.

Если без ссылок, то из опыта или общих соображений, причем зачастую адаптирую под новичков.
Правда, все еще непонятно что же именно вас не устраивает. Комментария "???" для этого явно недостаточно. Разверните свою мысль.

0

rat0r, в контексте обсуждения с ТС было сказано на понятном ему языке. Тут вы уже второй участник с большим опытом нашедший "ошибку". А тема просится в новичковский раздел прямо со стартового текста. И первое уточнение (с выбором преобразования от С-style cast к реально выполняемому компилятором) вынесет любому новичку мозг выбросив далеко от темы. Что касается целочисленного типа, то да, неудачное словосочетания, но оно наиболее кратко соответствует вопросу:

Сообщение от Dimgo2 Я знаю, что указатель—это обычный int, который система принимает за адрес в памяти.

Ни кто разумеется не думает о integral types, отвечая на этот текст. Но мера условности соответствует уровню спрашивающего. И устанавливает её отвечающий. Почему бы вам не дать свой вариант ответа (и сравнить его потом с тем что уже есть, учитывая уровень ТС). Я не с сарказмом предлагаю. Пусть будут разные варианты ответов.
А пока, имеем:

Сообщение от IGPIGP То есть, раздел - минное поле. Скажешь слово, - жди беды.

0

Сообщение от IGPIGP То есть, раздел - минное поле. Скажешь слова - жди беды.

...

Миниатюры

 

0

rat0r, это типичная история о том, как плохо быть бестолковым. Причём, зная наших врачей, не очевидно, - кто в данной ситуации есть кто из действующих по фотографии лиц. Но вероятность, что тот кто пытается лечить очень высока. Даже в случае, когда клиент приходит к доктору добровольно становясь пациентом. Когда же доктор (или самозванец) сам проявляет инициативу, идя к клиенту наугад, то важно просто правильно выбрать меру допустимой самообороны.

0