jython-2.2

>он компилируется 2 раза.

Именно так. И в Java. Но с точки зрения языков программирования нас интересует только первый этап. Ибо второй касается уже не языка, а среды исполнения. Мы один и тот же бинарный код можем выполнить на живом процессоре, а можем - в виртуальной машине. Но язык не может поменять свою концепцию только от того, на чём будет исполняться конечный код. Ибо глупость :)

>термин "виртуальная машина" в области реализаций ЯП четко определился к началу 80-х и означал спецификацию абстрактной машины и программый _интерпретатор_ ее команд - до сих пор большинство виртуальных машин таковы.

Ещё раз. Что Вы скажете о Java-поцессорах?

А если я x86-программу, скомпилированную в C++ запущу в эмуляторе x86, от этого C++ превратится в интерпретатор?

>Зачем нужен еще один "скриптовый недоязычок" ((с) VSL), да еще на Java? Программирование ради программирования?

Программирование ради массовых практических задач.

> запомните, что интерпретатор - это транслятор, исполняющий исходную программу "с листа", читая голый текст токен за токеном и тут же её исполняющий.

Это относится только к древним простейшим интерпретаторам. Все более-менее продвинутые интерпретаторы переводят программу во внутреннее представление (которое может быть и байт-кодом, и шитым кодом) и интерпретируют уже его.

> Компилятор - это транслятор, сперва преобразующий текст программы во внутреннее представление, удобное для выполнения и исполняющий его уже во внутреннем, более быстром виде.

То есть компилятор _исполняет_ скомпилированные программы? Ну что тут скажешь... GCC - это и не компилятор никакой, так получается O_O

> Java никогда не была интепретатором.

Java - это вообще язык. Интерпретатором были первые версии JVM.

> А википедия - это тот ещё источник, ага :D

То есть ты не веришь, что в первых JVM не было JIT? Или что первые JVM были интерпретаторами?

> Ещё раз. Что Вы скажете о Java-поцессорах?

Их практически не существует. И речь не шла о них - речь шла о реализациях Java из Реального Мира (r) (tm).

> А если я x86-программу, скомпилированную в C++ запущу в эмуляторе x86, от этого C++ превратится в интерпретатор?

Нет. Но вот эмулятор x86 вполне может оказаться интерпретатором.

>То есть компилятор _исполняет_ скомпилированные программы?

Нечётко выразился, имелись в виду как раз трасляторы, сразу же и исполняющие программу. Каковых и сегодня полно. От Forth'а до PHP.

> Потому что Вы не знаете общепринятых определений компилятора и транслятора.

Крут, дяденька. Разъяснил детям академические термины, да. Только на этом уровне школьную информатику и я знаю.

А когда я называл JVM интерпретатором, я имел ввиду лишь то, что к моменту начала исполнения программы её целиком в машинных кодах не существует. И хотя формально я не прав (на что Вы очень доходчиво, хоть и чересчур... эмоционально, и указали), несмотря на все ухищрения Sun java-софт всё равно работает гораздо медленнее написанного на С. Неважно, относится ли это к монстрам вроде Эклипса, или к мелким апплетам, написанным "на коленке" за вечер. И я, как пользователь, стараюсь не использовать java-софт именно по этой причине. Терять, знаете ли, полчаса работы от аккумулятора из-за концептуальных вывертов отдельно взятого языка "ну очень высокого уровня" - не хочется.

>То есть ты не веришь, что в первых JVM не было JIT? Или что первые JVM были интерпретаторами?

JIT не было. JVM были интерпретаторами. Но JVM - это не язык программирования. А вот Java - была компилятором. Более того, она даже была компилятором в нативный код. Только не в код x86 :D

>Нет. Но вот эмулятор x86 вполне может оказаться интерпретатором.

Так мы про языки программирования говорим, а не про виртуальные машины. Не стоит путать Java и JVM на x86.

>Вы просто не знаете, что этот термин обозначает. Как тут уже кто-то говорил, в таком случае процессор - интерпретатор машинного кода.

Я прекрасно знаю что этот термин обозначает. И как тут уже кто-то сказал (если конкретно, то я) процессор действительно интерпретирует машинный код. Если это открытие для Вас - сочувствую

