Предисловие:
Иногда необходимо производить явное преобразование типа. Я понимаю, что это, скорее всего, из-за неправильной архитектуры, но ситуации бывают разные. Например, если используешь готовую функцию, как в QIODevice

если у меня массив unsigned char x[1000], то я должен в явном виде преобразовать указатель на него к char*.
Я всегда ( по привычке, а не потому, что это правильно ) делаю преобразование в стиле Си

Вопрос:
в чём существенное отличие такого преобразования от Си++-сного reinterpret_cast. И в чём отличие reinterpret_cast от static_cast.
Спасибо

Это сообщение отредактировал(а) borisbn - 16.9.2010, 10:08

Привет.

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

static_cast является почти аналогом сишного кастования но добавляет проверки типов:





>> И в чём отличие reinterpret_cast от static_cast.
reinterpret_cast применяется при кастовании поинтеров:

второй, умеет бросать исключение при невозможности каста.


вот  

Добавлено через 44 секунды
вай, Алена фотку сменила.

borisbn, ко всему выше сказанному добавлю что reinterpret_cast аццкая вещь и использовать ее нужно осторожно. 
у нее были проблемы с выравниванием. 


ололо. ну ты особо не увлекайся. рабочий день еще только начался.

вообще рекомендуется использовать C++ style cast, но в данном случае сложно назвать какую-то существенную причину.


reinterpret_cast не проверяет ничего, просто проводит cast. Какой угодно указатель к другому (какому угодно).



static_cast проводит compile-time проверку, там, где это возможно например

а вот в этом случае все будет работать

иногда возникают ситуации, когда compile-time проверки недостаточно

тут можно использовать dynamic_cast, он проверяет runtime, при ошибке приведения возвращает NULL (если возвращает указатель) или генерирует исключение, если возвращает reference.

Добавлено через 37 секунд

  это dynamic_cast, и то только тогда, когда делается cast к reference.

Добавлено через 1 минуту и 17 секунд

а static_cast типа этого не умеет?

глупости, даже преобразовывать не нужно, нужно только понимать чем unsigned char от char отличается в случает применения логических и орифметических операций

и даже это ? :



разочарую вас, но reinterpret_cast тоже проверяет возможность преобразования, но по своим правилам в отличии от static_cast.

главное отличие в том, что reeinterpret осуществляет "прямое" преобразование, а static, учитывая правила преобразования ( стандартные либо пользовательские для соотв. типов).




может стоит проверить ? 

нет, это уж слишком даже для reinterpret_cast, эти указатели размером не совместимы.


имелась ввиду проверка по иерархии классов (показано на примере). reinterpret_cast этого не делает.


Это сообщение отредактировал(а) azesmcar - 16.9.2010, 11:56

интересно, что подразумевается под словом "проверка" ?

Это сообщение отредактировал(а) mes - 16.9.2010, 11:56

проверка можно ли совершать данное преобразование.


по поводу этого, не уверен, но мне кажется это все же implementation defined.

откуда вы знаете?
в ряде случаев в винде они будут совместимы.

Не всегда. И если в каком-то компиляторе их размер равен это не значит, что они совместимы. я уже кажется писал



Это сообщение отредактировал(а) azesmcar - 16.9.2010, 12:07

тогда следующий вопрос: есть класс B некий наследник класса А, соответсвенно преобразование возможно. Раз проверка прошла, то результат будет всегда ли  одинаков в обоих случаях ?

Нет, не всегда. reinterpret_cast игнорирует vtable pointer.

Добавлено через 39 секунд
хотя я не совсем понял каким образом этот вопрос связан с темой проверки возможности преобразования?

azesmcar, нет, размер указателя на член класса зависит еще и от ОС и назначения этого члена класса.
в ряде случаев ОС будет гарантировать что указатель на член класса будет обычным указателем

повторяю, несовместимыми их делает не компилятор под названием "вставить название по своему желанию" а стандарт, который не гарантирует, что их размеры совпадают.

не  совсем понятно  что имелось ввиду  по отношению к static_cast.


