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

G>>>и заплачу за разработку стоимость еще 10. и?
S>>Пятьдесят, ага.
G>вполне возможно и пятьдесят.
G>тебе вообще не пристало бы шутить на эту тему, учитывая, сколько ты знаешь о разработке высоконагруженных систем. Одно дело сайт на 10 страничек на с++ написать и утверждать, что сэкономил на железе, другое серьезно говорить о экономии на железе в нагруженных платформах.

А с каких пор мы начали о высоконагруженных серверах разговаривать? о0

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

S>А с каких пор мы начали о высоконагруженных серверах разговаривать? о0

с тех пор как про 5 серверов речь зашла.

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

S>>А с каких пор мы начали о высоконагруженных серверах разговаривать? о0
G>с тех пор как про 5 серверов речь зашла.

Мне одного достаточно

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

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

A>>Тут надо учесть, что Button_Click вернет управление сразу и нужно задизэйблить кнопку, чтоб повторный запрос нельзя было сделать — UI не блокируется же.

_>Лучше этот пример переписать вот так:
_>

void async Button_Click()
_>{
_>    txt.Text=await DownloadAsync();
_>}
_>

_>для одновременно большей красоты и непонятности (при условии, что мы хотим вообще понимать суть происходящего, а не рассчитывать на таинственную магию .net'a). Т.е. в таком коде надо чётко понимать, что между вычислением правой части (причём не важно в отдельном потоке или нет) и самим приравниванием может быть выполнен (в том же потоке) произвольный объём кода.

Т.е. проблема в недостаточной многословности — должно быть, чтоб с 5 метров глядя на монитор было видно, что у нас тут асинхронщина?

A>>Понятно, что цикл обработки сообщений UI потока. Интересуют детали.
_>В каком смысле детали? ) Показать как подключаются обработчики сообщений в каком-то фреймворке или что? ) Или вытащить из исходников библиотеки код самого цикла? )
Интересовало откуда PostData узнает у какого инстанса формы нужно вызвать OnData. Из глобальной переменной? Или PostData это экземплярный метод той же формы.

A>>И без разрыва может произойти что угодно, если у нас больше одного потока. И таки код не притворяется линейным, а таким и является, до тех пор пока мы параллельность явно делать не начнем (массивы тасков с WhenAny и т.п.).
_>Я бы сказал что код на C# является линейным. А компилируется это (и соответственно выполняется) в совсем другие сущности. Вот эта "подделка" мне и не нравится.
А ты, видимо, всегда отрубаешь оптимизацию, когда компилируешь C++. Ведь оптимизатор может камня на камне не оставить от твоего исходного кода.

A>>А у меня есть подозрение, что подавляющее большинство программистов, у которых в графе профессии стоит "C++", пишут код так, что ты это, мягко говоря, не назовешь идеоматичным кодом на C++.)
A>>Т.е. не только boost, но и часто STL не знают, а пишут с стиле "C++ 80х".
A>>И еще подозреваю, что самый тормозной код — это код на C++, написанный "индусами".))
A>>А если взять среднестатистических C++ и C# программистов, то на типичном проекте с типичными ограничениями ресурсов (время, деньги) продукт на C++ будет содержать больше багов и (о ужас!) будет тормозить, по сравнению с написанным на C#.

_>Ну я в общем то со всем эти согласен. Я тут уже не раз говорил, что у C++ и C# есть свои ниши, где они однозначно царят, ну и плюс большое промежуточное поле, в котором можно использовать с пользой оба инструмента. По моему мнению Java/C# отлично подходит для не IT компаний (кстати, надо понимать, что таких большинство), а соответственно C++ хорош для высокотехнологичных IT компаний, которые могут позволить себе нанимать не рядовых программистов.

