Эта тема на forum.dklab.ru


Xoce:
Значит все-таки интерпритатор, а не компилятор и интерпритатор? :)
Дмитрий Котеров:
Вначале надо разобраться, что означают оба эти слова. А уж потом - спрашивать.
Xoce:
Это точно. Я до сих пор не понимаю...
Подскажите, если знаете, где про это можно почитать?

ЗЫ. Я Вашу книжку в этом месте несколько раз читал, но так ничего не понял. Может другими словани доступнее будет..? :) Извиняюсь за оффтопик.
_
Дмитрий Котеров:
Обо всем можно прочитать в Яндексе и Гугле (о чем я Вам по ICQ и сказал несколько недель назад — видимо, впустую). А про книгу не надо ничего говорить: месяц назад я как раз эти главы редактировал, и там столько про интерпретацию написано, что мало не покажется. Вы просто невнимательно читаете, по-моему (а может, просто лень перечитать эту главу).
Xoce:
Все понял - буду тыкаться самостоятельно. Одно правда не понятно - откуда Вы знаете номер моей аськи? Может Вы со мной и переписывались, но я с Вами точно - нет, я бы запомнил - поверьте! :)
Дмитрий Котеров:
Одно правда не понятно - откуда Вы знаете номер моей аськи?
Ну, наверное, я обознался. Был просто один товарищ, который по аське все донимал насчет интерпретаторов в очень похожей манере. Я подумал, что двух таких людей быть не может, поэтому решил попасть пальцем в небо. (-;

Если Вы — это не он, тогда, может быть, скажете, что же именно не понятно в книге?
Xoce:
наверное, я обознался
Эт точно :) Если я Вас донял - извиняюсь, совсем не хотел этого...
что же именно не понятно в книге?
Я новичок. Вообще никогда не прогромировал. Сложно было понять мудреные слова типа компилятор, транслятор, интерпритатор, причем все в перемешку, да еще в сравнении с другими языками.
Теперь, когда я самую малось начал что-то в самостоятельном порядке делать(даже собственную функцию придумал и написал самостоятельно! :)) уже значительно все легче начал усваивать - думать начал как работает программа. Вы меня тыкнули в веб я туда и пошел, а что делать..? Нашел вот эту тему http://phpclub.ru/talk/showthread.php?s=1a1b29f1520f8f086eb53e229baaf756&threadid=29904&highlight=%EA%EE%EC%EF%E8%EB%FF%F2%EE%F0 , почитал и понял, что PHP - интерпритатор. Так должен думать человек, который что-то делает на PHP. А в качестве развития кругозора, человек еще может знать(совсем не в обязательном порядке), что для ускорения выполнения програм на PHP, разработчики этого языка придумали некий механизм, который позволяет добиться приемлемого быстродействия, достаточного для, того чтобы быть достаточно конкурентно способным по сравнению с другими распространеными языками для веба. Так вот этот механизм основан на промежуточной компиляции исходного PHP-кода в байт-код, который как раз и позволяет добиться желаемого результата, за счет, того, что этот байт-код на порядки быстрее может быть выполнен.
Я конечно в объяснении механизма был не доконца точен, но суть от этого не меняется - знать это нужно только по стольку - по скольку. В практике нужно знать, что переменные и функции нужно сначала объявлять и присваивать, а потом использовать, иначе программа интерпритатор просто не будет знать где ему взять то, чего от него требуют.
_
Дмитрий Котеров:
Если я Вас донял - извиняюсь, совсем не хотел этого...
Да Вы-то как раз не доняли. (-; Тот товарищ донимал. А потом, если мне не изменяет память, начал сильно хамить, так что я его поставил в игнор. (-; (Кстати,е сли я Вам что-то сказал излишне резкое тут, прошу простить — я сгоряча.)

Я раз, что Вы нашли тот топик, там все очень хорошо рассказано. Даже ссылка на мою книгу есть. (-;

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

Интерпретатор или компилятор?

Возможно, вы уже слышали, что PHP версий 4 и 5, в отличие от своих пред-шественников, является компилятором. Так вот, это не совсем так. Во избе-жание разногласий в терминах давайте определимся, что мы будем называть компилятором, а что — интерпретатором. Если быть до конца откровенными, компиляторами очень часто и незаслуженно называют программы, которые на самом-то деле являются интерпретирующими трансляторами, т. е., по своей главной функции — интерпретаторами. Так обстоит дело и с PHP версий 4 и 5.

Транслятор — программа, которая переводит код с одного "языка" на другой. Например, утилита, преобразующая исходный Паскаль-код на Си, — транслятор. В общем понимании любой компилятор — это транслятор, конвертирующий код программы на языке высокого уровня в машинный код. Интерпретатор же — утилита, которая просматривает код некоторой программы и выполняет одну ее инструкцию за другой, т. е. полностью контролирует процесс исполнения.

Давайте посмотрим, как работает PHP. Получая на свой вход исходный код программы, он в первую очередь анализирует его (в частности, проверяет синтаксис) и транслирует в особое внутреннее представление. Оно пред-ставляет собой специальный «байт-код», который, конечно, невозможно про-читать глазами, но с которым в дальнейшем проще всего будет оперировать PHP. Вот эту-то фазу чаще всего и называют ошибочно компиляцией. Далее, PHP исполняет (интерпретирует) полученный байт-код. В этот момент он представляет собой классический интерпретатор.

Итак, мы видим, что PHP составлен из двух почти независимых блоков — транслятора и интерпретатора. Зачем же понадобилось так делать? Конечно, из соображений быстродействия. Посудите сами: синтаксический разбор осу-ществляется всего один раз на этапе трансляции, а исполняется уже "полу-фабрикат" — байт-код, который гораздо более удобен для этих целей.

Пусть, например, в программе есть цикл с большим числом итераций. PHP версии 3, в котором отсутствует фаза трансляции, вынужден перед исполне-нием очередной итерации заново анализировать ее код, проводить строковый разбор, проверку синтаксиса и т. д. В то же время, PHP старших версий дела-ет это только один раз (при трансляции кода программы), и на каждой итера-ции цикла занимается лишь исполнением готового байт-кода. Выигрыш оче-виден, не правда ли?

Язык Perl, который практически всегда называют компилятором, работает точно по та-кой же схеме — он транслирует текст программы во внутреннее представление, а затем использует результирующий код при исполнении. Так что, можно сказать, PHP пред-ставляет собой компилятор ровно настолько, насколько им является Perl.

Впрочем, описанная только что схема работы PHP не совсем соответствует действительности. Дело в том, что в языке можно создавать конструкции, ко-торые просто физически невозможно перевести во внутреннее представление во время фазы трансляции (к таковым, например, относится инструкция вклю-чения в программу кода внешнего файла, имя которого выясняется только на этапе исполнения программы — к примеру, вводится пользователем). В этом случае PHP просто пропускает их, "откладывая на потом", и транслирует, как только до них дойдет управление. Конечно, это несколько замедляет выпол-нение программы, но если подобных конструкций в ней немного (и они не вставлены в цикл с большим количеством итераций), замедление не так уж и существенно.
Как вы видите, PHP версий 4 и 5 коренным образом отличается от своего предшественника — PHP версии 3. Фактически, весь код программы в оче-редной раз был переписан заново. При этом возникла серьезная проблема с переносимостью программ: не так-то легко обеспечить совместимость класси-ческого интерпретатора с новым транслирующим блоком (вообще, транслято-ры по своей природе ограничивают свободу действий, зато привносят быст-родействие). Тем не менее, разработчики PHP блестяще справились с проблемой: практически любая программа, работающая на PHP версии 3 и не использующая недокументированных возможностей языка, будет работать и на старших версиях.

Что же такое PHP? Как мы выяснили, уж точно не компилятор, т. к. не имеет ни малейшего отношения к машинному коду. И, конечно же, не транслятор в чис-том виде — ведь оттранслированный байт-код нельзя ни сохранить в файле, ни использовать повторно. В то же время, главной фазой работы PHP является интерпретация внутреннего представления программы и ее исполнение. Имен-но эта фаза и занимает больше всего времени в серьезных сценариях. Итак, мы вынуждены заключить, что PHP является интерпретатором с встроенным бло-ком трансляции, оптимизирующим ход интерпретации.

Множество читателей, возможно, не согласятся с такой формулировкой. Конечно, слово "компилятор" звучит солиднее, чем какой-то там "интерпретирующий транслятор". Но все дело в том, что английское слово compiler переводится не только как "компилятор", но также и как "транслятор". Задумайтесь над этим, если окончательно решили для себя счи-тать PHP и Perl компиляторами.

Достоинства и недостатки интерпретатора

Если вы — бывший системщик или прикладной программист и не знакомы с языком Perl, довольно непросто будет привыкнуть к тому, что PHP, как и большинство языков для Web, является интерпретатором (правда, как мы уже говорили, с транслирующим оптимизатором).

Что ж, это так. Да, сценарии, написанные на PHP, работают в тысячи раз мед-леннее, чем Си-программы (но почти с такой же скоростью, как созданные на Perl — может быть, отстают максимум в несколько раз на особо критических участках), и к этому придется привыкнуть. Например, если мы напишем на Си пустой цикл с миллионом итераций примерно такого вида:
for(long i=0; i<1000000; i++);
то он будет работать всего долю секунды, в то время как аналогичный цикл на PHP:
for($i=0; $i<1000000; $i++);
проработает на эталонном процессоре Pentium 100 несколько секунд.

Приведенные оценки, особенно сравнения с Perl, касаются только PHP версий 4 и 5, но не версии 3. Последний отстает даже от Perl по быстродействию почти в 100 раз. Так что стоит задуматься, допустимо ли вообще применять PHP версии 3 при написании нетривиальных программ.

Однако для сценариев, не содержащих в себе громадных циклов (а таких про-грамм, как мы вскоре увидим, большинство), время работы будет отличаться очень несущественно. Ну, в самом деле, какая разница, работает ли сценарий 0,01 секунды или 0,1 секунды, если передача данных по каналам Интернета через модем будет длиться, например, 5 секунд?

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

В этом случае придется просто отказаться от PHP и перейти на более быстрый (но и более сложный) язык — например, Си или Java.

Интерпретатор и компилятор

У интерпретатора есть и другие преимущества перед классическим компиля-тором, например, перед Си. Вот некоторые из них.
r Упрощается обнаружение ошибок во время выполнения программы.
В случае сбоя интерпретатор сразу же выведет сообщение, что именно и где произошло не так.
r Можно не заботиться об освобождении выделенной памяти. Интерпрета-тор сам определит, когда та или иная переменная в программе уже не ис-пользуется, и освободит память, выделенную для нее.
r Существует возможность написать программу, которая, грубо говоря, будет формировать и тут же исполнять другую программу, что очень часто прак-тикуется при шаблонной системе организации скриптов. В частности, мы можем формировать идентификаторы во время исполнения программы, создавать массивы анонимных функций и т. д.
r Не нужно думать о типах переменных (как это, кстати, было сделано в при-веденном цикле for). Мы еще вернемся к данному вопросу в дальнейшем.

Есть и другие достоинства. Вообще, использование интерпретатора способно дать сценариям ту мощь, которую пользователи Web от них и ожидают.

Но за все нужно платить: эта пресловутая медлительность интерпретаторов, даже с блоком трансляции, способна вывести из себя самого закаленного программиста. Проигрыш особенно заметен в случае больших и сложных цик-лов, при обработке большого количества строк и т. д. Однако, заметьте, это единственный недостаток PHP, который будет все меньше и меньше прояв-ляться по мере выхода более мощных процессоров, чтобы в конце концов вообще сойти на нет.

PHP версии 5

До сих пор мы в основном подчеркивали различия между PHP версий 3 и 4. Это объ-ясняется тем, что они отличаются друг от друга значительно сильнее, чем PHP версий 4 и 5.

Что хорошего можно сказать о пятой версии? Конечно, прежде всего, еще немного возросла скорость работы. Этим мы обязаны переходу на новое ядро системы — Zend Engine 2. Но главная причина смены номера версии с 4 на 5 — это существенное улучшение объектно-ориентированных возможностей PHP и встраивание в ядро ин-терпретатора двух мощных библиотек: СУБД sqLite (в данной книге не рассматрива-ется) и модуля для работы с XML (ей посвящены две части книги).

PHP версии 5 совместим с PHP4 значительно лучше, чем PHP4 с PHP3. Это значит, что программы, разрабатывающиеся в расчете на PHP версии 4, с высокой вероятно-стью заработают на PHP5 без всяких изменений. Единственный возможный камень преткновения — это изменение механизма работы ссылок на объекты. Мы обязатель-но остановимся на этом вопросе в главе, посвященной объектно-ориентированному программированию.

В общем, с точки зрения внутренней архитектуры PHP4 отличается от PHP5 доста-точно слабо.
Ant:
Приведу тут небольшую выдержку из новой книги.
Блин, классно написано! Читается на одном... (-:
Уже хочу эту книгу.
Xoce:
PHP составлен из двух почти независимых блоков — транслятора и интерпретатора
Язык Perl, который практически всегда называют компилятором, работает точно по та-кой же схеме — он транслирует текст программы во внутреннее представление, а затем использует результирующий код при исполнении. Так что, можно сказать, PHP пред-ставляет собой компилятор ровно настолько, насколько им является Perl.
Впрочем, описанная только что схема работы PHP не совсем соответствует действительности
Что же такое PHP? Как мы выяснили, уж точно не компилятор
И, конечно же, не транслятор в чис-том виде
и в заключение, что б до костей :)
Что же такое PHP? Как мы выяснили, уж точно не компилятор, т. к. не имеет ни малейшего отношения к машинному коду. И, конечно же, не транслятор в чис-том виде — ведь оттранслированный байт-код нельзя ни сохранить в файле, ни использовать повторно. В то же время, главной фазой работы PHP является интерпретация внутреннего представления программы и ее исполнение. Имен-но эта фаза и занимает больше всего времени в серьезных сценариях. Итак, мы вынуждены заключить, что PHP является интерпретатором с встроенным бло-ком трансляции, оптимизирующим ход интерпретации.

Я извиняюсь что столько много цитат, но я их вынес вот почему. Как известно, человек при прочтении текста, который ему надо было бы запомнить, выхватывает определенные куски, на которые обращает особое внимание - их и запоминает, как ключевые моменты. Цитаты которые я привел запомнились лично мне. Так вот, если сумарно сложить все эти цитаты, у меня не осталось общего понимания, т.е. какая основная была мысль? Я понял то, что все очень запутано, и непонятно. Вот то что я вынес из первой части.
Конечно, Вы оговариваетесь, что книга не для новичков, однако. На мой взгляд, закончить все рассуждения нужно четкой и понятной фразой, типа:
на практике относитесь к PHP как к интерпритатору, т.е. все ваши программы будут выполняться построчно, таким образом Вы никогда не допустите ошибку и будете правильно понимать выполнение ваших программ с точки зрения компьютера.
Наверно эта фраза для тех кто не умеет програмировать вообще, но она концентрирует главное, что должен вынести человек собирающийся писать на PHP, и потом - раз Вас интересует мое мнение, то это мнение новичка(для которого не предназначена эта книга :))
Вот и все что я могу рассказать об этом (с)Форест Гамп :)

Кстати, если Вам интересно, то примерно такое же ощущение у меня осталось и от понятий про ООП. Скорее всего Ваша книжка вообще ни при каких обстоятельствах не притендует на объяснение ООП, но может Вы знаете где про это можно почитать и достаточно просто усвоить?
Просто я во всех книжках, которые пытался читать, видел примерно следующее: Это ООП. Оно делеется вот так. А что, почему, как про это нужно думать, чтобы легко понимать... не ясно. Не обижайтесь, пожалуйста, когда я говорю, где об этом можно почитать, просто на самом деле иногда очень помогает, когда рассказывают все тоже самое, но другими словами. Лично для меня так.
_
Дмитрий Котеров:
Спасибо за ценные замечания. Попробую этот кусок перекомпоновать немного.

Что касается ООП. Вот как раз сейчас я пишу эту часть и пытаюсь разъяснять, _для чего_, а не -как_. Не знаю. насколько хорошо получается. Посмотрим.

Единственный способ разобраться с ООП - это писать. писать и еще раз писать программы. Вначале - много писать без ООП, чтобы выявидись основные неудобства "простого" программирлования. И уж только потом - начинать читать про ООП. Не очень даже важно, что именно - я, честно говоря, не видел хороших книг, касающихся ООП. Сам я разбирался по тонюсенькой брошюрке, прочитал ее, наверное, раз 10, прежде чем до конца разобрался, что е хотел сказать автор (как сейчас помню, самое сложное - это виртуальные базовые классы; я из-за них, помнится, нарисовал на книжке мишень и расстрелял ее, до сих пор лежит вся в дырках). Практика и еще раз практика. Без этого ООП немыслимо - мне так кажется. Можно почитать большой труд Страуструмпа - но там только о С++. Можно (и, наверное, даже лучше всего) - по Java (и, если уже вышли книги по С№, то по C#).
Александр Мон-ский:
какое именно место в ней вызывает сложности
Захотелось и мне добавить свое личное мнение. (Я тоже без особого опыта программрования не только на РНР...)
Текст воспринялся и переварился. Все в общем-то понятно. Описано доступным языком, легко и просто. Да и вопросов к написанному не осталось. Просто мне потребовалось приложить некоторые усилия, что ли... Не знаю как обяснить свое внутреннее ощущение от прочитанного, но мне кажется, что то ли акценты в тексте расставлены как-то не так, то ли текста много, то ли незнакомые понятия (компилятор, транслятор, интерпретатор) употребляются чаще, чтобы состояние легкости и доступности текста осталось полным...

Не понятно?

По другому попробую так сказать. Представте, что Вы иностранец (для примера лучше, если какой-нибудь араб, для которого не свойственна славянская речь) и Вас познакомили с тремя русскими девушками. Их имена: Саша, Даша и Маша. Они разные - это понятно всем, в том числе и Вам. Но для Вас русская речь не является привычной (хоть Вы и обладаете опред. словарным запасом и даже умеете строить фразы и предложения), поэтому эти разные имена для Вас почти одинаковые на слух. Вы больше сейчас услышали звук (!) этих имен, чем поняли различия между этими словами. В общем, чтобы различать этих девушек вам придется прикладывать усилия. Слишком легко оперировать этими именами у Вас не получится - придется приложить усилия.

Хм... Не знаю смог ли я донести до Вас, то, что именно я (!) почувствовал при прочтении.

Компилятор. Транслятор. Интерпретатор.

Та частота и легкость с которой Вы оперируете этими понятиями не соответствовала моей готовности их воспринимать.

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

Благодарю за внимание :-)
Дмитрий Котеров:
Выделено из темы «Можно ли вот так схитрить?»,
расположенной в форуме Программирование::PHP::Все в кучу (24 Апреля 2004, 02:58).
Дмитрий Котеров:
Ну а если вот так? Что скажете?
Xoce:
ИМХО.
Мне так больше нравиться, хотя я уже в теме, поэтому сужу о написаном сквозь свое восприятие.
В качестве рецензента могу отметить некоторые нюансы :)
Первые два абзаца делают завязку, т.е. они показывают, что ситуация запутанная и не простая. Потом Вы вводите
"Ляторы" и "аторы"quote]
Идея названия понятна, но не говорит главного. А главное это понять смысл основных понятий. Поэтому я бы назвал эту часть Термины или Основные термины. Потому, что в правильном понимании темы заключается правильное понимание как раз трех основных терминов, т.е. это азбука - запомнил эти буквы, значит узнаешь их в любом шрифте.

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

