Если кто знает ответ или задача покажется слишком элементарной, просьба восхищаться собой молча
Есть класс
| Код |
|
Можно ли взять адрес у экземпляра этого класса? Если да, то как?
Решение должно быть по стандарту С++, работать на любых платформах и т.п.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > небольшая задачка |
| Автор: Alek86 18.3.2008, 12:15 | ||
| Задачка по чистым C++, потому сюда и кидаю. Если кто знает ответ или задача покажется слишком элементарной, просьба восхищаться собой молча Есть класс
Можно ли взять адрес у экземпляра этого класса? Если да, то как? Решение должно быть по стандарту С++, работать на любых платформах и т.п. |
| Автор: korian 18.3.2008, 12:29 | ||
не знаю, является ли это правильным решением, но вот что у меня получилось:
|
| Автор: Alek86 18.3.2008, 12:32 |
| тут раньше сморозил... |
| Автор: MAKCim 18.3.2008, 12:33 |
| РЕШЕНИЕ ВНИЗУ!!! &static_cast<const C&>© |
| Автор: korian 18.3.2008, 12:34 | ||
| да проверил, работает, т.к. оператор не константный. а вот если еще добавить константный оператор - тада я хз вообще.
|
| Автор: MAKCim 18.3.2008, 12:34 | ||
нет |
| Автор: Alek86 18.3.2008, 12:35 |
| ну, пусть будет добавлен - про константность забыл :( в оригинале звучало: класс, у которого переопределен опратор & |
| Автор: korian 18.3.2008, 12:50 |
| нашел решение. static_cast<C*>(static_cast<C&>(obj)) |
| Автор: MAKCim 18.3.2008, 12:50 | ||
|
| Автор: korian 18.3.2008, 12:52 |
| MAKCim, размер указателя на A и размер указателя на C могут отличаться, так что есть вероятность потерять часть данных |
| Автор: Alek86 18.3.2008, 13:10 | ||||
разве можно статиккастить так? Добавлено через 4 минуты и 55 секунд
ты уверен? в каком случае? у меня решение было похожее (только A был наследником C и статик каст использовался) |
| Автор: mes 18.3.2008, 13:36 | ||
| вот что нашел : Функция addressof() возвращает адрес объекта. ... C++ разрешает программисту заменять унарный оператор в классе operator&() для получения адреса объекта. Получение истинного адреса объекта требует неуклюжих тюков с преобразованием (casting), чтобы избежать вызова перегруженного оператора operator&(). Функция addressof() обеспечивает обертку для необходимого кода< чтобы упростить получение истинного адреса объекта. ... Пример
|
| Автор: Alek86 18.3.2008, 13:43 | ||
хехе
думаю, это и есть решение... |
| Автор: korian 18.3.2008, 13:54 | ||||||
на борланде 6.0 работает 
в C++ гарантируется только то что в void* влезит любой указатель, размер остальных указателей может быть любым. умные люди пишут, что если вы уж решились использовать reinterpret_cast, то лучше делать это так: int* intptr = reinterpret_cast<int*>(static_cast<void*>(objptr)); насчет "с наследованием" не знаю, поидее тоже должны как-то транслироваться друг в друга. вот только не известно должно ли оно работать, если приводить к наследнику, а сам объект является базовым классом... поидее это не правильно, т.к. получился указатель, на объект которого не существует.
ну да... чистый C++ ... |
| Автор: Alek86 18.3.2008, 14:21 | ||||
то есть реализация бустовского addressof некроссплатформенна?
должно. у компилера есть вся инфа для этого |
| Автор: korian 18.3.2008, 14:48 | ||||
Из книги "Стандарты программирования на C++" Герб Саттер, Андрей Александреску
не знаю, может те преобразования входят в число "некоторых гарантированно обратимых преобразований". в этой книги они не описаны, надо читать стандарт. |
| Автор: korian 18.3.2008, 15:33 | ||||
http://www.comeaucomputing.com/ такой код не компилит а Borland C++ Builder хавает  |
| Автор: MAKCim 18.3.2008, 22:06 | ||||||||
вы о чем, сударь?  мне адрес надо получить, что я и делаю это раз во-вторых, размер указателя фиксирован разрядностью процессора и не важно какого он типа Добавлено @ 22:10
это неправильно если предположить, что такой каст прокатывает, то я удивляюсь, что результат является адресом (а он точно им является?)  семантически результат в таком случае должен быть равен значению объекта c, приведенного к указателю а значение объекта недетерминировано, т. к класс не определяет ни одного поля в таком случае размер объекта c обычно 1 и соответствующий байт должен быть беззнаково дополнен до 32-х (64-х) разрядов Добавлено @ 22:17
зачем такой изврат?
|
| Автор: korian 18.3.2008, 23:33 | ||||
ключевая фраза - работать на любых платформах. а у вас уже привязка к конкретному процессору. C++ не оговаривает, что все указатели имеют один размер.
полностью согласен. |
| Автор: MAKCim 19.3.2008, 09:56 | ||
указатель (aka адрес) имеет один и тот же размер в рамках одной платформы его размер не зависит от типа адрес - это понятие, вообще не связанное с С++ |
| Автор: Alek86 19.3.2008, 10:35 | ||
| MAKCim, можно ссылку на стандарт, если есть? Добавлено через 1 минуту и 25 секунд
честно говоря не знаю, но, думаю, если бы он (такой изврат) не был нужен, то в бусте его бы и не было |
| Автор: MAKCim 19.3.2008, 11:08 | ||||
это очевидно ты сам подумай указатель определяет адрес от изменения типа переменной, адрес которой содержит указатель, размер адреса измениться не может это по определению Добавлено через 1 минуту и 12 секунд
"не видел, но осуждаю" |
| Автор: Alek86 19.3.2008, 11:24 | ||
| Допустим есть некая платформа, в которой есть 2 вида указателей - на мелкие объекты и на большие обьеты (< 1'000'000 бит). Размеры у них (указателей) разные, так как памяти максимум 100'000'000 бит. потому указатели на мелкие объекты должны иметь одно из 100 млн значений, а указатели на большие обьекты - всего лишь 1 из сотни (из-за выравнивания). Потому указатели на мелкие обьекты состоят из 20 бит, а на большие - из 7 бит. И из-за того. что
на C++ на такой платформе работать нельзя? По-моему такие "мелочи" должны быть оговорены в стандарте. |
| Автор: vinter 19.3.2008, 14:09 | ||
нет таких платформ. Нет смысла реализовывать указатели разного размера. |
| Автор: bsa 19.3.2008, 14:38 |
| vinter, DOS. Там есть far и near указатели. |
| Автор: Alek86 19.3.2008, 14:41 |
| vinter, откуда знаешь? вопрос на засыпку - есть ли платформы, у которых в байте нецелое число бит? |
| Автор: vinter 19.3.2008, 15:27 | ||||||
bsa, я думаю DOS во внимание брать не стоит, слишком уже устарела ОС.
есть.
я догадываюсь.. я таких лично не встречал. |
| Автор: bsa 19.3.2008, 15:30 |
| vinter, в стандарте говорится, что void* может вместить любой другой указатель. Но не говорится, что они все обязаны быть одинакового размера. |
| Автор: vinter 19.3.2008, 16:38 | ||
хорошо, поставим вопрос по другому. Назовите хоть одну(из нынедействующих) систем, где используются разные размеры указателей.
так с этим никто не спорит, только вот указатели это платформенная фича, а не языковая. |
| Автор: bsa 19.3.2008, 16:59 |
| В том то и дело, что указатель - это языковая вещь. На ассемблере понятия указателя нет, есть понятие адрес. |
| Автор: baldina 19.3.2008, 17:15 |
| MAKCim, vinter, Очень хороший пример привел bsa: near и far появились из-за особенностей системы команд. Конкретный пример разного размера для разных типов привести не могу, но теоретический - пожалуйста. Представьте некий встроенный девайс, у которого разные области памяти, реализованные разными способами с разной разрядностью. Например, ПЗУ и ОЗУ. Некая библиотека С++ для программирования этого девайса возвращает указатели на объекты (часть объектов жестко зашита в ПЗУ) - они будут разного размера. Кстати разная разрядность ОЗУ и ПЗУ - обычное дело. Возможности адресации вообще-то определяются разрядностью счетчика команд. Если её недостаточно, применяют страничный метод. Это все я к тому, что архитектура процессора - не 100% гарантия свойств С++, на котором он исполняется. |
| Автор: vinter 19.3.2008, 17:27 |
| baldina, согласен, но мы уже впадаем в лирику.. Так же можно спорить(что когда то и было) что всегда нужно использовать sizeof(char), хотя на привычных нам платформах это 1 байт. Универсальной во всех отношениях программы не напишешь, так что извращения над кодом который "где-то там в теории может пригодится", может вызвать непонимание человека читающего этот самый код, так как он избыточен. bsa, в принципе игра терминами, указатель хранит адрес, так что можно сказать я неправильно применил термин. Но суть от этого не изменилась. Разрядность адреса все же зависит от платформы, а не от языка. |
| Автор: MAKCim 19.3.2008, 17:33 | ||||
бред
нет far указатель - это дополнительная фича борландовского компилятора для поддержки прямой работы с сегментной моделью памяти реального режима в виду ограниченности размера одного сегмента 64K точно так же дополнительной фичей является концепция указателя на метод в С++ разница лишь в том, что это официальная стандартная фича в отличие от far указателя и far указатель, и указатель на метод не обязаны инкапсулировать адрес имплементация не специфицирована |
| Автор: baldina 19.3.2008, 17:39 | ||
это вообще сложный вопрос. легче всего читать чужой код человеку, имеющему примерно такой же уровень, что у писавшего. если рассчитывать на человека, который "все хорошо понимает", то приведение не через void должно вызывать стойкую ассоциацию "в единой модели памяти на подобных этой платформах". Точно так же описание конструкторов/деструкторов, выполняющих то же, что и генерируемыми по умолчанию, будет вызывать недоумение и раздражение у более опытного. А у менее опытного может вызвать такое же недоумение их отсутствие. простите за  |
| Автор: MAKCim 19.3.2008, 17:42 | ||||
1. ПЗУ также как и ОЗУ отображается на физическое адресное пространство, разрядность которого в рамках определенной процессорной архитектуры фиксировано (например 36 или 40 разрядов на платформах Intel или AMD соответственно) 2. Возможности адресации не всегда определяются разрядностью указателя инструкции к примеру IA-32e специфицирует 64-х разрядный RIP, хотя линейное адресное пространство ограничено 48-ми разрядами 3. По поводу 100% гарантии, приведите примеры разных свойств Добавлено через 5 минут и 13 секунд
void * определяет адрес объекта int * определяет адрес объекта short * определяет адрес объекта и т. д размеры их одинаковы и не могут быть различными ни при каких условиях на данной архитектуре конкретный тип T - это подсказка компилятору, с какими конкретно данными ему предстоит работать |
| Автор: MAKCim 19.3.2008, 18:04 | ||
система команд здесь не причем |
| Автор: UnrealMan 19.3.2008, 22:17 | ||||
Вот только авторы не удосужились объяснить, чем двойное приведение лучше. Пока я вижу лишь то, что эта запись более громоздкая и хуже читается. |
| Автор: korian 20.3.2008, 02:45 | ||
потому, что это гипотетически, имху таких систем не существует, поэтому писать как может быть они не стали. а вариантов может быть масса, например такой: чтобы перевести указатель A* в указатель void* - надо сделать смещение битов по кругу на 4 влево чтобы перевести указатель B* в указатель void* - надо сделать смещение битов по кругу на 8 влево A* = B* - тупа скопирует биты void* = A*; B* = void*; - сделает необходимые преобразования. |
| Автор: MAKCim 20.3.2008, 09:23 |
| korian, это чушь имхо |
| Автор: korian 20.3.2008, 11:49 | ||
это и есть чушь, до тех пор пока не придумают такую платформу... если придумают. |
| Автор: MAKCim 20.3.2008, 13:54 | ||
да причем здесь вообще платформа? тип указателя - это подсказка компилятору, каким образом использовать данные, которые находятся по адресу, определяемом указателем тип указателя не влияет на его значение |
| Автор: UnrealMan 20.3.2008, 16:32 | ||||
Давай-ка не будем сочинять, а? Где в стандарте написано, что reinterpret_cast тупо скопирует биты?
IMHO, разработчикам компилятора ничто не мешает реализовать reinterpret_cast хотя бы через тот же двойной static_cast - в случае, когда тупое копирование битов даст неправильный результат, а двойной static_cast даст правильный результат. Теперь по поводу преобразования из void* в B*. В общем случае нету никакой гарантии стандарта, что результат будет корректным. Но в случае reinterpret_cast появляется шанс, что компилятор выдаст хотя бы предупреждение о том, что конкретное преобразование из A* в B* невозможно произвести должным образом. Двойной же static_cast через void* компилятор вряд ли будет проверять. |
| Автор: JackYF 20.3.2008, 19:03 | ||
Наоборот. Оба staticа компилятор проверяет. А вот в случае reinterpret_cast компилятор умывает руки: программист сказал, что там double, и пополам, что по адресу лежал std::map. Надо double - получи double. |
| Автор: UnrealMan 20.3.2008, 19:46 | ||
Видимо, ты вообще не в курсе, что здесь обсуждается. |
| Автор: korian 21.3.2008, 05:18 | ||
| что-то с тем примером я перегнул, reinterpret_cast впринципе может выполнить те же самые преобразования... короче начитался, и вот:
вообщем, что reinterpret_cast, что static_cast, в данном случае undefined, unspecified и implementation-defined. static_cast есть смысл использовать, потому что стандарт гарантирует, что d3 == d4, при reinterpret_cast, стандарт не гарантирует, что d1 == d2 и ответ на задачу: получить реальный указатель на объект, у которого operator & переопределен таким образом, платформо-независимым методом, на чистом C++ нельзя. можно использовать бустовский addressof, который платформонезависим, как у платформонезависимой библиотеки. но реализация этой функции платформозависима, и может изменяться от платформы к платформе. |
| Автор: MAKCim 21.3.2008, 10:59 | ||||
почему? объясни, почему этот код платформо-зависим
ссылка на нижнем уровне эквивалентна указателю но с точки зрения языка на нее навешана дополнительная семантика, которая проверяется на этапе компиляции указатель так же как и ссылка определяет адрес независимо от типа для получения адреса не важен тип объекта важно наличие самого объекта синтаксический сахар в виде преобразования ссылок одного типа в другой является только синтаксическим сахаром и определяет что-то функционально только при использовании результатов преобразования на нижнем уровне идет манипуляция с одним и тем же адресом |
| Автор: korian 21.3.2008, 11:08 | ||
он может и платформо-независим - я не знаю, т.к. это не C++, а C конструкция читать про C, о зависимости такой конструкции нет желания, т.к. нету желания читать про C вообще. И так слишком много лишнего в моск напихали, от которого не знаю как избавиться. |
| Автор: baldina 21.3.2008, 11:13 |
| MAKCim, ты убежден, что адрес (любой адрес) - это просто число, номер ячейки памяти, независящее, что лежит по этому номеру. Резоны понятны. Однако: стандарт С++ утверждает, что это не обязательно так. Добавлено через 1 минуту и 29 секунд Абстрагируйся от железок. Ты ведь можешь написать компилятор С++ для виртуальной машины, где это не соблюдается, и все в строгом соответствии со стандартом. |
| Автор: MAKCim 21.3.2008, 11:21 | ||||||
да так оно и есть
1. что значит компилятор для виртуальной машины? 2. все будет соблюдаться пусть к примеру есть переменная типа int абстрагируемся от того, где она расположена но в любом случае она будет иметь некоторый адрес (опять же абстрагируемся от того, как представим этот адрес) я получаю этот адрес посредством & и присваиваю его переменной типа A*, где A - класс A* определяет адрес в результате присвоения переменная типа A* будет содержать другой адрес, нежели адрес переменной типа int? естественно, нет аналогично со ссылками в случае, если преобразование разрешается компилятором Добавлено через 4 минуты и 30 секунд
ошибаешься это так же С++ конструкция |
| Автор: korian 21.3.2008, 11:42 |
| MAKCim, рассуждать можно как угодно, а как оно есть на самом деле никто не знает. особенно то как оно будет. поэтому стандарты и придумывают. можно смотреть как оно работает и радоваться, а потом получать кучу проблем при переносе на другую платформу/операционку/компилятор. а можно изучать стандарт и писать код, в котором будешь уверен, что он будет работает на любой платформе/операционке, если на этой платформе/операционке есть компилятор C++ соответствующий стандартну. |
| Автор: MAKCim 21.3.2008, 11:45 |
| korian, попрошу конструктивно как моя логика теоретически может стать неправильной? господа, но это же очевидно если я пишу int a = 1234 int b = a то b - всегда и везде будет содержать 1234 аналогично int a = 1234 int * b = &a; A * c = (A*)b; c всегда будет содержать адрес a (если преобразование допустимо компилятором), несмотря на то, что c - другого типа |
| Автор: baldina 21.3.2008, 11:53 | ||||
http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F Например, MIX. Нетрудно придумать свою, где int и double лежат в принципиально разных областях памяти.
Необязательно. У тебя есть опыт, который говорит, что адреса одинаковые. Попробуй посмотреть со стороны. Мы знаем, что параллельные прямые не пересекаются и т.п. - тоже на основе опыта. Не упирайся, поразмышляй. На эту тему флеймить больше не буду. За убеждения получи плюс. |
| Автор: MAKCim 21.3.2008, 12:16 | ||
ну и пусть себе лежат никто их и не трогает пусть даже указатели лежат отдельно какой код должен быть сгенерирован для этого случая? A * c = (A*)b значение b - адрес оператор (A*) прибавляет к нему какое-то смещение? вопрос какое? если ему известно только значение b и его тип таблица отображений A <- offset -> int? т. е для каждого int создается параллельный объект A? извините, чушь во-первых, в этом нет никакого смысла во-вторых, нарушается семантика, т. к в результате преобразования я получу адрес какого-то неизвестного мне объекта неизвестно как созданного задавать таблицы отображения вручную? а какой в этом смысл, если они мне не нужны? и где про это в стандарте сказано? |
| Автор: UnrealMan 21.3.2008, 14:30 | ||||||||||||||
 Всё смешалось в одну кучу.
А подтверждение цитатами из стандарта можно?
Открою страшную тайну: в целом boost - это платформозависимая библиотека. Добавлено через 4 минуты и 33 секунды
Мдя...
Однако, вот незадача: соответствующим стандарту можно назвать, наверное, лишь Comeau. |
| Автор: korian 21.3.2008, 15:41 | ||||||||
ну расскажите принципиальную разницу в этих понятиях в данном контексте (прочитайте первый пост и вспомните о чем тут вообще речь)
-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, если взять платформу, у которой нету стандартного ввода/вывода.
и? |
| Автор: UnrealMan 21.3.2008, 17:11 | ||||||
Эта цитата неприменима к твоему примеру, т.к. у тебя не выполняется преобразование из 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 описания не требуется.
Соблюдая стандарт, нельзя быть уверенным в реальной переносимости программы. |
| Автор: JackYF 21.3.2008, 17:49 | ||||
Естественно. И в тему от фонаря написал :/
И? Твои предложения? |
| Автор: Alek86 21.3.2008, 18:41 | ||
делать как в бусте - #ifdef'ами... |
| Автор: JackYF 21.3.2008, 20:09 | ||
Правильно. Так и делают. Я не понял, к чему это было написано? Иделала нет. Так что, стандарт не соблюдать? |
| Автор: vinter 21.3.2008, 20:16 | ||
соблюдать, но понимать что на каком нить компиляторе это может не сработать. |
| Автор: Alek86 21.3.2008, 20:19 | ||
идеала в нашей жизни нету помойму, если какой-то нерастпространенный компилер будет еще и свои требования к коду предьявлять, то его заочно втопку (или пускай программисты, на нем работающие, подстраивают свои #ifdef'ы) |
| Автор: korian 25.3.2008, 09:16 | ||
+ вам за разьяснения... из всего выше сказанного получается, что, если платформа предпологает возможность перевода из T1* в T2*, то reinterpret_cast для такого перевода обязан быть реализован, т.к. reinterpret_cast - implementation-defined. а кастинг через void* из начально undefined и может работать не правильно и реализовываться не обязан. поэтому reinterpret_cast лучше при переводе не связанных типов. я правильно понял? по всему инету пишут, что reinterpret_cast хуже потому, что тупа копирует биты, но стандарт не оговаривает, что это должо быть именно так. |
| Автор: UnrealMan 25.3.2008, 16:29 | ||||
Я не могу быть на 100% уверенным, что я сам всё правильно понимаю. Стандарт C++ - штука хитрая, порой встречаешь описание чего-нибудь там, где совсем его не ожидаешь увидеть.
Возможно, существует какая-то платформа, где reinterpret_cast криво реализован, а двойной static_cast хорошо отрабатывает, откуда некоторыми людьми делаются выводы в пользу повсеместного применения последнего способа. Но каких-то предпосылок со стороны стандарта для применения такого трюка я не вижу. |
| Автор: JackYF 25.3.2008, 17:52 | ||
Ну дык и я про что |