У меня более правдоподобная версия: С/C++ имеет смысл использовать, если требуется производительность любой ценой (даже если это приведет к удорожанию проекта в 10 раз). На C/C++ можно написать более производительный код, но это не значит, что, выбирая С/С++ у нас код автоматом будет более производительным, т.к. для этого, помимо этого выбора, требуется еще вбухать в 10 раз больше ресурсов.
Большинство проектов выглядят так: вот лежит у тебя в трекере задачка "реализовать такое-то поведение"; первое, на что посмотрят когда ты ее сделаешь, это на сколько это поведение корректно реализовано; второе — на сколько код понятен, поддерживаем и расширяем; а на производительность будут смотреть только если тормоза будут слишком заметны. Ближе к концу проекта, если время останется, пройдуться пару раз профайлером, пофиксят пару косячков и в продакшен.
И это все не зависит от выбора языка (мы все еще про большинство проектов). Думаешь какой-нибудь MS Word по другому разрабатывался? Сомневаюсь.
Какой бы тормозной язык не был выбран, в типичном среднесложном проекте, на нем реализованном, имеется "запас оптимизации", превосходящий портирование на C++. Т.е., не меняя язык реализации, можно соптимизировать в десятки или сотни раз, а портирование даст ускорение только в 2-5 раз. После портирования, конечно, можно приложить сверхусилия и добиться производительности, недостижимой для "тормозного языка". Только ресурсов и времени потребуется астрономическое количество. А если брать C++ изначально, то высок шанс просрать дэдлайны и там уж точно не до восокой производительности будет — лишь бы хоть как, но работало.
Короче, я тоже нелюблю тормозные программы, но делать вывод "это потому, что они написаны на таком-то говноязыке" не стал бы. Можно, разве что, предположить, что порог вхождения в язык сильно ниже, поэтому в проект просочились некомпетентные и/или немотивированные люди и т.п. Но это вопрос в людях, а не в языке как таковом. Если этих же людей заставит писать на С++ будут еще большие тормоза, если вообще что-то работать будет...
А С++ не выбирают далеко не только те, которые его не осилили, как тебе могло показаться.

Здравствуйте, genre, Вы писали:
G>и заплачу за разработку стоимость еще 10. и?
И подумаешь, чего у тебя разработчики так плохо работают, например

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

G>>и заплачу за разработку стоимость еще 10. и?
E>И подумаешь, чего у тебя разработчики так плохо работают, например

Я? нет, не подумаю. Я знаю что отверткой гвозди забивать можно, но неэффективно.

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


S>

S>void CMenu::menu()
S>{
S>  std::string loginMenuItem = "<li><a href='/auth'>Вход</a></li>",
S>              canAddTaskMenu = "",
S>              canAddMemberMenu = "",
S>              canAddDivisionMenu = "";
S>  if(userIsLoggedOn())
S>  {
S>    DFDB_R memberDivision = DFDB_Q("member_division_id", "select division_id from members where id=$1",(session().get<int>("member_id")));
S>    loginMenuItem    = "<li><a href='/auth/quit'>Выход</a></li>";
S>    canAddTaskMenu   = CMS_RIGHTS->check(df::rights::otTask, df::rights::rtCanAdd, memberDivision[0][0].as<int>(), session().get<int>("member_id")) ?
S>                       "<ul><li><a href='/tasks/add'>Создать задачу</a></li></ul>" : "";
S>    canAddMemberMenu = CMS_RIGHTS->checkMember(df::rights::rtCanAdd, session().get<int>("member_id")) ?
S>                       "<ul><li><a href='/members/add'>Зарегестрировать пользователя</a></li></ul>" : "";
S>    canAddDivisionMenu = CMS_RIGHTS->checkDivision(df::rights::rtCanAdd, session().get<int>("member_id")) ?
S>                       "<ul><li><a href='/divisions/add'>Добавить подразделение</a></li></ul>" : "";
S>  }
S>  HTML
S>  (
S>    <!++
S>    <ul class='menu'>
S>      <li><a href='/'>Главная</a></li>
S>      <li><a href='/calendar'>Календарь</a></li>
S>      <li><a href='/tasks/'>Задачи</a><v++ canAddTaskMenu ++v></li>
S>      <li><a href='/members/'>Пользователи</a><v++ canAddMemberMenu ++v></li>
S>      <li><a href='/divisions/'>Подразделения</a><v++ canAddDivisionMenu ++v></li>
S>      <v++ loginMenuItem ++v>
S>    </ul>
S>    ++!>
S>  );
S>}
S>