с учетом стандарта, не понятно при чем тут вообще vtable 

я же показал на примере.




а где в процитированном сообщении я говорил про vtable?

я вообще уже перестал понимать предмет спора, вопрос был

ответ - нет, не всегда. причем тут стандарт? про стандарт я писал в другом сообщении, по другому вопросу и вообще не Вам.

Это сообщение отредактировал(а) azesmcar - 16.9.2010, 12:39

в процитицированном не было.. но в двух подряд сообщениях Вы придерживаетесь разных позиций по отношению к стандарту ))


опять же если касательно стандарта, то размер указателей непричем, стандарт просто его (преобразование) не допускает.



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




связано с тем, что слова "проверка" не достаточно для показания разницы поведения между обсуждаемыми кастами.

вот именно, не только проверка их различает 



Это сообщение отредактировал(а) mes - 16.9.2010, 12:49

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

где?  
В одном сообщении я говорил о совместимости, о термине совместимость и том, какой смысл в него вкладывается. В другом сообщении речь шла о совсем другой теме, раз мы говорим о C++ то стандарт надо упоминать всегда и везде, и не важно о чем мы говорим и в каком контексте?


наш спор был НЕ про reinterpret_cast и то, почему это преобразование не допускается, а про то, что размеры void* и указателя на member функцию несовместимы. Напомню


если вы тоже считаете их совместимыми - тогда можем поспорить.


а я будто возражаю? я лишь допустил, что не разрешает ИМЕННО из за несовместимости этих указателей.


есть еще много чего, множество исключений, разных поведений для разных типов, множество undefined behavior -ов..всего не перескажешь.


...для написания непереносимого кода, и все таки это не делает их совместимы.

Это сообщение отредактировал(а) azesmcar - 16.9.2010, 12:55

когда есть зависимость от размера, то в стандарте так и пишут :

а в данном случае для преобразования учтена только одна возможность :


Это сообщение отредактировал(а) mes - 16.9.2010, 12:55

ну так дополняйте, я же не претендую на всеобъемлющий пост.

Хорошо переформулирую :

на



Добавлено через 2 минуты и 40 секунд

уже

А по моему очень даже характеризует, по моему это и есть основное различие. Лично я reinterpret_cast использую крайне редко, но использую только тогда, когда я лучше компилятора знаю что мне нужно и мне не нужны его проверки. 

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

если при возможном преобразовании возможны различные результаты для случаев с применением разных кастов, то как "проверка" может повлиять на результат ?

Добавлено через 4 минуты и 5 секунд
кажись не слишком ясно, лучше перефразировать.

Если оба преобразования возможны, но дают разный результат, то при чем тут "проверка" ?

boostcoder, спасибо за ссылку на Алёну ( +1 ). Очень просто и понятно всё рассказано.
Тему закрываю, хотя подозреваю, что война здесь ещё не закончена 

mes

давайте сравним описания на разных источниках

http://msdn.microsoft.com/en-us/library/e0w9f63b(VS.80).aspx


http://www.cppreference.com/wiki/keywords/reinterpret_cast


http://www.cplusplus.com/doc/tutorial/typecasting/


http://publib.boulder.ibm.com/infocenter/c...erpret_cast.htm


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


reinterpret_cast много чего не учитывает, но это уже как следствие.

с "грубой силой" согласен, а вот с "другими словами" - нет.

static_cast не осуществляет проверку на связанность, а преобразовывает в соответствии с пользовательскими преобразованиями (естественно что речь о пользовательских типах).

Добавлено через 2 минуты и 4 секунды

акцент не на reinterpret_cast, которому и не  нужно ничего этого учитывать
а на static_cast,  поведение которого определяется не только проверкой на связанность.

о каких пользовательских преобразованиях идет речь, когда мы говорим о преобразовании указателей?

azesmcar, mes, господа, не ругайтесь. вы ведь почти интеллигенты  

а мы и не ругаемся, мы мирно беседуем. 

Добавлено через 31 секунду
во имя выяснения правды между прочим..для потомков стараемся  