>В общем, рекомендую ознакомиться с терминологией перед тем, как бездумно её использовать. Не демонстрируйте так явно свою техническую безграмотность.

Вы считаете себя таким грамотным? А я вот не считаю количество зеленых звезд на лоре показателем грамотности

именно так и есть, только он харварный :)

>> Ещё раз. Что Вы скажете о Java-поцессорах?

>Их практически не существует.

Он практически существуют. Или для Вас не существует ничего, чтобы не вписывалось в Вашу модель мира? Но, видите ли, Java-процессоры от этого не исчезнут. И тогда получается, что по Вашей логике Java - это интепретатор, если оттранслированный ею когда-то код исполняется на JVM без JIT, или или компилятор, если работают JVM с JIT или Java-процессор. Не слишком ли шаткое определение типа языка, меняющееся при изменении столь далёких от процесса трансляции исходного кода условий?

Ещё раз, вот у мен Volcov Commander, написанный на Си и скомпилированный в x86-код. Я его исполняют в x86-эмуляторе на ARM-процессоре моего КПК. От этого Си превратился в интерпретатор? Это практическая, так сказать, задача. Могу скриншот приложить. Или опять то, что не вписывается в Вашу модель будет объявлено "практически не существующим"? :D

>Он там от рождения был, судя по всему. Ибо термины интерпретатор и компилятор получили своё наполнение намного раньше :)

Это сообщение было адресовано другому анонимусу, поэтому тут комментировать ничего не буду:)

>А когда я называл JVM интерпретатором

Я, ведь, задолбаю Вас тем, что, во-первых, Java != JVM, во-вторых тем, что есть процессоры, нативно исполняющие байткод Java. Так что же, Java становится то компилятором, то интерпретатором в зависимости от того, на чём будет потом исполняться байткод? Что у Вас с логикой и причинно-следствеными связями?

>В общем, вопрос таков - может ли кто-нибудь внятно, толково и без
>издёвки объяснить, зачем вообще один интерпретатор реализовывать поверх
>другого. Что это вообще даёт принципиально нового, чего нельзя получить
>другими способами?

Да просто все как велосипед. JAVA машина работает очень много где. Постарались люди. Потом JIT реализован очень не лохо. Ну и от сюда вытекает само собой, зачет писать десятки интерпретаторов змеюки, если можно написать один раз. Байт код на JABA выполняется весма быстро. Легегдвы про тормознутось JAVA существуют только на ЛОРе. Причем, анонимусам даже реальные примеры где JAVA обгоняет GCC за отмаз не катят. Уперлись лбом в столб и мычат...

>Я прекрасно знаю что этот термин обозначает. И как тут уже кто-то сказал (если конкретно, то я) процессор действительно интерпретирует машинный код. Если это открытие для Вас - сочувствую

То есть для Вас Си и Си++ - интепретаторы? Или Вы тоже путаете язык программирования и среду исполнения? Иногда они, действительно, совмещаются, но иногда - нет.

>А я вот не считаю количество зеленых звезд на лоре показателем грамотности

Я тоже :) Но грамотным я себя считаю не поэтому.

>Гы. Это в ЛОР-квотес нужно. Человек путает компиляцию и трансляцию в нативный код. Действительно, выросло Windows-поколение

В чем же дело, go to lorquotes. Трансляция в нативный код - это понятие более общее. Трансляция в свою очередь в самом широком смысле обычно разделяется на компиляцию и интерпретацию. Трансляция ВСЕГДА происходит в нативный код, ибо только его способен выполнить процессор. А заставить выполнить программу процессором - это и есть задача транслятора

>А мсье хоть когда-нибудь слышал про Java-процессоры, которые исполняют байткод Явы нативно? О сколько ещё его открытий ждёт... десяти- и двадцати-летней давности. А уже современные процессы просто взорвут его мозг :D

А мсье умеет читать? http://www.linux.org.ru/view-message.jsp?msgid=2107420&page=1#2108275 Сами прочитаете, о грамотный Вы наш?

> Это сообщение было адресовано другому анонимусу, поэтому тут комментировать ничего не буду:)