Страх и ужас. Потому что смесь кода и html — такое было популярно лет 10 назад. Еще и компилить надо, причем С++ — очень долго компилить. Даже ужас типа пхп сейчас ушел от сменения логики и представления в одну кучу. Ибо это реально кошмар. И строки прямо в коде. Представь, что тебе нужно будет в готовом продукте добавить выбор языка — например, один из региональных языков России. Или тот же английский.
Да тут недостатков можно тысячи найти только по этому куску.
Не говоря уже о том, что выглядит это все как полный пипец, и читать это невозможно.

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

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

S>>Вот тебе кусочек кода

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

Вот редко я с тобой согласен, но это полный п...

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


S>И вообще, я так понимаю, тут почему то никому не нравится с++. Ну так не ешьте. Были сомнения что веб-приложения на с++ написать нельзя? Я эти сомнения развеял. Что вы еще пытаетесь доказать? Что я как то неправильно пишу? Ну так это мои проблемы, пишите правильно.

Мне нравится С++. И на нем можно писать веб-приложения. Но убого, долго, и с кучей уязвимостей, которые те же разрабы на жабе или шарпе даже не смогут сделать при всем желании(хотя япри некотором смогут, юзая unsafe, но это совсем другая история, так с++ можно сравнить с наличествующим пистолетом с самонаведением в ногу, а жабошарп — с процедурой покупки и использования боевого пистолета в условиях РФ).

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


S>Гм. Давай посмотрим.
S>пэхапэ + шаблоны: получение запроса, парсинг кода, интерпритация, запрос данных в бд, парсинг шаблонов, сборка страницы из "шаблон+данные", передача клиенту.

Я далек от пхп, но мне рассказывал знакомый, что оно давно научилось компилироваться. Что-то по типу JIT.

S>с++ + инлайн-хтмл: получение запроса, запрос данных в бд, сборка страницы исходя из данных, передача клиенту.
S>Из этого я вижу укорачивание процесса запрос-результат на три шага, от 7 к 4. Причем уходят именно ресурсоёмкие шаги: парсинг, интерпритация.
S>Да и вообще, оправдывать тормозной код тем, что все равно "много" времени уйдет на доставку результата как минимум неверно, ибо результат надо доставить в любом случае.

Ты забываешь еще одну операцию в с++. А именно — подчистка памяти прямо в потоке запроса, что создает дыры в куче, что усложняет и тормозит выделение памяти, и тормозит весь запрос. В то время как GC во-первых, выполняется в другом потоке, не тормозя основные(если писали не дибилы, и использовали только короткоживущие объекты), и память выделяется последовательно, без поиска области, т.е. обычным увеличением указателя. Для веба как раз характерно использование огромного количества объектов, время жизни которых — один запрос. Потому тут управляемая память ложит на лопатку модель памяти с++.

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


EP>А в управляемых языках есть, например, unsafe,

Которое используется крайне редко, в силу ну очень специфических требований. И обычно это небольшой кусок кода, который пишут люди с совсем не юниорской квалификацией, способные этот кусок вылизать до блеска.
А в с++ все unsafe.

EP> вызов сторонних динамических библиотек и общая склонность к type erasure а-ля System.Object

И что? Ошибка ClassCastException? Ну да, сами виноваты. Но к уязвимости это вести не может вообще никак.

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

A>Т.е. проблема в недостаточной многословности — должно быть, чтоб с 5 метров глядя на монитор было видно, что у нас тут асинхронщина?