ЗЫ. Я конечно не писатель и книжки писать не умею, но думаю, что если Вы введете некоторый сюжет в свою книгу, то она должна по идее легче читаться, потому, что будет появляться интуитивное желание узнать чтоже там будет дальше. Хотя Вы наверное и без меня это знаете и стараетесь так делать :)
_
Евгений Галашин:
Xoce:
Машинный код и байт-код — это разные вещи...
Xoce:
Евгений Галашин:
В тексте этого не оговоривается явно. Или я не правильно, что-то понял... В любом случае не описано чем байт-кот отличается от машинного кода.
_
Дмитрий Котеров:
Хм... Понятно, спасибо, поправлю. Сколько ж раз этот кусок придется править... (-: А в книге, кстати, есть и горазхдо более сложные (и более важные) места.
Ant:
Так выкладывай их сюда — будем читать.
Дмитрий Котеров:
Я и так зашиваюсь, а если еще начать во всех возможных местах править, получится вообще - "каждую пятилетку - по книге". (-:
Xoce:
Это, наверное, как PHP с открытыми кодами - все могут книжку купить и прочитать, а потом автору написать об неточностях и нюансах, чтобы сначала вышла книжка "Самоучитель PHP4" версии 1.2, потом 1.3, ... :)
_
Дмитрий Котеров:
Основные термины
Да будет так. (-;

На мой взгляд нужно при первом(кстати и последнем ) упоминании понятия "машинный код" в скобачках поставить "(байт-код)"
Добавлены детальные разъяснения, что это не одно и то же.
Ramzes:
Транслятор - Программа переводящая из одного представление в другое. Слово транслятор произошло от слова translate - переводить, делать перевод(о языках). Например PHP транслирует php-cкрипт в байт-код, в такой вид, где вместо, например, слова for стоит число 1, а вместо функции explode, он ставит, к примеру, 42. Такой вид намного проще исполнять компилятору, но намного сложнее писать человеку(это понятно, проще написать for чем помнить какой числовой код у for и писать число). Я обьяснил сейчас очень грубо, на самом деле может быть и не так, но принцип именно такой.

Компилятор - программа, транслирующая код который написал программист, в машинный код, т.е. в язык чисел - язык процессора. Машинный код исполняется с молниеносной скоростью. Процессор оперирует только числами, целыми числами... У него есть простейшие комманды, он их исполняет. Компилятор превращает сложные структуры кода высокого уровня, в элементарные инструкции процессора.

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

Я посторался обьяснить как можно лучше. Думаю после прочтения вопросы должны пропасть.
†berkut†:
<?php
$a = "Hello";
$b = "World";
echo $a;
echo $b;
?>

Этот код транслируется в следующий набор внутренних инструкций:

0 FETCH_W $0, 'a'
1 ASSIGN $0, 'Hello'
2 FETCH_W $72, 'b'
3 ASSIGN $72, 'World'
4 FETCH_R $144, 'a'
5 ECHO $144
6 FETCH_R $180, 'b'
7 ECHO $180
8 RETURN 1

phpclub.ru
Дмитрий Котеров:
Вставить, что ли, в книгу...
Xoce:
Ramzes:
Да, это объяснение что надо!
_
Евгений Галашин:
и еще очень много дополнительных вспомогательных действий, которые потом исполняются...
Не согласен. Токенайзер — он и в Бейсике токенайзер.
Юрий Насретдинов:
Не согласен. Токенайзер — он и в Бейсике токенайзер.
Токенайзер-токенайзером, но исполняет он код построчно, по крайней мере бейсик (у него как раз это хорошо получается, у него вместо точки с запятой ставится \n)
Евгений Галашин:
yUAC:
Это — да. я не согласен с том, чтоЗдесь все получается намного сложнее.
Не настолько уж сложнее...
Anonymous:
Вставить, что ли, в книгу...
Был бы рад =)
Anonymous:
Евгений Галашин:
Токенайзер это только малая часть процесса распознавания... Поверь... Я однажды пытался написать интерпретатор....
Дмитрий Котеров:
http://www.antlr.org — программа для упрощения написания компиляторов.
Дмитрий Котеров:
точнее, трансляторов (-;
bæv:
точнее, трансляторов

Ещё точнее, и тех и других и ещё -- "рекогнайзеров" ("анализатор кода"?):

framework for constructing recognizers, compilers, and translators
Rumata:
Компиляторы, трансляторы, интерпретаторы...

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

В общем понимании любой компилятор — это транслятор

фраза компилирующий интерпретатор соответствует сути PHP - исходный текст программы транслируется в промежуточный машинный код (байт-код или p-код), которое быстрее исполняется за счет того, что 1) каждая инструкция программы имеет внутренеее представление; 2) все инструкции не требуют повторной трансляции (например, в циклах)