Вот уже не первый раз задумываюсь: а как вы их различаете? ;-)

>А что Вы смеетесь? >Потому что Вы не знаете общепринятых определений компилятора и транслятора.

Нет, Вы все-таки не умеете читать... Вопрос "А что Вы смеетесь?" был адресован человеку, впервые узнавшему, что на самом деле процессор машинные инструкции интерпретирует, а не исполняет "сразу". Хотя, судя по Вашим постам, для Вас это тоже новость

>В общем, если Вы никогда не занимались концепциями языков программирования, то запомните, что интерпретатор - это транслятор, исполняющий исходную программу "с листа", читая голый текст токен за токеном и тут же её исполняющий

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

>Трансляция ВСЕГДА происходит в нативный код

Не всегда. Трансляция Java-программы в байткод не приводит к появлению нативного кода.

Более того, даже если расширить определение, что _серия_ трансляций до момента исполнения программы порождает в итоге нативный код, то всё равно утверждение в общем случае будет неверным. Скажем, Форт-трансляторы в классический шитый код никогда не порождают нативный код. Или та же трансляция из qbasic или bash - тоже не породит нативного кода. Будет исполняться только уже имеющийся нативный код среды исполнения.

>А заставить выполнить программу процессором - это и есть задача транслятора

Да. Но это не обозначает "трансляцию в нативный код".

>А мсье умеет читать?

А кто в вас, анонизмусах разнокалиберных разберётся. Тем хуже для Вас. По-вашему, Java-транслятор, в зависимости от того, на чём будет исполняться байткод, становится то интерпретатором, то компилятором? Ну так я тогда также скажу, что и Си/Си++ - тоже интепретаторы. Поскольку их x86-код может исполняться в эмуляторах на иных платформах. Не нативно для них.

>Хотя, судя по Вашим постам, для Вас это тоже новость

Нет, знаете ли. Мне доводилось даже заниматься разработкой архитекутур процессоров. А с микрокодами процессоров познакомился 18 лет тому назад, за несколько лет до того, как впервые познакомился даже с 8086.

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

Да нет, этот сценарий работает в любых условиях и любых системах. В отличии от Ваших вариантов, по которым у нас одна и та же реализация языка то транслятор, то компилятор, и где даже GCC - интерпретатор в ряде условий работы конечной программы :D

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

> Именно так. И в Java. Но с точки зрения языков программирования нас интересует только первый этап. Ибо второй касается уже не языка, а среды исполнения. Мы один и тот же бинарный код можем выполнить на живом процессоре, а можем - в виртуальной машине. Но язык не может поменять свою концепцию только от того, на чём будет исполняться конечный код. Ибо глупость :)

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

>Не всегда. Трансляция Java-программы в байткод не приводит к появлению нативного кода.

Вот это номер :)) Мсье целый час трындел про хардварные Java-процессоры, а теперь говорит что байт-код Java не является нативным. Как же так? Для Java-процессоров (picoJava например) он является самым что есть нативным, родным и приятным сердцу:) Зарапотравались... И я в десятый раз повторяю, что я НЕ ОТРИЦАЛ НАЛИЧИЯ КОМПИЛЯТОРА в Java. Писал об этом уже столько раз, что устал уже. Применяется он на первом этапе, чтобы получить байт-код, и все.

>Да. Но это не обозначает "трансляцию в нативный код".

Именно это оно и означает

>причем странно это не знать человеку занимающегося фортом

Я Форт как раз и упоминал ранее. Почитайте, что я писал.

>Компилятор в Java есть, и если Вы все-таки умеете читать, то выше это было написано. Но применяется он только на начальном этапе, чтобы получить байт-код.

Так что это - компиляция или интепретация? :D

>Мсье целый час трындел про хардварные Java-процессоры, а теперь говорит что байт-код Java не является нативным. Как же так?

Так получается потому, что другой мсье не умеет читать. Даже собственные сообщения. Ибо там было написано "Трансляция ВСЕГДА происходит в нативный код". С выделением слова "ВСЕГДА".

Это во-первых.

Во-вторых, там даже про Java речь не шла.

> Далее этот байт-код либо интерпретируется виртуальной машиной,