Нет, вопрос не в объёме кода, а в его разделение. Т.е. в моём варианте части кода, между которыми возможно произвольное число итераций главного цикла обработки сообщений, чётко разделены между собой. Собственно они и оформлены как отдельные обработчики, что даёт полную ясность и прозрачность. А в варианте с await (что на C++, что на C#) у нас получается картина, в которой эти части находятся вообще в одном выражении. Т.е. если человек хочет понимать происходящее и при этом пользоваться такой архитектурой, то он должен постоянно держать в голове мысль, что местами между вычислением правой части равенства и собственно приравниванием может произойти произвольное число итераций главного цикла сообщений.

Хотя конечно если не понимать что происходит и относится к данной технологии, как к некой загадочной .net магии, то инструмент действительно симпатичный выходит...

A>>>Понятно, что цикл обработки сообщений UI потока. Интересуют детали.
_>>В каком смысле детали? ) Показать как подключаются обработчики сообщений в каком-то фреймворке или что? ) Или вытащить из исходников библиотеки код самого цикла? )
A>Интересовало откуда PostData узнает у какого инстанса формы нужно вызвать OnData. Из глобальной переменной? Или PostData это экземплярный метод той же формы.

Ну это зависит от фреймворка. Ну в случае той же формы и скажем wxWidgets так и есть. А вообще (особенно в случае системных потоков/акторов) ещё частенько удобно использовать thread message (тоже есть в том же wxWidgets). Вообще это всё тривиальные вещи, имеющие десятки различных удобных решений.

A>А ты, видимо, всегда отрубаешь оптимизацию, когда компилируешь C++. Ведь оптимизатор может камня на камне не оставить от твоего исходного кода.

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

A>У меня более правдоподобная версия: С/C++ имеет смысл использовать, если требуется производительность любой ценой (даже если это приведет к удорожанию проекта в 10 раз). На C/C++ можно написать более производительный код, но это не значит, что, выбирая С/С++ у нас код автоматом будет более производительным, т.к. для этого, помимо этого выбора, требуется еще вбухать в 10 раз больше ресурсов.
A>Большинство проектов выглядят так: вот лежит у тебя в трекере задачка "реализовать такое-то поведение"; первое, на что посмотрят когда ты ее сделаешь, это на сколько это поведение корректно реализовано; второе — на сколько код понятен, поддерживаем и расширяем; а на производительность будут смотреть только если тормоза будут слишком заметны. Ближе к концу проекта, если время останется, пройдуться пару раз профайлером, пофиксят пару косячков и в продакшен.
A>И это все не зависит от выбора языка (мы все еще про большинство проектов). Думаешь какой-нибудь MS Word по другому разрабатывался? Сомневаюсь.
A>Какой бы тормозной язык не был выбран, в типичном среднесложном проекте, на нем реализованном, имеется "запас оптимизации", превосходящий портирование на C++. Т.е., не меняя язык реализации, можно соптимизировать в десятки или сотни раз, а портирование даст ускорение только в 2-5 раз. После портирования, конечно, можно приложить сверхусилия и добиться производительности, недостижимой для "тормозного языка". Только ресурсов и времени потребуется астрономическое количество. А если брать C++ изначально, то высок шанс просрать дэдлайны и там уж точно не до восокой производительности будет — лишь бы хоть как, но работало.
A>Короче, я тоже нелюблю тормозные программы, но делать вывод "это потому, что они написаны на таком-то говноязыке" не стал бы. Можно, разве что, предположить, что порог вхождения в язык сильно ниже, поэтому в проект просочились некомпетентные и/или немотивированные люди и т.п. Но это вопрос в людях, а не в языке как таковом. Если этих же людей заставит писать на С++ будут еще большие тормоза, если вообще что-то работать будет...
A>А С++ не выбирают далеко не только те, которые его не осилили, как тебе могло показаться.

Ты совсем не понял мою мысль. Инструмент определяется не тем осилил/неосилил, а определяется задачей. Причём частенько этот выбор делается не нанятым программистом, а программиста нанимают под изначально выбранный оптимальный инструмент. Так вот на мой взгляд для сектора энтерпрайза java/c# являются оптимальными инструментами, т.к. позволяют реализовать задачи на приличном уровне без поиска высококвалифицированных специалистов — это очень важно для них, т.к. у них it не является профильной деятельностью. У IT компаний же расклад совсем другой...

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

