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

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


Это сообщение отредактировал(а) 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'ами...

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

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