Это было в Java1 на не-ява-процессорах, если мы правильно разобрались.

> Но компиляцией это назвать нельзя

Это вот интерпретацией - точно нельзя. А компиляцией - можно, только писать процесс целиком. Если байткод\CIL считать не машинным кодом, то (по русской терминологии) в жаве и цлр два процесса - трансляции в другой язык программирования и затем компиляция (то есть траснялция в машинный код) на лету.

Хотелось бы сделать уточнение.

По русскоязычной формальной терминологии, как я понимаю:

- транcляция - перевод с одного формального языка на другой

- компиляция - трансляция в язык машинных кодов какого-то процессора (например ява-процесора, ага? :)

По англоязычной и то, и то компиляция.

Я не ошибаюсь?

>Я, ведь, задолбаю Вас тем, что, во-первых, Java != JVM, во-вторых тем, что есть процессоры, нативно исполняющие байткод Java. Так что же, Java становится то компилятором, то интерпретатором в зависимости от того, на чём будет потом исполняться байткод? Что у Вас с логикой и причинно-следствеными связями?

Вы себя для начала задолбайте. Вы читали вообще предыдущие посты? Или просто выборочно выдираете фразы из контекста дабы показать какой Вы умный? Придется носом тыкать... Про "Java != JVM" и про "компилятор", я специально БОЛЬШИМИ БУКВАМИ ВЫДЕЛИЛ:

>Компилятор в java есть, с этим никто не спорит: это программа, транслирующая исходный текст на ЯЗЫКЕ ПРОГРАММИРОВАНИЯ JAVA (высоуровневый ООП-язык) в байт-код. Все, на этом работа компилятора закончена

> Я, ведь, задолбаю Вас тем, что, во-первых, Java != JVM, во-вторых тем, что есть процессоры, нативно исполняющие байткод Java.

Не задолбаете.

Во-первых, для меня, как пользователя, язык и среда исполнения неразделимы. То есть, говоря о С-программе, я подразумеваю, разумеется, бинарник для архитектуры и ОС, используемой в конкретном компьютере, поскольку все С-программы, встречавшиеся мне до сих пор, именно такие. А в случае с Java-программой - это некий jar, который непонятно как исполнять, без установленной в системе JVM.

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

полностью согласен с KRoN73 народ че-то путает сильно два понятия, которые вообще не пересекаются.. никто не мешает интерпретируемому языку компилировать :-) вот, например, python.. Язык интерпретируемый.. Что ему совершенно не мешает компилировать исходники в байт-код (py->pyc, pyc = pyCOMPILED)

>Так получается потому, что другой мсье не умеет читать. Даже собственные сообщения. Ибо там было написано "Трансляция ВСЕГДА происходит в нативный код". С выделением слова "ВСЕГДА".

Я умею читать, в отличие от Вас. Да, трансляция происходит ВСЕГДА в нативный код. Компилятор java генерирует НАТИВНЫЙ код для Java-процессора. НАТИВНЫЙ КОД - это код, который процессор способен непосредственно исполнить. Нативный код - это НЕ та система команд, которая используется на компьютере, на котором работает компилятор. Вы можете писать программы на машине c процессором Pentium под управлением Windows/Linux, под те же ARMы или какие-нибудь DSP. И что, генерируемый компилятором код не будет нативным? Как можно не понимать такие элементарные вещи?

> Легегдвы про тормознутось JAVA существуют только на ЛОРе. Причем, анонимусам даже реальные примеры где JAVA обгоняет GCC за отмаз не катят. Уперлись лбом в столб и мычат...

Да причём тут легенды? Мне по работе периодически приходится запускать java-софт. Делаю это с большой неохотой, ибо он по личным ощущениям гораздо медленнее аналогичного на С, а не по легендам. А уж на личной машине вообще такового не держу. Сколько ни пробовал, радости ноль.

>Как показало общение в этом топике, некоторые индивидумы элементарно путают компиляцию вообще с компиляцией в нативный код. Простейший контрпример я уже привёл - Java-байткод