E__>Я далек от пхп, но мне рассказывал знакомый, что оно давно научилось компилироваться. Что-то по типу JIT.

Нет там ничего даже близкого к компиляции. И быстродействие отстаёт не в разы (как Java/C# относительно C++), а в десятки раз! Есть отдельные проекты компилируемого php у Facebook и VK, но там вроде какое-то подмножество языка и в любом случае это уже другие языки.

E__>Ты забываешь еще одну операцию в с++. А именно — подчистка памяти прямо в потоке запроса, что создает дыры в куче, что усложняет и тормозит выделение памяти, и тормозит весь запрос. В то время как GC во-первых, выполняется в другом потоке, не тормозя основные(если писали не дибилы, и использовали только короткоживущие объекты), и память выделяется последовательно, без поиска области, т.е. обычным увеличением указателя. Для веба как раз характерно использование огромного количества объектов, время жизни которых — один запрос. Потому тут управляемая память ложит на лопатку модель памяти с++.

Ха, вот буквально на днях писал об этом мифе и надо же, снова его кто-то озвучил. Даже забавно.

Чтобы не повторяться, оставлю здесь ссылку на сообщение http://rsdn.ru/forum/nemerle/5808797.1

Автор: alex_public
Дата: 06.10.14

.

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

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

A>>Т.е. проблема в недостаточной многословности — должно быть, чтоб с 5 метров глядя на монитор было видно, что у нас тут асинхронщина?

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

Имхо, несколько непрозрачно даже то, что PostData вызывает onData.

_>А в варианте с await (что на C++, что на C#) у нас получается картина, в которой эти части находятся вообще в одном выражении. Т.е. если человек хочет понимать происходящее и при этом пользоваться такой архитектурой, то он должен постоянно держать в голове мысль, что местами между вычислением правой части равенства и собственно приравниванием может произойти произвольное число итераций главного цикла сообщений.

Ну так а это намеренно так сделано. А постоянно держать в голове не нужно — достаточно посмотреть на код, увидеть await и все сразу станет понятно.

_>Хотя конечно если не понимать что происходит и относится к данной технологии, как к некой загадочной .net магии, то инструмент действительно симпатичный выходит...

Не уловил мысль.

A>>Короче, я тоже нелюблю тормозные программы, но делать вывод "это потому, что они написаны на таком-то говноязыке" не стал бы. Можно, разве что, предположить, что порог вхождения в язык сильно ниже, поэтому в проект просочились некомпетентные и/или немотивированные люди и т.п. Но это вопрос в людях, а не в языке как таковом. Если этих же людей заставит писать на С++ будут еще большие тормоза, если вообще что-то работать будет...
A>>А С++ не выбирают далеко не только те, которые его не осилили, как тебе могло показаться.

_>Ты совсем не понял мою мысль. Инструмент определяется не тем осилил/неосилил, а определяется задачей. Причём частенько этот выбор делается не нанятым программистом, а программиста нанимают под изначально выбранный оптимальный инструмент. Так вот на мой взгляд для сектора энтерпрайза java/c# являются оптимальными инструментами, т.к. позволяют реализовать задачи на приличном уровне без поиска высококвалифицированных специалистов — это очень важно для них, т.к. у них it не является профильной деятельностью. У IT компаний же расклад совсем другой...

И, в подтверждение этих слов, сразу вспоминаются Roslyn, Singularity, LMAX Disruptor...

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


E__>>Я далек от пхп, но мне рассказывал знакомый, что оно давно научилось компилироваться. Что-то по типу JIT.

_>Нет там ничего даже близкого к компиляции. И быстродействие отстаёт не в разы (как Java/C# относительно C++), а в десятки раз! Есть отдельные проекты компилируемого php у Facebook и VK, но там вроде какое-то подмножество языка и в любом случае это уже другие языки.

Не буду утверждать — это не мои слова, как я уже говорил, в пхп я ламер.

E__>>Ты забываешь еще одну операцию в с++. А именно — подчистка памяти прямо в потоке запроса, что создает дыры в куче, что усложняет и тормозит выделение памяти, и тормозит весь запрос. В то время как GC во-первых, выполняется в другом потоке, не тормозя основные(если писали не дибилы, и использовали только короткоживущие объекты), и память выделяется последовательно, без поиска области, т.е. обычным увеличением указателя. Для веба как раз характерно использование огромного количества объектов, время жизни которых — один запрос. Потому тут управляемая память ложит на лопатку модель памяти с++.

_>Ха, вот буквально на днях писал об этом мифе и надо же, снова его кто-то озвучил. Даже забавно.

_>Чтобы не повторяться, оставлю здесь ссылку на сообщение http://rsdn.ru/forum/nemerle/5808797.1

Автор: alex_public
Дата: 06.10.14

.

Ты там говоришь про общий случай. Для десктопа — да, модель памяти в с++(стандартная, я в курсе про кастомизацию) выигрывает. Но вот в вебе — нет. Это как раз тот случай, когда GC гораздо выгоднее. ВМ всегда может выбрать свободное ядро проца для сборки мусора, и она в вебе очень легкая(грубо говоря — просто маркается большой блок памяти, который был использован под строки). Много мелких объектов — это немного другой случай. В вебе в основном куча строк, живущих миллисекунды.

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


E__>Страх и ужас. Потому что смесь кода и html — такое было популярно лет 10 назад.
Жуть то какая. Ну вынесу я хтмл в отдельный файл и заинклудю его в код. Что от этого поменяется? "Зато только с++"? Неужели удобно править два файла, прыгая между ними вместо правки одного, где всё сразу перед глазами?
У меня там и sql код. Его тоже в отдельный файл?

E__>Еще и компилить надо, причем С++ — очень долго компилить.
Один проект

# time ./linux-build -d -c
./linux-build -d -c  19,78s user 0,98s system 308% cpu 6,728 total

И второй проект

# time ./linux-build -d -c
./linux-build -d -c  29,59s user 2,03s system 271% cpu 11,638 total

Учти, что это не просто сборка, это полный цикл: подготовка (сборка стилей при помощи lessc в один компактный файл, сборка жабаскрипта при помощи closure-compiler в один компактный файл, препроцессинг исходников своим препроцессором), компиляция и установка (в тестовый или продакшн таргет, зависит от ключа).

E__>Даже ужас типа пхп сейчас ушел от сменения логики и представления в одну кучу. Ибо это реально кошмар.
E__>И строки прямо в коде.
У меня еще и код прямо в строках

  CMSDB_R article = CMSDB_Q("single_article", CMS_SQL_TEXT(
                              select
                            /* 0*/ articles.caption,
                            /* 1*/ articles.text,
                            /* 2*/ to_char(articles.publication_timestamp, 'YYYY.MM.DD'),
                            /* 3*/ articles.id,
                            /* 4*/ articles.image_id,
                            /* 5*/ media.caption,
                            /* 6*/ media.path,
                            /* 7*/ articles.id
                              from articles
                              left join media on media.id = articles.image_id
                              left join divisions on divisions.id = articles.division_id
                              where    articles.class=$1
                                   and articles.url_part=$2
                                   and articles.division_id=$3
                              group by articles.id, divisions.id, media.id;),
                          (m_articleType)
                          (urlPart)
                          (currentDivisionID()));
  m_currentArticleID = article[0][7].as<std::string>();
  putBaseHeader();
  HTML
  (
    <!++
        <div class='article'>
          <table class='article'>
            <tr>
              <td rowspan="2" class='thumbnail'>
                <async_image_with_modal_preview++ [++tn_<v++ article[0][4].as<std::string>() ++v>++] [++thumbnail++] [++full++] [++<v++ article[0][6].as<std::string>() ++v>++] [++<v++ article[0][5].as<std::string>() ++v>++]>
              </td>
              <td class='date'><v++ (userIsLoggedOn() ? <s++<span class='manage'><a href=/admin/++s> + m_articleType + <s++/edit/++s> + m_currentArticleID + <s++>Изменить</a></span>++s> : <es++>) ++v><v++ article[0][2].as<std::string>() ++v></td>
            </tr>
            <tr>
              <td class='caption'><v++ article[0][0].as<std::string>() ++v></td>
            </tr>
            <tr>
              <td colspan="2" class='text'><v++ article[0][1].as<std::string>() ++v></td>
            </tr>
            <tr>
              <td colspan="2">
                <div id='articlegallery' class='articlesline'></div>
                <thread_load++ [++'/<v++ m_articleType ++v>/articlegallery/<v++ m_currentArticleID ++v>'++] [++articlegallery++]>
              </td>
            </tr>
            <tr>
              <td colspan="2">
                <div id='articlenews' class='articlesline'></div>
                <thread_load++ [++'/<v++ m_articleType ++v>/articlenews/<v++ m_currentArticleID ++v>'++] [++articlenews++]>
              </td>
            </tr>
            <tr>
              <td colspan="2">
                <div id='articlearticles' class='articlesline'></div>
                <thread_load++ [++'/<v++ m_articleType ++v>/articlearticles/<v++ m_currentArticleID ++v>'++] [++articlearticles++]>
              </td>
            </tr>
          </table>
        </div>
    ++!>
  );
  putBaseFooter();

E__>Представь, что тебе нужно будет в готовом продукте добавить выбор языка — например, один из региональных языков России. Или тот же английский.
Ничего сложного, только рутины больше. И несколько вариантов решения: от генерации кода для каждого языка в отдельности до использования жабаскрипта для подстановки перевода уже у коиента. Я бы например сделал генерацию кода для каждого из поддерживаемых языков, было бы интересно

E__>Да тут недостатков можно тысячи найти только по этому куску.
Осторожнее, ты описываешь слона, ощупывая его хвост.

E__>Не говоря уже о том, что выглядит это все как полный пипец, и читать это невозможно.
А приведенный выше кусок? Тоже невозможно?

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

E__>А в с++ все unsafe.
Как страшно жыть....

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

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

A>Имхо, несколько непрозрачно даже то, что PostData вызывает onData.

Оно и не вызывает (это же невозможно, из разных потоков). Оно оставляет сообщение, а потом цикл обработки сообщений нашего ui потока видит его и соответственно запускает OnData.

_>>Хотя конечно если не понимать что происходит и относится к данной технологии, как к некой загадочной .net магии, то инструмент действительно симпатичный выходит...
A>Не уловил мысль.

Я про тех, кто вообще не понимает как внутри работает await/async — для них данная архитектура и не должна казаться запутанной, т.к. в "клиентской" части там всё выглядит простенько.

A>И, в подтверждение этих слов, сразу вспоминаются Roslyn, Singularity, LMAX Disruptor...

Непонятно только в чью пользу идут подобные аргументы. )))

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

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

За что я ненавижу аутсорсинговое системное администрирование. Взгляд со стороны клиента

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

E__>Ты там говоришь про общий случай. Для десктопа — да, модель памяти в с++(стандартная, я в курсе про кастомизацию) выигрывает. Но вот в вебе — нет. Это как раз тот случай, когда GC гораздо выгоднее. ВМ всегда может выбрать свободное ядро проца для сборки мусора, и она в вебе очень легкая(грубо говоря — просто маркается большой блок памяти, который был использован под строки). Много мелких объектов — это немного другой случай. В вебе в основном куча строк, живущих миллисекунды.

С такой формулировкой согласен. Я просто хотел уточнить, что если нужна максимальная производительность, то и на сервере это опять же будет C++ (а не Java/C#), только с нестандартными аллокаторами. )