компилим в MSVC, запускаем, ассёрт не срабатывает.

Добавлено через 2 минуты и 25 секунд
пишем

ассерт возможно срабатывает, зависит от конкретной версии msvc

пишем

ассёрт гарантированно не срабатывает

Добавлено через 3 минуты и 41 секунду
подсказка: в MSVC указатель на функцию член не является обычным указателем тогда и только тогда, когда функция виртуальная и возможно множественное наследование.

Это сообщение отредактировал(а) Abyx - 16.9.2010, 13:55

что-то у меня иной результат. и полагаю - правильный.
http://liveworkspace.org/code/24c04c97f407...33bbad04cc30050

Добавлено через 1 минуту и 56 секунд
как дополнение: http://liveworkspace.org/code/4dd7dd41b34b...91ed7d46d397852

boostcoder, на liveworkspace.org MSVC ?

в данном случае о преобразованиях в соответствии с иерархией наследования.

Добавлено @ 14:15

странные у Вас представления о ругани 



Добавлено @ 14:18


т.е. другими словами, при статик_касте изменяется не только тип, но может измениться значение указателя, если оно не NULL..  а раз значение меняется , то это не проверка.




Это сообщение отредактировал(а) mes - 16.9.2010, 14:20

нет. просто, абсолютно не понятно, почему MSVC дает такой результат...

boostcoder, потому что MSVC поддерживает определенные ABI win32, экспорт методов и COM

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

не совсем понял о чем это

я так понял речь идет об этом (пользовательские преобразования)

но причем тут пользовательские преобразования, если мы говорим об указателях?

Добавлено через 3 минуты и 56 секунд

значение конечно может и меняться, это же cast, но это не отменяет факта проверки. Я же не говорил, что static_cast это только проверка.

Использую только ()-кастование и dynamic_cast. Все остальное - синтаксическое излишество.

Добавлено через 14 секунд
конс_каст не в счет.

djamshud, всегда так и делал. но тут закрался червь сомнения. Если верить статье, которую привёл boostcoder, то


Это сообщение отредактировал(а) borisbn - 16.9.2010, 15:11

это я наверно упустил.. я думал мы об общем сравнении reinterpreta и статика.

чтоб убрать запутанности, покажу свое видение темы спора.


Я придрался к фразе, смыслом которой был, что статик_каст отличается от реинтерпрет_каста наличием проверки.
И высказал свое имхо, что суть не в наличие проверки, а в различном способе приведений,
которое для одних и тех же данных может дать разный результат в зависимости от типа  каста.

аа..ну автор писал про указатели, я отвечал про указатели..вообще весь разговор вел в этом контексте..  


ну я имел ввиду в контексте каста указателей, другого сравнения я и не предполагал, ведь reinterpret_cast вообще только с указателями работает.

borisbn, все правильно там написано. И что в этом плохого? Если начинаются пляски с определенным кастом, значит что-то пошло не так намного раньше написания кода. А const_cast я выделил отдельно, только потому, что это огромнейшая кривизна, либо хак by design, в обоих случаях const_cast это место прекрасно документирует.

ммм.. разве ? 

а что, нет?  
reference не в счет, это одно и тоже

mes, да)

интегер в указатель .. хотя если грубо то в принципе можно отнести к "только с указателями"

Добавлено @ 15:41

ну как сказать.. 

ну вот например : http://codepad.org/Lw5JRCml


Это сообщение отредактировал(а) mes - 16.9.2010, 15:44

разница лишь синтаксическая
http://codepad.org/CdLbCjqY

для interpret`a да, но не для static_cast`a..

да, но мы ведь сейчас про reinterpret говорим  

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

сложно сказать  
просто я с самого начала полагал, что так и сравниваем, а вы полагали, что иначе.  

я и не говорил, что плохо



IMHO и static_cast и reinterpret_cast тоже получше документируют место, чем (), но это - не решающий аргумент, а я как раз хотел увидеть решающий, и не увидел, поэтому пошёл хоронить червя 

по отношению к конвертации char * в unsigned char * или в общем случае ? 

