Здравствуйте, Sheridan, Вы писали:

S>Расставлять кавычки вокруг каждой строки мне как то надоело

В C++11 появились raw string literals.

Здравствуйте, Sheridan, Вы писали:

G>>Пойми ты, качество кода определяется не его скоростью, а требованиями к коду. От них надо отталкиватся, а не от своего идеализма.
S>Так уж сложилось что требования себе выставляю я сам.

Ну так выстави блин сам себе адекватные требования! Ну скажи, неужели тебе самому не хочется, чтобы система работала, чтобы ей пользовались, вместо того, чтобы пилить еще фиг знает сколько?

сформулируй себе требования так как это делают все остальные:
1. на таком-то железе и стольки-то запросах в секунду веб страница в браузере пользователя должна нарисоваться за ххх секунд.
2. модификация шаблона страницы должна занимать ххх дней.
3. добавление новой страницы должно занимать ххх дней
4. итд (дальше пошли пользовательские сценарии )

Слепи прототип, померяй. Возьми адекватный требованиям инструмент и твоя система будет у пользователей гораздо быстрее.

S>

S>#define DF_SQL_TEXT(...) #__VA_ARGS__
S>

S>Расставлять кавычки вокруг каждой строки мне как то надоело, и код запроса хотелось оставить читабельным.

Ты не понял. Код который использует данные из базы не должен знать ничего про sql. Он должен делать типизированные вызовы типа getUsers().

Здравствуйте, Privalov, Вы писали:

S>>Начнем с того, что бюджета нет вообще
P>Т. е. ты работаешь бесплатно?
Основная моя работа — не программирование. Программирование — между делом.

P>>>Я как-то наблюдал случай.
S>>Виноват конечно же, с++.
P>В известном смысле. У того разработчика не было необходимой инфраструктуры на C++ для разработки такого приложения, и он начал делать ее самостоятельно. В результате туда ушел весь бюджет проекта, а перень остался без работы.
Ну это отсутствие опыта, а как следствие — отсутствие знаний о возможных библиотеках, которые можно использовать. Но никак не с++.

P>Ты в своем проекте, по крайней мере, не думаешь про рисование окон и доступ к БД.
Ну, мне не понравился cppdb и pqxx, нарисовал свою обёртку над pqxx...

P>>>Так и в моем случае они уходят. Пусть не сразу. Зато автоматически.
S>>А у меня сразу
P>Но вручную. Зачем тогда компьютеры, если ты делаешь за них их работу?
Это передергивание

P>Гораздо больше одного раза в сутки.
P>Кроме того, гораздо дешевле поднять производительность системы, просто установив рядом с рабочим сервером, который перестает справляться, пары тройки таких же серверов. Не надо тиакты считать. Железо все равно намного дешевое того софта, который на нем бежит.
Вот и я об чём. А мой проект будет вполне себе работать на raspberry pi, при условии конечно что БД будет на нормальном сервере.
Иными словами я смогу разделить бюджет на железо не поровну между сервером приложения и сервером БД, а взять действительно мощный сервер для БД, а приложение запустить на чем то попроще.

P>>>Кстати, сейчас я получаю ответы от некоторого сервера со слишком большой задержкой. Бутылочное горлышко — именно сеть.
S>>А если бы ты писал например на перле или вообще на бэйсике — тот сервер бы тебе быстрее данные отдавал?
P>А если бы у бабушки была борода, это был бы дедушка. ©
P>Проблема на стороне сервера. Какая разница, на чем я пишу? Во всяком случае, принимающий модуль дольше ждет, чем принимает.
То есть ты оправдываешь тормоза кода тем, что есть более сильные тормоза где то еще и твой код всё равно простаивает? Такое впечатление что до запроса и после запроса твой код ничем не занимается.

