MAKCim, 
vinter, 
Очень хороший пример привел bsa: near и far появились из-за особенностей системы команд.
Конкретный пример разного размера для разных типов привести не могу, но теоретический - пожалуйста. Представьте некий встроенный девайс, у которого разные области памяти, реализованные разными способами с разной разрядностью. Например, ПЗУ и ОЗУ. Некая библиотека С++ для программирования этого девайса возвращает указатели на объекты (часть объектов жестко зашита в ПЗУ) - они будут разного размера.

Кстати разная разрядность ОЗУ и ПЗУ - обычное дело. Возможности адресации вообще-то определяются разрядностью счетчика команд. Если её недостаточно, применяют страничный метод. Это все я к тому, что архитектура процессора - не 100% гарантия свойств С++, на котором он исполняется.

baldina, согласен, но мы уже впадаем в лирику.. Так же можно спорить(что когда то и было) что всегда нужно использовать sizeof(char), хотя на привычных нам платформах это 1 байт. Универсальной во всех отношениях программы не напишешь, так что извращения над кодом который "где-то там в теории может пригодится", может вызвать непонимание человека читающего этот самый код, так как он избыточен.
bsa, в принципе игра терминами, указатель хранит адрес, так что можно сказать я неправильно применил термин. Но суть от этого не изменилась. Разрядность адреса все же зависит от платформы, а не от языка.

бред

нет
far указатель - это дополнительная фича борландовского компилятора для поддержки прямой работы с сегментной моделью памяти реального режима в виду ограниченности размера одного сегмента 64K
точно так же дополнительной фичей является концепция указателя на метод в С++
разница лишь в том, что это официальная стандартная фича в отличие от far указателя
и far указатель, и указатель на метод не обязаны инкапсулировать адрес
имплементация не специфицирована

это вообще сложный вопрос. легче всего читать чужой код человеку, имеющему примерно такой же уровень, что у писавшего.
если рассчитывать на человека, который "все хорошо понимает", то приведение не через void должно вызывать стойкую ассоциацию "в единой модели памяти на подобных этой платформах".
Точно так же описание конструкторов/деструкторов, выполняющих то же, что и генерируемыми по умолчанию, будет вызывать недоумение и раздражение у более опытного. А у менее опытного может вызвать такое же недоумение их отсутствие.

простите за   

1. ПЗУ также как и ОЗУ отображается на физическое адресное пространство, разрядность которого в рамках определенной процессорной архитектуры фиксировано (например 36 или 40 разрядов на платформах Intel или AMD соответственно)
2. Возможности адресации не всегда определяются разрядностью указателя инструкции
к примеру IA-32e специфицирует 64-х разрядный RIP, хотя линейное адресное пространство ограничено 48-ми разрядами
3. По поводу 100% гарантии, приведите примеры разных свойств

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

void * определяет адрес объекта
int * определяет адрес объекта
short * определяет адрес объекта
и т. д
размеры их одинаковы и не могут быть различными ни при каких условиях на данной архитектуре
конкретный тип T - это подсказка компилятору, с какими конкретно данными ему предстоит работать

система команд здесь не причем

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

потому, что это гипотетически, имху таких систем не существует, поэтому писать как может быть они не стали.
а вариантов может быть масса, например такой:
чтобы перевести указатель A* в указатель void* - надо сделать смещение битов по кругу на 4 влево
чтобы перевести указатель B* в указатель void* - надо сделать смещение битов по кругу на 8 влево

A* = B* - тупа скопирует биты

void* = A*;
B* = void*; - сделает необходимые преобразования.

korian, 
это чушь
имхо

это и есть чушь, до тех пор пока не придумают такую платформу... если придумают.

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

Давай-ка не будем сочинять, а? Где в стандарте написано, что reinterpret_cast тупо скопирует биты?


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

Теперь по поводу преобразования из void* в B*. В общем случае нету никакой гарантии стандарта, что результат будет корректным. Но в случае reinterpret_cast появляется шанс, что компилятор выдаст хотя бы предупреждение о том, что конкретное преобразование из A* в B* невозможно произвести должным образом. Двойной же static_cast через void* компилятор вряд ли будет проверять.

Наоборот. Оба staticа компилятор проверяет. А вот в случае reinterpret_cast компилятор умывает руки: программист сказал, что там double, и пополам, что по адресу лежал std::map. Надо double - получи double.

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

что-то с тем примером я перегнул, reinterpret_cast впринципе может выполнить те же самые преобразования...
короче начитался, и вот:



вообщем, что reinterpret_cast, что static_cast, в данном случае undefined, unspecified и implementation-defined.
static_cast есть смысл использовать, потому что стандарт гарантирует, что d3 == d4,
при reinterpret_cast, стандарт не гарантирует, что d1 == d2

и ответ на задачу:
получить реальный указатель на объект, у которого operator & переопределен таким образом, платформо-независимым методом, на чистом C++ нельзя.
можно использовать бустовский addressof, который платформонезависим, как у платформонезависимой библиотеки.
но реализация этой функции платформозависима, и может изменяться от платформы к платформе.

Это сообщение отредактировал(а) korian - 21.3.2008, 06:04