в отличие от PHP, например, чистый бейсик - интерпретатор, каждая инструкция которого транслируется в машинный код
Xoce:
Ну теперь наверное уже со всех сторон все рассмотрено.. :)

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

Знаю, что существуют программы как раз реализующие эту идею, но самый рекомендуемый из них - Zend Accelerator. Однако он стоит порядка 450 кредитов... это, на мой взгляд, достаточно дофига(извиняюсь за жаргон). Как Вы думаете на этой теме разработчики PHP решили заработать? Почему настолько большая цена за вполне логичную опцию?
_
Дмитрий Котеров:
разработчики PHP не придумали возможности создания откомпилированных скриптов?
Почему же, очень даже придумали — Zend Encoder и Zend Optimizer называется. По сравнению с плачевной ситуацией в Perl там все очень неплохо. Платны они только для промышленного применения, и только — функция кодирования. Декодирование бесплатно и установлено почти у всех хостеров (у нас, например). Кроме того, никто ведь не мешает воспользоваться крэком. Так что тут все в порядке.
Rumata:
по вопросам этой темы http://kulichki.com/kit/ - старый, но актуальный в плане теории
Евгений Галашин:
Xoce:
есть ещё и http://turck-mmcache.sourceforge.net/ GPL'ный.
Maus:
Ветка выделена в отдельную тему «можно ли сделать standalone-приложение на PHP»,
расположенную в форуме Разное :: PHP (28 Декабря 2007, 23:59).
Гавриленко Дмитрий:
Извените если не по теме! Я обращаюсь к Вам Дмитрий, я не так давно начал изучать php, всего 3 дня назад и начал с четвертой части. Вот строки из вашей книги где начались мои затруднения-
Пример CGI-сценария
Настало время привести небольшой сценарий на Си, который иллюстрирует некото-
рые возможности, которые были описаны выше (листинг 3.1).
Листинг 3.1. Простейший сценарий script.c
#include <time.h> // Нужна для инициализации функции rand()
#include <stdio.h> // Включаем поддержку функций ввода/вывода
#include <stdlib.h> // А это — для поддержки функции rand()
// Главная функция. Именно она и запускается при старте сценария.
void main(void) {
// инициализируем генератор случайных чисел
int Num; time_t t; srand(time(&t));
// в Num записывается случайное число от 0 до 9
Num = rand()%10;
// далее выводим заголовки ответа. Тип — html-документ
printf("Content-type: text/html\n");
// запрет кэширования
printf("Pragma: no-cache\n");
// пустой заголовок
printf("\n");
// выводим текст документа — его мы увидим в браузере
printf("<html><body>");
printf("<h1>Здравствуйте!</h1>");
printf("Случайное число в диапазоне 0-9: %d",Num);
printf("</body></html>");
}
Исходный текст можно откомпилировать и поместить в каталог с CGI-сценариями на
сервере.
Как я понял, надо создавать файл script.c и ввести в него то что я написал выше, а после ввода откопилировать. Вопрос- как ооткомпилировать его? Если не ошибаюсь, до этогов книге не чего о компиряторах указанно не было!
dimagolov:
Гавриленко Дмитрий, Ваш вопрос никоим образом не связан ни с PHP вообще, ни с данным форумом и данной темой в частности. Это вопрос о программировании на C. В свою очередь, язык C требует компиляции в платформенно-зависимые исполняемые файлы при помощи специфических для данной платформы компиляторов и линкеров.

Кроме того, надо заметить, сто создавать CGI сценарии Вам никогда не придется, так что этот момент можно и пропустить. Для веб-программирования придумали гораздо более удобные средства, тот же PHP, к примеру.
Гавриленко Дмитрий:
Спасибо Вам большое за то что решили мою проблему в изучение php.

Эта тема на forum.dklab.ru