P>>>Ты не угадал. Хотя бы потому, что Фортран в своей области гораздо удобнее C++.
S>>Тем не менее с++ победил и до сих пор жив.
P>Он жив, но Фортран непобедим. Во всяком случае написать переходник С — Фортран мне в свое время оказалось намного дешевле, чем переписывать отлаженный Фортрановский код полностью на Сях.
Надо бы фортран покурить. Второй кирпичик на весы желания вкурить фортран. Лень пока перевешивает

Здравствуйте, Sheridan, Вы писали:

S>Основная моя работа — не программирование. Программирование — между делом.

Ну, это заметно.

S>>>Виноват конечно же, с++.
P>>В известном смысле.

S>Ну это отсутствие опыта, а как следствие — отсутствие знаний о возможных библиотеках, которые можно использовать. Но никак не с++.

Но на Фоксе проект, не сразу падающий, был сделан за несколько дней. Полагаю, что в данном случае речь идет о выборе правильного инструмента.
Да, описываемые события происходили в середине 90-х далеко от центров международной информатики. Так что далеко не все можно было легко добыть. А с тем, что, что было, нужно было разбираться. Тогда в моде были Turbo Vision, Paradox Engine, по-моему, CodeBase. А на Фоксе сидишь и клепаешь учетные задачи, думая только об этих самых задачах. Немножко о реляционных БД надо было почитать.

S>Ну, мне не понравился cppdb и pqxx, нарисовал свою обёртку над pqxx...

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

S> Это передергивание

Вовсе нет. Впрочем, тут же КСВ.

S>Вот и я об чём. А мой проект будет вполне себе работать на raspberry pi, при условии конечно что БД будет на нормальном сервере.

Дак причем тут клиент? ОН каким угодно может быть. К нему другие требования.

S>Иными словами я смогу разделить бюджет на железо не поровну между сервером приложения и сервером БД, а взять действительно мощный сервер для БД, а приложение запустить на чем то попроще.

Ты уверен, что знаешь значение термина "сервер приложений"?

А если выяснится, что сервер недостаточно мощный, сможешь ли ты просто воткнуть с ним рядом такой же, чтобы снять напряжение, или снова будешь такты считать?

S>То есть ты оправдываешь тормоза кода тем, что есть более сильные тормоза где то еще и твой код всё равно простаивает? Такое впечатление что до запроса и после запроса твой код ничем не занимается.

А чем серверный код заниматься должен помимо обслуживания запросов от клиентов?

Как-то мужики профилировали новую ОС, и увидели, что некий цикл занимает 50% времени выполнения. Они его соптимизировали. Оказалось, это холостой цикл.

S>Надо бы фортран покурить. Второй кирпичик на весы желания вкурить фортран. Лень пока перевешивает

Покури. Но имей в виду: граблей в нем до фига. Правда, я новый Фортран не видел, может, там какие-то и убрали.

Здравствуйте, Sheridan, Вы писали:

S>Поэтому я их и пишу.
S>Вот тебе кусочек кода
S>...

https://www.youtube.com/watch?v=HcfHBgUTn7I

Здравствуйте, Sheridan, Вы писали:

S>>>Вот тебе кусочек кода
НС>>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно?
S>Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода?

Если тебе реально надо экономить процессорные такты на сервере, то логично сделать по другому — шаблонизатор на клиенте, а сервер выдает json (ну или xml) для динамических результатов и стататические страницы. Т.е., вообще никакого изготовления на лету HTML-страниц на сервере.

Здравствуйте, Sheridan, Вы писали:

S>И так в отдельном классе. Наружу только запуск исполнения запроса и доступ к данным.
S>

