<!--toc--> |
|
####Вы сумасшедший или мазохист? |
|
Насколько мне известно — нет. |
|
####Зачем создавать веб-сайты на C++? |
|
Есть много причин, смотрите [Обоснование CppCMS](/wikipp/ru/page/rationale). |
|
####CppCMS — это такая же готовая система управления контентом (CMS), как Drupal? |
|
Нет, CppCMS не является системой управления контентом (CMS) аналогичной Drupal, это фреймворк веб-разработки, такой как Django или RoR. |
|
####Если CppCMS не CMS, откуда пришло это название? |
|
Оригинальная идея — «Напиши собственную _CMS_ на _C++_» |
|
Ведущий разработчик [задал вопрос в 2008 году](http://blog.cppcms.com/post/23), как лучше назвать проект, но лучших ответов не было и поэтому было принято решение оставить название как есть. |
|
####Зачем делать веб-сайты на C++? Это опасный язык! |
|
Современный C++ — безусловно сложный язык и требует гораздо больше времени для ознакомления, по сравнению с динамическими языками вроде Python или PHP, или статическими вроде C#/Java, которые очень популярны в веб-разработке. |
|
Однако если Вы в нем разберетесь, у Вас есть огромный набор средств, позволяющих писать приложения быстро и безопасно, без утечек памяти и случайных падений. Если Вы придерживаетесь принципов [RAII](http://ru.wikipedia.org/wiki/RAII), пишете защищенный код с использованием исключений и _понимаете,_ как работает STL, для вас всё будет простым и вполне ясным. |
|
####Разве главным узким местом любого веб-приложения не является SQL-движок, а не язык серверной части? |
|
Это весьма распространенное заблуждение. И его весьма легко проверить. Запустив простые тесты производительности типичной CMS вы обнаружите, что она может создавать около 5-50 страниц в секунду. |
|
Если Вы возьмете лог SQL-запросов к базе данных и запустите их аналогично тому, как если бы они были запросами от движка CMS, то обнаружите, что можете достичь 1000 запросов в секунду (запросов, не SQL-запросов)... Таким образом, SQL создает около 5% от Вашей общей проблемы производительности. |
|
Фактически, если взять действительно большие проекты вроде Википедии, можно обнаружить, что гораздо больше вычислительных ресурсов тратится на обработку PHP, чем на обработку SQL-запросов. |
См.: ["Является ли база данных узким местом веб-сервиса?"](http://blog.cppcms.com/post/42) |
|
####Как я могу помочь? |
|
Прочитайте [это руководство](/wikipp/ru/page/contrib) |
|
####Какова политика лицензирования? |
|
фреймворк лицензируется на условиях [LGPL](http://ru.wikipedia.org/wiki/GNU_Lesser_General_Public_License) и других, совместимых с LGPL лицензий. Это означает (в основном): |
|
1. Вы можете создавать коммерческие и FOSS приложения с этим фреймворком. |
2. Вы **обязаны** свободно распространять изменения, сделанные в фреймворке самостоятельно. Однако это не заставляет Вас также распространять свой собственный код приложений. |
|
Приложения основанные на CppCMS, являющиеся часть Проекта CppCMS Project (как этот wiki) лицензируются на условиях [GPL](http://ru.wikipedia.org/wiki/GPL). |
|
####Планируете ли Вы изменить лицензию фреймворка в будущем? |
|
Пока я не сошел с ума (см. Q1), я не не собираюсь менять лицензию на проприетарную или жесткую [копилефт-лицензию](http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BF%D0%B8%D0%BB%D0%B5%D1%84%D1%82). Т.е.: |
|
1. Я не закрою исходники. |
2. Я не переключусь на что-то вроде GPL и заставлю коммерческих пользователей приобретать лицензии (как Trolltech или C++ Web Toolkit). |
|
Я могу изменить лицензию на что-то более разрешающее. |
|
|
####Какие из текущих фреймворков на Вас повлияли? |
|
В основном Django. Иногда, когда я хочу добавить какое-нибудь новшество в CppCMS, я читаю документацию Django и пытаюсь понять, как они это сделали. |
|
Хорошие примеры: наследование темплейтов и форм. |
|
####Это кроссплатформенный проект? |
|
Да. |
|
Поддерживается: Linux, Windows, Solaris, FreeBSD и Mac OS X |
|
|
####Зачем откомпилированные темплейты?<br/>Почему не использовать систему интерпретации темлейтов или XSLT? |
|
Давайте начнем с истории. Первая система темплейтов CppCMS (CppCMS 0.0.1b) была интерпретируемой и динамически типизируемой. Она требовала от пользователя обеспечения некоторой склейки между используемыми ими данными и системой рендеринга. |
|
Но эта система темплейтов была отброшена в пользу статически типизируемых компилируемых темплейтов по следующим причинам: |
|
- C++ нерефлективный, статически типизируемый язык, поэтому выполнение проверок типов времени компиляции потребовал бы реализации C++ парсера, что почти невозможно. |
|
- В компилируемых темплейтах множество проверок может осуществляться самим C++ компилятором. |
|
Это очень важно для генерации HTML, потому что Модульное Тестирование пользовательских интерфейсов крайне сложно и потому статическая типизация дает значительное преимуществом, перенося большую часть тестирования в этап компиляции. |
|
- Гораздо более сложные типы данных могут поддерживаться всего лишь введением оператора `<<` над `std::ostream`. |
|
- Введение наследования темплейтов, поддержка стандартных структур данных (контейнеров), таких как list, map, hash-таблиц и даже типов определенных пользователем - становится тривиальным. |
|
Есть несколько недостатков компилируемых темплейтов: |
|
- Обновление темплейта требует перекомпиляцию и перелинковку отображения или даже самого приложения. |
- Такие обновления требуют перезапуск приложения. |
|
Первое еще не так критично, потому что при использовании темплейтов, компилируемых в совместно используемые объекты или dlls, время компиляции значительно сокращается и пользователю не требуется ждать долго. Например, компиляция и линковка темплейтов wikipp, занимает около 1.5 секунд. |
|
Второе относится к CppCMS 1.x.x, в котором темплейты могут автоматически перезагружаться как совместно используемые объекты отображения или dll, обновляемые без рестарта всего приложения. |
|
<!--toc-->
|
|
####Вы сумасшедший или мазохист?
|
|
Насколько мне известно — нет.
|
|
####Зачем создавать веб-сайты на C++?
|
|
Есть много причин, смотрите [Обоснование CppCMS](/wikipp/ru/page/rationale).
|
|
####CppCMS — это такая же готовая система управления контентом (CMS), как Drupal?
|
|
Нет, CppCMS не является системой управления контентом (CMS) аналогичной Drupal, это фреймворк веб-разработки, такой как Django или RoR.
|
|
####Если CppCMS не CMS, откуда пришло это название?
|
|
Оригинальная идея — «Напиши собственную _CMS_ на _C++_»
|
|
Ведущий разработчик задал вопрос в 2008 году, как лучше назвать проект, но лучших ответов не было и поэтому было принято решение оставить название как есть.
|
|
Позднее было решено оставить это название, т.к. оно уже было широко известно и все окружающее ПО уже использовало `cppcms` в качестве пространства имен.
|
|
####Зачем делать веб-сайты на C++? Это опасный язык!
|
|
Современный C++ — безусловно сложный язык и требует гораздо больше времени для ознакомления, по сравнению с динамическими языками вроде Python или PHP, или статическими вроде C#/Java, которые очень популярны в веб-разработке.
|
|
Однако если Вы в нем разберетесь, у Вас есть огромный набор средств, позволяющих писать приложения быстро и безопасно, без утечек памяти и случайных падений. Если Вы придерживаетесь принципов [RAII](http://ru.wikipedia.org/wiki/RAII), пишете защищенный код с использованием исключений и _понимаете,_ как работает STL, для вас всё будет простым и вполне ясным.
|
|
####Разве главным узким местом любого веб-приложения не является SQL-движок, а не язык серверной части?
|
|
Это весьма распространенное заблуждение. И его весьма легко проверить. Запустив простые тесты производительности типичной CMS вы обнаружите, что она может создавать около 5-50 страниц в секунду.
|
|
Если Вы возьмете лог SQL-запросов к базе данных и запустите их аналогично тому, как если бы они были запросами от движка CMS, то обнаружите, что можете достичь 1000 запросов в секунду (запросов, не SQL-запросов)... Таким образом, SQL создает около 5% от Вашей общей проблемы производительности.
|
|
Фактически, если взять действительно большие проекты вроде Википедии, можно обнаружить, что гораздо больше вычислительных ресурсов тратится на обработку PHP, чем на обработку SQL-запросов.
|
См.: ["Является ли база данных узким местом веб-сервиса?"](http://blog.cppcms.com/post/42)
|
|
####Как я могу помочь?
|
|
Прочитайте [это руководство](/wikipp/ru/page/contrib)
|
|
####Какова политика лицензирования?
|
|
фреймворк лицензируется на условиях [LGPLv3](http://ru.wikipedia.org/wiki/GNU_Lesser_General_Public_License) и [коммерческой](http://commercial.cppcms.com) лицензий.
|
|
Прочитайте [это](http://commercial.cppcms.com/faq), чтобы выяснить разницу и руководствоваться в выборе подходящей для Вас лицензии.
|
|
####Планируете ли Вы изменить лицензию фреймворка в будущем?
|
|
Пока я не сошел с ума (см. Q1), я не не собираюсь менять лицензию на проприетарную или жесткую [копилефт-лицензию](http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BF%D0%B8%D0%BB%D0%B5%D1%84%D1%82). Т.е.:
|
|
1. Я не закрою исходники.
|
2. Я не переключусь на что-то вроде GPL и заставлю коммерческих пользователей приобретать лицензии (как Trolltech или C++ Web Toolkit).
|
|
Я могу изменить лицензию на что-то более разрешающее.
|
|
|
####Какие из текущих фреймворков на Вас повлияли?
|
|
В основном Django. Иногда, когда я хочу добавить какое-нибудь новшество в CppCMS, я читаю документацию Django и пытаюсь понять, как они это сделали.
|
|
Хорошие примеры: наследование темплейтов и форм.
|
|
####Это кроссплатформенный проект?
|
|
Да.
|
|
Поддерживается: Linux, Windows, Solaris, FreeBSD и Mac OS X
|
|
|
####Зачем откомпилированные темплейты? Почему не использовать систему интерпретации темплейтов или XSLT?
|
|
Давайте начнем с истории. Первая система темплейтов CppCMS (CppCMS 0.0.1b) была интерпретируемой и динамически типизируемой. Она требовала от пользователя обеспечения некоторой склейки между используемыми ими данными и системой рендеринга.
|
|
Но эта система темплейтов была отброшена в пользу статически типизируемых компилируемых темплейтов по следующим причинам:
|
|
- C++ нерефлективный, статически типизируемый язык, поэтому выполнение проверок типов времени компиляции потребовал бы реализации C++ парсера, что почти невозможно.
|
|
- В компилируемых темплейтах множество проверок может осуществляться самим C++ компилятором.
|
|
Это очень важно для генерации HTML, потому что Модульное Тестирование пользовательских интерфейсов крайне сложно и потому статическая типизация дает значительное преимуществом, перенося большую часть тестирования в этап компиляции.
|
|
- Гораздо более сложные типы данных могут поддерживаться всего лишь введением оператора `<<` над `std::ostream`.
|
|
- Введение наследования темплейтов, поддержка стандартных структур данных (контейнеров), таких как list, map, hash-таблиц и даже типов определенных пользователем - становится тривиальным.
|
|
Есть несколько недостатков компилируемых темплейтов:
|
|
- Обновление темплейта требует перекомпиляцию и перелинковку отображения или даже самого приложения.
|
- Такие обновления требуют перезапуск приложения.
|
|
Первое еще не так критично, потому что при использовании темплейтов, компилируемых в совместно используемые объекты или dlls, время компиляции значительно сокращается и пользователю не требуется ждать долго. Например, компиляция и линковка темплейтов wikipp, занимает около 1.5 секунд.
|
|
Второе относится к CppCMS 1.x.x, в котором темплейты могут автоматически перезагружаться как совместно используемые объекты отображения или dll, обновляемые без рестарта всего приложения.
|
|
_Доп. примечание:_ Ничто не запрещает Вам использовать любую другую систему темплейтов. Если Вы находите это удобным, можете всегда писать вывод напрямую без темплейтов. |
