Задачка по чистым C++, потому сюда и кидаю.
Если кто знает ответ или задача покажется слишком элементарной, просьба восхищаться собой молча 

Есть класс



Можно ли взять адрес у экземпляра этого класса? Если да, то как?
Решение должно быть по стандарту С++, работать на любых платформах и т.п.

не знаю, является ли это правильным решением, но вот что у меня получилось:

тут раньше сморозил...

Это сообщение отредактировал(а) Alek86 - 18.3.2008, 12:34

РЕШЕНИЕ ВНИЗУ!!!







&static_cast<const C&>©

да проверил, работает, т.к. оператор не константный.
а вот если еще добавить константный оператор - тада я хз вообще.

нет

ну, пусть будет добавлен - про константность забыл :(

в оригинале звучало: класс, у которого переопределен опратор &

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

нашел решение.






static_cast<C*>(static_cast<C&>(obj))

Это сообщение отредактировал(а) korian - 18.3.2008, 12:51

MAKCim, 
размер указателя на A и размер указателя на C могут отличаться, так что есть вероятность потерять часть данных

разве можно статиккастить так?

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

ты уверен? в каком случае?

у меня решение было похожее (только A был наследником C и статик каст использовался)

вот что нашел :

Функция addressof() возвращает адрес объекта.

...

C++ разрешает программисту заменять унарный оператор в классе operator&() для получения адреса объекта. Получение истинного адреса объекта требует неуклюжих тюков с преобразованием (casting), чтобы избежать вызова перегруженного оператора  operator&(). Функция addressof() обеспечивает обертку для необходимого кода< чтобы упростить получение истинного адреса объекта. 

...

Пример

хехе



думаю, это и есть решение... 

на борланде 6.0 работает   


в C++ гарантируется только то что в void* влезит любой указатель, размер остальных указателей может быть любым.
умные люди пишут, что если вы уж решились использовать reinterpret_cast, то лучше делать это так:
int* intptr = reinterpret_cast<int*>(static_cast<void*>(objptr));
насчет "с наследованием" не знаю, поидее тоже должны как-то транслироваться друг в друга. вот только не известно должно ли оно работать, если приводить к наследнику, а сам объект является базовым классом... поидее это не правильно, т.к. получился указатель, на объект которого не существует.


ну да... чистый C++ ...

то есть реализация бустовского addressof некроссплатформенна?


должно. у компилера есть вся инфа для этого

Это сообщение отредактировал(а) Alek86 - 18.3.2008, 14:22

Из книги "Стандарты программирования на C++" Герб Саттер, Андрей Александреску



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

http://www.comeaucomputing.com/  такой код не компилит
а Borland C++ Builder хавает   

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

Добавлено @ 22:10

это неправильно
если предположить, что такой каст прокатывает, то я удивляюсь, что результат является адресом (а он точно им является?)   
семантически результат в таком случае должен быть равен значению объекта c, приведенного к указателю
а значение объекта недетерминировано, т. к класс не определяет ни одного поля
в таком случае размер объекта c обычно 1 и соответствующий байт должен быть беззнаково дополнен до 32-х (64-х) разрядов

Добавлено @ 22:17

зачем такой изврат?


Это сообщение отредактировал(а) MAKCim - 18.3.2008, 22:17

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


полностью согласен.


Это сообщение отредактировал(а) korian - 18.3.2008, 23:35

указатель (aka адрес) имеет один и тот же размер в рамках одной платформы
его размер не зависит от типа
адрес - это понятие, вообще не связанное с С++

MAKCim, можно ссылку на стандарт, если есть?

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

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

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

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

"не видел, но осуждаю"   

Допустим есть некая платформа, в которой есть 2 вида указателей - на мелкие объекты и на большие обьеты (< 1'000'000 бит). Размеры у них (указателей) разные, так как памяти максимум 100'000'000 бит. потому указатели на мелкие объекты должны иметь одно из 100 млн значений, а указатели на большие обьекты - всего лишь 1 из сотни (из-за выравнивания). Потому указатели на мелкие обьекты состоят из 20 бит, а на большие - из 7 бит.
И из-за того. что


на C++ на такой платформе работать нельзя? По-моему такие "мелочи" должны быть оговорены в стандарте.

нет таких платформ. Нет смысла реализовывать указатели разного размера.

vinter, DOS.
Там есть far и near указатели.

vinter, откуда знаешь?
вопрос на засыпку - есть ли платформы, у которых в байте нецелое число бит?

bsa, я думаю DOS во внимание брать не стоит, слишком уже устарела ОС.

есть.

я догадываюсь.. я таких лично не встречал.

vinter, в стандарте говорится, что void* может вместить любой другой указатель. Но не говорится, что они все обязаны быть одинакового размера.

хорошо, поставим вопрос по другому. Назовите хоть одну(из нынедействующих) систем, где используются разные размеры указателей.

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

В том то и дело, что указатель - это языковая вещь. На ассемблере понятия указателя нет, есть понятие адрес.

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

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

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


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

он может и платформо-независим - я не знаю, т.к. это не C++, а C конструкция   
читать про C, о зависимости такой конструкции нет желания, т.к. нету желания читать про C вообще.
И так слишком много лишнего в моск напихали, от которого не знаю как избавиться.

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

MAKCim, ты убежден, что адрес (любой адрес) - это просто число, номер ячейки памяти, независящее, что лежит по этому номеру. Резоны понятны. Однако: стандарт С++ утверждает, что это не обязательно так.

Добавлено через 1 минуту и 29 секунд
Абстрагируйся от железок. Ты ведь можешь написать компилятор С++ для виртуальной машины, где это не соблюдается, и все в строгом соответствии со стандартом.

да
так оно и есть

1. что значит компилятор для виртуальной машины?
2. все будет соблюдаться
пусть к примеру есть переменная типа int
абстрагируемся от того, где она расположена
но в любом случае она будет иметь некоторый адрес (опять же абстрагируемся от того, как представим этот адрес)
я получаю этот адрес посредством &
и присваиваю его переменной типа A*, где A - класс
A* определяет адрес
в результате присвоения переменная типа A* будет содержать другой адрес, нежели адрес переменной типа int?
естественно, нет
аналогично со ссылками в случае, если преобразование разрешается компилятором

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

ошибаешься
это так же С++ конструкция

Это сообщение отредактировал(а) MAKCim - 21.3.2008, 11:22

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


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

korian, 
попрошу конструктивно
как моя логика теоретически может стать неправильной?
господа, но это же очевидно
если я пишу

int a = 1234
int b = a

то b - всегда и везде будет содержать 1234
аналогично

int a = 1234
int * b = &a;
A * c = (A*)b;

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


Это сообщение отредактировал(а) MAKCim - 21.3.2008, 11:48

тут

Например, MIX. Нетрудно придумать свою, где int и double лежат в принципиально разных областях памяти.


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

Не упирайся, поразмышляй. На эту тему флеймить больше не буду. За убеждения получи плюс.   

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

A * c = (A*)b

значение b - адрес
оператор (A*) прибавляет к нему какое-то смещение?
вопрос какое? если ему известно только значение b и его тип
таблица отображений A <- offset -> int?
т. е для каждого int создается параллельный объект A?
извините, чушь
во-первых, в этом нет никакого смысла
во-вторых, нарушается семантика, т. к в результате преобразования я получу адрес какого-то неизвестного мне объекта
неизвестно как созданного
задавать таблицы отображения вручную?
а какой в этом смысл, если они мне не нужны?
и где про это в стандарте сказано?
  

 Всё смешалось в одну кучу.



А подтверждение цитатами из стандарта можно?


Открою страшную тайну: в целом boost - это платформозависимая библиотека.

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

Мдя...


Однако, вот незадача: соответствующим стандарту можно назвать, наверное, лишь Comeau.

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


-10- An rvalue of type ``pointer to cv void'' can be explicitly converted to a pointer to object type. A value of type pointer to object converted to ``pointer to cv void'' and back to the original pointer type will have its original value. 


так можно сказать и про STL, если взять платформу, у которой нету стандартного ввода/вывода.


и?

Эта цитата неприменима к твоему примеру, т.к. у тебя не выполняется преобразование из pointer to cv void к оригинальному типу. Относительно приведения не к оригинальному типу стандарт ничего не говорит, что, согласно положению "Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior", можно расценивать как undefined behavior.


Каком-таком контексте? Undefined behavior, unspecified behavior и implementation-defined behavior - это три разных термина стандарта, значение которых описано в п. 1.3 Terms et definitions. Поведение reinterpret_cast классифицируется как implementation-defined и потому должно быть описано в документации для каждой реализации. Для двойного static_cast через cv void описания не требуется.


Соблюдая стандарт, нельзя быть уверенным в реальной переносимости программы.

Естественно. И в тему от фонаря написал :/


И? Твои предложения?

делать как в бусте - #ifdef'ами...

Правильно. Так и делают. Я не понял, к чему это было написано? Иделала нет. Так что, стандарт не соблюдать?

соблюдать, но понимать что на каком нить компиляторе это может не сработать.

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

+ вам за разьяснения...
из всего выше сказанного получается, что, если платформа предпологает возможность перевода из T1* в T2*, то reinterpret_cast для такого перевода обязан быть реализован, т.к. reinterpret_cast - implementation-defined. а кастинг через void* из начально undefined и может работать не правильно и реализовываться не обязан. поэтому reinterpret_cast лучше при переводе не связанных типов.
я правильно понял?
по всему инету пишут, что reinterpret_cast хуже потому, что тупа копирует биты, но стандарт не оговаривает, что это должо быть именно так.

Я не могу быть на 100% уверенным, что я сам всё правильно понимаю. Стандарт C++ - штука хитрая, порой встречаешь описание чего-нибудь там, где совсем его не ожидаешь увидеть.


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

Ну дык и я про что