borisbn,

>IMHO и static_cast и reinterpret_cast тоже получше документируют место, чем (), но это - не решающий аргумент, а я как раз хотел увидеть решающий, и не увидел, поэтому пошёл хоронить червя

Имхо, обычные касты документировать не нужно, т.к. это не хаки. Действительно хак - избавляться от константности. А преоразование типа - это нормальная практика.

не считаю это - нормальной практикой. почему если ты ( или кто-то другой ) забыл поставить const, то const_cast - хак, а если ты ( или кто-то другой ) не определил перегруженные функции для всех простых типов, не сделал шаблон, сделал char *, вместо void * - это не хак, а нормально ?

borisbn, принудительное кастование типов происходит не по забывчивости, а по необходимости. Тогда, когда автоматическое не срабатывает. Примеров можно придумать много, начиная от передачи чего-то в printf (ой, как не по-плюсовому!:) ) и заканчивая приведением типов по дереву наследования, когда динамический каст не нужен. Я говорю про такое использование кастования. Когда это происходит по чьей-то забывчивости (читай - глупости) - это конечно хак, и тут наверное обозначить его стоит, хотя хак этот - следствие ошибки, допущенной еще до начала написания кода. Так может лучше исправить первопричину? Про кривые библиотеки знаю. Не пользуюсь.

А использование const_cast - всегда очень тонкое место, будь то грязный хак или гениальный трюк.

Добавлено через 5 минут
ЗЫ. В предыдущем сообщении кривизной я называл грязный хак, а хак by design - гениальный трюк. Сорри за путаницу в терминалогии:).

djamshud, const_cast - средство языка, так что это по определению не хак.

Ремарка Капитана. Да, в рамках синтаксиса и семантики языка это весьма годная конструкция, но джамшут с borisbn не стандарт языка грызут, а рассуждают о дизайне приложения и его частей, а так же о культуре программирования в общем. С этой точки зрения попытка записи в const-область - весьма нестандартный поступок. Капитан в курсе, что const_cast случается и из-за кривости рук разработчика АПИ.

специально для Капитана:

1. const- объект далеко не всегда реально константный, всего лишь логически.
2. const_cast бывает нужный не только для убирания константности, но и для ее добавления 

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


Ээ.. А можно пример, где это действительно нужно и не произойдёт автоматом? При передачи в функцию, возврате из функции или присваиванию переменной - всегда само отработает (ну это и логично).

там где надо вызвать именно константную версию метода, а имеем не константный объект..



Это сообщение отредактировал(а) mes - 16.9.2010, 19:56

mes

1. Капитан считает это очевидным:). Он писал не о константной области памяти, а о сферическом нечто, что попадает к нам в руки и представляется константным. В это нечто, по хорошему, писать - ни-ни!
2. Хороший пример. Но тоже весьма нестандартный, значит следует это отметить в коде.

Это сообщение отредактировал(а) djamshud - 16.9.2010, 20:45

бывает так, что требуется что то изменить объекту, не меняя при этом логической константности.. 
пример тот же внутренний  кэш..  


Это сообщение отредактировал(а) mes - 16.9.2010, 20:58

mes, конечно. Это не хак, а гениальный трюк:). И парой камментов раньше я это писал. Но мсье прикопался к "хаку", вот я и раскрывал хаковую часть природы const_cast

const - это как правило запрет на запись времени компиляции, не более того.

Это нормально, если внутри библиотеки объект mutable,
а во внешнем интерфейсе библиотеки он const, чтоб пользовательский код его не трогал.

Да, согласен. Хотя логически это всё равно очень странно. Обычно константная и неконстантная версия одного метода делают одно и тоже. Иначе это слишком неочевидно, как я считаю (с точки зрения конечного пользователя).

Добавлено через 1 минуту и 49 секунд

Ну что-то мне подсказывает, что для локальных переменных "простых типов" const будет означать либо их непосредственную подстановку, либо (если это массив или структура) запись данных в "неменяемую" область памяти. Хотя, очевидно, это компиляторозависимо и т. д.