Wt учебные материалы.

В других языках кода будет не меньше.

facepalm++:

#include <Wt/WApplication>
#include <Wt/WBreak>
#include <Wt/WContainerWidget>
#include <Wt/WLineEdit>
#include <Wt/WPushButton>
#include <Wt/WText>

// c++0x only, for std::bind
// #include <functional>

using namespace Wt;

class HelloApplication : public WApplication
{
public:
  HelloApplication(const WEnvironment& env);

private:
  WLineEdit *nameEdit_;
  WText *greeting_;

  void greet();
};

HelloApplication::HelloApplication(const WEnvironment& env)
  : WApplication(env)
{
  setTitle("Hello world");                               

  root()->addWidget(new WText("Your name, please ? "));  
  nameEdit_ = new WLineEdit(root());                     
  nameEdit_->setFocus();                                 

  WPushButton *button
    = new WPushButton("Greet me.", root());              
  button->setMargin(5, Left);                            

  root()->addWidget(new WBreak());                       

  greeting_ = new WText(root());                         

  button->clicked().connect(this, &HelloApplication::greet);

  nameEdit_->enterPressed().connect
    (boost::bind(&HelloApplication::greet, this));

  // b->clicked().connect(std::bind([=]() { 
  //       greeting_->setText("Hello there, " + nameEdit_->text());
  // }));
}

void HelloApplication::greet()
{
  greeting_->setText("Hello there, " + nameEdit_->text());
}

WApplication *createApplication(const WEnvironment& env)
{
  return new HelloApplication(env);
}

int main(int argc, char **argv)
{
  return WRun(argc, argv, &createApplication);
}

Ruby:

require 'sinatra'

get '/greet' do  
  erb :greet
end

post '/greet' do  
  "Hello there, #{params[:name]}, don't trust anonymous he's lying fuck."
end

views/greet.erb

<form method="post" action="/greet">
  <label>Your name, please? <input name="name" type="text">
  <input type="submit" value="Greet me">
</label>

Давно меряются хеллоуворлдами?

В реальной задаче вышеприведенный «костяк» будет составлять какие-то или доли процентов от всего остального кода.

Но меня останавливает, то что это «чьё-то» , в java чтонить изменят и всё накроется. Хочется иметь возможность, контролировать то с чем работаешь, и в случае необходимости, изменять это.

«Контролёр», С от С++ не отличаешь, что ты контролировать собрался?

Самый главный минус Wt это её плюс: Wt заменяет собой всё. Вероятность того, что тебе понадобится что-то из HTML/CSS/JS, что не будет иметь поддержки Wt гораздо выше того, что «в java что-нить изменят и всё накроется» (c).

Давно меряются хеллоуворлдами?

Если кто-то тупит и заявляет, что на C++ кода будет столько же, остаётся только носом ткнуть в самый простой пример, где кода _уже_ гораздо меньше. На реальной задаче кода на С++ будет на порядок больше, я не знаю, чем кроме как хелловорлдом для идиотов это доказать. Мне что, кинуть код реального сайта и кто-то кинется аналог на Wt писать, чтобы сравнить можно было?

Будет очень много кода.

Спорно, если не писать на plain C/C++, а юзать современные либы и фишки из стандарта C11/C++11

Придется искать шаблонизатор.

CTPP2. Один из самых быстрых и мощных шаблонизаторов.

Придется вручную переезжать на другой движок БД,

Обёртка пишется легко, да и ORM не так уж и мало.

То есть либо получится мегалего из разных блоков, из которых не факт что все оттестированы и проверены в бою;

То же касается модулей к python/ruby/perl/etc.

В C++ есть более-менее строгая типизация, статический анализ, и проверки при компиляции, что позволяет избегать множества ошибок.

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

facepalm++:
Ruby:

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

На реальной задаче кода на С++ будет на порядок больше, я не знаю, чем кроме как хелловорлдом для идиотов это доказать.

В хеллоуворлде основное место занял костяк сайта. В реальной задаче вышеприведенный «костяк» будет составлять какие-то или доли процентов от всего остального кода.

К тому же вместо Wt я бы выбрал C++11 с шаблонизатором, ORM, SCGI/FastCGI-интерфейсом, boost, либой для сессий, остальное по вкусу.

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

Почему, на твоё мнение, кода должно быть очень много?

Спорно, если не писать на plain C/C++, а юзать современные либы и фишки из стандарта C11/C++11

Ой, да если точиться под хелловорлды, кто мешает создать библиотеку, в которой результирующее приложение будет выглядеть как-нибудь эдак без C11/C++11:

#include 'sinatra.h'

SString greetHandler(Sinatra S, SMap params){
  return "Hello there, "+params["name"]+", don't trust anonymous he's lying almost like Reaper."
}

Sinatra S=new Sinatra("/greet",null,&greetHandler);

.

Wt мне как-то с Qt созвучно. Может, потому что лицензия-то GPL. А для библиотеки как-то LGPL лучше, с чем для Qt и согласились. А вот в Wt - нет.

Не смущает? Ведь если этот большой сайт будет доступен из ВЕБа, то все исходники тоже придётся там вывесить (по крайне мере по требованию).

если этот большой сайт будет доступен из ВЕБа, то все исходники тоже придётся там вывесить

Пойду я спать, пожалуй. Не хочу видеть как тебя убивают за эту наглую лошь.

Почему, на твоё мнение, кода должно быть очень много?

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

К тому же вместо Wt я бы выбрал C++11 с шаблонизатором, ORM, SCGI/FastCGI-интерфейсом, boost, либой для сессий, остальное по вкусу.

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

Но тут есть одна проблема. Этого удобного инструмента, который абстрактно щас сядут и напишут, пока нет.

ты не распространяешь софт, значит и выкладывать ничего не должен

Хм, точно. HTML, что я вижу - это всё же не прога, а только её вывод. Но если оно там часть себя как js пошлёт, выйдет, что распространение части софта идёт!

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

Дело не в хэлловорлдах, дело в самом коде в целом. Писанина на плюсах никогда короче не будет, чем писанина на питоне/руби и т.п.

Писанина на плюсах никогда короче не будет, чем писанина на питоне/руби и т.п.

Я там дальше привёл пример псевдокода

Посмотри еще http://cppcms.com/wikipp/en/page/main

и http://cas.havoc.ru/ тут шаблонизатор идет отдельно http://ctpp.havoc.ru/

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

Написание веб приложений на C++ позволяет хорошо прокачать навык программирования на C++. Только тебе нужно заранее учесть, что это приложение никто кроме тебя не сможет развивать и никому другому оно не нужно будет. Большинство необходимых библиотек для разработки web-приложений на C++ есть, велосипеды приходится делать лишь для совсем простых вещей (типа клиента OAuth2 и то только потому, что существующие решения слишком громоздкие и решают не совсем нужную тебе задачу, типа OAuth2 для facebook).

P.S. В провокации «C++ для веба - гавно» я не участвую. Дискутируйте без меня. У многих людей есть причины написать веб приложение на C++ в том числе и у ТС, а доказывать это кому-либо ни одной.

В провокации «C++ для веба - гавно» я не участвую. Дискутируйте без меня.

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

Я там дальше привёл пример псевдокода

Я тебе тоже могу абстрактный псевдокод привести для аргументации любого бреда. Его и в рабочий вид приводить не надо и типа аргумент.

Тем не менее он опровергает твоё утверждение «Писанина на плюсах никогда короче не будет, чем писанина на питоне/руби и т.п.» чуть более чем полностью.

Каким образом? Это же псевдокод, мы за плюсы говорили, а не х.з. за что.

Претензия к слову «никогда»? Ну, синтетический пример бессмысленного кода, который будет очень короткий и не потеряет лаконичность в плюсах сделать можно, правда, и он, вероятно, не будет короче аналога на руби.

Конкретные претензии к приведённому куску есть? Это функциональный аналог твоего кода на рубях, который использует некий С++-нутый аналог твоей синатры. И который нисколько не длиннее твоего рубанутого кода. Какие претензии к языку?

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

Конкретные претензии к приведённому куску есть?

Есть, я уже написал. Это не C++, это хер знает что. Ну, и пальцем ткни в плюсанутый аналог синатры, а то хорошё всё только на словах.

x_hash
Огромное спасибо за ссылки! посмотрю!

Это не C++, это хер знает что

Поясни свою мысль.

http://www.boutell.com/cgic/
http://www.fastcgi.com/drupal/

но предыдущие люди во многом правы, писать для веб на C/C++ нельзя назвать самым оптимальным вариантом

писать для веб на C/C++ нельзя назвать самым оптимальным вариантом

<br/><br/> Хм. Казалось бы оптимальный вариант - писать для веб на C/C++. Ведь пишешь один раз, а потом об тормоза твоего интерпретатора плюются миллионы пользователей, а сам ты с интересом ждёшь того часа, когда масштабирование на аппаратном уровне тонны костылей, подложенных под твой продукт, перестанет окупаться.