Да, случай похоже клинический... Как я уже сказал постом выше, компиляция ВСЕГДА происходит в НАТИВНЫЙ код, иначе какой от этого компилятора толк. Просто Вы не понимаете, что же это такое НАТИВНЫЙ код. И если в компьютере стоит Pentium или Alpha, то этот факт не делает код, сгенеренный компилятором Java менее нативным

> А в случае с Java-программой - это некий jar, который непонятно как исполнять, без установленной в системе JVM.

gcc.gnu.org/java/

GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile Java source code to Java bytecode (class files) or directly to native machine code, and Java bytecode to native machine code.

> А во-вторых, java-процессоры - это такая экзотика...

Контроллеры с программами на асме - это такая экзотика....

>Во-первых, для меня, как пользователя, язык и среда исполнения неразделимы. То есть, говоря о С-программе, я подразумеваю, разумеется, бинарник для архитектуры и ОС, используемой в конкретном компьютере, поскольку все С-программы, встречавшиеся мне до сих пор, именно такие. А в случае с Java-программой - это некий jar, который непонятно как исполнять, без установленной в системе JVM.

Каким образом связаны среда исполнения и язык??????? Явная проблема с логикой и причинно-следственной связью..

Я вот взял, допустим программу на C скомпилировал ее под платформу x86. Чувствуете.. дальше уже не важно, что с ней я делаю? я ее уже скомпилировал.

Взял программу на Python, скомпилировал ее в байт-код (pyc-файл). Опять я взял и скомпилировал.

НО Python интерпретируемый язык, а C нет... в чем же между ними разница? Уж тоно не в возможности скомпилировать :-)))

Ну про "нативный" код тут уже много сказано было. для кого x86 и нативный, а кто его и под эмулятором выполняет.. (и поверьте не из праздного любопытства)

KRoN73 не позорься, язык не бывает интерпретируемым или компилируемым, это свойство _реализации_. Если ты не знал, то есть _интерпретатор_ языка С, как есть и компиляторы Scheme (наряду с интерпретаторами).

В приведенном тбой случае x86-эмуляторе на ARM-процессоре будет интерпретатором, как при исполнении x86 программ на x86 процессоре интерпретатором будет процессор.

> KRoN73 не позорься, язык не бывает интерпретируемым или компилируемым, это свойство _реализации_. Если ты не знал, то есть _интерпретатор_ языка С, как есть и компиляторы Scheme (наряду с интерпретаторами).

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

>хех.. посмотрел бы я на интерпретатор языка с++ (нормальный такой ++ с шаблонами), что-то в округе не видать...

В округе не видать, потому что это нахрен никому не надо. А если сильно захотеть - то можно

>В округе не видать, потому что это нахрен никому не надо. А если сильно захотеть - то можно


особенно интересно, как интерпретатор будет интерпретировать следующую конструкцию:

int f();
int main()
{
f();
}

Вам не приходило в голову, что некоторые вещи невозможно сделать, потому что они нивозможны? :-)

>Вам не приходило в голову, что некоторые вещи невозможно сделать, потому что они нивозможны? :-)

Я уже высказался на этот счет, но лично для Вас повторюсь:) KRoN73 предложил алгоритм работы интерпретатора в таком виде: берем исходный текст и "токен за токеном" последовательно, сразу же его исполняем. Я ему возразил, что таким макаром получится интерпретировать разве что последовательный участок на ассемблере. На что мне возразили и уверили, что усе работает:) Лично я предерживаюсь мнения, что интерпретаторы все же похитрее работают, особенно когда смотрю на какой-нибудь мудреный код на JavaScript

>> А во-вторых, java-процессоры - это такая экзотика...

>Контроллеры с программами на асме - это такая экзотика....

Даёшь контроллеры с программами на java массы! :-D

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

>Даёшь контроллеры с программами на java массы! :-D Только, боюсь, массовое быдлокодерство (в угоду ынтерпрайзу) лишь увеличит темпы потребления энергии без какой-либо реальной отдачи в производительности, это не может продолжаться вечно

