а какие такие 640к впаяны в материнку? первый раз слышу.
у меня когда-то был Acer Acros 486й, там 4 мега onboard были. но то брендовый системник, на обычных такого не практиковалось :)
в парсере все "классы" самого языка непосредственно "мапятся" на классы С++ в исходниках интерпретатора. таким образом, создавая на парсере, скажем, таблицу:
$sql_table[^table::sql{select * from news}]
мы, в конце концов, создаём экземпляр "настоящего ООП" С++ класса CTable. Соответственно все вызовы методов парсерного класса table приводят к вызовам соответствующих методов CTable.
С парсеровскими пользовательскими классами и классами-потомками чуть по-другому, но смысл тот же.
причём вовсе не обязательно писать в ООП стиле. для простых сайтов можно обойтись функциями (которые фактически становятся методами класса main)
я использую. см. первую строчку в тексте новости о выходе версии 3.2.2 ;)
парсер очень хорош для реализации любых сайтов со средней посещаемостью (т.е. которым достаточно мощностей одного сервера), разве что за исключением специфических применений, для которых в парсере просто нет нужных функций: сложная математика, доступ к "железу" и т.д.
достоиства парсера с моей точки зрения:
+ синтаксис, позволяющий встраиваться непосредственно в HTML, без необходимости всяких (правда, это одновременно и недостаток, в разнообразных скобочках можно и запутаться поначалу :)
+ формирование структуры страницы от крупного к мелкому без необходимости повторять структуру в каждом файле. Т.е. не надо в каждом .htm писать как в SSI и php всякие , достаточно просто определить изменяющиеся куски.
+ благодаря особой работе с внешними данными практически исключены атаки типа SQL Injection и иже с ними
+ благодаря самоограничению доступа уже не прочитаешь /etc/passwd, подсунув это имя вместо другого файла. Всякие ls, rm и прочие cat тоже не запустятся :)
+ удобный доступ к SQL методами каждого из классов "таблица", "хеш", "строка", "число"
вот. немного сумбурно. писать код у меня получается лучше :)
у меня когда-то был Acer Acros 486й, там 4 мега onboard были. но то брендовый системник, на обычных такого не практиковалось :)
$sql_table[^table::sql{select * from news}]
мы, в конце концов, создаём экземпляр "настоящего ООП" С++ класса CTable. Соответственно все вызовы методов парсерного класса table приводят к вызовам соответствующих методов CTable.
С парсеровскими пользовательскими классами и классами-потомками чуть по-другому, но смысл тот же.
причём вовсе не обязательно писать в ООП стиле. для простых сайтов можно обойтись функциями (которые фактически становятся методами класса main)
парсер очень хорош для реализации любых сайтов со средней посещаемостью (т.е. которым достаточно мощностей одного сервера), разве что за исключением специфических применений, для которых в парсере просто нет нужных функций: сложная математика, доступ к "железу" и т.д.
достоиства парсера с моей точки зрения:
+ синтаксис, позволяющий встраиваться непосредственно в HTML, без необходимости всяких (правда, это одновременно и недостаток, в разнообразных скобочках можно и запутаться поначалу :)
+ формирование структуры страницы от крупного к мелкому без необходимости повторять структуру в каждом файле. Т.е. не надо в каждом .htm писать как в SSI и php всякие , достаточно просто определить изменяющиеся куски.
+ благодаря особой работе с внешними данными практически исключены атаки типа SQL Injection и иже с ними
+ благодаря самоограничению доступа уже не прочитаешь /etc/passwd, подсунув это имя вместо другого файла. Всякие ls, rm и прочие cat тоже не запустятся :)
+ удобный доступ к SQL методами каждого из классов "таблица", "хеш", "строка", "число"
вот. немного сумбурно. писать код у меня получается лучше :)
http://images.fastcompany.com/blog/121503billboard.jpg
ибо младших школьников учат писать её вовсе не так, как она выглядит в шрифте Arial :)