MAKCim, позвольте узнать, когда  Вы проигрываете ход программы в голове (допустим нет дебагера под рукой), получаемый  "объектный код" близок к асмовскому?
т.е в представлении Вы оперируете больше асмовскими понятиями (в случаях когда речь идет типа : об объектах, ссылках и указателях) ?

Это сообщение отредактировал(а) mes - 26.12.2008, 13:29

тру программисты должны ассемблировать программу и эмулировать ее выполнение в уме
дизассемблировать и трассировать тоже в уме

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

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

тогда ИМХО тут желательно подправить :

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

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

Адрес не обязан быть реальным адресом в памяти.. Адрес это идентификатор в виртуальном адресном пространстве, а реализации которого фактически знает только компилятор.
а разный размер ?? никто же не удивляется что адреса far и near были разного размера  )) 


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

В том конкретном случае это не случайное совпадение.

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

В общем я думаю, что правильным ответом на вопрос топикстартера будет нечто вроде: "Физический смысл указателя и ссылки известен только разработчикам конкретного компилятора. И не исключено, что физического смысла может не быть вообще как такового. Однако на момент 26 декабря 2008 года в наиболее распространенных компиляторах C++ физические смыслы указателей и ссылок такие-то. Разница в реализацииях на разных платформах и компиляторах такая-то."

  

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

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

Это сообщение отредактировал(а) UnrealMan - 26.12.2008, 15:55

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

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



Это сообщение отредактировал(а) mes - 26.12.2008, 16:52

Ни у кого случаем нет примера как как из указателя на функцию-член класса получить:
1. Адрес  объекта
2. Настоящий адрес метода (метод не статик, но компилятор не дурак, чтобы копировать код метода для каждого объекта, по сути код метода  единый для всех).

1. Указатель не хранит адрес объекта, поэтому при вызове метода, обязательно указывать объект для которого идет вызов
2. Зависит от компилятора и типа метода. (то что в скобках в цитате не понял)

вот пример для вызова метода как обычной функции:

Модератор: особо флеймовая часть темы перенесена сюда

Я прекрасно знаю, что такое язык Ассемблера - с 2001 года это основной источник моего дохода.
Мне вот не очень понятно, почему jmp может быть в нескольких вариантах (абсолютный и относительный), а загрузка в регистр должна иметь несколько названий в зависимости от набора параметров? На мой взгляд, как раз jmp должен иметь каждый свое имя (ну если мне позарез нужен относительный в данном месте, а абсолютный не приемлим!).
В этом плане мне больше нравится подход создателей процессора Z80. Там все команды загрузки называются LD (от load) - в независимости от машинного кода (коды от 1 [например: LD A,B] до 4 байт [например: LD (IX+4),5]), а переходы называются JR (относительный - Jump Relative) и JP (абсолютный - JumP), условия перехода задаются с помощью первого параметра, поэтому не надо в памяти держать миллион мнемоник как в x86 (JA, JAE, JB, JBE, JC, JCXZ, JE, JG, JGE, JL, JLE, JNA, JNAE, JNB, JNBE, JNC, JNE, JNG, JNGE, JNL, JNLE, JNO, JNP, JNS, JNZ, JO, JP, JPE, JPO, JS, JZ), а достаточно знать ряд базовых условий (Z, C, NZ, NC, PO, PE, M, P).

bsa, может я действительно не разбираюсь в асме, но в нем нету варианта jmp с переходом по абсолютному смещению
есть jmp rel8, jmp rel32(16), jmp r/m32(16), но jmp imm32(16) нету
есть правда jmpf ptr16:32(16) но его нельзя сравнивать с jmp rel32

я рад за Z80, кроме него есть еще много МП и МК, есть еще и виртуальные машины, но применительно к IA-32, lea это lea, а mov это mov

Цитата из документации, стр. 3-333:Кстати, хочу обратить внимание на разные машинные коды, соответствующие одной и той же мнемонике.

bsa, я написал то же самое. Посмотрите любую другую инструкцию, в зависимости от адресации операндов у нее будут разные опкоды, есть много опкодов с мнемоникой MOV и много опкодов с мнемоникой LEA, однако LEA это LEA а MOV это MOV, поэтому LEA r32,[r32+r32] это не MOV r32, r32+r32