Контроллеры java и так достаточно распространены. Хотел было рассказать о них кое-что, да передумал, когда прочитал вторую часть Вашего опуса. ЛОР есть ЛОР:(

>особенно интересно, как интерпретатор будет интерпретировать следующую конструкцию:

>int f(); >int main() >{ >f(); >}

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

Если ты пропустил предыдущее обсуждение: интерпретаторы Си и Си++ существуют, так что, выдавая такие детские подначки, ты сам себя выставляешь... ну ты понял.

>Флейм уже... см предыдущий пост, мы просто говорим о разных вещах, или,
>точнее, о разных уровнях одного и того же предмета. 1) я уточняю
>умозаключение: есть разница в том как запустить исходник в процесс
>преобразования его в результат исполнения. 2) я говорю именно об этой
>разнице - о разнице запуска интерпретируемого исходника и
>скомпилированного файла. 3) мои представления о самом процессе
>преобразования исходника в результат исполнения - действительно на
>уровне, но может быть не шестого класса, а скажем 10 :) Впрочем, об
>этом процессе мне большего знать и не надо, равно как и о том, почему
>нет жизни на марсе.

ИМХО недопонимание возникает немного на другом уровне.
Тот же gcc, компилятор, сначало преобразует исходные код в промежуточный
код и только потом уже в машинные инструкции. Так вот с Java, этот процесс
разделен. То есть по сути промежуточный код, это по аналогии тот же байткод.
А его преобразование в машинные инструкции происходит на этапе запуска.
Вот и вся разница.

С моей точки зрения разница интерпретатора и компилятора в том (в
обзем случае, так сказать грубо говоря), что интерпретатор выполняет
команды одну за одной (ну или небольшие блоки) переводя их на лету в
машинные инструкции, а компилятор сначало всю программу переводит в
машинный код и только потом исполняет. Надеюсь это хоть как то развеет
Ваши сомнения/недопонимания.

> Я уже высказался на этот счет, но лично для Вас повторюсь:) KRoN73 предложил алгоритм работы интерпретатора в таком виде: берем исходный текст и "токен за токеном" последовательно, сразу же его исполняем. Я ему возразил, что таким макаром получится интерпретировать разве что последовательный участок на ассемблере. На что мне возразили и уверили, что усе работает:) Лично я предерживаюсь мнения, что интерпретаторы все же похитрее работают, особенно когда смотрю на какой-нибудь мудреный код на JavaScript

Именно так (концептуально) интерпретатор и работает. Все остальное методы ускорения интерпретации. (например компилляция в байт-код питоном)

>>> Ещё раз. Что Вы скажете о Java-поцессорах?

>>Их практически не существует.

>Он практически существуют. Или для Вас не существует ничего, чтобы не вписывалось в Вашу модель мира?

Java(и Форт)-процессоры прекрасно вписываются в мою модель мира. И аппаратные реализации микроядер - тоже. Только занимают они все в этой модели место курьезов.

> Ещё раз, вот у мен Volcov Commander, написанный на Си и скомпилированный в x86-код. Я его исполняют в x86-эмуляторе на ARM-процессоре моего КПК. От этого Си превратился в интерпретатор?

Если ты не читал предыдущего поста - это не делает Си интерпретатором. Но твой эмулятор вполне может оказаться именно интерпретатором.

(ЕМНИП, программа называется Volkov Commander, через "k")

P.S. Замечательную фразу: "Компилятор - это транслятор, сперва преобразующий текст программы во внутреннее представление, удобное для выполнения и исполняющий его уже во внутреннем, более быстром виде" ты прокомментировать не желаешь, я правильно понял? :)

Да наш Великий Мегамозг куда-то экстренно пропал... А жаль, я от него тоже комментариев жду:(

>Есть 2 варианта: 1) интерпретатор скажет, что функция f не определена, если она действительно не определена в наборе файлов, переданных на интерпретацию; 2) если функция таки определена в другом файле, и интерпретатор знает, в каком - он просто выполнит ее.

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

>Если ты пропустил предыдущее обсуждение: интерпретаторы Си и Си++ существуют, так что, выдавая такие детские подначки, ты сам себя выставляешь... ну ты понял.

Прочитал... ссылку в студию! Есть интерпретаторы языка "похожего" на C (CSL, кажись) но интерпретатора C и уж тем более С++ не бывает. По простой причине! Потому что эти языки впринципе не интерпретируемые.