S>  DFDB_R coworkers = DFDB_Q("task_coworkers", DF_SQL_TEXT(
S>              select
S>              /* 0*/ members.id,
S>              /* 1*/ members.name,
S>              /* 2*/ divisions.id,
S>              /* 3*/ divisions.short_name
S>...
S>            <a href='/members/show/<v++ coworkerID ++v>'><v++ coworker[1].as<std::string>() ++v></a>&nbsp;
S>           (<a href='/divisions/show/<v++ coworker[2].as<std::string>() ++v>'><v++ coworker[3].as<std::string>() ++v></a>)
S>

Как-то это неудобно, по индексам к выборке обращаться, комментарии обновлять. Можно ведь вначале сделать:

int memberIdIndex = result.getColumnIndex("members.id");

Здравствуйте, genre, Вы писали:

G>Ты не понял. Код который использует данные из базы не должен знать ничего про sql. Он должен делать типизированные вызовы типа getUsers().

То есть, сначала мы придумаем мощный LINQ, а потом обернем его в тупой репозитарий, с тыщей методов и у каждого метода — тыща флагов.

Ой.

Здравствуйте, Слава, Вы писали:

G>>Ты не понял. Код который использует данные из базы не должен знать ничего про sql. Он должен делать типизированные вызовы типа getUsers().
С>То есть, сначала мы придумаем мощный LINQ, а потом обернем его в тупой репозитарий, с тыщей методов и у каждого метода — тыща флагов.
С>Ой.

Че?

Здравствуйте, genre, Вы писали:

G>сформулируй себе требования так как это делают все остальные:
G>1. на таком-то железе и стольки-то запросах в секунду веб страница в браузере пользователя должна нарисоваться за ххх секунд.
G>2. модификация шаблона страницы должна занимать ххх дней.
G>3. добавление новой страницы должно занимать ххх дней
G>4. итд (дальше пошли пользовательские сценарии )
Это есть, их и соблюдаю.

G>Слепи прототип, померяй. Возьми адекватный требованиям инструмент и твоя система будет у пользователей гораздо быстрее.
Уже частично в работе. В смысле — люди уже местами пользуются

G>Ты не понял. Код который использует данные из базы не должен знать ничего про sql. Он должен делать типизированные вызовы типа getUsers().
У, нет. В таком случае этих getUsers будет несколько вариантов. Ибо тут нужны юзеры с должностями, там с последней датой посещения, здесь с количеством исполненых заданий, заданий в работе итд. Выбирать ВСЁ сразу, чтобы подошло под любые нужды? может быть поэтому тут говорят о том что БД — слабое место?

Здравствуйте, Sheridan, Вы писали:

НС>>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно?
S>Всё правильно, упор на производительность.

Зачем тебе микросекунды при генерации html, если 99% времени у тебя будет выборка из БД занимать? И твоя собственная производительность тебя что, совсем не волнует?

S> Или в 2014 году есть какая то сложность в компиляции кода?

В 2014 году есть намного более удобные средства, чем ручная склейка строк.

Здравствуйте, genre, Вы писали:

G>Здравствуйте, Слава, Вы писали:

G>>>Ты не понял. Код который использует данные из базы не должен знать ничего про sql. Он должен делать типизированные вызовы типа getUsers().
С>>То есть, сначала мы придумаем мощный LINQ, а потом обернем его в тупой репозитарий, с тыщей методов и у каждого метода — тыща флагов.
С>>Ой.

G>Че?

Не нужны, говорю, ваши репозитарии. Нет в них смысла при использовании LINQ. Лишняя прослойка, вдобавок еще и уродливая. А делают ее, потому что так в книжке написано, а автор книжки еще при царе горохе опердени писал, и у него была задача — обеспечить переносимость между dBase и Interbase.

Здравствуйте, Sheridan, Вы писали:

S>Так вот, у меня генерация страницы как минимум на порядок быстрее при том же внешнем виде и функционале.

При одном пользователе?
Масштабируемость? Не, не слышал.

S>И вообще, я так понимаю, тут почему то никому не нравится с++.

Многим нравится. Когда применен по месту. Более мнее сложные HTML странички — точно не такое место.

S>Были сомнения что веб-приложения на с++ написать нельзя? Я эти сомнения развеял.

URL можно, чтобы на твой развей поглядеть?

Здравствуйте, Sheridan, Вы писали:

S>Это есть, их и соблюдаю.

Есть да не то. У тебя есть требование "хочу чтобы этот кусок кода работал быстро". А это называется не написание работающего софта, а удовлетворение собственных технических амбиций.

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

G>>Слепи прототип, померяй. Возьми адекватный требованиям инструмент и твоя система будет у пользователей гораздо быстрее.
S>Уже частично в работе. В смысле — люди уже местами пользуются

Что-то мне подсказывает, что это "частично" очень надолго.

G>>Ты не понял. Код который использует данные из базы не должен знать ничего про sql. Он должен делать типизированные вызовы типа getUsers().
S>У, нет. В таком случае этих getUsers будет несколько вариантов. Ибо тут нужны юзеры с должностями, там с последней датой посещения, здесь с количеством исполненых заданий, заданий в работе итд. Выбирать ВСЁ сразу, чтобы подошло под любые нужды? может быть поэтому тут говорят о том что БД — слабое место?

Будет. И может даже довольно много вариантов. Но как только ты задашь себе вопрос например "а нужно ли мне оптимизировать этот кусок кода и если нужно то как же мне померять его скорость" или к примеру у тебя появится странное, на первый взгляд, желание написать тесты, то окажется, что декомпозиция это не просто благо, а практически серебрянная пуля в твоем случае.

Не говоря уж о дублировании кода, поиске багов и прочем и прочем.

Здравствуйте, Слава, Вы писали:

С>Не нужны, говорю, ваши репозитарии. Нет в них смысла при использовании LINQ. Лишняя прослойка, вдобавок еще и уродливая. А делают ее, потому что так в книжке написано, а автор книжки еще при царе горохе опердени писал, и у него была задача — обеспечить переносимость между dBase и Interbase.

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

Здравствуйте, Privalov, Вы писали:

S>>>>Виноват конечно же, с++.
P>>>В известном смысле.
S>>Ну это отсутствие опыта, а как следствие — отсутствие знаний о возможных библиотеках, которые можно использовать. Но никак не с++.
P>Но на Фоксе проект, не сразу падающий, был сделан за несколько дней. Полагаю, что в данном случае речь идет о выборе правильного инструмента.
P>Да, описываемые события происходили в середине 90-х далеко от центров международной информатики. Так что далеко не все можно было легко добыть. А с тем, что, что было, нужно было разбираться. Тогда в моде были Turbo Vision, Paradox Engine, по-моему, CodeBase. А на Фоксе сидишь и клепаешь учетные задачи, думая только об этих самых задачах. Немножко о реляционных БД надо было почитать.
Ну, как я и сказл — дело в отсутствии опыта и знаний, но не в с++.


S>>Ну, мне не понравился cppdb и pqxx, нарисовал свою обёртку над pqxx...
P>Слышал я, как кому-то MSMQ не понравился, и его функционал решили переписать. Продукт, говорят, получился неплохой, но никому не нужный. Разрабатывался он как часть большого проекта, применить его где-то еще не удалось. Ресурсы потрачены впустую, основной проект провалился.
И исходники, небось, закрыты. Впрочем, у меня пока еще тоже

S>>Вот и я об чём. А мой проект будет вполне себе работать на raspberry pi, при условии конечно что БД будет на нормальном сервере.
P>Дак причем тут клиент? ОН каким угодно может быть. К нему другие требования.
Я как раз про серверную часть

S>>Иными словами я смогу разделить бюджет на железо не поровну между сервером приложения и сервером БД, а взять действительно мощный сервер для БД, а приложение запустить на чем то попроще.
P>Ты уверен, что знаешь значение термина "сервер приложений"?
P>А если выяснится, что сервер недостаточно мощный, сможешь ли ты просто воткнуть с ним рядом такой же, чтобы снять напряжение, или снова будешь такты считать?
Нет, я не планировал распределять серверную часть между несколькими серверами. Нет необходимости, по крайней мере в этом проекте.

S>>То есть ты оправдываешь тормоза кода тем, что есть более сильные тормоза где то еще и твой код всё равно простаивает? Такое впечатление что до запроса и после запроса твой код ничем не занимается.
P>А чем серверный код заниматься должен помимо обслуживания запросов от клиентов?
Так мы дойдём до "А чем серверный код заниматься должен помимо формирования одних данных исходя из других?". Слишком общий вопрос, тут ответ один: "ничем". Безотносительно назначения приложения.

P>Как-то мужики профилировали новую ОС, и увидели, что некий цикл занимает 50% времени выполнения. Они его соптимизировали. Оказалось, это холостой цикл.
Гдето я читал байку про геймдев, где упёрлись в ограничение по памяти. Ничего сами сделать не смогли, хотя много чего оптимизировали. Обратились к зубру, который давно ушел из проекта. Тот открыл какие то дебри кода и удалил одну строку char a[1024*1024*15];, сказав что предвидел проблему заранее и подготовил путь к отступлению.

Здравствуйте, Хон Гиль Дон, Вы писали:

ХГД>Если тебе реально надо экономить процессорные такты на сервере, то логично сделать по другому — шаблонизатор на клиенте, а сервер выдает json (ну или xml) для динамических результатов и стататические страницы. Т.е., вообще никакого изготовления на лету HTML-страниц на сервере.
В некоторых местах так и есть. Например, так у меня формируются таблицы, списки.

Здравствуйте, Слава, Вы писали:

С>Как-то это неудобно, по индексам к выборке обращаться, комментарии обновлять. Можно ведь вначале сделать:

С>

С>int memberIdIndex = result.getColumnIndex("members.id");
С>

Можно и так, движок позволяет. Только поиск по int индексу все таки быстрее, чем поиск по std::string индексу. Да и индексы столбцов у меня на виду всегда, лишней работы по вытаскиванию индекса делать не надо.

Здравствуйте, Sheridan, Вы писали:

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

Поэтому в современных фреймворках для компилируемых языков страница при первом обращении компилируется. А при желании ее можно скомпилировать в момент деплоймента или даже при компиляции веб-приложения.

S>Да, у меня в проекте хтмл генерируется прямо в коде.

Ты не поверишь, но в каком нибудь ASP.NET страница тоже генерируется прямо в коде. Разница в том, что этот код никто руками не пишет.

S>А ты в курсе про байку, в которой говорится что если разработчик не уверен в необходимости/правильности чегототам (поведения, меню, вида), он добавляет новую опцию в настройки?

Байка в качестве аргумента? Достойно Шеридана.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sheridan, Вы писали:

НС>>>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно?
S>>Всё правильно, упор на производительность.

НС>Зачем тебе микросекунды при генерации html, если 99% времени у тебя будет выборка из БД занимать? И твоя собственная производительность тебя что, совсем не волнует?

S>> Или в 2014 году есть какая то сложность в компиляции кода?
НС>В 2014 году есть намного более удобные средства, чем ручная склейка строк.

Скотчем двухсторонним клею, ага
Под это дело у меня написан на перле препарсер, который разворачивает некоторые блоки типа

<async_image++ [icon] [i_<v++ row ++v>] ["/<v++ sr.get<std::string>(4) ++v>/icon.jpg"] [undefined] [undefined] [<v++ sr.get<std::string>(3) ++v>]>
...
<v++ row ++v>

в

<div class='image_container_icon loading' id='icon_i_1_image_container'></div>
<script type='text/javascript'>loadImage('icon_i_1_image_container', 'icon_i_1_image', "/path/icon.jpg", 'icon', undefined, 'string', undefined);</script>
...
" << row << "

В коде же у меня хтмл вполне себе отдельно от остального

void putBaseFooter()
{
  if(m_canRender)
  {
    HTML
    (
      <!++
      </main>
      <footer><f++ composePageFooter(); ++f>
        <div style='font-size: 5pt; text-align:right'><a href='/auth'>В.</a></div>
      </footer>
      </body>
      </html>
      ++!>
    );
  }
}