X_OSL 13 июл 2015 в 12:57

Выбор между C++ и C#

8 мин

300K

C# * C++ * Анализ и проектирование систем *

Из песочницы

-12

484

Комментарии 484

BOBS13 13 июл 2015 в 13:14

Анализ конечно хороший в статье, но я почувствовал огромный скептицизм и недооцененность в сторону C#.

impwx 13 июл 2015 в 13:34

На мой взгляд, анализ крайне субъективный, и автор вместо конкретных примеров просто переозвучил распространенные стереотипы: C++ побыстрее (и не такой страшный, как кажется), а C# поудобнее (но не настолько удобнее, как кажется).

X_OSL 13 июл 2015 в 19:08

Анализ безусловно субъективный, но основан на практике по большей части. Я хотел не вдаваться в частности, а предоставить общее видение ситуации. Можно было бы детальнее расписать пункты с конкретными примерами, но думаю это сильно бы утяжелило статью.

У меня действительно есть некоторый скептицизм относительно C#, возможно он вызван завышенными ожиданиями от С# ранее.

X_OSL 13 июл 2015 в 19:45

Я понимаю, что болшая часть Windows разработчиков аудитории сайта, предпочитают C# в силу тех или иных причин, я и сам недавно его предпочитал.
Но я хотел бы зародить сомнения в том, что C# является столь перспективным и показать некоторую недооцененность
С++, сложившуюся за последние 5-10 лет.

lair 13 июл 2015 в 19:47

Вот как раз с перспективами у C# (и вообще .net) все неплохо, учитывая, что под перспективами вы понимаете параллельные вычисления, а в .net над этим активно работают.

X_OSL 13 июл 2015 в 20:06

Параллельные обработки часто упираются в синхронизацию и доступ к ограниченным ресурсам. И тут становится крайне важным быстро обрабатывать такие ситуации, что требует оптимизации. А поскольку возможности по оптимизации managed кода ниже, вполне возможно что это станет узким местом, избавиться от которого можно только перейдя на unmanaged решения.

lair 13 июл 2015 в 20:08

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

… или перехода на решения с минимумом синхронизации. На десктопе это, правда, в меньшей степени критично, на мой вкус, но тут вообще все очень занятно даже с банальной точки зрения «а зачем нам столько производительности».

X_OSL 13 июл 2015 в 20:48

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

В целом, я конечно согласен, что по возможности нужно переходить на решения с минимумом синхронизации, но мои опасения в том, что перейти на них можно далеко не везде.

lair 13 июл 2015 в 20:50

Мне кажется минимум синхронизации возможен только в очень изолированных задачах (чисто математичаских например).

А тем не менее, сейчас такие решения активно используются для LOB-приложений.

Далее, если говорить о приложениях для пользователя — всегда есть метрика отзывчивости приложения на ввод пользователя. В таких ситуациях многопоточность может больше мешать чем помогать, ведь в пределе для максимально быстрого отклика (в виде результата, а не в виде прогрессбара)

Пожалуйста, не путайте отзывчивость (т.е., скорость отклика приложения на действия пользователя) с производительностью (т.е., скоростью получения им результата).

X_OSL 13 июл 2015 в 21:01

Посмотрим какую долю и какого рынка займут LOB-приложения.

Я не путаю отзывчивость и производительность, я говорю что часто для отзывчивости важна производительность. Ведь существуют операции где нельзя показывать прогрессбар, а нужно сразу реагировать на ввод, например изменением модели или каких-то параметров сцены.

lair 13 июл 2015 в 21:26

Посмотрим какую долю и какого рынка займут LOB-приложения.

Уже заняли, стопроцентную. LOB — line-of-business, приложение, выполняющее основные задачи предприятия.

Ведь существуют операции где нельзя показывать прогрессбар, а нужно сразу реагировать на ввод, например изменением модели или каких-то параметров сцены.

Существуют. Но сколько их в процентах от всего ПО?

X_OSL 13 июл 2015 в 21:56

Все таки интересно какого именно рынка заняли 100% долю LOB приложения.

Относительно частоты задач где очень желательна быстрая реакция приложения: CAD область, работа с музыкой и видео, веб браузеры, терминалы ввода данных, игры, думаю кстати что если из проектов по созданию дополненой реальности что-то выстрелит — то там определенно реакция будет критична.

Какой процент таких задач в ПО? Возмонж не очень большой, но далеко не нулевой. И если критично избежать ощущения тормознутости приложения, эти задачи придется решать…

lair 14 июл 2015 в 08:09

Все таки интересно какого именно рынка заняли 100% долю LOB приложения.

Рынка приложений для бизнеса, очевидно. Как игры заняли 100% рынка игр.

Относительно частоты задач где очень желательна быстрая реакция приложения: [...] веб браузеры, терминалы ввода данных

В браузерах и терминалах ввода данных есть I/O, которое доминирует (должно доминировать) над процессорным временем. И здесь — с точки зрения скорости реакции — платформа, которая умеет нативно (и прозрачно для программиста) работать с IOCP в ощутимом выигрыше.

X_OSL 14 июл 2015 в 08:17

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

Можете охарактеризовать сегмент, в который позиционируются LOB приложения? Есть ли примеры внедрений? Было-бы интересно узнать…

lair 14 июл 2015 в 08:20

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

Серьезно? Ни один известный вам бизнес не использует ERP? CRM? Бухгалтерию в любом виде? Систему управления складом? Интернет-магазин? Систему управления проектами? Систему управления задачами?

X_OSL 14 июл 2015 в 09:21

Я наверное не правильно понял, что вы имеете ввиду под LOB-приложениями. Мне показалось что вы имели ввиду какието специфичные приложения построенные на специфичных технологиях.Я никогда раньше не слышал этот термин, хотя знаком со всеми остальными перечисленными вами терминами.

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

lair 14 июл 2015 в 09:25

Я же вам сразу написал:

LOB — line-of-business, приложение, выполняющее основные задачи предприятия.

en.wikipedia.org/wiki/Line_of_business:

In the context of computing, a «line-of-business application» is one of the set of critical computer applications perceived as vital to running an enterprise.

X_OSL 14 июл 2015 в 09:44

Спасибо, понятно) Это видимо достаточно широкий термин.

Тогда возвращаясь к вопросу о том «минимум синхронизации» используется в LOB приложениях.
Теперь, наконец поняв что вы имели ввиду,- думаю что в любых приложениях пытаются использовать «минимум синхронизации» и это вполне естественно пытаться ее избегать, просто не всегда возможно.

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

prishelec 13 июл 2015 в 13:26

Спасибо автору. Помогло «окинуть » взглядом основные отличия.
Хотя не сказано было про отладку кода, здесь то разбежка в скорости будет существеннее.

X_OSL 13 июл 2015 в 21:15

Пожалуйста.Про отладку я написал в п.5 что С# тут безоговорочно лучше до тех пор пока не нужно отлаживать Mixed код.

Вообще забавно что единственный чисто позитивный комментарий жестно заминусован.

Да, я знаю что фанаты С# и Microsoft могут болезненно отнестись к некоторым моим рассуждениям и их количество тут не в пользу моих рассуждений, но я пишу не с целью троллить фанатов, а с целью задуматься о перспективах как С++ так и С# и в конечном счете о перспективах наших приложений и нас в свете их развития.

prishelec 13 июл 2015 в 21:42

Я не являюсь фанатом ни того ни другого. И уважительно отношусь к обоим языкам.
Я сам разработчик в области прикладного и web. Владею навыками как С++ так и шарпа, но прикладное разрабатываю – так уж сложилось на делфях.
Для меня чужое мнение о выборе языка не является конечно решающим, но считаю полезным для общего просвещения прочесть материал от человека имеющего опыт разработки в обеих сравниваемых им языках.

astudent 13 июл 2015 в 13:32

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

qw1 13 июл 2015 в 13:51

также как и на шарпе кроссплатформенную игру под андроид и айос

Тысячи их, на фреймворке Unity

VEG 13 июл 2015 в 14:11

Не только Unity. MonoGame тоже используется.

astudent 14 июл 2015 в 09:15

Я сам использовал и Xamarin, и MonoGame, и могу вас заверить, что это не лучшее решение.
Я же не отрицаю, что нельзя, можно и на плюсах обычное ui-приложение наваять, но этот инструмент не для таких задач.
А вот банковский клиент на Xamarin под три платформы — самое то.

Nagg 15 июл 2015 в 09:02

Может потому, что моногейм не лучшее решение, а не Xamarin? Знаю несколько игр, написаных на Xamarin (не MG) которые работают очень шустро (и новые фичи в них добавляются очень быстро сразу на все платформы ибо C#).

stepanp 14 июл 2015 в 09:25

сама Unity написана на C++

qw1 14 июл 2015 в 10:08

Части .net framework, python и lua написаны на C/C++. Это что-то меняет по отношению к обсуждаемому вопросу?

k12th 13 июл 2015 в 14:27

на шарпе кроссплатформенную игру под андроид и айос

Я вас порадую (а может, и огорчу): xamarin.com.

stepanp 13 июл 2015 в 19:33

xamarin все же не самый лучший выбор для игр

X_OSL 13 июл 2015 в 19:21

UI-приложения бывают разные. Например если это CAD (или другое ресурсоемкое приложение), то исключительно на шарпе он будет очень неэффективный (медленный и часто прожорливый).
Бывает такие приложения сводится к компромисному решению, когда в одном приложении собирается нативный код для рендеринга и ресурсоемких задач, а C# для UI.
Все это приводит к Mixed коду который отлаживать часто хуже чем нативный C++ код. Про частные проблемы с Mixed кодом можно написать достаточно много, но это за рамками статьи.

Razaz 14 июл 2015 в 08:00

WPF в Autocad так та…
Странное заблуждение по части прожорливости — не плодите объекты бездумно и все будет ок.
Такими темпами можно и до ассемблера опуститься. Вот еще на почитать — Numeric performance in C, C# and Java

DancingOnWater 14 июл 2015 в 08:15

Уверены?
forums.autodesk.com/t5/tag/Qt/tg-p www.nixp.ru/news/10377.html да и среди вакансий есть псециалисты по Qt

Razaz 14 июл 2015 в 08:23

И? с 2009 года морда Autocad перепилена на WPF. MS нанимает спецов по Linux — пилят свой дистр?
Можете ради интереса погуглить Autocad + WPF.
Интерфейс AutoCad 2009 построен на WPF

X_OSL 14 июл 2015 в 08:31

Autocad перепилена на WPF
Чуть точнее — на WPF в нем добавлен рибон и кнопка «пуск» + несколько _новых_ диалогов написаны на WPF. Больше WPF там нет. Примечательно, что далеко не все новые диалоги с 2009 года были построены на WPF. И разумеется к рендерингу сцены WPF не причастен вообще.

Razaz 14 июл 2015 в 08:39

Одновременно используется одна из новых возможностей упрощенного хостинга Direct3D сцен в рамках приложения для той части, где визуализируются создаваемые модели.

Только сейчас весь гугл закакан туториалами о том как хостить WPF в автокаде во всех возможных местах) Если научились делать игры на C# так что GC не мешает, то уж UI нарисовать — не проблема. В целом, я бы на вашем месте обсуждал тему десктопных приложений на JS, так как в 90% случаев C#+Java не оставят шансов C++ на сервере и клиенте(ИМХО).

X_OSL 14 июл 2015 в 10:08

Хостинг WPF для сцены в Автокаде не используется. Максимум для превью в тултипов, но это вряд-ли можно назвать хостингом Direct3D сцен.

Насчет игр, пока не видел тяжелых 3D игр на C#, все(что я знаю) топовые 3D игры — исключительно С++. Если у вас есть примеры релизов чего-нибудь уровня GTA4,5\Fallout\Battlefield на C# — очень хотелось бы увидеть, напишите пожалуйста.

Десктопные приложения на JS я бы вряд-ли ожидал. Я не спорю, что например на связке HTML+JS и правильном подходе можно достичь производительности не многим меньше чем на связке WPF + C#, но все-таки для interoperability JS мне кажется плохой вариант, да и инфраструктура JS библиотек недотягивает ни до С# ни до С++ в области за пределами написания веб клиентов.

Razaz 14 июл 2015 в 10:34

У вас есть исходники Автокада?

C# for Gaming
«Тяжесть игры» это что? Если вы про рендер — то спору нет. Но тут и C++ не всегда хорош) Если про логику — то разницы особой нет. Вон на Unity шлепают фигалионы игр. Как Мигель договорится то и в UE появится поддержка C#.

C# прекрасно уживается вместе с C++ как в движках так и в тулинге и на серверах.

ORLY?
Atom, VS Code нативные приложения в Win на XAML+JS?

X_OSL 14 июл 2015 в 11:15

Зачем исходники, когда есть дизассемблер, Spy++ и reflector ?:)

Под тяжестью конечно рендер в первую очередь имею ввиду.

Atom, VS Code нативные приложения в Win на XAML+JS — не встречался с этим. не могу судить, если есть примеры приложений обещаю посмотреть.

Razaz 14 июл 2015 в 11:33

Я не берусь судить весь их codebase по Spy++ )

Редкое использование C# в рендеринге в первую очередь из-за необходимости RAII и нежелательности доп. интеропа. Тут уж разные платформы и особо ничего не попишешь(разве что Unsafe, но расходы на интероп остаются)
Но и тут уже есть прогресс — Paradox 3D Engine Trailer
Paradox Game Engine. Плюс не списывайте со счетов .Net native. Поглядим еще как пойдет ;)

Активно педалируемая тема — берем V8 и хостим в него наше приложение на JS — Profit.

X_OSL 14 июл 2015 в 13:55

Редкое использование C# в рендеринге в первую очередь из-за необходимости RAII и нежелательности доп. интеропа.

Это тоже правда, но знаете, мне тут как-то попалась библиотека для чтения и рендера DWG написанная на .net (конкретно вот эта: https://www.woutware.com/cadlib/4.0)
Интерес ее в том, что она действительно работает с файлом и рендерит его на .net

И вот она открывала не очень сложный DWG значительно медленнее AutoCAD-а, разница была многократной. WPF рендеринг в библиотеке работал ужасно медленно, впрочем как и GDI+ рендеринг (обычные pan\zoom безбожно тормозили)

Единственный рендеринг работающий в ней более менее достойно был рендеринг с помощью OpenGL, он хотя и строил сцену дольше остальных но зато потом работал с ней довольно быстро. При этом именно он был написан через импорты opengl32.dll, то есть по сути и не был .net овским.

Возможно этот пример один из худших… Но в частности он вызывал у меня глубокий скептицизм относительно использования .net для работы с кадовской графикой.

Помню еще в 2005 году были библиотеки для разработки на C# 3D приложений, но с тех пор прошло 10 лет, а любая графика чуть потяжелее как писалась на С++ так и пишется, врядли это иррационально.

Razaz 15 июл 2015 в 09:58

Вы не думали что просто через одно место написана? Можно и на C++ Написать так, что будет ползать.
Вот небольшой пример — Debunking C# vs C++ Performance

У C++ нет явных преимуществ без RAII и возможности работы с памятью. Небольшой оверхед есть из-за рефлекшена, но он же иногда помогает компилятору лучше оптимизировать код чем на C++. Плюс советую посмотреть .Net Native.

С++ нишевое решение для специфических задач, где необходим очень жесткий контроль ресурсов, да и то при большом желании — unsafe в помощь.

В общем можете почитать достаточно подробные ответы на SO — C++ performance vs. Java/C#

X_OSL 15 июл 2015 в 10:50

>Вы не думали что просто через одно место написана?
Никакой другой .Net библиотеки решающей ту же задачу я не нашел. Вообще.

>Вот небольшой пример — Debunking C# vs C++ Performance
Это же чистая синтетика в вакууме, работающая сама с собой.
В реальных же задачах нужно достаточно часто работать с системой, где и случаются основные провалы у С# на маршалинге

>.Net Native.
Интересно. Пара глупых вопросов по нему: как его потом дебажить? И можно ли заставить студию строить прямо в него, а не в IL?

>В общем можете почитать достаточно подробные ответы на SO — C++ performance vs. Java/C#
Кажется читал как-то, но ссылка хорошая, спасибо.

Razaz 15 июл 2015 в 11:18

И? Причем тут выводы о быстродействии .Net на основе левой либы?

Это пример, показывающий что говнокодить можно везде, и вы, возможно сталкивались с этим. Делать выводы на основе этого — глупо.

Google

X_OSL 15 июл 2015 в 12:09

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

>И? Причем тут выводы о быстродействии .Net на основе левой либы?
Я видел и другие библиотеки .net, которые не поразили меня своей производительностью.

Например возьмем WPF, вы тоже скажете что это пример говнокода?
Если нет, то почему у нее такая низкая производительность?

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

Или например WPF рибон, в каком-нибудь автокаде или вашем приложении. Почему переключение между табами идет так долго?

А если взять какую-нибудь библиотеку WPF контролов, например DevExpress, то там с производительностью все будет еще раза в 2 хуже.

Вы можете сказать что C# в этом не виноват, что .net в этом тоже не виноват.
Хорошо, а кто тогда виноват в столь низкой производительности WPF?

Razaz 15 июл 2015 в 12:38

Если вас интересует отладка — Debugging support for .NET Native Preview apps

С чего вы взяли что у WPF низкая производительность? На нем например пишется софт для трейдеров в Дойче Банке ЕМНИП?

Вы серьезно? Для начала соберите свой софт без флага Debug ;)

Не берите DevExpress. Возьмите Telerik или напишите свое.

Вы серьезно думаете что в медленном переключении табов виноват .Net? Еще раз — если вы сталкивались с посредственными результатами — не означает, что .Net медленный. Это то же самое, что сказать — C++ медленный, так как игры на нем тормозят.

X_OSL 15 июл 2015 в 13:38

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

>На нем например пишется софт для трейдеров в Дойче Банке ЕМНИП?
Я очень сильно этому удивился. Может это попил какой-то…

>Telerik
Вполне возможно он заметно быстрее DevExpress, но базовую тормозню WPF он вряд-ли уберет.

>Если вы сталкивались с посредственными результатами — не означает, что .Net медленный
Не подскажите альтернативную UI библиотеку под .net без проблем с производительностью?

Razaz 15 июл 2015 в 14:33

Ваша практика — контрол от DevExpress?

Попил в Дойче — это даже не смешно.

Еще раз повторю — торомозит не WPF, а товарищи, пихающие в ObservableCollection миллион записей по одной.

X_OSL 15 июл 2015 в 15:34

>контрол от DevExpress
У DevExpress медленно работали Tabbed groups, Grid, Property Grid

Чего там в Дойче я не знаю, но у меня тормозит именно WPF, например у моем обычном wpf датагриде нет никаких ObservableCollection, но как только там появляется больше 1000-2000 элементов он начинает тормозить.

Я его профайлил — тормозит обход дерева визуальных элементов и многократные вызовы Measure.Я незнаю зачем так часто и в таком количестве мерить ячейки грида, но я знаю что мой код в этом процессе не вызывался.

Razaz 15 июл 2015 в 19:28

Еще раз — как тормоза DevExpress относятся к .Net? И еще раз — тестить производительность надо без флага Debug.

Может надо понять почему он тормозит при 2000+ элементах? У нас в админке по 10к+ транзакций без тормозов показываются, а у вас простой грид тупит. Может искать проблему в своем коде?

Вот ответ на ваш вопрос — Performance issue with “Measure”

Обычный баг для которого уже давно есть хотфикс. При чем тут .Net то? Как лишние вызовы метода стали являться мерилом производительности платформы?

X_OSL 15 июл 2015 в 19:39

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

Вероятно что то недофиксили и забили, как это принято в Microsoft :(

Razaz 15 июл 2015 в 19:46

Или вы криво построили дерево контролов, проводите лишние модификации дерева.

Может перестанете кидаться голословными утверждениями? После того как вы сделали вывод о тормозах .Net по частому вызову метода Measure в WPF — я бы рекомендовал вам внимательно присмотреться к своему коду.
WPF MeasureOverride called multiple times after multiple PropertyChanged notifications
Optimizing Performance: Layout and Design

X_OSL 15 июл 2015 в 20:14

Да тут собственно и дерева то нет. Я же говорю, только обычный родной WPF датагрид. В нем штук 10 колонок, некоторые из них на основе DataTemplate c одним простым контролом (комбобоксом или datetime picker или numericupdown из codeplex) внутри, остальные колонки стандартные.

Из своего кода только установка ItemSource обычным листом из 1000-2000 элементов и xaml разметка.

И вот этого уже хватает чтобы контрол скролился с сильными лагами, а в профайлере были многочисленные вызовы Measure.

Код смотрели многократно — нету там ничего особенного.

Razaz 15 июл 2015 в 20:21

Как нет? Вы точно понимаете как устроен WPF? У кого Measure то дергается? В ответ на какое событие?

Если это грид DevExpress — то к ним и пишите на форум. Опять же WPF и .Net То тут каким местом?

Не поленился, скачал демку Telerik — 1 млн. записей отфильтровались за ~400ms и плавно скролятся.

X_OSL 15 июл 2015 в 20:53

Кроме грида на форме ничего не было, поэтому дерево только грида.
Measure дергается по всей видимости для ячеек грида в ответ на попытку скролить содержимое.

Это стандартный датагрид WPF.

(C DevExpress отдельные проблемы)

Telerik вполне возможно работает лучше — не знаю — не пробовал…

gouranga 15 июл 2015 в 21:48

Я сейчас сделал датагрид, в нем 10,000,000 элементов. И ничего не тормозит, виртуализация работает…

Какая точно была версия фремворка? Как вы добавляли элементы? Просто datagrid.ItemsSource = somelist? Что было внутри того контрола numericupdown смотрели? Как правильно заметил Razaz: Measure у какого элемента дергался и после чего? Если фреймворк был >= 4.5, то какой стоял VirtualizationMode?

Пожалуйста, покажите уже этот код. Хочу понять, что за мистика такая у вас.

qw1 15 июл 2015 в 21:58

А теперь заказчик хочет, чтобы слово Customer было зелёным, а номер за ним — красным. Для этого ячейка темплейтится и в template ставится два TextBlock. Вроде как после этого будет плоховато скроллиться

gandjustas 16 июл 2015 в 00:04

Не будет. Только если ты datatemplate selector применишь, или группировку к элементам и еще в некоторых случаях. А по умолчанию виртуализирует и показывает спокойно хоть миллионы элементов.

qw1 16 июл 2015 в 09:18

После TDBGridEh из дельфи, который стабильно даст 60fps при навигации, wpf-ные гриды оставляют плохое впечатление. Сложно объяснить, но как будто интерфейс лагает, уже в раздумьях не погоняешь Selection по строкам, потому что лаг отклика раздражает.

X_OSL 16 июл 2015 в 09:36

Кстати можете ради интереса попробовать UI из FLTK

Это кросплатформенная С++ библиотека, кстати разработка по ней вполне жива
www.fltk.org/index.php

Там конечно нельзя по-простому делать всякие WPF-овские красивости и нет биндингов, но UI написанный на ней крайне отзывчивый.

qw1 16 июл 2015 в 14:22

К сожалению, на плюсах никто не даст писать gui для enterprise ))

lair 16 июл 2015 в 14:39

Интересно, почему?

qw1 16 июл 2015 в 15:32

Молодёжь не умеет писать на древних языках

lair 16 июл 2015 в 15:33

Ну «даст/не даст» — это обычно начальство, а оно обычно не такое молодое и дерзкое.

qw1 16 июл 2015 в 16:16

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

lair 16 июл 2015 в 16:42

Это заведомо проигрышная стратегия, вне зависимости от языка.

qw1 16 июл 2015 в 18:42

Почему? Вместо нудного клепания тупых формочек и отчётов лучше дать новичкам нечто сложное и важное?

lair 16 июл 2015 в 18:50

Потому что хороший интерфейс — это не тупые формочки и отчеты.

qw1 16 июл 2015 в 19:16

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

Или есть такие скучные направления, как «зарплата и управление персоналом». Там в приложении куча списков сущностей и редакторов для них. Что там можно сделать хорошего и нетупого, кроме как поиграться расположением контролов, размером и цветом кнопочек?

lair 16 июл 2015 в 19:24

Перевести с сущностно-ориентированной парадигмы на задаче-ориентированную, например. Внезапно выяснится, что это далеко не так скучно, как кажется.

qw1 16 июл 2015 в 21:13

Обычно пользователи привыкли работать по стандартам (и это в принципе нормально, годами проверенные способы работы) и от программиста не ждут, что он придумает новые подходы к работе, а если и придумает, скажут — не хотим нового, хотим привычного.

lair 16 июл 2015 в 21:47

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

X_OSL 16 июл 2015 в 15:33

В enterprise отзывчивость интерфейса стоит на одном из последних мест в списке приоритетов.
Ведь тот кто за него платит, и тот кто им пользуется — как правило абсолютно разные люди.
(я возможно немного драматизировал ситуацию, но думаю не сильно)

gandjustas 16 июл 2015 в 14:51

К счастью

gandjustas 16 июл 2015 в 10:08

У меня на WFP 3.5 не было проблем с производительностью грида, 60FPS на современном (на тот момент) компе.

Если чето лагает надо запускать профайлер и смотреть что. Скорее всего перерисовка в несколько слоев.

ЗЫ. Не надо WPF запускать в RDP.

gouranga 16 июл 2015 в 00:10

И… ничего не поменялось.

X_OSL 16 июл 2015 в 05:50

Спасибо, что попробовали воспроизвести.

>Какая точно была версия фремворка?
4.0 и 4.5

>Как вы добавляли элементы? Просто datagrid.ItemsSource = somelist?
да
>Что было внутри того контрола numericupdown смотрели?
Профайлер непосредственно этот контрол не дергал. В каком смысле что внутри?

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

>Если фреймворк был >= 4.5, то какой стоял VirtualizationMode?
Все варианты VirtualizationMode были точно испробованы на 4.0 фреймворке.
На машинах с 4.5 это тоже не помогало. Специфичные только 4.5 режимы не использовались, т.к. нужна была поддержка 4.0

По вашему примеру, важно как минимум поменять:
1. Колонки должны быть не автогенеренные, а явно прописанные в xaml с указанным размером
2. Их должно быть хотябы 10 штук
3. Часть из них, доблжы быть типа datagridtemplatecolumn, c Combobox внутри
4. Колонки должны быть забинжены на данные
5. В гиде должны быть разрешены редактирование и сортировка
— возможно этого минимума хватить чтобы воспроизвести проблему

Можно еще добавить (хотя и не обязательно, и наверное не стоит вам тратить на это время):
1. Визуальные стили на лист
2. Конвертеры в биндинге
3. В идеале добавить datagridtemplatecolumn с datetime picker и numericupdown из codeplex
4. В datagridtemplatecolumn использовать разные темплейты для редактирования и просмотра.

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

gouranga 16 июл 2015 в 08:42

Профайлер непосредственно этот контрол не дергал. В каком смысле что внутри?

В прямом, код смотрели? С учетом, что непонятно, как компонент написан.

Больше всего времяни было кажется в базовой реализации Measure, могу уже не помнить

Вот не понял, в базовой реализации чего и где? Откуда постоянно вызывались Measure и после какого события?

По вашему примеру, важно как минимум поменять:
1. Колонки должны быть не автогенеренные, а явно прописанные в xaml с указанным размером
2. Их должно быть хотябы 10 штук
3. Часть из них, доблжы быть типа datagridtemplatecolumn, c Combobox внутри
4. Колонки должны быть забинжены на данные
5. В гиде должны быть разрешены редактирование и сортировка

Добавил 10 колонок. Остальное и так все было. И ничего не поменялось.

Можно еще добавить (хотя и не обязательно, и наверное не стоит вам тратить на это время):
1. Визуальные стили на лист
2. Конвертеры в биндинге
3. В идеале добавить datagridtemplatecolumn с datetime picker и numericupdown из codeplex
4. В datagridtemplatecolumn использовать разные темплейты для редактирования и просмотра.

1-2. с конвертерами и стилями все ясно. я пытаюсь понять где был затык с Measure.
3-4. проверил с компонентами от Telerik, засунул и в CellTemplate и в CellEditingTemplate, и только в Editing — ничего.

В общем, я думаю что где-то у вас в коде зарылась ошибка. С виртуализацией такой DataGrid вообще не тормозит — визуальное дерево обновляется только для того, чтобы покрыть видимую область. А если поставить

VirtualizingStackPanel.VirtualizationMode="Recycling"

так и вообще визуальное дерево не меняется при перелистывании.

lair 16 июл 2015 в 08:54

На самом деле, там регулярно упоминаются какие-то контролы с codeplex. В них вообще что угодно может быть.

X_OSL 16 июл 2015 в 09:12

>Остальное и так все было.
и datagridtemplatecolumn-ы были и биндинг на контролы в них?

>В общем, я думаю что где-то у вас в коде зарылась ошибка. С виртуализацией такой DataGrid вообще не тормозит — визуальное дерево обновляется только для того, чтобы покрыть видимую область.

Видимо нужно найти время и тот проект, и выцепить грид оттуда

X_OSL 16 июл 2015 в 16:27

А вот кстати воспроизвел, на обычном гриде, даже без темплейтных колонок.
Вот скриншот

i61.tinypic.com/f00uwo.png

Снапшута профайлера во время скроллинга вертикальным скроллером вверх и вниз. Лаги при этом страшные(без профайлера разумеется)

(почемуто у меня нормально картинка в пост не вставилась :( )

X_OSL 16 июл 2015 в 16:36

Да и еще проект тестовый, очень быстро набросан, кода почти нет

s000.tinyupload.com/?file_id=09607171972593390390

Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.

X_OSL 16 июл 2015 в 16:44

Перезалил скриншот профайлера, тот както плохо открывается

s30.postimg.org/4lvgfhrnl/Measure.png

X_OSL 16 июл 2015 в 17:05

В общемто тут нет ни темплейтных колонок, ни codeplex-а, ни стилей.

Тут вообще ничего нет, только сгенеренные данные, и достаточно много колонок (автогенеренные колонки я не выключал)

Виртуализация — включена.

X_OSL 16 июл 2015 в 17:51

Показываю код

s000.tinyupload.com/?file_id=09607171972593390390

Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.

А ниже можно еще найти скриншот профайлера.

X_OSL 16 июл 2015 в 19:49

Razaz, я выложил тестовый проект с тормозным гридом (на чистом WPF), и скриншот профайлера во время скрола. Можете посмотреть и вынести свое суждение относительно причин тормозни, былобы очень интересно узнать.

X_OSL 14 июл 2015 в 08:24

WPF в Autocad — да это реальность, но там есть и Windows Forms, и MFC даже на html+javascript некоторые контролы написаны.
Qt в виндовом Autocad я не замечал, но возможно они работают над тем чтобы уйти от зоопарка Microsoft контролов, кто знает…
Так или иначе, под MacOS есть своя версия Autocad и она написана не на UI от Microsoft.

Razaz 14 июл 2015 в 08:31

Спору нет. Просто у них скорее всего ядро и морды для каждой платформы — под Win — скорее всего перепиливают на WPF+XAML. Ядро хоть на бэйсике можно написать, один фиг все будет слито на видеокарту для рассчета.

maaGames 13 июл 2015 в 13:33

Дочитал до пункта про отсутствие сборки мусора в С++ и ринулся комментировать, извините.

1. Сборщик мусора в С++ НЕ НУЖЕН! Точка.
2. Если (ЕСЛИ!!!) сборщик мусора в С++ всё-таки нужен (прям необходим, ага, RAII для слабаков, дайте сборщик мусора, даже два), то этот самый сборщик мусора вполне можно реализовать самостоятельно. Т.к. самостоятельно реализовать сборщик мусора такой программист не сможет (такой — которому нужен сборщик мусора), то его можно взять из библиотеки Loki, например. Александреску не только с шаблонами извращается. Его вкусы могут показаться… хотелось вставить картинку про 50 оттенков, но лучше не буду.)

Пока писал комментарий, случайно прочитал пункт 9. Опровергну. На С++ можно скомпилировать приложение БЕЗ рантайма. Это будет извращение похлеще реализации сборщика мусора, но это возможно.

Добавлю ещё к выводу: С++ и С# это разные языки с разными задачами. Их бесполезно сравнивать. Вот замените цвет текста у кнопки на С++ и С#. А после нажатия на эту кнопку, производится поиск обратной матрицы размером 100000*100000. И какой язык для этого лучше? ;)

BOBS13 13 июл 2015 в 13:50

Меня больше всего поразило, записанный в минус отсутсвие глобальный процедур и функций в C#. Это огромный плюс. Это ООП, какие глобальные процедуры.

kekekeks 13 июл 2015 в 15:34

Есть using static же.

BOBS13 13 июл 2015 в 15:36

Пока до нас докатится C#6, много еще ждать. Поэтому пока о нем умолчим.

kekekeks 13 июл 2015 в 15:38

Он прекрасно работает даже при использовании .NET 2.0 в качестве целевого фреймворка. Я не вижу ни одной причины не использовать его уже сейчас и начал миграцию всех проектов ещё пару месяцев назад.

НЛО прилетело и опубликовало эту надпись здесь

atd 13 июл 2015 в 13:54

> На С++ можно скомпилировать приложение БЕЗ рантайма. Это будет извращение похлеще реализации сборщика мусора, но это возможно.

Есть ещё один вариант: слинковать рантайм в свой бинарник, это очень просто, но имеет свои плюсы и минусы

DancingOnWater 13 июл 2015 в 13:55

в Qt замена цвета кнопки — плевое дело, ну а для матриц есть Eigen. Так что в данном сравнении C# проигрывает C++ по всем статьям.

maaGames 13 июл 2015 в 14:15

Да, я несколько не корректно выразился. Разумеется, я имел в виду замену цвета текста кнопки на чистом WinAPI (к С++ вообще никакого отношения, (MF)Сишечный код).

stepanp 13 июл 2015 в 17:24

Сборщик мусора нужен чтобы собрать эту статью

X_OSL 13 июл 2015 в 19:28

1. Может быть он и не нужен, но его отсутсвие влечет дополнительные требования к разработчикам, что так или иначе удорожает разработку.
2. Это хорошо.

На счет разних задач С++ и С# я соглашусь. Но вопрос в том где проходит линия раздела этих задач?
Ведь широкий круг задач успешно решаем и на С++ и на С# соизмеримым количеством времяни разработчика…

stepanp 13 июл 2015 в 19:39

В задачах требующих высокой производительности, наличие gc наоборот усложняет разработку

grossws 14 июл 2015 в 01:00

Сильно зависит от задачи. И того, что понимать под производительностью (throughput или latency). В комментариях к этому топику их периодически путают.

gandjustas 14 июл 2015 в 02:03

А можно пример, какие задачи вы имеете ввиду? И какую производительность вы имеете ввиду?

Я видел несколько задач, в которых C++ «рулит»:
1) Числомолотилки, только в них не C++, а скорее C_с_классами. Да и рулит C_c_классами по одной причине — более крутые компиляторы, которые арифметику оптимизируют до невозможности. Использование любых фишек C++ (динамическое выделение памяти, stl и прочие радости) убивают быстродействие.
2) Всяческий embedded с очень ограниченными ресурсами, тут по понятным причинам надо контролировать каждый байт. Но такого embed_а все меньше. Устройства дешевеют и получают больше ресурсов. Пару сотен МБ уже не редкость, а на таких объемах даже JS работает.

Задачи в которых реально C++ рулит:
1) Визуальные редакторы, браузеры — любые десктоп-приложения с большим количеством объектов. Так как большинство GC не проектируются для работы с миллионами мелких объектов. Но и C++ тоже не сильно рулит, нужно много приседаний с кастомными аллокаторами, иначе стандартный механизм выделения памяти убивает все быстродействие
2) Там где нужно «пидарасить такты» — две известные мне задачи — разработка БД и HFT. Тут чем быстрее, тем лучше, достаточного быстродействия для таких задач не существует.
3) Всяческие COM-компоненты (плагины) для проводника, офиса, IE. Тупо уменьшают время загрузки.

Во всех остальных случаях востребованность C++ преувеличена.

Вкратце нужно просто посмотреть где «быстродействие» выше воспринимаемого человеком порога будет конкуретным преимуществом — там и нужен C++. В остальных случаях C# достаточно.

X_OSL 14 июл 2015 в 04:19

Хороший комментарий, отражающий давольно полно текущую ситуацию.
Я бы добавил еще один момент: кроме задачи стоящей в данный момент неплохо бы учитывать и перспективы приложения (что актуально в долгосрочных проектах и относительно крупных) — может стать что оно попадет например в одну из перечисленных категорий.

gandjustas 14 июл 2015 в 16:47

К счастью, не может. Такие вещи как базы, браузеры и hft не рождаются в процессе эволюции прикладных приложений, всякие плагины тоже. И вообще такие задачи редки, вот вы например что писали на c++?

Razaz 14 июл 2015 в 08:03

Apache Cassandra? HBase? Hadoop?

stepanp 13 июл 2015 в 19:45

Четкой линии водораздела не существует, выбор технологии решается для каждой задачи(проекта) отдельно. И для этого уж точно не нужно делать «анализ» на пятьсот пунктов. Если это конечно не троллинг ;)

X_OSL 13 июл 2015 в 19:56

Я часто сталкивался с ситуациями, где выбор падал на C#, даже без мысли относительно анализа и мне не кажется такой подход правильным.
С другой стороны, я сталкивался и с ситуациями, где С# проекты портировалисть на С++, хотя ранее выбор безоговорочно падал на C#.
Мне кажется портирование с C# на С++ может стать трендом будущих разработок.

Хотя конечно можете считать это троллингом:) Но я правда думаю что вероятность развития трэнда по переходу с С# на С++ достаточно высока.

stepanp 13 июл 2015 в 20:08

Тренд по переводу проектов с шарпов на плюсы может возникнуть вследствие тренда бездумного выбора языка под проект. Сталкивался с ситуациями когда выбор падал на С++ просто «патамушта не люблю сишарп» или «не люблю языки с gc» или «проприетарщина отстой».

X_OSL 13 июл 2015 в 20:30

Видимо я сталкивался с ситуациями, где бездумно выбирали С# «патамушта можно писать быстрее», и вообще «все что надо есть».
И этот расчет был верен по своему. Если бы в 2000х годах производительность железа росла бы также как м в 90х, никаких С++ 0x мы бы не увидели. Но реальный рост производительности сильно замедлился…

nomit 14 июл 2015 в 03:30

Мне кажется портирование с C# на С++ может стать трендом будущих разработок.

Ох уж эти сказочки! Ох уж эти сказочники!

Вы как будто с другой планеты. Вряд ли заказчики будут платить за такое, дешевле докупить оперативки или уйти в облака, чем переписывать проект с одного языка на другой. Причем необходимость такая может понадобится только в реал-тайм системах требующих молниеносный отклик, но во первых такие системы скорей всего уже написаны на языке под конкретное железо, а если нет то их на столько малый объем, что назвать это портирование, с С# на С++, тредом язык не повернется сказать.

PS. Я все же допускаю, что вы из будущего. В котором к власти во всем мире пришел Тиран с фетишизмом к С++. Был издан закон об святой инквизиции неугодных языков.

X_OSL 14 июл 2015 в 06:52

Совсем не факт, что железо будет докупить дешевле. Например даже скромные +500$ на рабочее место в большой компании дадут десятки, а может и сотни тысяч, и это не говоря о потреблении энергии и других конкурентных преимуществах. А повально уходить в облака большие компании пока не торопятся…

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

Таким образом перепись критичных к производительности компонентов вполне может стать экономический выгодной. Насчет «тренда», возможно я несколько преувеличил, но думаю что как минимум явление переписи библиотек с С# на С++ будет достаточно распространенным в будущем.

nomit 14 июл 2015 в 06:58

+500$ рабочее место(не знаю что за компания такая? со специалистами студентами?) * на количество месяцев потраченное на переписку продукта.
Как раз в современном мире как раз тенденция докупить железа. чем нанимать штат специалистов. Да еще и во время портирования не о каких новых фичах и быть не может, а бизнес к такому крайне скептично относиться.

X_OSL 14 июл 2015 в 07:22

Вы наверное неправильно поняли что я написал.
Я писал про затраты на железо в +500$ на рабочее место, а не про затраты на разработку. Затраты на разработку будут другими, но если разработчиком многократно меньше чем пользователей они вполне могут окупиться.

Да и по поводу переписи продуктов. Продукт может быть дешевле переписать, чем вообще остаться без ниши на рынке.

lair 14 июл 2015 в 07:04

А какой смысл переписывать «библиотеку» с C# на С++? Большая часть внешних зависимостей в .net — инфраструктура, она ничего от этого не выиграет.

X_OSL 14 июл 2015 в 07:48

Зависит от интерфейсов библиотеки и того что именно делает библиотека.
Математика например слабо завязана ни инфраструктуру. Работа с файлами может сравнительно легко переведена на схожую C++ инфраструктуру. Работа с не-.net библиотеками «сама просится» к такому переводу.

Конечно для .net есть некоторая уникальная инфраструктура, но все-таки многое из .net инфраструктуры имеет адекватные аналоги для С++ (что не всегда верно в обратном направлении)

lair 14 июл 2015 в 07:52

Математика например слабо завязана ни инфраструктуру.

И зачем переписывать математическую библиотеку с C# на C++ — на плюсах своих библиотек мало?

Работа с файлами может сравнительно легко переведена на схожую C++ инфраструктуру.

Весь «новый» I/O в .net сделан с учетом TPL, и переписать это на C++ (с сохранением внешнего интерфейса) просто не выйдет (точнее, будет неоправданно дорого).

X_OSL 14 июл 2015 в 08:09

И зачем переписывать математическую библиотеку с C# на C++ — на плюсах своих библиотек мало
Имеется в виду случай, если это ваша библиотека, которую разработали вы для ваших расчетов.

Весь «новый» I/O в .net сделан с учетом TPL
Проблема не в I\O, а в быстрой раскладке файла в тот вид с которым вы сможете работать.

lair 14 июл 2015 в 08:10

Проблема не в I\O, а в быстрой раскладке файла в тот вид с которым вы сможете работать.

И это принципиально непотоковая задача?

X_OSL 14 июл 2015 в 09:12

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

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

Да и если все это удастся сделать, на потоках С++ параллельное решение все-равно будет работать быстрее…

lair 14 июл 2015 в 09:14

Я не про те потоки, которые threads, я про те, которые streams — т.е., про чтение/запись файла.

X_OSL 14 июл 2015 в 09:31

Я чаще сталкивался с тем что производительность упирается не в скорость работы stream-a, а в скорость обработки прочитанного из него.

Поэтому и пишу что с файлами часто проблема в производительности обработки, а не в самом I\O.

lair 14 июл 2015 в 09:35

Я чаще сталкивался с тем что производительность упирается не в скорость работы stream-a, а в скорость обработки прочитанного из него.

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

gandjustas 14 июл 2015 в 16:53

За время чтения с диска одного мегабайта можно около 1000 раз отсортировать этот мегабайт в памяти. Поэтому упереться в обработку можно только на очень маленьких файлах. Но тогда и время обработки очень маленькое будет.

X_OSL 14 июл 2015 в 17:07

Как правило, задачи стоят несколько сложнее чем сортировка мегабайта во время чтения.

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

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

gandjustas 14 июл 2015 в 19:06

Как правило, задачи стоят несколько сложнее чем сортировка мегабайта во время чтения.

Например?

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

Большинство алгоритмов архивирования потоковые, им не надо читать весь файл. То есть вполне можно разархивировать во время чтения.

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

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

X_OSL 14 июл 2015 в 19:30

Откуда вы взяли все эти цифры, как вы считали?
Почему вы пропустили этап создания объектов из прочитанных данных?

lair 14 июл 2015 в 19:42

Потому что в среднем этот этап занимает пренебрежимо мало времени даже по сравнению с сетевом i/o, не говоря уже о дисковом.

X_OSL 15 июл 2015 в 06:01

Вот смотрите, HDD умеет отдавать данные со скоростью примерно 80 Mb/s, SSD так вообще 300 Mb/s, эта скорость вполне реальна если просто брать данные с носителя в память как есть.

И вы хотите сказать что сжатый структурированный структурированный поток данных распаковывается и раскладывается в объектную модель параллельно процессу чтения, с той-же скоростью? Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?

И да, простой пример: по такой логике копирование архива и распаковка архива должны занимать почти одинаковое время, но это не так.

vedenin1980 15 июл 2015 в 06:38

Вот смотрите, HDD умеет отдавать данные со скоростью примерно 80 Mb/s, SSD так вообще 300 Mb/s, эта скорость вполне реальна если просто брать данные с носителя в память как есть.

Только при последовательном доступе и если HDD/SSD не занят другими процессами. Если на сервере десятки приложений, sql база данных, nosql база данных и все терзают один жесткий диск, то цифры будут куда более печальными.

И вы хотите сказать что сжатый структурированный структурированный поток данных распаковывается и раскладывается в объектную модель параллельно процессу чтения, с той-же скоростью?

С намного большей скоростью, были задачи интеграции когда скорость достигала нескольких Гб/сек на сервере занятом десятком других задач. Базы данных, интеграция, любые высоконагруженные приложения ВСЕГДА утыкаются в скорость чтения с диска и приходится танцевать с кэшами в памяти и кластерами серверов.

Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?

Любые серьезные задачи интеграции, Big date и т.д. Из практики потоковое архивирование/разархивирование каким-нибудь gzip'ом выполняется намного быстрее чтения/записи неархивного файла.

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

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

X_OSL 15 июл 2015 в 06:57

> если HDD/SSD не занят другими процессами
Я именно об этом и говорю. Не надо занимать другими процессами — и у вас будет производительность, а если полезете в параллель — получите падение производительности везде, так как железо будет дольше переключаться, чем передавать вам данные. (кстати с SSD ситуация лучше в этом плане)

> Базы данных, интеграция, любые высоконагруженные приложения ВСЕГДА утыкаются в скорость чтения с диска
Я разбирал другой пример. Упакованный структурированный файл, который нужно разложить в объектную модель, а не storage базы данных формата оптимизированного до такой степени, что времени на его обработку практически не требуется. Конечно там будет все упираться в железо.

>Распаковка архива в памяти выполняется намного быстрее чтения с диска почти всегда (есть совсем уж медленные форматы, но их в интеграции не используют), основное замедление происходит когда пытаешься записать распакованный архив на диск.
Я согласен с тем что сравнение с копированием не совсем корректное, если объем распакованных данных много больше упакованных.

Но мы можем упаковать например какой-нибудь divx\xvid AVI — он практический не сожмется, поэтому разницы времени записи между копированием и распаковкой не будет. Однако почему-то он будет дольше распаковываться, чем просто копироваться…

vedenin1980 15 июл 2015 в 07:10

Упакованный структурированный файл, который нужно разложить в объектную модель, а не storage базы данных формата оптимизированного до такой степени, что времени на его обработку практически не требуется. Конечно там будет все упираться в железо.

Я тоже про это говорил, на самом деле объектная модель в памяти создается быстро были бы данные, забить 10 Гб объектами меньше чем за секунду не так сложно.

gandjustas 15 июл 2015 в 08:08

HDD 80МБ в секунду? Да вы оптимист, реально для HDD рассчитывать на 10мб в секунду в лучшем случае. А ssd вам еще никто не даст, все SSD давно под sql server задействованы.

10МБ в секунду не означает, что мы секунду ждем, в потом 10мб обрабатываем. Мы читаем 100КБ, а пока ждем буфера обрабатываем предыдущие 100КБ прочитанных.

То есть суммарное время при потоковой обработке растет незначительно.

И да, простой пример: по такой логике копирование архива и распаковка архива должны занимать почти одинаковое время, но это не так.

В большинстве архиваторов распаковка это — чтение всего архива в память, работа алгоритма распаковки, запись кучи отдельных файлов на диск. Самая долгая операция — запись.

При копировании файла используется как раз потоковая модель, поэтому суммарное время возрастает не сильно (если диски разные).

X_OSL 15 июл 2015 в 16:57

>HDD 80МБ в секунду? Да вы оптимист, реально для HDD рассчитывать на 10мб в секунду в лучшем случае.
У меня HDD без проблем выдает 80МБ в секунду. Мне сложно представить где взять HDD, который выдаст только 10мб в секунду. Если только по USB 1.1 его подключить :)

lair 15 июл 2015 в 08:30

Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?

Чтение нежатого видео с диска. Чтение большого PSD с диска. Сканирование большого объема фотографий в поисках нужного тега.

X_OSL 15 июл 2015 в 17:07

>Чтение нежатого видео с диска.
Тут упремся в железо без вариантов. Если есть возможность видео лучше пожать.

>Сканирование большого объема фотографий в поисках нужного тега.
Есть смысл построить индекс на теги. Или хотябы испрользовать SSD, на HDD это будет работать более-менее быстро только на втором поиске, когда он прокэшируется.

lair 15 июл 2015 в 17:44

Тут упремся в железо без вариантов. Если есть возможность видео лучше пожать.

Что камера отдала, с тем и работаем.

Есть смысл построить индекс на теги.

Есть-то есть, только индекс (а) тоже надо построить, это время и (б) он все равно будет ограничивающим фактором по скорости.

X_OSL 15 июл 2015 в 19:15

>Что камера отдала, с тем и работаем.
можно попробовать брать поток в память прямо с камеры по USB\Firewire (или как она подключается), сжимать и уже потом класть на диск…

>Есть-то есть, только индекс (а) тоже надо построить, это время и (б) он все равно будет ограничивающим фактором по скорости.
Индекс конечно решение неоднозначное. Если сканирование нужно проводить всегда для разных множеств фотографий — то лучше наверное просто взять SSD и все.

А если надо многократно сканировать надо одни и теже фотографии, которые могут немного меняться, то индекс должен бы окупиться, если правильно прописать его обновление.

lair 15 июл 2015 в 19:17

можно попробовать брать поток в память прямо с камеры по USB\Firewire (или как она подключается), сжимать и уже потом класть на диск…

И мы будем ограничены в скорости сразу двух I/O, круто.

А если надо многократно сканировать надо одни и теже фотографии, которые могут немного меняться, то индекс должен бы окупиться, если правильно прописать его обновление.

Да какая разница, окупится ли он, достаточно того, что все равно скорость работы будет ограничена скоростью I/O, а не вычислений.

X_OSL 15 июл 2015 в 19:28

>И мы будем ограничены в скорости сразу двух I/O, круто.
Я не вижу вашей задачи полностью. Но если I/O камеры заметно быстрее чем I/O диска, то при надлежащем сжатии(если мы его потянем по cpu) мы будет ограничены только I/O камеры, так как количество данных для записи на диск станет многократно меньше и его I/O с этим легко справится.
И это разумеется позволит работать быстрее чем с диском.

Но все это только в случае если I/O действительно быстрее I/O диска.

>Да какая разница, окупится ли он, достаточно того, что все равно скорость работы будет ограничена скоростью I/O, а не вычислений.
Да, разумеется, но в этой задаче, и вычислений то особых нет, тут в основном только I/O и выполняется…

lair 15 июл 2015 в 19:33

Типичная задача «открой видеоредактор и смонтируй что-нибудь». Но, собственно, вы просили привести пример, когда I/O — ботлнек. Вот вам их несколько не напрягаясь.

И я сегодня весь день на них натыкаюсь.

X_OSL 15 июл 2015 в 20:01

Такие задачи тоже бывают конечно, в основном при обработке сырых данных.

Кстати, если вы не выжимаете предельную скорость из вашего HDD, то С++ думаю помог бы ее выжать. А если выжимаете и так, то тут либо другое железо поможет, либо читать можно какнибудь с уровнем детализации «через кадр» (в несжатом стриме наверное достаточно просто пропустить кадр или несколько и добрать их когда они будут очень нужны)

lair 15 июл 2015 в 20:03

Кстати, если вы не выжимаете предельную скорость из вашего HDD, то С++ думаю помог бы ее выжать.

Вот это ваше «думаю» — оно на чем основано? Почему вы думаете, что другие языки на это не способны?

X_OSL 15 июл 2015 в 20:28

С++ будет работать через меньшее количество прослоек, как с I/O так и с памятью, куда это I/O положит данные, это может помочь.

ReadFileEx например можно вызывать и из C# по
[DllImport(«kernel32.dll»)]
static extern bool ReadFileEx(IntPtr hFile, [Out] byte [] lpBuffer,
uint nNumberOfBytesToRead, [In] ref System.Threading.NativeOverlapped lpOverlapped,
ReadFileCompletionDelegate lpCompletionRoutine);

Но я честно говоря не уверен что byte [] lpBuffer отмаршалится без дополнительных издержек.

А нативные стримы С# до ReadFileEx идут через несколько оберток, чтобы убедиться — возмите рефлектор и посмотрите на реализацию System.IO.FileStream.Read, там давольно много возможно лишнего для вашего случая кода, до того как вызывается

[DllImport(«kernel32.dll», SetLastError=true)]
internal static extern unsafe int ReadFile(SafeFileHandle handle, byte* bytes, int numBytesToRead, IntPtr numBytesRead_mustBeZero, NativeOverlapped* overlapped);

Вы сможете сделать это вызов без выполнения этого кода, кроме того вы возможно сможете избежать вызова
Buffer.InternalBlockCopy(this._buffer, this._readPos, array, offset, byteCount);
в System.IO.FileStream.Read

Я незнаю сколько именно это добавит производительности в процентах, но точно знаю что прочитать файл на С++ можно меньшим количеством исполняемого машинного кода, чем будет выполнено в System.IO.FileStream.Read

lair 15 июл 2015 в 20:38

Вот только в C# есть такая милая штука, как прозрачное взаимодействие с IOCP, которая позволит мне активировать обработчики ровно в то время, когда новый чанк данных дочитался.

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

X_OSL 15 июл 2015 в 21:01

Собственно говоря в ReadFileEx есть OVERLAPPED чтение и lpCompletionRoutine
msdn.microsoft.com/ru-ru/library/windows/desktop/aa365468(v=vs.85).aspx

Что, как я понимаю, тоже позволит активировать ваш обработчик.

На счет доли производительности… Смотря как часто этот код выполняется, чем чаще, тем больше будет доля…

lair 15 июл 2015 в 21:10

Собственно говоря в ReadFileEx есть OVERLAPPED чтение и lpCompletionRoutine
msdn.microsoft.com/ru-ru/library/windows/desktop/aa365468(v=vs.85).aspx

Что, как я понимаю, тоже позволит активировать ваш обработчик.

Ну, во-первых, нет, completion routine — это не IOCP (что, кстати, показывает, что вы с этим не работали). А во-вторых, каково количество прыжков и ужимок, которое мне на это понадобится, по сравнению с простым async/await-кодом в C#?

Смотря как часто этот код выполняется, чем чаще, тем больше будет доля…

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

Если, конечно, выполняемая операция — потоковая.

X_OSL 15 июл 2015 в 21:22

>Ну, во-первых, нет, completion routine — это не IOCP (что, кстати, показывает, что вы с этим не работали).

C IOCP я и правда не работал — необходимости в этом не было… видимо имеется ввиду это
msdn.microsoft.com/ru-ru/library/windows/desktop/aa363862(v=vs.85).aspx

>А во-вторых, каково количество прыжков и ужимок, которое мне на это понадобится, по сравнению с простым async/await-кодом в C#?
Это уж вопрос к тому насколько вам принципиально написать этот кусок (чуть?) быстрее. Безусловно прыжков и ужимок будет больше, но это будут ваши прыжки и ужимки, о которых вы точно будете знать что они делают, а не прыжки и ужимки дотнета.

>Если время выполнения обработчика чанка будет значительно меньше времени чтения следующего чанка с диска, то общее время обработки будет лишь слегка превышать общее время чтения
Я имел ввиду количество вызовов необходимых для инициализации чтения чанка.

lair 15 июл 2015 в 21:25

Безусловно прыжков и ужимок будет больше, но это будут ваши прыжки и ужимки, о которых вы точно будете знать что они делают, а не прыжки и ужимки дотнета.

А это одного порядка вещи. Вы настолько же не знаете, что внутри себя делает ReadFile, насколько я — как именно ReadAsync делает свое волшебство.

Я имел ввиду количество вызовов необходимых для инициализации чтения чанка.

Мой аргумент остается — мне достаточно синхронизировать эти вызовы таким образом, чтобы диск читался линейно, а потери были пренебрежимыми на фоне собственно чтения.

Нет, ну правда, сколько процентов от времени чтения мегабайтного чанка будет занимать оверхед? А десятимегабайтного?

X_OSL 16 июл 2015 в 16:59

>А это одного порядка вещи. Вы настолько же не знаете, что внутри себя делает ReadFile, насколько я — как именно ReadAsync делает свое волшебство.

C одной лишь разницей,- я знаю что ReadAsync(и любое другое дотнетовское чтение файла) в конечном счете вызовет ReadFile

>Нет, ну правда, сколько процентов от времени чтения мегабайтного чанка будет занимать оверхед? А десятимегабайтного?
При больших чанках процент очень малый. И если в работе с памятью оверхеда не будет, то смысла в переходе на С++ конкретно для этой задачи мало.

lair 16 июл 2015 в 18:59

C одной лишь разницей,- я знаю что ReadAsync(и любое другое дотнетовское чтение файла) в конечном счете вызовет ReadFile

Ну да… наверное. В той версии, в которой вы посмотрели. Вы не знаете (а) с какими параметрами (б) от чего они зависят (ц) что будет в следующей версии (д) что будет на соседней платформе. И самое главное — вы все равно не знаете, что внутри ReadFile.

При больших чанках процент очень малый.

А малыми на таких задачах никто и не читает. Что, собственно, и показывает нам некоторое преувеличение важности C++.

gandjustas 16 июл 2015 в 00:30

ReadFileEx например можно вызывать и из C#

А думаешь FileStream.Read делает что-то сильно другое? Он проверяет состояние стрима, вызывает ReadFileCore, который уже вызывает нативную функцию.
Смотри сам referencesource.microsoft.com/#mscorlib/system/io/filestream.cs,9d70a9236f810fcb

Думаешь в STL обвязок меньше? Или ты под каждую платформу свои нативные методы вызываешь в кроссплатформенном языке?

Но я честно говоря не уверен что byte [] lpBuffer отмаршалится без дополнительных издержек.

А я уверен, тупо буфер пинится (выставляется флаг) и передается указатель.

Я незнаю сколько именно это добавит производительности в процентах, но точно знаю что прочитать файл на С++ можно меньшим количеством исполняемого машинного кода, чем будет выполнено в System.IO.FileStream.Read

И получишь в среднем более медленный код, потому что FileStream.Read под капоптом использует буферизацию для чтения маленьких кусков, а ты про это, скорее всего, даже не подумаешь.

Короче не думай что ты умнее людей, которые писали .NET, особенно BCL. Это не так с вероятностью 100%.

X_OSL 16 июл 2015 в 06:28

>А думаешь FileStream.Read делает что-то сильно другое?
Нет, не сильно, просто машинного кода в нем будет исполнено больше во время этого вызова

>Думаешь в STL обвязок меньше? Или ты под каждую платформу свои нативные методы вызываешь в кроссплатформенном языке?
В простом чтении из файла обвязок меньше. Еще меньше обвязок в вполне кросплатформенном fread.

Но конкретно IOCP в STL нет.
Возможно только в Boost.Asio будет что-то подобное.
Я думаю IOCP лучше прописать под каждую платформу, т.к. IOCP платформо-зависимая фича, которая в таком виде есть только в Windows, на других платформах есть схожие, но другие фичи.

Опять таки, реализация IOCP в Mono будет совсем другой и по всей видимости обернута еще большим количеством кода.

>Короче не думай что ты умнее людей, которые писали .NET, особенно BCL. Это не так с вероятностью 100%.
Я не спорю, конкретно BCL — действительно хорошо написан, но часто он решает более общую задачу чем требуется, что будет всегда немного отжирать дополнительного времени в рантайме.

gandjustas 15 июл 2015 в 20:25

Чем C++ поможет при работе с диском?

gandjustas 15 июл 2015 в 19:12

1. Сборщик мусора в С++ НЕ НУЖЕН! Точка.

Подсчет ссылок это тоже форма сборки мусора. Но очень низкий уровень языка C++ позволяет генерировать гораздо меньше мусора, чем managed языка.

Добавлю ещё к выводу: С++ и С# это разные языки с разными задачами. Их бесполезно сравнивать. Вот замените цвет текста у кнопки на С++ и С#. А после нажатия на эту кнопку, производится поиск обратной матрицы размером 100000*100000. И какой язык для этого лучше? ;)

Очевидно C, без плюсов ;)

stepanp 13 июл 2015 в 13:40

Статья ниочем, аж 11 пунктов из пальца высосаны.

DancingOnWater 13 июл 2015 в 13:49

как-то на тостере я сравнивал оба языка ( toster.ru/q/80210#answer_262418 ) Прошел год, мое недовольство C# возросло, но для справедливости надо сказать, что используется устаревшая версия 3.5, на плюсах пишу для души с использованием последнего стандарта (C++14)

Хотя нельзя не отметить, что рефлексия это очень удобно и общение с БД в шарпе сделано лучше, чем тем ORM-библиотеки что я пробывал в свое время.Но на этом все.

Кстати, рефлексию обещают добавить в C++17, а сделать на основе этого удобную сеарилизацию и ORM уже труда не составляет. Так что это преимущество шарпа вскоре может быть съедено.

В итоге мой выбор это плюсы вот в такой связке: gcc 4.9 (на clang пару раз наскакивал, да в боевом режиме пока не пробовал — не сравнивал) + Qt + Boost + qbs + doxygen

ostapbender 13 июл 2015 в 16:18

Но на этом все.

Небесконечное время компиляции, отсутствие .h-файлов, несравнимая по человечности отладка и диагностика ошибок, LINQ в целом и применительно к БД и XML в частности, лямбды, итераторы, async/await, Unicode.

maaGames 13 июл 2015 в 18:15

Будто в С++ нет лямбд, итераторов и юникода. Можно хоть по-русски, кроме здравого смысла никто слова против не скажет. async в новом стандарте подтягивают.

ostapbender 13 июл 2015 в 21:55

Про лямбды и итераторы сказал тут по соседству, а про Юникод даже не смешно. Думаю, было понятно, что Юникод должен поддерживаться не на уровне

ВыходнойПоток << "Меня зовут " << имя;

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

DancingOnWater 14 июл 2015 в 07:40

в STL: wstring, u16string, u32string — все есть, все прекрасно.

В Qt Qstring поддерживает из коробки. Что вам еще надо?

ostapbender 14 июл 2015 в 08:26

в STL: wstring, u16string, u32string — все есть, все прекрасно.

Вы, наверное, издеваетесь:

typedef basic_string<char16_t> u16string

Что «прекрасного» есть в std::basic_string? Про Юникод она знает чуть меньше, чем ничего: ни Code Point'ов, ни графем, ни нормализации. Как «класс строка» она нежизнеспособна.

DancingOnWater 14 июл 2015 в 11:41

Ну и в string BP C# этого нет, а то, что вы хотите есть в ICU, Boost.Locale или Qt

grossws 14 июл 2015 в 14:25

В utf16 же не бывает суррогатных пар, правда?

DancingOnWater 15 июл 2015 в 05:46

Отношение к суррогатным парам неоднозначное, вот Javascript их не поддерживает

grossws 15 июл 2015 в 10:30

Какое может быть неоднозначное? Если используется utf16 и нет поддержки суррогатов — то unicode в полной мере не поддерживается.

DancingOnWater 13 июл 2015 в 18:43

LINQ-ORM, о нем уже говорил
.h -файл это большуй плюс к самодокументированности, мне не нужно пролистывать тысячи строк кода, чтоб понять с чем едят этот класс. Мое мнение — наличие .h -файлов это огромный плюс. Проблемы с сигнатурами в разных файлах решает IDE. Вот например в QT Creator написал сигнатуру объявления, нажал ALT+ENTR и пишишь код определения в cpp-файле.

Итератор в C# это вообще что-то:

var e = list.GetEnumerator()
и тадам e.Current ==null, а чтобы получить первое значение нужно сказать e.MoveNext(). Кто мне сможет чем разработчики руководствовались?
Если сказ про foreach — то уже в C++11 он есть, да и стандартный после введения auto уже не проблема
Лямбды — тоже есть, причем я могу укзать тип захвата: по ссылке или по значению. Если мне нужно захватить по значению в лямбде, то начинается стандартные проблемы с глубоким клонированием. Но это пол беды, беда начинается тогода, когда мне надо захватить по ссылке что-то из struct…

Async\await тыщу лет нету проблем в Qt и Boost, а как довесок — у них есть гораздо удобне организован проброс сигнала, в том числе в другой поток. Базу уже подтянули в стандарте

lair 13 июл 2015 в 19:11

var e = list.GetEnumerator() и тадам e.Current ==null, а чтобы получить первое значение нужно сказать e.MoveNext(). Кто мне сможет чем разработчики руководствовались?

Тем, что (а) итератор может быть пустым и (б) первое значение еще сто лет может быть никому не нужно.

DancingOnWater 14 июл 2015 в 06:43

Если итератор пустой (сиречь ссылается на пустую коллекцию) то в C++ он равен end и проблем никаких. Получить итератор и не начать проход по коллекции — нарушение принципа объявление переменной там где это надо. но не раньше.

Поясню чуть шире: допустим мне по какой-то причине не подходит foreach и я вынужден использовать for,
Пишем такой код:
for (var iterator = list.GetEnumerator(); iterator.HasNext(); iterator.MoveNext()){
Обработка
}
На основе опыта, основанного на доступе по индексу я ожидаю, что если я попал в тело цикла, то для начало работы с элементом мне больше телодвижений делать не надо нарушается. Причины такой логической нестыковки не понятны.

lair 14 июл 2015 в 08:15

Если итератор пустой (сиречь ссылается на пустую коллекцию) то в C++ он равен end и проблем никаких.

… кроме необходимости его на это проверить.

Получить итератор и не начать проход по коллекции — нарушение принципа объявление переменной там где это надо. но не раньше.

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

Пишем такой код:
for (var iterator = list.GetEnumerator(); iterator.HasNext(); iterator.MoveNext()){
Обработка
}
На основе опыта, основанного на доступе по индексу я ожидаю, что если я попал в тело цикла, то для начало работы с элементом мне больше телодвижений делать не надо нарушается. Причины такой логической нестыковки не понятны.

Просто ваш опыт здесь не применим (а должен быть?). В вашем коде есть две ошибки: (а) у итератора нет HasNext и (б) типизованные итераторы реализуют IDisposable, который надо не забыть обработать.

Enjoy:

using(var iterator = list.GetIterator())
{
  while(iterator.MoveNext())
  {
    //обработка
  }
}

DancingOnWater 14 июл 2015 в 08:29

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

>> (а) у итератора нет HasNext
Посыпаю голове пеплом.

>>… кроме необходимости его на это проверить.
using(var iterator = list.GetIterator())
{
while(iterator.MoveNext())
{
//обработка
}
}
Да-да, но получается, что используете цикл с предусловием в любом случае, не всегда это идет коду на пользу. Ну и сама конструкция разрастается в монстра, если у меня коллекция из коллекций.

Иными словами, основной мой посыл: «работа с итераторами в C# проще, чем в C++» требует серьезных примеров.

lair 14 июл 2015 в 08:34

Согласен, что да. может и не быть. Но это не упрощает написание кода, а только усложняет.

Это проблемы вашего опыта, а не C#/.net.

Да-да, но получается, что используете цикл с предусловием в любом случае, не всегда это идет коду на пользу.

«В любом случае» я использую foreach. Я просто показал вам, как решить вашу конкретную задачу.

Иными словами, основной мой посыл: «работа с итераторами в C# проще, чем в C++» требует серьезных примеров.

Вот вам один простой пример:

IEnumerable<ValidationError> Validate()
{
  if (Name == null) yield return ValidationError.FromProperty("Name");
  if (Text == null) yield return ValidationError.FromProperty("Text");
  if (Price < 0) yield return ValidationError.FromProperty("Price");
}

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

DancingOnWater 14 июл 2015 в 09:04

>>Вот вам один простой пример:
М-да, тостер не торт, увы…

>>Это проблемы вашего опыта, а не C#/.net.
И да и нет. Да — это проблема моего опыта, тут спора нет. Но это и проблема и C#, т.к. нарушение общего стиля увеличивает количество ошибок в коде новичков, а мы вроде как хотим это избежать.

lair 14 июл 2015 в 09:07

И да и нет. Да — это проблема моего опыта, тут спора нет. Но это и проблема и C#, т.к. нарушение общего стиля увеличивает количество ошибок в коде новичков, а мы вроде как хотим это избежать.

Нет никакого «общего стиля». Есть конкретный стиль C#, в котором итераторы обрабатываются единообразно, и там у новичков проблем нет. А если кто переучивается с другого языка, то это его дело — не тащить в новый язык нерелевантный опыт из старого.

DancingOnWater 14 июл 2015 в 09:24

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

Но ниже дали совсем схожий код. Так что и тут в целом серьезных вопросов нет

lair 14 июл 2015 в 09:26

Индекс в цикле это такой же итератор.

Упс, нет. В этом ваша ошибка. Индекс в цикле — это не итератор (по крайней мере, в C#), это отдельная парадигма.

DancingOnWater 14 июл 2015 в 10:55

А по-подробнее?

lair 14 июл 2015 в 11:23

Индекс — это произвольный доступ. Он (предположительно) имеет сложность O(1), он повторяем, вы (обычно) можете как прочитать, так и записать элемент.

А перечислитель (раз уж мы полезли в терминологические тонкости) — это последовательный доступ, с непредсказуемой сложностью, и (в конкретном .net) — без возможности записи, т.е., вам выдали элемент из последовательности, и повлиять на саму последовательность вы не можете никак.

1x1 14 июл 2015 в 09:04

А так?

for (var iterator = list.GetEnumerator(); iterator.MoveNext();){
    ...
}

ostapbender 13 июл 2015 в 21:50

А, например, OData? Тот же LINQ, но поверх HTTP.

.h-файл — атавизм, который адепты C/C++ пытаются всячески оправдывать; пользы от них — ни на грош. а мороки — уйма: те же разъезжающиеся сигнатуры, нарушение DRY и вообще масса способов отстрелить разные куски комиссарского тела. (И позвольте, к слову, заметить, что класс «в тысячи строк кода» — явный антипаттерн; но да что уж). Так вот все современные IDE для современных статически типизированных языков умеют замечательно показывать публичный контракт класса вместе с документацией.

Про итератор сказали уже, но вообще странно слышать претензии к простым и понятным .NET'ным итераторам от C++-разработчика с зоопарком begin(), end(), iterator, reverse_iterator и т.д. И вообще — Iterators Must Go.

Лямбды с Dangling Reference'ами прэлэстны, право слово.

Ну и сравнивать библиотечную подпорку для асинхронного программирования в C++ со встроенной в C# поддержкой оного — несколько за гранью

DancingOnWater 14 июл 2015 в 07:32

>> А, например, OData? Тот же LINQ, но поверх HTTP.
не знал, можно по-подробнее?

>>И позвольте, к слову, заметить, что класс «в тысячи строк кода» — явный антипаттерн; но да что уж
В патерне MVVM Visual Model, как правило, наиболее сложный класс, где зачастую функционал легко разбивается на приватные методы, а вот развал их на классы может привести лишь к неоправданной усложнению.

>>.h-файл
Итого я сказал, что проблемы с оными решаются средствами IDE, вы сказали, что проблемы без оных решается средствами IDE. Концептуально баш на баш.
>> Про итератор сказали уже, но вообще странно слышать претензии к простым и понятным .NET'ным итераторам от C++-разработчика с зоопарком begin(), end(), iterator, reverse_iterator и т.д.
Я программирую и на том и на том. Что до итераторов в C++, то я не вижу там зоопарка, begin\end и const их вариации логично и понятно и использование. Что до зоопарка, то не вижу в этом проблем ( www.cplusplus.com/reference/iterator ) все особенности диктуются особенностями коллекции. Знаю и понимаю коллекцию => знаю и понимаю работу итераторов без лишнего напряга памяти.

>> Лямбды с Dangling Reference'ами прэлэстны, право слово.
Если ссылка повиснет, то в 90% случаев вы получите сегфолт при попытке вызова. А вот если вы в C# периодически добавляете лямбды, в качестве обработчика сигнала, то вы получаете тихую утечку памяти. Но и то и то на самом деле в рамках языка не являются проблемой, т.к. это ключевые особенности языка, которые должен отслеживать программист.

>> Ну и сравнивать библиотечную подпорку для асинхронного программирования в C++ со встроенной в C# поддержкой оного — несколько за гранью
Честно говоря async\await не пробывал и не по своей вине, но судя по этой ( habrahabr.ru/post/139734 ) статье разница в опыте с С++ ровно ноль:
Код вызова:

Task task = new WebClient().DownloadStringTaskAsync(«microsoft.com»);
task.Wait(); // Здесь мы ждем завершения задачи, что блокирует поток
TextBox.Text = task.Result;

Аналог в C++, например с Qt
auto task = QtConcurrent:run([&]()={WebClient().DownloadStringTaskAsync(«microsoft.com»)})
task.wait();
TextBox.Text = task.result();

На STL будет тоже самое, разве что вы вызовете поток не из пула потоков.
Т.к. в C# потоки это обертка над потоками системы, то я не вижу принципиальных различий между потоками в C# и С++

lair 14 июл 2015 в 07:57

Код вызова:

Task task = new WebClient().DownloadStringTaskAsync(«microsoft.com»);
task.Wait(); // Здесь мы ждем завершения задачи, что блокирует поток
TextBox.Text = task.Result;

Вот оно и видно, что не пробовали. Так на TPL писать противопоказано. Вот правильный вариант:

//на время вызова существующий поток, скорее всего, будет "отпущен" и сможет выполнять другие задачи
TextBox.Text = await new WebClient().DownloadStringTaskAsync(«microsoft.com»);

Т.к. в C# потоки это обертка над потоками системы, то я не вижу принципиальных различий между потоками в C# и С++

Вот только задачи (Task) в TPL — это не обертка над потоками, а абстракция уровнем выше, поэтому ваше рассуждение тут немного не применимо.

DancingOnWater 14 июл 2015 в 08:34

>>Вот оно и видно, что не пробовали. Так на TPL писать противопоказано. Вот правильный вариант:
Благодарю, добавил в избранное. Действительно проще.
>> Вот только задачи (Task) в TPL — это не обертка над потоками, а абстракция уровнем выше, поэтому ваше рассуждение тут немного не применимо.
Ну так и future это тоже абстракция уровнем выше.

lair 14 июл 2015 в 08:38

Ну так и future это тоже абстракция уровнем выше.

По факту, future (скажем, в Scala) и task в TPL — это одно и то же.

DancingOnWater 14 июл 2015 в 08:56

И это только подтверждает мое утверждение, что в реализациях различий минимум. кстати, сейчас думаю, а можно ли конструкцию с await также элегантно сделать в плюсах. Но, покапавшись в доке
код на плюсах:

TextBox.Text = QtConcurrent:run([&]()={WebClient().DownloadStringTaskAsync(«microsoft.com»)}).result();
Можно сделать макрос:
#define await (func) QtConcurrent:run([&]()={func}).result()
и тогда код такой же, что и в C#
TextBox.Text = await (WebClient().DownloadStringTaskAsync(«microsoft.com»));

lair 14 июл 2015 в 09:02

Вы не понимаете.

await в C# — это не синтаксический сахар к task.Result (который, в свою очередь, ведет себя так же, как QFuture::result()). Ваш макрос приведет к тому, что поток, в котором идет выполнение, будет заблокирован до получения результата из future. А await выпихивает весь остаток метода в continuation, причем аккуратно захватывая используемые объекты и следя за жизненным циклом.

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

DancingOnWater 14 июл 2015 в 09:10

Понял. Согласен, это очень удобно. Для плюсов аналог еще надо придумать.

DancingOnWater 15 июл 2015 в 06:03

Утро вечера мудренее. На Qt это проблема решается, с единственным условием — после выполнения вызова кода поток попадает в цикл событий. Думаю, что для C# это тоже должно быть справедливо. Итоговый синтаксис будет выглядеть как-то так:

TextBox.Text << await (WebClient().DownloadStringTaskAsync(«microsoft.com»));

Есесно await определен существенно иначе, чем я делал до этого

lair 15 июл 2015 в 08:33

Здесь есть ровно один важный вопрос: что происходит с потоком, в котором мы находимся до вызова этой строчки?

DancingOnWater 15 июл 2015 в 08:39

Вопроса не понял, что может происходить с потоком до того как вы сделали вызов?

lair 15 июл 2015 в 08:41

Я имею в виду: вот у нас шел вызов метода до написанной вами строчки, он был в каком-то потоке. Вы вызвали ваш await — что стало с потоком?

DancingOnWater 15 июл 2015 в 08:44

Так это все-таки после. А ничего не происходит, поток не блокируется и продолжает исполняться, но в конце-концов должен попасть в цикл событий

lair 15 июл 2015 в 08:47

А что в нем исполняется?

DancingOnWater 15 июл 2015 в 09:07

в нем это где? в потоке или цикле событий?

lair 15 июл 2015 в 09:09

Для начала — в потоке.

DancingOnWater 15 июл 2015 в 09:31

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

Чтоб извлечь его надо попасть в цикл событий. Цикл событий это стандартный для Qt QEventLoop: бесконечный цикл с очередью событий, который он потокобезопасно извлекает.

Возможно, данный пример не совсем корректен, т.к. я представлял не проперти, а поле, т.е. переменную, у которой можно получить указатель.

Чтоб получить указатель на функцию, похоже, придется чуток повозиться, вытанцовывая вокруг std::function и, возможно, синтаксический сахар станет чуть горше. Но это надо обдумать.

lair 15 июл 2015 в 09:35

Поток вызывает метод асинхронно и продолжает любую свою работу.

Что значит «поток вызывает метод»? Нет такой операции, поток может либо выполнять какой-то код, либо не выполнять его (сидеть в пуле).

Нет, я серьезно вас не понимаю.

void someFunc()
{
//some code
//мы в потоке 1
TextBox.Text << await (WebClient().DownloadStringTaskAsync("http://microsoft.com")); //что стало с потоком 1? какой конкретно код он выполняет? куда делся код, находящийся ниже по функции?
//some code
}

DancingOnWater 15 июл 2015 в 10:10

Мы выполняем операцию асинхронно, т.е. мы входим в тело макроса await, делает ряд подготовительных приседаний, а после вызова QtConcurrent:run мы выходим из макроса; дальше исполняется код ниже по тексту

lair 15 июл 2015 в 10:20

Код «ниже по тексту» выполняется после завершения await или до него? Если после, то за счет чего останавливается выполнение кода между «до» и «после»?

DancingOnWater 15 июл 2015 в 10:34

WebClient().DownloadStringTaskAsync(«microsoft.com») выполняется в отдельном потоке. он не ждет родительский от слова вообше, Он может быть выполнен как «до» захода родительского в somecode, так и «после». Значение TextBox.Text будет инициализировано только после того, как попадет в eventloop, а попасть он может черт знает где: как в самом somecode, так и после него.

lair 15 июл 2015 в 10:37

Code1();
TextBox.Text << await (WebClient().DownloadStringTaskAsync("http://microsoft.com"));
Code2();

В какой момент будет выполнено обращение к сайту по отношению к Code1 и Code2? Из ваших слов у меня создается ощущение, что после Code1, но в произвольный момент по отношению к Code2 (т.е., в том числе и после выполнения Code2). Я правильно вас понял, или как-то иначе это устроено?

DancingOnWater 15 июл 2015 в 11:02

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

lair 15 июл 2015 в 11:11

Вы просто не понимаете, как работает async/await в C#. Там в аналогичном коде гарантируется строгая последовательность вызовов (Code1 — обращение к сайту — Code2), при этом на время обращения к сайту вызывающий код не блокируется, а полностью останавливается, не занимая потока, а само обращение, если оно правильно построено, тоже не блокирует поток на время собственно работы сетевого вызова.

Собственно, это позволяет делать вот такие прекрасные вещи:

var page  = await GetPageFromWikipedia(someterm);
var terms = page.GetOutgoingTerms();
var linkedPages = await Task.WhenAll(terms.Select(t => GetPageFromWikipedia(t)));

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

Wyrd 15 июл 2015 в 11:28

Более того, при вызове await еще и не создаются потоки, если все правильно написано: habrahabr.ru/post/216659

lair 15 июл 2015 в 11:33

Там «все сложно». В зависимости от того, что у вас реально в операции, потоки могут создаваться, а могут не создаваться. Если у вас IO-bound, то скорее всего, потока — как и описанно по вашей ссылке — не будет. Но это не единственный сценарий.

Собственно, Стивен Клири именно поэтому предлагает разделять собственно асинхронность и параллелизм, и подчеркивает, что async/await в первую очередь направлен на асинхронность, но позволяет работать и с параллелизмом, что порождает кучу путаницы.

Razaz 15 июл 2015 в 11:34

Del

DancingOnWater 15 июл 2015 в 11:42

>>Вы просто не понимаете, как работает async/await в C#.
Я это честно признал, т.к. не щупал. А сейчас пытаюсь понять по вашему описанию
>>а полностью останавливается, не занимая потока
Эм… поток это набор инструкций, они либо выполняются либо нет и третьего не дано. Соответственно поток либо выполняется, либо блокирован.

Но спасибо, ваш пример и пример из msdn прояснил ситуацию. Это уже сложнее, чем я думал, но если я снова придумаю ответ чамберлену, то это уже будет отдельная статья. Т.к. тут придется сидеть — думать.

p.S. Создание тысячи потоков и быстро можно только из пула потоков, тут все понятно.

Razaz 15 июл 2015 в 11:44

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

lair 15 июл 2015 в 11:46

Эм… поток это набор инструкций, они либо выполняются либо нет и третьего не дано. Соответственно поток либо выполняется, либо блокирован.

Либо в нем нет ни одной инструкции, и он тихо лежит в idle. Вот именно это и делает await в C# — он выходит из метода в этой точке, возвращая управление системе, и вешает «остаток» метода (в виде continuation) на «когда-нибудь потом».

Это уже сложнее, чем я думал, но если я снова придумаю ответ чамберлену, то это уже будет отдельная статья. Т.к. тут придется сидеть — думать.

Я искренне думаю, что без переписывания кода вам это не удастся. Компилятор C# генерит там большую и красивую стейт-машину с кучей деталей.

DancingOnWater 15 июл 2015 в 12:03

>>и вешает «остаток» метода (в виде continuation) на «когда-нибудь потом».
Т.е. код показанный вами выполняется после завершения await… но при этом, поток уходит в пул.

>>Я искренне думаю, что без переписывания кода вам это не удастся. Компилятор C# генерит там большую и красивую стейт-машину с кучей деталей

ну как варианты:
1) мы свершаем прыжок в конец функции, при это сохраняем состоянии стека и указатель на текущую инструкцию… Громоздко и сложно.
2) Проще блокировать поток, если за время блокировки пул потоков переполнится, то выводя такой поток из пула, а на его месте создаем новый, по окончании метода этот же поток убивается.

lair 15 июл 2015 в 12:05

Т.е. код показанный вами выполняется после завершения await… но при этом, поток уходит в пул.

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

мы свершаем прыжок в конец функции, при это сохраняем состоянии стека и указатель на текущую инструкцию… Громоздко и сложно.

Вот поэтому и не получится без рерайтинга.

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

Потоки стоят ресурсов (и немалых), поэтому вы быстро упретесь в ограничения.

Razaz 15 июл 2015 в 12:40

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

100к запросов к серверу в секунду с I\O? Что вы там будете блокировать?

DancingOnWater 15 июл 2015 в 12:47

100к запросов в секунду, это значит у нас на обработку операции отведено не более 10^-5с, в таком темпе попытка вызвать поток из пула — уже дорогая операция.

Razaz 15 июл 2015 в 13:05

Да не. Вон новый asp.net 800к+ способен обработать до оптимизаций на 12 портах. Benchmarks. А теперь повторю вопрос — что вы собираетесь блокировать?

DancingOnWater 15 июл 2015 в 13:16

И вы считаете, что там такая ситуация:

Пришел запрос — вызывается поток из пула — обрабатывается запрос — возвращается поток в пул.

Вместо: пришел запрос — помещается в очередь на обработку — обрабатывается запрос- удаляется из очереди?

Razaz 15 июл 2015 в 13:27

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

DancingOnWater 15 июл 2015 в 17:39

Если так, то получается, что мы дергаем пул 1.6 млн раз за секунду. Усатая сила, вместо того, чтоб чуток пораскинуть мозгами пользуем мощь компилятора.

Razaz 15 июл 2015 в 19:31

Что значит «дергаем»? Пораскиньте и запилите pull-request. При чем тут .Net или C++ тогда?

DancingOnWater 16 июл 2015 в 07:36

Прошу прощения за то, что не ясно выразил свою мысль.

10^-5 c — это фактически стоимость вызова потока из пула. Соответсвенно, если мы в потоке идущей с частотой в 100 кГц запрашиваем поток из пула, то ничего другого мы сделать уже не сумеем. И если у нас именно такие нагрузки на сервер. то логичнее было бы не останавливать и возвращать их в поток, а брать запрос из очереди.

>>При чем тут .Net или C++ тогда?
Холивар здесь не причем. Любой язык это набор инструментов со своими границами применимости. И конкретно здесь мне интересно знать для await\async и рядом связанных.

Этот механизм, как мне показали, удобен для асинхронных вызовов. Целевая ниша асинхронных вызовов: не частые внешние запросы, но с возможной(!) длительной обработкой.

Вся хитрость тех примеров, что привел привел уважаемый lair и ребята из msdn заключаемся в том, что этот код, который в плюсах нужно было бы запускать в другом потоке, можно записать в вызывающем.

Массу нюансов, который при этом механизм поглощает, конечно, впечатляет. НО это означает, что перед программистом гайка и у него вместо целого набора ключей один универсальный. Удобно, согласен, но на основе этого заявлять, что инструментарий не сравним — нельзя.

Razaz 16 июл 2015 в 08:52

Вы поставите 100к запросов в секунду в очередь и начнете ее последовательно разбирать?

С чего вы взяли что асинхронность для не частых внешних вызовов? Хитрости в примерах нет. В зависимости от таск шэдулера выполнение будет проходить в том или другом потоке.

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

lair 16 июл 2015 в 08:54

И конкретно здесь мне интересно знать для await\async и рядом связанных.

Этот механизм, как мне показали, удобен для асинхронных вызовов. Целевая ниша асинхронных вызовов: не частые внешние запросы, но с возможной(!) длительной обработкой.

Вся хитрость тех примеров, что привел привел уважаемый lair и ребята из msdn заключаемся в том, что этот код, который в плюсах нужно было бы запускать в другом потоке, можно записать в вызывающем.

Вот вы еще не разобрались в механизме, а уже делаете о нем выводы. Все, на самом деле, совсем не так.

Во-первых, сам по себе механизм async/await — это всего лишь синтаксический сахар вокруг продолжений (continuations). Да, он очень умный, да, он разворачивает эксепшны, следит за жизненным циклом объектов и контекстом синхронизации, но это всего лишь удобная обертка вокруг Task.ContinueWith().

(кстати, будем честными, тоже не уникально для C#: в F# есть совершенно свои async workflows, в Scala — for-comprehension for Futures).

Во-вторых, построен этот механизм вокруг реактивной парадигмы, которая радикально отличается от потоков. Смысл ее в очень простом — когда у нас есть потенциально долгоиграющая операция, мы оборачиваем ее в «нам нужен результат когда он будет» (Task в C#, Async в F#, Future в Scala, Promise/deferred в JS и так далее) и прекращаем текущее выполнение. Именно прекращаем (отдаем контроль внешнему фреймворку), а не блокируем — это важно.

А дальше у нас есть набор композиций, которые позволяют нам сказать «когда этот результат появится, мы хотим сделать с ним вот это» (а так же «если произошла ошибка, мы хотим сделать вот это» и так далее), и каждое «это» — это «продолжение» (continuation), очередная функция, которая может быть как синхронной (т.е. вернуть простой результат), так и асинхронной (вернуть обещание результата в будущем), и дальше эта картинка продолжается и продолжается и продолжается.

В C#, опуская детали, это без синтаксического сахара выглядит так:

webClient
  .ReadStringAsync()
  .ContinueWith(FindParent)
  .ContinueWith(parentUri => new Request(parentUri).ReadAndParse(n+1))

И так далее.

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

Скажем, CalculateFibonacciAsync может внутри себя открывать другой поток, в нем запускать вычисление, а по его завершению возвращать поток в пул, а результат — потребителю. А уж упомянутая Stream.ReadAsync — открывать асинхронную операцию чтения, вешать делегат на ее завершение, и не трогать потоки вообще; причем в зависимости от нижележащей системы, того, что она поддерживает, и банально типа потока, эта асинхронная операция чтения может быть реализована через совершенно разные вызовы API — но для потребителя это все равно всего лишь обещание байтового массива когда-то в будущем. А при чтении из потока в памяти (который просто абстракция над буфером) результат будет просто синхронным — но пользователь снова не заметит разницы.

Прелесть .net не в том, что это единственная система, где есть реактивное программирование. Прелесть в том, что (а) оно есть в стандартной библиотеке (б) оно как можно больше опирается на возможности ОС (ц) оно продвигается фреймворками (стандартные интерфейсы в том же WebAPI почти все асинхронны, в OWIN — все асинхронны, в Windows Runtime, насколько я помню, вообще нельзя писать синхронный I/O код). Просто в MS однажды поняли, что для того, чтобы система была отзывчивой, нужно по максимуму избегать блокирующих операций — и решили сделать все, чтобы программисту (а) было удобно писать в неблокирующем стиле и (б) было сложно писать в блокирующем. Второе удалось хуже, чем первое, но мы только в начале пути.

DancingOnWater 16 июл 2015 в 09:15

Даже не знаю как благодарить

Wyrd 15 июл 2015 в 12:03

>> Я это честно признал, т.к. не щупал. А сейчас пытаюсь понять по вашему описанию

Чтобы понять как это работает попробуйте пописать код через Task.ContinueWith, Microsoft.Async и т.п. в MSVS 2010.
Там нету ключевых слов async/await, что СИЛЬНО усложняет код, но позволяет понять что же все-таки за этими словами кроется (хотя бы приблизительно).

lair 15 июл 2015 в 12:06

Да я, когда мне нужен контроль, и в свежей студии пишу с ContinueWith, это так… доставляет.

А вообще, у Липперта есть хороший цикл статей про continuations (на которых все это построено).

ostapbender 14 июл 2015 в 08:31

Поподробнее:

var selectedOrders = from o in context.Orders
                     where o.Freight > 30
                     orderby o.ShippedDate descending  
                     select o;

http://localhost:12345/Northwind.svc/Orders?Orderby=ShippedDate&?filter=Freight gt 30

Т.е. нарушение DRY (да, я ленив) при использовании .h-файлов — это нормально? Зачем сначала заставлять разносить объявление и определение, а потом подтыкать это подпорками в IDE?

DancingOnWater 14 июл 2015 в 08:41

Спасибо, добавил в избранное.

>>.Т.е. нарушение DRY (да, я ленив) при использовании .h-файлов — это нормально?
Давайте не будем молиться на эмперические правила. Если уж так, то partial классы в C#, которые генерируются Дизайнером на лету это тоже DRY.Основная цель DRY — избежать ошибок в рантайме. Разделение на объявление и определение к этому не способно привести.
>>Зачем сначала заставлять разносить объявление и определение, а потом подтыкать это подпорками в IDE?
Ну а не является ли подобной подпоркой контракт в IDE?

X_OSL 13 июл 2015 в 20:15

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

Отладка и диагностика ошибок, как и писал безусловно лучше в C#, но только пока вы не вышли за managed код.

Остальные фичи в С++ на тоже есть, только в виде библиотек. Например все перечисленное вами легко покрывает boost. Не хотите boost? Есть много других.

ostapbender 13 июл 2015 в 21:59

Как вы лихо подменили время в рантайме временем запуска. И нет, прямой корреляции между «размером» приложения и временем запуска нет.

«Поддержка фич в виде библиотек» — это путь PHP. «У нас нет нормального синтаксиса создания массивов, но зато есть функция!». Так и в С++: «язык не поддерживает нормальную работу со строками, Юникод, итераторы и кучу всего еще, но зато у нас есть Boost!».

X_OSL 14 июл 2015 в 07:06

Вы правы, .net библиотеки не обязаны инициализироваться на старте приложения, и если так, то время старта .net приложения действительно может быть небольшим.

Время запуска будет соизмеримым, только если для инициализации нужно выполнить достаточно много .net кода на старте приложения, это важный момент и я его не отметил. Однако среди множества .net библиотек немало тех, которые так или иначе надо инициализировать на старте приложения.

И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
STL есть в базе, везде и никаких boost-ов для этого не нужно.

ostapbender 14 июл 2015 в 08:34

И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
STL есть в базе, везде и никаких boost-ов для этого не нужно.

Напоминаю: мы сравниваем в первую очередь языки, а не библиотеки. Ну да ладно. Строки — ужасны, итераторы — покажите мне встроенный в язык foreach и yield.

X_OSL 14 июл 2015 в 10:22

Каким образом то, что строки и итераторы являются сущностями не языка, а библиотек делает их ужасными?

lair 14 июл 2015 в 10:25

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

(про yield уже все написали)

X_OSL 14 июл 2015 в 10:39

Это скорее вопрос к тому как написана конкретная библиотека.
В своем же проекте можно использовать те библиотеки и итераторы что устраивают вас.

Совсем не обязательно использовать свои строки если есть строки STL и уж точно плохая идея делать свои строки совсем не совместимыми со стандартными.

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

lair 14 июл 2015 в 11:15

В своем же проекте можно использовать те библиотеки и итераторы что устраивают вас.

Теперь мне надо сопрягать итераторы из одной библиотеки с теми, что устраивают меня из другой библиотеки. Заводно, правда?

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

А что такое «стандартный итератор» в C++? Или стандартная строка с поддержкой Unicode? Или стандартная многопоточность?

X_OSL 14 июл 2015 в 11:37

Да, решено использовать несколько библиотек с разными базовыми типами — их сопряжение достаточно неприятная вещь, и как я писал это недостаток выбора С++.

Стандартные итераторы и строки это строки STL.
Для стандартной многопоточности, есть например en.cppreference.com/w/cpp/thread,

Вообще например тут:
en.cppreference.com/w/cpp
Описаны основные стандартные библиотеки и типы, единственное что для поддержки части из них нужна поддержка С++11 компилятором.

lair 14 июл 2015 в 12:03

Вот вам и ответ, почему то, что строки и итераторы — не сущности языка, ужасно.

X_OSL 14 июл 2015 в 13:13

Я бы все-таки не стал драматизировать и называть это ужасом:)

Конечно это неприятный момент, но формальный и вполне решаемый.
Если нужно — не так и сложно привести строку к подходящему типу, тем более, что делать это придется только работая со старыми библиотеками.

lair 14 июл 2015 в 13:56

Да почти все в программировании «вполне решаемо», только зачем этим заниматься, когда можно решать конкретные прикладные задачи вместо борьбы с языком?

X_OSL 14 июл 2015 в 15:43

Борьба всетаки не с языком, а с некоторыми библиотеками, далеко не все из которых обязательно использовать.

Зачем с ними бороться? Ради производительности, ради кроссплатформенности, ради независимости от фреймворка.

Конечно здесь и сейчас прикладную задачу быстрее решить на C#, и если не думать на перспективу, то это вполне разумный выбор в большинстве проектов которые нужно сдать и забыть.

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

lair 14 июл 2015 в 15:53

Борьба всетаки не с языком, а с некоторыми библиотеками, далеко не все из которых обязательно использовать.

А без них язык начинает проигрывать в легкодоступной функциональности.

Конечно здесь и сейчас прикладную задачу быстрее решить на C#, и если не думать на перспективу, то это вполне разумный выбор в большинстве проектов которые нужно сдать и забыть. Но если попробовать спрогнозировать развитие отрасли, то возможно ценность независимости от платформы и производительности окажется выше, чем быстрое решение прикладной задачи?

Это же типичная предварительная оптимизация — вы не знаете ни понадобится ли вам отвязываться от платформы, ни понадобится ли вам такая производительности, ни куда будет развиваться отрасль, но предлагаете здесь и сейчас пожертвовать реальной скоростью разработки, которая позволит выйти на рынок и/или оценить жизнеспособность продукта.

X_OSL 14 июл 2015 в 16:55

Это страховка. Я предлагаю минимизировать риск закрытия проекта из-за изменившейся ситуации на рынке.
Возможно данная стратегия мало полезна в проектах до года, но в проектах время развития которых 3-5 лет и более, думаю стратегия впролне оправдана.

lair 14 июл 2015 в 18:11

А вы способны предсказать такое изменение рынка через 3-5 лет, при котором ваш нынешний проект закроется из-за того, что он на C#, хотя сейчас он со всем справляется?

Мне вот что-то ни одного примера в голову не приходит.

X_OSL 14 июл 2015 в 18:37

Я могу нарисовать массу апокалиптических сценариев, если угодно:

1. Сильная реорганизация, смена приоритетов в Микрософте и следующая за ней заморозка развития .net. (MFC они неоднократно замораживали, некоторые платформы хоронили заживо, нельзя исключать что .net-у тоже достанется)

2. Переход заказчика на что-то вроде Эльбруса (сценарий конечно фантастический, но может когото он и постигнет) Да и кто знает какие платформы появятся через 3-5 лет…

3. Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)

4. Желание заказчика перейти на «зеленые технологии» с потреблением 20w на рабочее место (а вдруг?)

Можно придумать и еще чтонибудь. Я бы дал примерно 30% на то что один из пунктов может случиться в течении 3-5 лет и нанести серъезный урон проекту.

lair 14 июл 2015 в 19:12

Сильная реорганизация, смена приоритетов в Микрософте и следующая за ней заморозка развития .net.

Ну так mono же (да и вообще Open Source). А за время, за которое оно протухнет, можно успеть смигрировать куда угодно.

Переход заказчика на что-то вроде Эльбруса (сценарий конечно фантастический, но может когото он и постигнет) Да и кто знает какие платформы появятся через 3-5 лет…

А разработчику на C++ этот переход обойдется бесплатно? Не верю. Что уж говорить про неизвестные платформы.

Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)

Такие вещи видны не вдруг, и решаются заранее. И да, .net-приложения прекрасно масштабируются горизонтально.

Желание заказчика перейти на «зеленые технологии» с потреблением 20w на рабочее место (а вдруг?)

.net тут никак не мешает.

Я бы дал примерно 30% на то что один из пунктов может случиться в течении 3-5 лет и нанести серъезный урон проекту.

Я вот в .net что-то вроде 12-ти лет, и за все это время ни с одним проектом ничего подобного не произошло. Более того, я в разное время имел дело с несколькими проектами возрастом более 5 лет, и с ними тоже ничего такого не происходило даже приблизительно.

X_OSL 14 июл 2015 в 20:06

mono — лучше чем ничего, но честно говоря немного страшновато использовать его в уомерческих проектах. Может это излишняя параноя.

А разработчику на C++ этот переход обойдется бесплатно?

нет, но заметно дешеале.

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

.net тут никак не мешает.
Вы возможно не часто пользовались .net приложениями на какихнибудь Atom-ах…

Я вот в .net что-то вроде 12-ти лет, и за все это время ни с одним проектом ничего подобного не произошло.

У вас очень удачная статистика, у меня есть другая. Например года 3 назад в моей статистике прошла волна закрытий ASP.NET проектов, предназначенных для «внутреннего пользования» и некоторые библиотеки были переписаны с C# на С++ в целях повышения производительности и совместимости с iOS\MACOS.

И я пока не уверен, что все худшее для .net, в моей статистике, уже позади.

KvanTTT 14 июл 2015 в 20:24

На атоме вообще все тормозит, вплоть до винды.

lair 14 июл 2015 в 20:47

нет, но заметно дешеале

На основании чего вы делаете этот вывод? Вы лично делали такие миграции для обоих языков?

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

А это в любом случае произойдет, вне зависимости от платформы.

Вы возможно не часто пользовались .net приложениями на какихнибудь Atom-ах…

Зато я пользуюсь ими на телефоне.

Например года 3 назад в моей статистике прошла волна закрытий ASP.NET проектов, предназначенных для «внутреннего пользования» и некоторые библиотеки были переписаны с C# на С++ в целях повышения производительности и совместимости с iOS\MACOS.

В разных компаниях или в одной?

И я пока не уверен, что все худшее для .net, в моей статистике, уже позади.

Эта уверенность — как и моя — ни на чем не основана. Мы можем только смотреть на то, что делает MS, а делает он многое.

X_OSL 15 июл 2015 в 06:20

>На основании чего вы делаете этот вывод? Вы лично делали такие миграции для обоих языков?

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

>Зато я пользуюсь ими на телефоне.
У вас наверное WinPhone)

> В разных компаниях или в одной?
Закрытие ASP.NET проектов в двух разных, миграция C# на С++ в другой.

>Мы можем только смотреть на то, что делает MS, а делает он многое
Да, это безусловно важно. Мне кажется они будут пытаться увеличить прибыль, которая падает уже несколько кварталов подряд

www.microsoft.com/investor/EarningsAndFinancials/Earnings/PressReleaseAndWebcast/FY15/Q3/default.aspx

Это показывает, что-то неправильно в их стратегии развития, и они безусловно как-то попытаются это исправить, вопрос в том как именно…

lair 15 июл 2015 в 08:34

У вас наверное WinPhone)

Да, у меня Windows Phone, и у меня нет ни одного нарекания на его производительность.

Закрытие ASP.NET проектов в двух разных

Чем это было обосновано?

X_OSL 15 июл 2015 в 16:23

>Чем это было обосновано?
В обоих случаях ASP.NET приложения были слишком ориентированы на исползование в Windows окружениии под IE.

И когда доля Windows и IE в целевом сегменте начала резко падать, оказалось не рентабельным делать эти приложения работающими на остальных браузерах, включая мобильные платформы.
То есть можно сказать что развитие мобильных платформ явилось причиной по которой данные приложения потеряли свою долю на рынке.

lair 15 июл 2015 в 17:46

В обоих случаях ASP.NET приложения были слишком ориентированы на исползование в Windows окружениии под IE.

Ээээ, внезапно выясняется, что asp.net в частности и .net вообще тут ни при чем, потому что они вообще никак не влияют на то, в каком браузере используется результат. Более того, и три, и пять лет назад уже вовсю был asp.net mvc, в котором вообще полный контроль за получающимся HTML (и в нем же, кстати, есть серверная адаптация под браузер, включая мобильные платформы).

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

X_OSL 15 июл 2015 в 18:22

> внезапно выясняется, что asp.net в частности и .net вообще тут ни при чем,
Не совсем, на сколько я понял, asp.net был одной из немногих технологий позволявших завязаться на IE на столько сильно. Хотя конечно, никто не заставлял использовать такие его «приемущества», но видимо из-за них asp.net и был выбран.

> Так что конкретно эта судьба могла бы постигнуть любую (подчеркиваю, любую) серверную платформу. А конкретный C++, как вы же признались, для веба еще и не подходит…
Я ни где и не рекомендовал использовать С++ для веба. Однако, если бы эти проекты были реализованы ввиде клиентов и сервера например на С++, а не в виде интернет приложений, то они имели бы намного больше шансов ожить на мобильных платформах в виде отдельных приложений.
Другое дело, что это абсолютно другая ветка развития и в крайне сослагательном наклонении.

lair 15 июл 2015 в 18:35

Не совсем, на сколько я понял, asp.net был одной из немногих технологий позволявших завязаться на IE на столько сильно. Хотя конечно, никто не заставлял использовать такие его «приемущества», но видимо из-за них asp.net и был выбран.

Типичная ошибка архитектуры, не имеющая отношения к выбранной технологии.

Однако, если бы эти проекты были реализованы ввиде клиентов и сервера например на С++, а не в виде интернет приложений, то они имели бы намного больше шансов ожить на мобильных платформах в виде отдельных приложений.

Вы это серьезно? Адаптация веб-приложения под мобильник обычно сводится к другому html-коду, а приложения надо писать и ощутимо продумывать.

А чем, по-вашему, серверная часть на C++ отличается от веб-бекэнда на C++, что первое на нем писать можно, а второе — нет?

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

X_OSL 16 июл 2015 в 20:14

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

>А чем, по-вашему, серверная часть на C++ отличается от веб-бекэнда на C++, что первое на нем писать можно, а второе — нет?
Серверная часть С++ может быть написана со своим протоколом, это может сильно снизить трафик и упростить «парсинг» пакетов.

>В общем и целом этот ваш пример вот никак не показывает ущербность C# с точки зрения перспектив
Да, но пример и не был призван иллюстрировать ущербность C#. Пример показывает риски связанные с завязкой приложения на одну платформу.

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

lair 16 июл 2015 в 21:46

Скорее ошибка оценки перспектив рынка. Если бы мобильные платформы не развились, проекты вероятно жили бы и по сей день.

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

Серверная часть С++ может быть написана со своим протоколом, это может сильно снизить трафик и упростить «парсинг» пакетов.

Очередной велосипед? Чем вам существующих протоколов мало, вот уж нужды типовых приложений они покрывают с головой.

Пример показывает риски связанные с завязкой приложения на одну платформу.

То, что вы описываете — не технологическая проблема.

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

И опять-таки, мобильное приложение к существующему сайту написать несложно, WebAPI из asp.net выставляется легко, все мобильные клиенты умеют есть REST API.

X_OSL 17 июл 2015 в 06:24

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

>Очередной велосипед? Чем вам существующих протоколов мало, вот уж нужды типовых приложений они покрывают с головой.
Если подходящий протокол с его реализацией найдется — конечно стоит взять его.

> То, что вы описываете — не технологическая проблема.
И да и нет. Это проблема затачивания приложения под фичи, которые существуют только на одной платформе. Она может возникнуть конечно не только с ASP.NET, это проблема подхода. Просто ASP.NET тогда оказался самым дешевым способом

> И опять-таки, мобильное приложение к существующему сайту написать несложно, WebAPI из asp.net выставляется легко, все мобильные клиенты умеют есть REST API.
Вероятно когда спохватились, было уже недостаточно ресурсов для адаптации. Да и приложение похоже было слишком ориентировано на работу в локалке с большим трафиком и хорошим пингом к серверу, что не хорошо для мобильной версии.

lair 17 июл 2015 в 08:32

Если подходящий протокол с его реализацией найдется — конечно стоит взять его

… а учитывая, что для веба все подходящие протоколы давно реализованы под все приличные языки, я что-то не вижу отличий для C++ в этом разрезе. Не сходится.

В общем, все это возвращает нас к началу дискуссии: при правильных архитектурных решениях C# сейчас является не более «опасным» с точки зрения будущего языком, чем C++.

X_OSL 17 июл 2015 в 10:11

>В общем, все это возвращает нас к началу дискуссии: при правильных архитектурных решениях C# сейчас является не более «опасным» с точки зрения будущего языком, чем C++.

Язык сам по себе не причем, но выбор С# часто тянет за собой выбор инфраструктуры и библиотек, которые «внезапно» оказываются существуют только под Windows. И это уже ведет к рискам.

Например: я собираюсь писать на С#, но не хочу завазываться на Windows. На чем мне писать UI? Если я из-за красивостей и биндинга (выгодных моей разработке) выберу WPF, то путь на другие платформы у меня будет отрезан, с Winforms ситуация не на много лучше, только без красивостей и биндинга и с некой реализацией winapi на mono, в 100% идентичность оригиналу которой я не верю.
Gtk#? Как-то страшновато, да и функционал до WPF не додягивает, хорошо если покроет Winforms.

И кроме UI можно найти еще направления, где для С# есть инфраструктура под Windows, для которой нет аналогов на других платформах.
Но парадокс в том, что именно ради нее часто и выбирают C#, отрубая путь на другие платформы.

Например вы выбрали IOCP. Замечательная штука, но на других платформах ее нет в таком виде, и она будет реализована через другие механизмы(по сути будет эмулироваться) поэтому будет по-другому работать.
Для вашей задачи это «по-другому» возможно будет приемлемо, но когда таких «по-другому» накапливается критическая масса, то это может вызвать критические проблемы.

Вы можете сказать, что на С++ тоже можно завязаться на платформо-зависимую и все проблемы будут теже самые.
Да, это правда, но разница в том, что для С++ есть практики и рекомендации как писать «кросплатформенно», а для C# такие практики не пропагандируются (разве что не тянуть импорты из dll) потому что такого рода пропаганда не выгодна Microsoft. Выгода Microsoft в максимально глубоком и сильно связанном подсаживании на свою платформу.

lair 17 июл 2015 в 10:17

И это уже ведет к рискам.

Риски надо осознавать.

Но парадокс в том, что именно ради нее часто и выбирают C#, отрубая путь на другие платформы.

Во-первых, а зачем не в UI многоплатформенность? Во-вторых, как раз не в UI .net ведет себя лучше (а теперь — еще лучше) на других платформах.

Например вы выбрали IOCP. Замечательная штука, но на других платформах ее нет в таком виде, и она будет реализована через другие механизмы(по сути будет эмулироваться) поэтому будет по-другому работать.

Вы не понимаете. Я не выбрал IOCP, я выбрал асинхронный I/O. На вин-платформе (причем не на каждой) это будет сделано через IOCP, а на других платформах — через другие механизмы. Не эмуляцию IOCP, а именно нативные механизмы нижележащей системы, дающие асинхронный I/O.

для C# такие практики не пропагандируются (разве что не тянуть импорты из dll) потому что такого рода пропаганда не выгодна Microsoft.

То-то MS официально объявила о выходе .net для других платформ, разбиении фреймворка и так далее. Наверное, чтобы усилить то, что им не выгодно.

Выгода Microsoft в максимально глубоком и сильно связанном подсаживании на свою платформу.

Вопрос в том, что считать платформой MS.

X_OSL 17 июл 2015 в 10:59

>как раз не в UI .net ведет себя лучше (а теперь — еще лучше) на других платформах.
Как же без UI на десктопе?

>Вы не понимаете. Я не выбрал IOCP, я выбрал асинхронный I/O.
То есть вы в целом были готовы к тому что работа асинхронного I/O может отличаться на разных платформах.
В конкретно вашем случае это отличие скорее всего вполне приемлемо, но врядли так будет во всех платформо-зависимых решениях…

>То-то MS официально объявила о выходе .net для других платформ, разбиении фреймворка и так далее.
Прошло 15 лет с появления .net и первого обещания MS о том что кросплатформенность будет и вот уже «MS официально объявила».
Объявление конечно это не может не радовать, но когда же уже он выйдет и какие библиотеки в нем будут? Почему именно сейчас?

> Вопрос в том, что считать платформой MS.
Думаю это в первую очередь то что приносит продажи MS

lair 17 июл 2015 в 13:02

как раз не в UI .net ведет себя лучше (а теперь — еще лучше) на других платформах.

Как же без UI на десктопе?

Так я не про десктоп.

То есть вы в целом были готовы к тому что работа асинхронного I/O может отличаться на разных платформах.

Что значит «отличаться»? Наблюдаемое мной поведение отличаться не будет, а детали его реализации меня интересуют мало. В этом, вообще-то, весь смысл абстракции.

Объявление конечно это не может не радовать, но когда же уже он выйдет и какие библиотеки в нем будут? Почему именно сейчас?

Если честно, то мне все равно. Лично меня устраивает тот факт, что конкретно используемый мной сервис работает и на Windows, и на Linux, причем на втором чуть ли не лучше. При этом он (сервис) написан на .net (с небольшими вкраплениями JS).

nomit 18 июл 2015 в 04:51

Ну скажите пожалуйста где вы видели нормальный кроссплатформенный UI который поддерживает все фишки любой платформы? И не надо сейчас про QT с его QML, там тоже есть костыли и не все так идеально.

X_OSL 18 июл 2015 в 07:14

>Ну скажите пожалуйста где вы видели нормальный кроссплатформенный UI который поддерживает все фишки любой платформы?

А мне не нужны ВСЕ фишки ЛЮБОЙ платформы. Мне нужно чтобы у UI было низкое время отклика и достаточное количество контролов в базе. Поддержка биндингов была бы плюсом, но жить можно и без нее (биндинги всеравно тянут MVVM, который хотя и приносит свои плюсы, но сильно раздувает код)

Для десктопа же очень много вариантов кросплатформенного UI.
Мобильный UI (и только UI) не вижу смысла делать кросплатформенным

lair 17 июл 2015 в 10:24

А, кстати, о кросс-платформенности.

If it isn't tested, it's broken.

Если вы не тестируете приложение регулярно на всех платформах — оно не кроссплатформенное. Вы готовы каждый раз, когда вы пишете UI, запускать его в двух-трех-пяти ОС?

X_OSL 17 июл 2015 в 11:19

Тестировать приложение надо перед релизом.
И да — конечно надо, на каждой платформе, если релиз на несколько платформ.

Однако это не значит что во время разработки вы должны каждое изменение проверять на всех платформах. Если писать более менее кросплатформенно, то этапа тестирования перед релизом должно бы хватить.

lair 17 июл 2015 в 13:03

Тестировать приложение надо перед релизом.

С какой частотой у вас «релизы»?

Если писать более менее кросплатформенно,

А как определить, кроссплатформенно ли вы пишете?

X_OSL 17 июл 2015 в 13:21

>С какой частотой у вас «релизы»?
Зависит от проекта и продукта, как правило от 4 месяцев до года, иногда больше.

>А как определить, кроссплатформенно ли вы пишете?
Есть некоторые стандарты и правила. Если коротко, суть их в том, что на С++ вы должны использовать только библиотеки включенные в стандарт С++ и кросплатформенные библиотеки, а всякие API операционной системы не использовать.

lair 17 июл 2015 в 13:25

Зависит от проекта и продукта, как правило от 4 месяцев до года, иногда больше.

Предположим, раз в год. А сколько у вас период тестирования «перед релизом»?

Если коротко, суть их в том, что на С++ вы должны использовать только библиотеки включенные в стандарт С++ и кросплатформенные библиотеки, а всякие API операционной системы не использовать.

Для GUI работает? Например, high-DPI в Windows и MacOS одинаково себя ведет?

X_OSL 17 июл 2015 в 13:45

>Предположим, раз в год. А сколько у вас период тестирования «перед релизом»?
Месяца 3-4.

>Для GUI работает? Например, high-DPI в Windows и MacOS одинаково себя ведет?
Например для Qt должно бы работать…
doc-snapshots.qt.io/qt5-5.4/highdpi.html

lair 17 июл 2015 в 13:51

Предположим, раз в год. А сколько у вас период тестирования «перед релизом»?

Месяца 3-4.

Угу. Восемь месяцев что-то писали, потом выяснили, что не работает под линуксом, на исправление нужно, скажем половина от этого — это четыре месяца. Когда будем тестировать то, что исправили?

(короткие итерации и CI не просто так придумали)

Например для Qt должно бы работать…
doc-snapshots.qt.io/qt5-5.4/highdpi.html

Вот то-то и оно, что «должно». А в реальности там танцы с бубнами.

(или, скажем, обнаружение removable drives — тоже совершенно по-разному себя ведет)

KvanTTT 14 июл 2015 в 20:39

3. Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)

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

Ну и за остальные «апокалиптические сценарии» я бы не дал и процента.

X_OSL 15 июл 2015 в 06:27

Мне кажется некорректно противопоставлять высокоуровневую оптимизации и низкоуровневую. Они не исключают друг друга, а дополняют.

DancingOnWater 14 июл 2015 в 11:47

Аналог foreach из С++11

std::vector result;
for (auto x: result)

vladon 15 июл 2015 в 18:51

Строго говоря, строк в языке C# тоже нет, это системная библиотека. Различайте язык и стандартную библиотеку и для C# тогда тоже.

qw1 15 июл 2015 в 21:46

Когда серия конкатенаций оператором + компилируется в один вызов Concat с соответствующим числом параметров, это уже поддержка на уровне языка, а не библиотека…

gandjustas 16 июл 2015 в 00:31

А еще и foreach по строке компилируется в for.

Razaz 14 июл 2015 в 08:17

NGen отменили?

Garrett 13 июл 2015 в 13:52

С# с огромным опозданием, но делает шаги в кроссплатформенность. Когда прибудет? Пока сложно сказать

dordzhiev 13 июл 2015 в 16:55

Судя по их GitHub, все хорошо + еще под FreeBSD делают. Надеюсь скоро зарелизят.

X_OSL 14 июл 2015 в 16:36

Я бы наверное поставил на то, что раньше в стандарт С++ добавят недостающие фичи.

Проблема «некросплатформенности С#» мне кажется не столько технической, сколько системной и отчасти даже политической.

Вот например, зачем Apple будет поддерживать .net framework?
Или зачем Google будет добавлять поддержку .net framework в Android?
Зачем разработчикам ядра линукс протаскивать оптимизацию под .net framework?

Отдельно стоит задаться вопросом почему Microsoft за 15 лет существования .net framework не выпустила не одной его официальной версии под другие платформы?

При этом С++ компилятор для всех этих платформ был всегда, он есть даже для какогонибудь Raspberry Pi и прочих встраиваемых решений, и скорее всего весьма оптимизированный.

nomit 13 июл 2015 в 15:33

8. Риски

Вообще в корне не верно, какая завязка, на что? На язык? — ну так вроде по другому и не может быть. На платформу .net? — так она вроде всегда была бесплатна, сейчас даже исходники открывают(или открыли уже). Ну VS? ну вас не кто не заставляет ей пользоваться есть уйма других(тут про качество речи не идет). Какая еще завязка? Разве что на ОС есть завязка.

X_OSL 13 июл 2015 в 19:37

Вероятно вы невнимательно читали. Я же написал: Основной риск — завязка на Microsoft и его интересы.

X_OSL 13 июл 2015 в 22:05

Может ли минусующий объяснить, почему он считает что комерческие интересы Микрософта никогда не станут риском для его разработки на C#?

(А относительно исходников .net — пока не увидел ничего кроме того, что и так показывает рефлектор, как думаю многим понятно, наиболее интересная и полезная для переносимостии окружения часть исходников связана с нативной его частью)

nomit 14 июл 2015 в 02:56

Вероятно так можно хоть чему добавить риск. Разработка на Java — риск попасть в зону интересов оракла. Используешь линукс — Торвальдс сидит и злобно улыбается — тоже риск? Используешь хоть что — разработчик сидит и думает как бы тебя нагреть. Вывод пишем все сами с нуля тогда у нас интересы будут только наши.

X_OSL 14 июл 2015 в 07:15

Я не разбирал в статье разработку на Java, о чем отдельно написал. И вы абсолютно правы в том, что риски есть и от использования линукса и от многого другого.

Я скорее разбираю вопрос минимизации рисков. И если вы будете иметь возможность уйти на другую платформу — вы безусловно минимизируете риски связанные с «неправильным развитием» вашей платформы.

nomit 14 июл 2015 в 07:34

Какая платформа имеет возможность(позволяет) уйти с себя на другую платформу? Таких чудес не бывает, это бесполезный пункт.
Приведите факты или пример, а так получается абстрактный конь сами знаете в чем.

X_OSL 14 июл 2015 в 08:00

Если вы пишите приложение на С++ _не_ завязываясь на платформо-зависимые функции (а это не так и сложно, поверьте) то вы получаете поддержку всех платформ под которые можно собрать ваше приложение. Например С++ библиотека может быть собрана из одного кода под Windows, Macos, Linux, Android, iOS, да хоть под ось и железо своей разработки, главное чтобы под них был компилятор С++.
.
Да, возможно в паре-тройке мест вам придется сделать что-то средствами специфичными для определенной платформы. И да, для полноценного приложения вам скорее всего придется на каждой платформе написать некоторый UI, родными для платформы средствами (хотя например можно написать кросплатформенный UI на Qt).
Но вы всегда сможете уйти на другую платформу при необходимости, и это не будет стоит катастрофично дорого.

nomit 14 июл 2015 в 10:26

Не совсем понимаю, при чем тут язык? Вроде как весь вопрос стоял, что выбрать язык C++ или С#. А сейчас все сводится к компилятору. Ну так под различные оси есть mono. Я думал вы про «платформу» как о неком стэки технологий, а не ОС.

X_OSL 14 июл 2015 в 10:45

Язык тянет за собой некую инфраструктуру в виде библиотек.
И если рассмотреть mono, то насколько я понимаю инфраструктура будет заметно менее полноценная, чем та что идет с .net под Windows. Далее вопрос сводится к тому, насколько вашему приложению нужна Windows-специфичная инфраструктура.

С С++-же такого перекоса в инфраструктуре между платформами нет.

Razaz 14 июл 2015 в 10:36

.NET Core?
К слову MONO Supported Platforms

qw1 14 июл 2015 в 16:33

Это если в ходе разработки не прекращать тестировать, оптимизировать и вылавливать грубли одновременно на всех платформах. Так, чтобы 5 лет сидели на Windows и писали «кроссплатформенно», и вдруг скомпилили под MacOS и всё работает как раньше — не бывает.

X_OSL 14 июл 2015 в 17:19

Необязательно постоянно «не прекращать тестировать, оптимизировать и вылавливать грубли одновременно на всех платформах»,
При необходимости поддержки MacOS, если 5 лет сидели на Windows и писали «кроссплатформенно» вам придется потратить условно 3-6 месяцев на вылавливание платформо зависимых граблей. (этих граблей не более 10% от общего количества граблей, т.е. большинство багов вылезают на всех платформах)

Если же вы 5 лет присали под Windows не «кроссплатформенно», то вам придется переписывать огромное количество кода и тратить уже годы на поддержку MacOS (тут конечно многое зависит от того, как много специфичной Windows функциональности было притянуто за эти 5 лет)

gandjustas 13 июл 2015 в 22:38

Почему же нету сотен новых проектов на C++ и их дофига на managed языках?
Почему при всех хорошести C++ его не используют для всего? Не секрет, что большая часть разработки это веб, и для бекэнда массово используются только managed языки.
Почему на «кроссплатфомренном» C++ нельзя написать один код, который заработает на всех мобильных устройствах, а на C# таки можно (см Xamarin).
Если для C++ так много библиотек, то почему нету единого репозитария? В nuget из 39 тысяч пакетов только 419 находится по запросу «C++» и 10 000 по запросу ".NET". А как найти нужные библиотеки для С++ без nuget?
Почему такая сильная завязка на Microsoft, если компилятор и .NET есть в открытом доступе, а код на C++ под винду не соберешь без SDK, который ставится со студией?

Короче слишком много желаемого выдается за действительное.

X_OSL 14 июл 2015 в 04:49

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

И, вообще говоря, для сборки C++ под Windows, совсем не обязательно ставить студию. Да и SDK скачиваются с сайта микрософта вполне свободно.

gandjustas 14 июл 2015 в 16:59

То есть c# все таки больше подходит для большинства проектов. В чем смысл поста тогда?

X_OSL 14 июл 2015 в 17:45

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

Как вы определили это «большинство» проектов? Терминами «нету сотен новых проектов» и «дофига»?
Есть ли у вас статистика по их востребованности и окупаемости?

И да, возвращаясь к вашему предидущему посту.
На С++ можно писать код, который заработает на всех мобильных устройствах.
Для веб бэкэнда используется в основном php, но я кстати пробовал писать веб бэкэнд на С++, это вполне реально, но я бы наверное не стал рекомендовать его.

Насчет процента пакетов nuget для С++, может быть дело просто в том что nuget ориентирован на .net, а не на С++?

lair 14 июл 2015 в 18:14

Для веб бэкэнда используется в основном php

Вы это серьезно? Вы на StackOverflow никогда не были?

X_OSL 14 июл 2015 в 18:45

Я исхожу из статистики
w3techs.com/technologies/overview/programming_language/all
w3techs.com/technologies/comparison/pl-aspnet,pl-php

lair 14 июл 2015 в 19:16

Может не стоит, все-таки, приравнивать веб-бэкенды к веб-сайтам? А то под php-бэкендами внезапно окажутся сотни блогов, написанных на WordPress и Drupal.

И отдельно надо понимать, что эта статистика вообще не покрывает приложения «для внутреннего пользования».

X_OSL 14 июл 2015 в 19:43

Если мы говорим о применении php в интернете, то мне кажется статистика достаточно адекватна.
То что на одном движке собрана масса сайтов-клонов и то что есть сотни блогов, движки которых на php вряд-ли ее искажают.
Ведь никто не мешает писать сайты-клоны на ASP.NET, никто не мешает создавать хостинги блогов на ASP.NET, то что их мало — это врадли вина метода измерения.

Если говорить внутриенних сайтах, работающих в локальной сети организации, то да — эта статистика не адекватна для сайтов внутреннего пользования. Но где мы можем найти статистику по ним?

lair 14 июл 2015 в 20:45

Ведь никто не мешает писать сайты-клоны на ASP.NET, никто не мешает создавать хостинги блогов на ASP.NET

Но зачем, если эта ниша уже занята PHP?

X_OSL 15 июл 2015 в 06:43

На самом деле вопрос скорее в том почему ниша оказалась занята PHP?

Первые версии ASP появились примерно в тоже время что и первые версии PHP, да и к моменту выхода ASP.NET, нишу еще нельзя было назвать занятой.

Другой интересный вопрос это снижение доли ASP.NET
w3techs.com/technologies/history_overview/programming_language/ms/y
(пусть даже в этом сегменте)

У меня есть некоторый опыт разработки под ASP.NET, но с PHP я знаком только по книжкам и огромному количеству сайтов на нем написанных. Я вряд-ли смогу провести их детальное сравнение… Поэтому как пользователь могу лишь сказать что сайты на PHP по какой-то причине работали достаточно быстро, а на ASP.NET — медленно… Может это и явилось причиной предпочтения PHP?

gandjustas 15 июл 2015 в 08:16

На самом деле вопрос скорее в том почему ниша оказалась занята PHP?

По историческим причинам. ASP.NET был еще в зародыше когда появились wordpress, drupal, joomla, phpBB и куча других движков. Нормальные средства для создания сайтов ASP.NET получил только в 2009 год, с выходом MVC3. Тогда и появились первые CMS на .NET.

Короче asp.net отстал от пыха примерно на 10 лет в этой области. Но даже при этом имеет огромную долю рынка.

ЗЫ. Снижение доли — больше делают сайтов (в основном лэндингов) на PHP, а не на asp.net. В количественном выражении asp.net не падает.

lair 15 июл 2015 в 08:41

На самом деле вопрос скорее в том почему ниша оказалась занята PHP?

Потому что он проще в изучении.

Первые версии ASP появились примерно в тоже время что и первые версии PHP, да и к моменту выхода ASP.NET, нишу еще нельзя было назвать занятой.

Не надо смешивать asp и asp.net, между ними общего только половина названия.

Поэтому как пользователь могу лишь сказать что сайты на PHP по какой-то причине работали достаточно быстро, а на ASP.NET — медленно…

Это какое-то ваше субъективное ощущение, подтверждения которому я не встречал ни в своем опыте, ни в объективных оценках.

Но на самом деле ваша фундаментальная ошибка в том, что вы смешиваете сайты и веб-приложения, хотя у них совершенно разный подход. asp.net по моему личному вкусу для сайтов подходит плохо. А веб-приложений в интернете, очевидно, существенно меньше.

gandjustas 14 июл 2015 в 19:17

Оо.

Эти графики говорят что несколько десятков миллионов сайтов работает на C#, а C++ попал в категорию менее 0.01%.

ЗЫ. Я думал сайтов на ASP.NET поменьше.

gandjustas 14 июл 2015 в 19:14

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

В самом посте кроме огульных суждений ничего нет.

Как вы определили это «большинство» проектов?

По статистике на HH, github, monster.

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

Ага, только код не будет ничего рисовать, обрабатывать ввод, поучать по сети и читать\писать в постоянную память. То есть бесполезный код. А на C# можно можно полноценное приложение сделать.

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

Для приложений в основном используются managed языки ;)
Если говорим про веб, то это не только публичные сайты (привет StackOwerflow), но и корпоративные приложения, а их на .NET чуть менее, чем дофига и в бесконечное число раз больше, чем подобных решений на C++.

почему бы не стал рекомендовать C++ для бекенда? Наверное потому что такой хороший язык, да?

Насчет процента пакетов nuget для С++, может быть дело просто в том что nuget ориентирован на .net, а не на С++?

Что значит «ориентирован»? там есть пакеты и для C++, только их мало.

vedenin1980 15 июл 2015 в 07:16

1. Скорость разработки — неверно, чудес не бывает, unmanaged код практически всегда будет разрабатываться медленее managed кода даже при одном и том же языке, причина — unmanaged код добавляет изрядное кол-во ручное работы по отлову багов. Можно поверить что код на unmanaged и managed языке наберут программисты примерно за одно время, но потом отладка и поиск багов в unmanaged займет значительно больше времени, просто потому что много багов при сборщике мусора просто нет.

2. Кросплатформенность — для реальной кросплатформенности десктопного приложения требуется чтобы писали один раз UI и это работало на любой ОС как сделано в Java. Есть что-то подобное на C++? Переписывание всего UI под каждую платформу это не кросплатформенность это лишь наличие компилятора под разные платформы.

3. Производительность кода и требовательность к ресурсам
«Очевидным является факт того, что возможности по оптимизации unmanaged кода куда шире, чем возможности по оптимизации managed кода.»
Неверно, очевидным является тот факт что сборщики мусора делают автоматическую оптимизацию (сборку копированием, уплотнение объектов в памяти), что повышает производительность, а unmanaged код заставлет тоже самое делать вручную, причем в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое вручную, поэтому я бы не говорил про очевидно. Очевидным фактом является тот факт что основные затраты по производительности съедают виртуальные машины и run-time компиляция, поэтому и в C# и Java есть компиляторы позволяющие производить компиляцию напрямую в нативный код. Очевидно, что максимальной оптимизации можно достичь только оказавшись от С++ в пользу С или вообще машинных кодов.

Немного о производительности, сейчас производительность машинных кодов вообще дело десятое для 99% бизнес приложений: чтение с диска, чтение с сети, работа с БД, параллельное выполнение, dead lock'и, плохая архитектура — все куда более страшные причины, убивающие prefomance. Есть вещи, которым действительно prefomance нужен (драйвера, библиотеки игровых движкой, движки баз данных), но их вообще пишут на С, а то и ассемблере.

7. Стоимость поддержки
Неверно, чем больше приложение, тем больше будет стрелять баги unmanaged кода. Чтобы не быть голословным, много лет назад общался с человеком работающем в фирме прозводящим гиганские приложения для автоматической торговле на бирже, так вот у них было старое приложение на С++ и новое на С#, хотя он сам был программистом С++ он с содроганием рассказывал, о том что ошибка с указателем в одном модуле рушила случайным образом совершенно другой, причем неделями всей фирмой не могли найти причину, то что джуниор, написаший небольшой плагин для репортов, может сломать всю гиганскую банковскую систему — убивало. При unmanaged коде при огромных проектах получается «В Африке охотник промахнулся стреляя в льва, а его пуля попала в собаку в Лондоне». Круто, да.

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

X_OSL 15 июл 2015 в 08:34

>очевидным является тот факт что сборщики мусора делают автоматическую оптимизацию (сборку копированием, уплотнение объектов в памяти), что повышает производительность,
Я чаще встречался с другим поведением сборщика мусора. Фундаментально сборщик мусора решает очень общую задачу, поэтому даже при идеальной реализации у него меньше шансов ее решить оптимально, чем у не-кривой ручной реализации, написанной под конкретную задачу. Менеджер памяти далеко не всегда может предсказать что захочет ваш код в следующий момент, а вы — можете.

>в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое вручную
Это печально, но думаю поправимо.

>сейчас производительность машинных кодов вообще дело десятое для 99% бизнес приложений: чтение с диска, чтение с сети, работа с БД, параллельное выполнение, dead lock'и, плохая архитектура — все куда более страшные причины
Многое из перечисленного следствие изначально непросчитанной архитектуры и выбора технологий, то есть эти проблемы не возникают внезапно… Сам по себе переход на unmanaged языки их конечно не решит, но и трудоемкость выправления таких приложений может быть соизмерима с их переписью.

>Вы правда верите что столько сил потрачено для разработку Java и С# когда был такой замечательный универсальный C++ просто так? Все не умели считать и думать?
Любые траты сил можно сравнить с инвестициями, а инвестиции, с рациональной точки зрения, привлекает ожидание роста. Пока на горизонте был рост производительности заниматься «ловлей блох» в с низкоуровневой оптимизацией не было смысла, это было бы просто убыточно потому что более производительное железо появлялось быстрее, чем писался оптимизированный код.
Для той рыночной ситуации такая стратегия была вполне разумна, по крайней мере для не очень больших проектов, но рыночная ситуация постоянно меняется.

Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)

lair 15 июл 2015 в 08:38

поэтому даже при идеальной реализации у него меньше шансов ее решить оптимально, чем у не-кривой ручной реализации, написанной под конкретную задачу.

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

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

Просто в некоторых технологиях шанс их возникновения меньше.

Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)

Ну вот StackOverflow уже семь лет, и он никуда не уходит.

vedenin1980 15 июл 2015 в 09:02

Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)

Пожалуйста, один из продуктов над которым я когда-то работал — NetCracker, существует уже 20 лет с самого рождения Java, практически лидер BSS и OSS в телекоммуникационной области (большая тройка РФ его тоже использует). Размеры продукта наверное десятки миллионов строк кода, базы терабайты данных. Ближайшие лет 10-20 точно проживет. Ну или Apache Hadoop — лидер направления bigdata, широко использовался гуглом, написан на Java, как ни странно ставит собой цель максимально быстрой обработки гигантских объемов данных. На самом деле, их море.

vedenin1980 15 июл 2015 в 09:18

Я чаще встречался с другим поведением сборщика мусора.

Вы знаете все сборщики мусора во всех языках? В одной Java их несколько сотен, причем многие open source.

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

Проблема в том что это можно и сказать про компилятор С++, он же тоже решает общую задачу оптимизации и если писать на ассемблере будет быстрее.

Это печально, но думаю поправимо.

Проблема в том что сборщики мусора в Java и C# придумывали и отлаживали годами тысячи программистов. В теории написать лучше и быстрее в частном случае можно, но вопрос какими силами и какими ресурсами.

Многое из перечисленного следствие изначально непросчитанной архитектуры и выбора технологий, то есть эти проблемы не возникают внезапно… Сам по себе переход на unmanaged языки их конечно не решит, но и трудоемкость выправления таких приложений может быть соизмерима с их переписью.

То есть к проблемам архитектуры добавить проблемы unmanaged языков (я их описывал выше)? Минус к минусы дает плюс только в математике и то не всегда…

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

Улыбнуло, большие проекты отлично живут на Java и C#.

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

Я правильно пока процессоры были слабые на их производительность можно было забивать, а как они стали быстрыми их производительность стало вдруг очень важна.

grossws 15 июл 2015 в 10:42

Apache Tomcat — с 1999 (15 лет), Jetty — с 1995 (20 лет). Всё ещё развиваются и останавливаться не собираются.

X_OSL 15 июл 2015 в 07:31

> Ага, только код не будет ничего рисовать, обрабатывать ввод, поучать по сети и читать\писать в постоянную память. То есть бесполезный код. А на C# можно можно полноценное приложение сделать.
Я не уверен, что приложение работающее с системой через кучу прослоек, и пытающееся использовать одинаковый UI на всех платформах можно назвать полноценным. Но, если угодно, тоже-самое можно сделать и на C++ используя Qt.

> почему бы не стал рекомендовать C++ для бекенда? Наверное потому что такой хороший язык, да?
Нет, не по этому :)
Очень мало веб фреймворков для С++, в результате многое придется писать самому, это все-таки дороговато.

> Что значит «ориентирован»? там есть пакеты и для C++, только их мало.
Вот смотрите:
en.wikipedia.org/wiki/NuGet

Разработчик: Microsoft — ок, это не всегда плохо.
Разработан на C# под .net framework, — казалось бы ладно, но это уже значит что как есть он мало где запустится.
Интегрирован с Visual Studio и SharpDevelop и все. Понимаете? Больше ни с чем.
С 2012 студией приходит preinstalled — а действительно что в этом такого? Explorer же идет preinstalled с Windows и ничего, Microsoft так часто делает со своими продуктами.

Думаете Visual Studio и SharpDevelop являются основными средствами для разработки на С++?
Уверяю вас — не являются, и хотя доля Visual Studio велика, нельзя серьезно говорить о том NuGet ориентирован на С++ если кроме Visual Studio под Windows он не поддерживает ни одну платформу.

gandjustas 15 июл 2015 в 08:24

Я не уверен, что приложение работающее с системой через кучу прослоек, и пытающееся использовать одинаковый UI на всех платформах можно назвать полноценным.

Про кучу прослоек ты сам придумал.

Но, если угодно, тоже-самое можно сделать и на C++ используя Qt.

Давай, жду пример кода на Qt, который без директив условной компиляции соберется в приложения под iOS, Android и WindowsPhone.

Очень мало веб фреймворков для С++, в результате многое придется писать самому, это все-таки дороговато.

Почему же мало? Язык-то такой хороший и такой популярный…

Вот смотрите:
en.wikipedia.org/wiki/NuGet

blogs.msdn.com/b/vcblog/archive/2013/04/26/nuget-for-c.aspx
Вообще ссылаться на википедию в профессиональной дискуссии — все равно что считать надписи на заборе за доказательства теорем. Показывет ваш уровень.

нельзя серьезно говорить о том NuGet ориентирован на С++ если кроме Visual Studio под Windows он не поддерживает ни одну платформу

headsigned.com/article/running-nuget-command-line-on-linux

Nuget вообще не завязан на Visual Studio если что. Наоборот, студия завязана на Nuget.

X_OSL 15 июл 2015 в 08:45

> Про кучу прослоек ты сам придумал.
Даже .net на Windows прослойка. И я с вами, на «ты» пока что не переходил, извольте это учитывать в ваших постах.

>пример кода на Qt, который без директив условной компиляции
Директивы условной компиляции в С++ используются даже в базовых заголовках. Примером кода можно привести массу, но примеров целостного приложения без директив условной компиляции вы не найдете.

>Вообще ссылаться на википедию в профессиональной дискуссии — все равно что считать надписи на заборе за доказательства теорем. Показывет ваш уровень.
Разве в википедии написана не правда?
Знаете, по степени агрессивности ваших высказываний мне кажется что вы тут на зарплате от Микрософта, и просто рекламируете его технологии, я прав?

Еще раз. Nuget не интегрирован ни с одной средой разработки С++ кроме тех, что распространяет микрософт. Это достаточно для того чтобы считать его не ориентированным на С#/

X_OSL 15 июл 2015 в 08:58

не ориентированным на С++ конечно

gandjustas 15 июл 2015 в 09:36

Даже .net на Windows прослойка.

Что значит «прослойка»? .NET компилируется в машинный код и исполняется непосредственно процессором.
Xamarin код тоже компилируется в нативный, для WinPhone и Android JIT, а iOS — AOT.

Директивы условной компиляции в С++ используются даже в базовых заголовках. Примером кода можно привести массу, но примеров целостного приложения без директив условной компиляции вы не найдете.

Мне все равно что в заголовках. Главное чтобы твой код был единым, а не огромным #ifdef IOS…
Пример все еще жду.

Разве в википедии написана не правда?

На заборе написано «Вася — лох, Оля — шлюха», тоже вполне может быть правдой. Только цивилизованный человек не станет на это ссылаться.

Знаете, по степени агрессивности ваших высказываний мне кажется что вы тут на зарплате от Микрософта, и просто рекламируете его технологии, я прав?

Нет, МС мне не платит.

Еще раз. Nuget не интегрирован ни с одной средой разработки С++ кроме тех, что распространяет микрософт.

Еще раз: это не мешает использовать nuget где угодно.
Например npm (Node Package Manager) вообще не интегрирован со средами разработки (ну кроме новой VS), а его прекрасно используют везде.

Но ты зря прицепился к nuget. Вопрос то начался с кучи библиотек для C++. Можешь показать ссылку где эту кучу можно увидеть?

X_OSL 15 июл 2015 в 10:03

>.NET компилируется в машинный код и исполняется непосредственно процессором.
Это только пока вашему коду ничего не нужно от системы. Когда что-то требуется .net код идет к системе через прослойки.

>Еще раз: это не мешает использовать nuget где угодно.
Вы правда в верите в то, что отсутствие интеграции не влияет на вероятность использования nuget?
(мы же говорили не о том, что его нельзя использовать, а о том насколько он репрезентативен как источник для количества С++ библиотек)

>Можешь показать ссылку где эту кучу можно увидеть?
Эта «куча» не собрана в одном месте. Правда. Есть много платных и бесплатных библиотек, но нету репозитория где бы они все были. Это конечно недостаток инфраструктуры, но не значит что библиотек нет.
Их просто сложнее искать т.к. они не собраны в одну кучу.

vedenin1980 15 июл 2015 в 10:39

Это только пока вашему коду ничего не нужно от системы. Когда что-то требуется .net код идет к системе через прослойки.

Вы не поняли, в нативный код компилируется вообще все, вся платформа Net/Java. Нет, конечно C# или Java код пойдет к системе через прослойки называемые Windows API чтобы создать UI, а что у С++ есть какой-то черный вход для этого?

X_OSL 15 июл 2015 в 11:41

>у С++ есть какой-то черный вход для этого?

Для С++ вызов того же winapi не отличается от родного вызова, то есть может быть написан без конверсий вообще, вот собственно и весь черный ход)

vedenin1980 15 июл 2015 в 11:58

да, для нативного кода тоже самое, тут вопрос чей компилятор лучше оптимизирует. Вообще не понимаю я ваши заморочки с производительностью десктопных приложений: если на Java или C# возникнет узкое место именно в скорости кода, кто мешает взят/написать нативную библиотеку и тупо её подключить? Причем память библотеки можно изолировать, оптимизировать именно саму библиотеку и т.п… Зачем ставить телегу впереди лошади и заниматься предварительной оптимизацией?

gandjustas 15 июл 2015 в 11:36

Если рассматривать Xamarin, то:
В iOS идет напрямую (внезапно!)
В Windows Phone тоже напрямую (C# компилируется в вызовы функций WinRT)
В Android код обращается к java-либам, так же как любое приложение на android.

Вы правда в верите в то, что отсутствие интеграции не влияет на вероятность использования nuget?

Конечно, влияет только наличие пакетов. Для .NET дофига пакетов в nuget, он и используется. Для C++ нету пакетов, их вообще нету ни в одном пакетном менеджере. Наверное потому что пакетов\библиотек так много ;)

Эта «куча» не собрана в одном месте.

Тогда откуда уверенность что это вообще куча, а не кучка?

X_OSL 15 июл 2015 в 11:52

>В iOS идет напрямую (внезапно!)
Прямо без конверсий типы .net ложатся на типы iOS?

>В Android код обращается к java-либам, так же как любое приложение на android.
На самом деле модули Android NDK могут делать вызовы напрямую, без Java

>Тогда откуда уверенность что это вообще куча, а не кучка?
Скажем так. Практический под любую _общую_ задачу (например задачу уровня реализованных в .net) мне удавалось найти библиотеку на С++ с помощью google :)
Конечно я не все задачи пробовал, но если вы найдете общую задачу для которой нет библиотек на С++, но есть на С# было бы о ней очень интересно узнать.

gandjustas 15 июл 2015 в 12:27

Прямо без конверсий типы .net ложатся на типы iOS?

Вся конверсия выполняется при компиляции

На самом деле модули Android NDK могут делать вызовы напрямую, без Java

Тока почему-то все пишут на жабе.

Практический под любую _общую_ задачу (например задачу уровня реализованных в .net) мне удавалось найти библиотеку на С++ с помощью google :)

Давай проверим.
Нужно три вещи:
1) Библиотека, которая позволит писать один и тот же код для UI и сетевых вызовов на мобильном устройстве.
2) Библиотека, которая позволит сделать сервер, принимающий такие запросы, и обрабатывающий их асинхронно (не блокируя потоки в ожидании).
3) Библиотека, которая позволит работать с данными в базе типизированно, чтобы не приходилось клеить строки руками и тоже асинхронно, чтобы поток не висел в ожидании, пока выполняется вызов.

DancingOnWater 15 июл 2015 в 12:52

Razaz 15 июл 2015 в 13:06

QT на сервере для асинхронной обработки?

DancingOnWater 15 июл 2015 в 13:25

Вас это смущает?

gandjustas 15 июл 2015 в 13:27

Наверное всем хочется увидеть пример.

Заодно пример Qt под WindowsPhone

DancingOnWater 15 июл 2015 в 18:43

>> Заодно пример Qt под WindowsPhone
С версии 5.3.

И да, я сосвсем забыл: а есть ли C# для QNX\Blackberry?

Razaz 15 июл 2015 в 13:28

Зачем он для серверных приложений?

X_OSL 15 июл 2015 в 13:09

>Вся конверсия выполняется при компиляции
Ведь неправда же. Это невозможно реализовать, ведь на этапе компиляции еще нет данных для конверсии, они появляются только в рантайме. Вы же не с константными параметрами вызовы делаете.

>Тока почему-то все пишут на жабе.
Кому нужно по-быстрому написать, а производительность приложения не критична — пишут. Их большинство возможно, но никак уж не «все».

По библиотекам насчет Qt поддерживаю — решает все эти задачи.
По второму пункту еще могу предложить Boost.Asio.
А типизированный доступ к базам данных есть даже в древнейшем odbc (хотя конкретно для него пул для асинхронного запуска придется написать руками :( )

lair 15 июл 2015 в 13:14

gandjustas под «типизированным доступом» имеет в виду ORM, и его в ODBC нет (хотя для Qt, в принципе, есть).

X_OSL 15 июл 2015 в 13:53

А в качестве ORM без QT — можно например использовать ODB или, как легкое решение, — SOCI

gandjustas 15 июл 2015 в 13:58

Ссылки сразу давай.

X_OSL 16 июл 2015 в 17:18

sourceforge.net/projects/soci/files

www.codesynthesis.com/products/odb

gandjustas 15 июл 2015 в 13:26

Ведь неправда же. Это невозможно реализовать, ведь на этапе компиляции еще нет данных для конверсии, они появляются только в рантайме. Вы же не с константными параметрами вызовы делаете.

Почему нет данных?
Теоретически ты глядя на код на языке X можешь написать аналогичный на языке Y. А вот Xamarin делает это практически, конвертируя .NET в код для iOS.

Кому нужно по-быстрому написать, а производительность приложения не критична — пишут.

Ты правда думаешь, что если переписать android приложение на C++, то оно будет быстрее работать? Ты вообще в курсе, что главный показатель скорости работы приложения для пользователя — отзывчивость. И ты уж точно в курсе, что нет в C++ средств делать асинхронный код, который не заставляет пользователя ждать пока программа получит данные с сервера. То есть переписав тупо все на C++ ты получишь более медленное приложение с точки зрения пользователя.

Больших расчетов все равно не будет в этом приложении, их нет смысла делать на устройстве.

Их большинство возможно, но никак уж не «все».

Все это больше 95%, у оставшихся 5% обычно задачи сильно специфические, что нет смысла рассматривать.

X_OSL 15 июл 2015 в 13:47

>Теоретически ты глядя на код на языке X можешь написать аналогичный на языке Y. А вот Xamarin делает это практически, конвертируя .NET в код для iOS.

Если конвертировать до компиляции, то да, это реально, но я бы не стал называть .net приложением, то что получится в результате этой конвертации. И я не уверен что конверсия кода до компиляции это очень эффективный подход…

>если переписать android приложение на C++, то оно будет быстрее работать?
Если в приложении есть участки критичные к производительности то их перепись на С++ ускорит приложение.

>нет в C++ средств делать асинхронный код
Это ложь. В С++ можно создавать потоки и запускать в них асинхронно все что вам нужно.

gandjustas 15 июл 2015 в 13:57

Если конвертировать до компиляции, то да, это реально, но я бы не стал называть .net приложением, то что получится в результате этой конвертации.

Какая разница как ты стал бы называть. По факту единый код пишется на C# для всех платформ.

А .NET Native, который вообще превращает код приложения в C++ и конвертирует в нем ты как стал бы называть? По сути ведь вся разработка ведется на C# и пользователь может и не знать что там под капотом.

Если в приложении есть участки критичные к производительности то их перепись на С++ ускорит приложение.

Такой участок один — человек. Надо не заставлять его ждать, делая приложение отзывчивым в любых условиях. Ты хоть представляешь как сделать так, чтобы приложение на C++ не тупило пока получает данные по сети. Причем кроссплатформенно?

Это ложь. В С++ можно создавать потоки и запускать в них асинхронно все что вам нужно.

Только это не асинхронный код ;)

X_OSL 15 июл 2015 в 14:15

Хорошо, перейду на ты, если тебе так проще

>Ты хоть представляешь как сделать так, чтобы приложение на C++ не тупило пока получает данные по сети. Причем кроссплатформенно?
Элементарно. Используй потоки они кросплатформенны (#include )

>Только это не асинхронный код ;)
Чем же он не асинхронный? И какой-же он тогда? синхронный?

qw1 15 июл 2015 в 15:08

Настоящий асинхронный код на Си это классический select в BSD Sockets или появившийся позже epoll. Такая же забавная штука, как писать в стиле ООП на языках, его не поддерживающих, руками вызывая «виртуальные» функции через таблицу методов.

lair 15 июл 2015 в 08:31

Очень мало веб фреймворков для С++,

Так почему их мало-то?

X_OSL 15 июл 2015 в 08:53

Писать для web на С++ всегда было дороже чем на любом другом языке, думаю это главная причина.

lair 15 июл 2015 в 08:54

(ну, не на любом, это вы преувеличиваете)

Но почему дороже, если у него так много достоинств? И почему тогда в других областях на нем писать не дороже?

X_OSL 15 июл 2015 в 09:09

Я не писал что на С++ в других областях писать «не дороже».
Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.

И кстати, С++ — используется для веба например на ebay.com, посмотрите код его страниц, они достаточно часто обращается к некой eBayISAPI.dll :) Но я не уверен что это хороший пример того как надо делать.

lair 15 июл 2015 в 09:11

Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.

Я же спросил: почему дороже-то? Что такого в вебе, что C++ не справляется, и что не критично в других областях?

И кстати, С++ — используется для веба например на ebay.com, посмотрите код его страниц, они достаточно часто обращается к некой eBayISAPI.dll

Ну во-первых, исапи не обязательно писать на C++. Во вторых, там вообще не факт, что есть живая ISAPI, а не редирект.

lair 15 июл 2015 в 09:32

Кстати, простое гугление показывает что фронт-енд eBay работает на java (под томкатом), так что на самом деле никакого исапи (и никакой DLL) там нет, разве что они зачем-то хостят томкат в IIS (извращенцы).

gandjustas 15 июл 2015 в 09:40

Так делали раньше, чтобы статику с IIS отдавать, а isapi проксировал запросы к томкату. Тоже самое я видел в старой версии LiveLink (OpenText).

lair 15 июл 2015 в 09:42

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

X_OSL 15 июл 2015 в 09:47

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

Managed-же языки, как правило, не в состоянии завалить сервер, вероятно это одна из основных причин, почему они предпочтительнее.

>Во вторых, там вообще не факт, что есть живая ISAPI, а не редирект.
Возможно ее там уже и нет, к сожалению узнать это точно можно лишь покопавшись на самом сервере.

lair 15 июл 2015 в 09:54

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

Это же должно бы быть верно для операционных систем, которые тем не менее на неуправляемых языках регулярно пишут. И для СУБД (аналогично). И, наконец, для прикладных серверов. И даже для мобильных устройств (вообще, краш телефона из-за ошибки приложения — очень печальное дело). Неужели в C++ до сих пор не научились адекватно делать изоляцию? (вообще странно, судя по операционным системам — научились)

Managed-же языки, как правило, не в состоянии завалить сервер, вероятно это одна из основных причин, почему они предпочтительнее.

Так это, опять-таки, верно для любого устройства, не только веб-сервера. Не понятно, в чем исключительность.

X_OSL 15 июл 2015 в 10:37

Изоляция ОС от прикладных приложений конечно есть, но вот изоляция внутри прикладного приложения уже отсутсвует, а веб сервер это прикладное приложение, пусть даже и сервис. И завалить его из кода выполняемого на сервере можно. (хотя думаю что при должном старании можно завалить и iis из asp.net кода, но вероятность написания такого кода для стандартных задач невысока)
С другой стороны можно просто перезапустить сервер чтобы обойти проблему… возможно она не такая страшная.

Возможно еще роль в распространении PHP (и других managed сред) для Web сыграло отсутствие для С++ библиотек, которые позволяют быстро решать задачи web разработки,
на момент роста Web-а. То есть 15 лет назад, задачи парсинга, работы с XML и регулярными выражениями на С++ решались существенно дороже, особенно если говорить о кросплатформенном решении, а не использовании

За 15 лет конечно библиотек решающих все эти задачи стало намного больше, но ниша уже была занята, возможно дело в этом…

lair 15 июл 2015 в 10:40

но вот изоляция внутри прикладного приложения уже отсутсвует, а веб сервер это прикладное приложение

Во-первых, вам уже написали, что она вполне присутствует и реализуема. Во-вторых, даже если вы правы, то почему так сделано? Неужели нельзя было сделать изоляцию? Очевидно, что можно — почему не сделали?

То есть 15 лет назад, задачи парсинга, работы с XML и регулярными выражениями на С++ решались существенно дороже

Это типовые задачи для программирования вообще — и вы говорите, что они решаются на C++ дороже, чем на других языках? Вы уверены?

За 15 лет конечно библиотек решающих все эти задачи стало намного больше, но ниша уже была занята, возможно дело в этом…

Или в чем-то совершенно другом — например, в том, что предполагаемые преимущества от использования C++ не оправдывают всего связанного с ним геморроя?

X_OSL 15 июл 2015 в 14:05

>Неужели нельзя было сделать изоляцию? Очевидно, что можно — почему не сделали?
Если реализовывать изоляцию, то она сделает из С++ кода управляемый код, и все возможные преимущества будут съедены этой «изоляцией», т.е. издержки производительности от изоляции сведут на нет ее смысл.

>Это типовые задачи для программирования вообще — и вы говорите, что они решаются на C++ дороже, чем на других языках? Вы уверены?
Я говорю что они раньше, 15 лет назад, решались заметно дороже. Сейчас ситуация другая, 15 лет назад даже boost-а не было…

>Или в чем-то совершенно другом — например, в том, что предполагаемые преимущества от использования C++ не оправдывают всего связанного с ним геморроя?
Да. На тот момент совокупное решение было именно таким. Но с того момента прошло немало времени, мир несколько изменился. Часть С++ гемороя ушла, а фаза галопирующего роста IT направления подходит(а может и подошла) к концу. Вполне возможно что все это вызовет переоценку приоритетов.

lair 15 июл 2015 в 14:09

Тогда почему сейчас, по вашим словам, мало хороших и удобных веб-фреймворков на C++? Раз все так изменилось?

X_OSL 15 июл 2015 в 15:45

>Тогда почему сейчас, по вашим словам, мало хороших и удобных веб-фреймворков на C++? Раз все так изменилось?

Фреймворки уже написаны по большей части и пока они справляются, оптимизировать их нет нужды. Поэтому и вкладываться в оптимизацию на C++ пока нету резона.
Запрос на оптимизацию такого рода, видимо еще не созрел.

lair 15 июл 2015 в 15:50

Ну то есть C++ в вебе не используется не из-за каких-то сложностей, а потому, что он там никому не нужен, я правильно вас понял?

X_OSL 15 июл 2015 в 16:04

Сложности всетаки некоторые тоже есть.
Но основная причина, действительно в том что в вебе С++ пока не нужен.

lair 15 июл 2015 в 17:42

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

DancingOnWater 15 июл 2015 в 18:33

Apache, NGNIX — они написаны на Си…

lair 15 июл 2015 в 18:36

Это все-таки инфраструктура.

X_OSL 15 июл 2015 в 18:50

А, кстати о инфраструктуре на C#, например Sharepoint 2013
Написан на C#, но как-же он тормозит…
На машине с 24Gb памяти и SSD на гигабитной локальной сетке ПУСТАЯ страничка с его сайта открывается секунд 5. А на холодную так вообще минуту ждать можно.

Конечно ему рекомендована ферма, а машина с 24 гигами это что-то вроде минималки, но мне сложно представить, зачем для решаемых им задач столько ресурсов…

lair 15 июл 2015 в 19:04

Что вы с ним делали, что он так тормозит? У нас он на копеечной виртуалке работал быстрее.

X_OSL 15 июл 2015 в 20:40

Честно говоря ничего особенного не делал с ним.
Единственное, когда я аттачился к нему дебагером, он периодический(хотя и не так часто) handled валился с какойто ошибкой аутентификации, толи ферму искал и не находил, толи еще что-то — уже не помню точно.
Может дело в конфигурации, но она у меня была дефолтная standalone, машина была в домене…

Может он и правда постоянно в фоне подваливался чем тормозил любые обработки, но врядли на столько. Еще создавалось ощущение что дольше чем надо подфисает на WCF коммуникациях между своими компонентами (дебажил его под рефлектором, поэтому код его видел — т.к. большая часть шарепоинта .net)… опять таки — незнаю почему…

lair 15 июл 2015 в 20:42

Ну то есть «что-то где-то работало не так, но не знаю, что». Очень напоминает вашу же проблему с WPF.

X_OSL 15 июл 2015 в 20:46

С WPF все достаточно четко на самом деле.

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

gandjustas 16 июл 2015 в 00:39

Тормозит шарик ровно потому что внутрях сидит код на C++, которому уже более 10 лет, в нем полно багов и костылей, самописный парсер и генератор XML (который умудряется проглатывать невалидный XML и выдавать такой же). Запросы в базу кстати этот же код генерирует, поэтому то, что касается получения и записи данных тормозит просто нереально.

А на холодную так вообще минуту ждать можно.

А это работает парсер-генератор, который все контролы ascx компилирует при поднятии пула. Причем сам парсер-генератор написан на C++.
Кстати уже есть подобный парсер для вебформ на новом C# компиляторе, который работает в 4-5 раз быстрее (сам замерял). Увы к шарику его прикрутить нельзя.

А в 2013 версии еще подключичи Distributed Cache, который имеет ядро на C++ и которомоу потребовалось три патча, чтобы поправить все учтечки памяти.

Кстати после патчинга и настройки кеша страницы открываются не более одной секунды. И на одном сервере может держать 40-50 страниц в секунду (оклоло 200 запросов в секунду), на каждый запрос обрабатывая права пользоваеля.

Почти каждая самописная система с таким функционалом, которую я видел, валилась уже на пяти запросах.

X_OSL 16 июл 2015 в 06:38

>Тормозит шарик ровно потому что внутрях сидит код на C++
>А это работает парсер-генератор, который все контролы ascx компилирует при поднятии пула. Причем сам парсер-генератор написан на C++.
Может быть…

>А в 2013 версии еще подключичи Distributed Cache, который имеет ядро на C++ и которомоу потребовалось три патча, чтобы поправить все учтечки памяти.

Вот кстати часть исключений точно была с ним связана, правда происходили они в managed коде, но это могла быть и обертка. Кэш у меня не был настроен (его вообще обязательно настраивать?)

>Почти каждая самописная система с таким функционалом, которую я видел, валилась уже на пяти запросах.
А есть ли примеры более менее известных, для сравнения?

gandjustas 16 июл 2015 в 06:53

Кэш у меня не был настроен (его вообще обязательно настраивать?)

Чтобы быстро работало — да. Иначе каждая страница по 3-5 сек.

А есть ли примеры более менее известных, для сравнения?

Битрикс Корп Портал. На таких же мощностях довольно сильно тупит при 200 RPS и холодный старт небыстрый.

X_OSL 16 июл 2015 в 11:24

>Чтобы быстро работало — да. Иначе каждая страница по 3-5 сек.
Кстати, а что можно почитать по правильной конфигурации кэша дла Sharepoint 2013?

>Битрикс Корп Портал
Спасибо, интересная информация.

gandjustas 16 июл 2015 в 14:41

Кстати, а что можно почитать по правильной конфигурации кэша дла Sharepoint 2013?

msdn: technet.microsoft.com/en-us/library/jj219613.aspx
А еще www.wictorwilen.se/how-to-patch-the-distributed-cache-in-sharepoint-2013

X_OSL 16 июл 2015 в 15:38

Спасибо, когда опять всплывет Sharepoint 2013 — надеюсь очень поможет.

X_OSL 15 июл 2015 в 18:39

Думаю в вебе высокую нагрузку пока побеждают другими способами и эти способы пока окупаются, не знаю как долго такая ситуация сохранится. Возможно достаточно долго.

Если говорить об областях где без С++ никак

Однозначно С++ нужен в CAD отрасли пока все кады которые мне попадались имели С++-ный рендер, и С++- ную модель данных, по сути на .net были только элементы UI.

В задачах решаемых продуктами Adobe, C++ очень уместен. Во превых потомучто продукты собираются примерно из одних исходников как минимум под MacOS и Windows, а во вторых потомучто производительность и отвывчивость UI там имеет большое значение, это как никак рабочие инструменты.

Конечно в топовых 3D играх с достаточно сложными моделями и графикой. Ни одной такой на .net не попадалось.

В реализации нектороых сервисов по обработке файлов ряда форматов.

Банально, но в разработке операционных систем.

В разработке встраимого ПО, там как правило и вариантов других нет.

Я думаю можно найти и другие отрасли, но это состояние потребностей на данный момент, вопрос как оно изменится в перспективе…

lair 15 июл 2015 в 18:43

Думаю в вебе высокую нагрузку пока побеждают другими способами и эти способы пока окупаются, не знаю как долго такая ситуация сохранится. Возможно достаточно долго.

Какими «другими»?

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

X_OSL 15 июл 2015 в 18:56

>Какими «другими»?
Думаю затратами на железо, энергию и место где все это железо находится.

>Это просто как иллюстрация границ применимости вашего поста и выводов в нем.
Да. Но это на данный момент, особый интерес представляет как развитие пойдет дальше. В железе наметилась стагнация, к чему она нас приведет?

lair 15 июл 2015 в 19:06

Думаю затратами на железо, энергию и место где все это железо находится.

И почему эти способы неприменимы там, где вы продвигаете C++? Для справки, машина, на которой я работаю с весьма маленькими по современным меркам фотографиями, греется, жужжит и жрет энергию как не в себя. А это, заметим, софт от Adobe, который, по вашим словам, должен бы быть отзывчивым и все такое.

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

Я вот про эту стагнацию слышу уже давно, но все никак ее не вижу. Может, покажете?

gandjustas 16 июл 2015 в 00:47

Однозначно С++ нужен в CAD отрасли пока все кады которые мне попадались имели С++-ный рендер, и С++- ную модель данных, по сути на .net были только элементы UI.

Я видел AutoCad на WPF, который вполне прилично работал

В реализации нектороых сервисов по обработке файлов ряда форматов.

Бред полнейший. Все парсеры на .NET умеют генерировать код, который распарсенные файлы раскладывает в структуры, не заставляя на каждое поле пересчитывать смещения. Умножив это на IO через IOCP, про который половина программистов C++ даже не в курсе, получаем гораздо более быстрые парсеры на .NET. При условии конечно, что руки растут не оттуда же, откуда и ноги.

В разработке встраимого ПО, там как правило и вариантов других нет.

Проснись. На intel edison пишут вообще на NodeJS.

Ты банально повторяешь штампы 2005 года. А на дворе 2015…

X_OSL 16 июл 2015 в 07:58

> Я видел AutoCad на WPF, который вполне прилично работал
Я такого AutoCad-а ни разу не видел :) во всех все что я видел от 2009 до 2016-го ядро чтения файла было написано на С++, рендеринг тоже, а на WPF была написана только некоторая часть UI. (В UI там вообще зоопарк)

> Проснись. На intel edison пишут вообще на NodeJS.
Справедливости ради да, NodeJS используется как средство разработки встраимого ПО, правда не уверен что это подойдет для любых платформ.

> Ты банально повторяешь штампы 2005 года. А на дворе 2015…
Некоторые вещи изменились с 2005, некоторые нет… конечно что-то я не знаю.

Но раз все так хорошо, зачем развивают С++, откуда вообще эти планы на С++17?

gandjustas 16 июл 2015 в 09:47

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

Ок, а для каких НЕ пойдет?
Кстати MC обещает что везде, где работает NodeJS можно будет запустить .NET Core.

Но раз все так хорошо, зачем развивают С++, откуда вообще эти планы на С++17?

Спрос-то есть, а язык до выхода C++11 устарел аж на 15 лет. К C++17 язык догонит сегодняшние современные языки.

X_OSL 16 июл 2015 в 09:58

>Ок, а для каких НЕ пойдет?
Не скажу точно. Вообще, если он написан на С, то вполне возможно пойдет почти везде, только если на очень дохлом железе в ресурсы упрется.

>К C++17 язык догонит сегодняшние современные языки.
Да, скорее всего. И дальше будет вопрос как разовьются современные языки к моменту выхода C++17.
Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет? Особенно если производительность железа не сильно вырастет…

gandjustas 16 июл 2015 в 10:05

Не скажу точно.

Ты продолжаешь поражать, ты даже не знаешь в каком эмбеде обязательно нужен C++, но продолжаешь утверждать, что это для C++ это важная область.

Кстати большинство эмбеда ранее (до 2010 года) было на C без плюсов. Так что странно что ты в контексте C++ говоришь про эмбед.

Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет?

Очень сомневаюсь. managed платформы развиваются быстрее, а программисты до сих пор — самые дорогие компоненты софтверных решений.

Скорее для C++ так и останется область системного софта и всяких плагинов\COM. При этом новые языки типа GO или Rust будут отжимать из этой области. Ну может еще сложная математика останется.

Особенно если производительность железа не сильно вырастет…

Ты удивишься, но десктопная программа 95% времени ждет действия пользователя, а серверы более 80% активного времени занимаются склейкой строк для генерации ответов на HTTP.

X_OSL 16 июл 2015 в 10:43

>Кстати большинство эмбеда ранее (до 2010 года) было на C без плюсов.
Да, это правда, и наверное кстати так С без плюсов и останется в ряде эмбеда.
Я бы правда не стал говорить что большинство, но действительно много эмбеда используют C причем зачастую вкупе со статической работой с памятью. С++ добавляет некоторый оверхед относительно С, и на дохлом эмбеде это проявляется.

>Ты удивишься, но десктопная программа 95% времени ждет действия пользователя, а серверы более 80% активного времени занимаются склейкой строк для генерации ответов на HTTP.
Да не, не удивлюсь — тут все вполне логично. Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.

lair 16 июл 2015 в 10:48

Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.

Вот только у десктопной пользователь один, а у серверной — десятки тысяч, и отклик нужен каждому.

gandjustas 16 июл 2015 в 14:51

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

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

Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.

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

Посмотри на Outlook — там как раз он много бегает в Exchange из UI потока и умудряется дико тупить не загружая процессор и не расходуя память. И кстати Outlook на C++ написан и там самописный движок хранения писем в pst, который умудряется 30-мегабайтный файл обрабатывать по полминуты на 8-ядерном ноуте (это к вопросу о парсинге).

X_OSL 16 июл 2015 в 15:57

>Посмотри на Outlook — там как раз он много бегает в Exchange из UI потока и умудряется дико тупить не загружая процессор и не расходуя память.

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

Да и вообще, если говорить о производительности офиса,
Могу сказать что например ворд из Офис 2007 работает на десктопном core i7 c 16 Гб не быстрее(по мноим ощущениям даже медленнее) чем ворд из Офис 97 на ноутбучном PIII 700 с 380Мб памяти.
Это касается и отклика на ввод пользователя и запуска приложения, причем я бы не сказал, что отличиями функционала этих двух продуктов можно объяснить такую разницу во времяни отклика.

gandjustas 16 июл 2015 в 17:48

Ну вот, получается C++ — вовсе не гарантия отзывчивости приложения. Офис-то на С++ весь написан, а особой шустротой и отзывчивостью не отличается. Кстати именно отзывчивость обещают в первую очередь починить в 2016.

X_OSL 16 июл 2015 в 18:07

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

>Кстати именно отзывчивость обещают в первую очередь починить в 2016.
Хорошо-бы.

lair 16 июл 2015 в 10:13

Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет? Особенно если производительность железа не сильно вырастет…

У вас нет никакого способа это угадать. Но судя по тому, куда идут «большие игроки» — нет, не станет. If anything, станет только менее актуальным.

X_OSL 16 июл 2015 в 20:25

> судя по тому, куда идут «большие игроки»
Каких именно «игроков» вы имеете ввиду, и куда они идут, по вашему мнению?

lair 16 июл 2015 в 21:50

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

X_OSL 17 июл 2015 в 06:37

>гугл с го, твиттер со скалой, мозилла с растом
Но это только «большие игроки» веба. Есть еще немало «больших игроков» десктоп-приложений. Они по большей части сидят на С++ и исправно переходят на более свежие компиляторы, поддерживают новые платформы.
Даже Микрософт пока не спешит переводить свои десктопные продукты на .net…
(конечно кое-что из дотнета в них есть, но вот например не-WPF рибоны в офисе у меня зародили сомнения в том, что микрософт уверен в перспективности технологии)
Да и хром от гугла, равно как и firefox от мозилы врядли будет переписан на что-то отличное от С++ (это если говорить о десктопных приложениях)

>Они все идут в сторону повышения абстракции и упрощения тех или иных аспектов современного программирования.
Безусловно, все развивающиеся средства разработки к этому так или иначе идут…

lair 17 июл 2015 в 08:40

Есть еще немало «больших игроков» десктоп-приложений. Они по большей части сидят на С++ и исправно переходят на более свежие компиляторы, поддерживают новые платформы.

А-га. Вот возьмем, например, Apple — эти долго и упорно работали с Objective-C, а недавно выкатили — и всем пропагандируют Swift.

Или Adobe. Внезапно, от 40 до 60 (по разным источникам) процентов Lightroom (это такое весьма графически интенсивное приложение) написано на Lua.

Даже Микрософт пока не спешит переводить свои десктопные продукты на .net…

Одно дело переводить, другое дело — писать новые. Кстати, MS как-то признал, что даже куски Windows написаны на C#.

не-WPF рибоны в офисе у меня зародили сомнения в том, что микрософт уверен в перспективности технологии

А по поводу WPF у многих есть такие сомнения (просто не надо путать WPF и .net), у него действительно был продолжительный период упадка.

Но понимаете, основной пойнт даже не в этом. Основной пойнт в том, что чистые десктопные приложения понемногу вымирают, их область применения не растет (в отличие от отрасли в целом).

X_OSL 17 июл 2015 в 09:48

>А-га. Вот возьмем, например, Apple — эти долго и упорно работали с Objective-C, а недавно выкатили — и всем пропагандируют Swift.
>Или Adobe. Внезапно, от 40 до 60 (по разным источникам) процентов Lightroom (это такое весьма графически интенсивное приложение) написано на Lua.

Можно еще добавить что часть офиса написана на VBA, и некоторые части кадов написаны на их встроены языках для приложений. Но тут важно понимать как это делается: сначала пишется быстрое API на C++, и потом оно проводится на верхний уровень, где уже с ним работают на «прикладных» языках. Но эта «управленческая» работа т.е. если хотят работать быстро, на верху оперируют очень крупными сущностными. Это конечно решает ряд задач, но далеко не все и поэтому не может стать единственным направлением развития. Тяжелые функции ведь тоже надо писать, если их писать наверху то приложение может деградировать по производительности (если говорить о кадах например, да похоже что и о офисе)

>А по поводу WPF у многих есть такие сомнения (просто не надо путать WPF и .net), у него действительно был продолжительный период упадка.
Да… Но на чем еще писать UI под .net? Winforms хоть и быстрее, но откровенный и не очень хороший враппер WinAPI. А других вариантов особо и нет вроде?

>Основной пойнт в том, что чистые десктопные приложения понемногу вымирают, их область применения не растет (в отличие от отрасли в целом).
Декстопные приложение уходят на Workstation, где им и место ну и плюс игры.
Пока Workstation на вебе есть в лучшем случае для бухгалтеров и документооборота. Даже офис приложения на вебе не смог занять нишу офиса в виде приложения для десктопов и мобильных устройств.

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

lair 17 июл 2015 в 09:53

Декстопные приложение уходят на Workstation, где им и место ну и плюс игры.

Что вы понимаете под «workstation»?

плюс игры.

По поводу игры консоли (и куча мобильных игр) тоже бы с вами поспорили.

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

Для всего энтерпрайза, если быть точным.

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

Да ладно вам. Я перестал дома (и на ноутбуке) пользоваться десктопным клиентом для почты.

Но, еще раз повторюсь: это все старые отрасли применения, по сравнению с ситуацией, скажем, десять лет назад — ничего нового не появилось. Или я пропустил что-то?

DancingOnWater 17 июл 2015 в 07:23

Не согласен по поводу Rust, он не идет по пути повышения абстрактности, он делает «рефакторинг» C++.

Скорее он идет по пути более глубинного понимания того, что творит программист, разбивая большие абстракции на более мелкие и требуя уточнения там, где это необходимо.

lair 17 июл 2015 в 08:46

Я тут не буду с вами спорить, я недостаточно хорошо знаю Rust для этого. Но у меня по короткому знакомству создалось ощущение, что он, по крайней мере, дает частично другой набор абстракций, нежели C++.

DancingOnWater 17 июл 2015 в 08:59

Это да, но введений новых абстракций не тянет за собой какие-то накладных расходы. Т.е. основной принцип С\C++ — ты не платишь за то, что не используешь соблюден полностью.

Нуи есть возможность перейти на более низкий уровень абстракции — вновь вернуться к указателям, или даже ассемблерному коду, опять же, не жертвуя производительностью.

lair 17 июл 2015 в 09:01

Введение новых абстракций меняет ход мысли, вот что важно.

X_OSL 17 июл 2015 в 10:33

> Что вы понимаете под «workstation»?
> Для всего энтерпрайза, если быть точным.
Согласен — термин не очень конкретный.
Я имел ввиду рабочие места дизайнеров, конструкторов, разработчиков ПО, и думаю не только их. А чьи рабочие места в вашем понимании входят в энтерпрайз, почему конструктора например не входят?

>Да ладно вам. Я перестал дома (и на ноутбуке) пользоваться десктопным клиентом для почты.
А как насчет Word, Excel, Visio? Кстати наверняка на смартфоне вы используете приложение клиента, а не веб интефейс. А если так, — не задумывались, — почему?

>Но, еще раз повторюсь: это все старые отрасли применения, по сравнению с ситуацией, скажем, десять лет назад — ничего нового не появилось. Или я пропустил что-то?
Да, это старые области применения, они развились и сейчас в них происходят не революционные, а эволюционные изменения. Но так ли много новых именно областей появилось для энтерпрайз?

lair 17 июл 2015 в 13:09

Что вы понимаете под «workstation»?

Я имел ввиду рабочие места дизайнеров, конструкторов, разработчиков ПО, и думаю не только их.

Тогда ваша формулировка «Декстопные приложение уходят на Workstation, где им и место» лишена смысла.

А чьи рабочие места в вашем понимании входят в энтерпрайз, почему конструктора например не входят?

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

А как насчет Word, Excel, Visio?

Из всего этого я если и пользуюсь, то вордом, да и то чаще проще зайти в гдокс или офис-онлайн.

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

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

Но так ли много новых именно областей появилось для энтерпрайз?

Мобильные приложения, например. Вообще распределенная, удаленная и совместная работа. Big Data в ее нынешнем понимании.

X_OSL 17 июл 2015 в 13:39

>Тогда ваша формулировка «Декстопные приложение уходят на Workstation, где им и место» лишена смысла.
Наверное я плохо сформулировал, имел ввиду что среди Декстопных приложений остаются только нужные на Workstation, а приложения более уместные на планшетах и телефонах — отмирают на десктопе. Но при этом и Workstation приложения не появляются на мобильных устройствах, то есть рынок просто делится.

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

>Вообще распределенная, удаленная и совместная работа.
Dms и PLM системы появились очень давно, и не в вебе… они очень стары…

>Big Data в ее нынешнем понимании.
А какое у нее сейчас понимание? (видел немного разные трактовки...)

lair 17 июл 2015 в 13:48

Наверное я плохо сформулировал, имел ввиду что среди Декстопных приложений остаются только нужные на Workstation, а приложения более уместные на планшетах и телефонах — отмирают на десктопе.

Что, собственно, подтверждает мой тезис об уменьшении доли десктопа на рынке.

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

Это неправда: игры.

И именно поэтому веб приложения проигрывают многим десктопным приложениям

Именно десктопным — нет (если мы про приложения, не требующие какой-то специальной графики, да и то).

Еще можно добавить отзывчивость интерфейса.

Нельзя. Почему вы считаете, что отзывчивость интерфейса у нативного приложения выше?

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

Во-первых, не отобрали — просто теперь помимо гмейла в браузере на десктопе я пользуюсь еще и гмейлом в приложении на планшете. И поэтому, во-вторых, с точки зрения гмейла как сервиса рынок увеличился. По большому счету, не важно, на чем сделан фронт-энд распределенной системы, бэкенд все равно надо писать, и он съедает подавляющее количество усилий.

X_OSL 17 июл 2015 в 14:11

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

>если мы про приложения, не требующие какой-то специальной графики
Мы не только про них) Если говорить о приложениях без особой графики и особо продвинутого UI, то да — веб в них имеет свою долю. Но и не все так просто. Если приложение должно что-то делать с данными на вашей файловой системе (а таких приложений не так и мало) то веб приложения начинают сильно проигрывать.

>Почему вы считаете, что отзывчивость интерфейса у нативного приложения выше?
Она потенциально может быть выше, т.к. больше шансов ответить без задержки на ввод из-за меньшего количество прослоек и задержек.
Хотя например некоторые WFP контролы работают медленнее подобных написанных на HTLM + JS. Поэтому в сравнении веб это может быть не так и плохо по отзывчивости, но врядли на wpf в этом вопросе стоит равняться.

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

lair 17 июл 2015 в 14:22

С ними все не однозначно.

С ними все однозначно — есть игры и для мобильных устройств, и для десктопов. Иногда разные, иногда одни и те же, иногда companions.

Если приложение должно что-то делать с данными на вашей файловой системе (а таких приложений не так и мало) то веб приложения начинают сильно проигрывать.

Опять-таки, зависит от области деятельности. С развитием распределенных хранилищ таких приложений все меньше и меньше.

Она потенциально может быть выше, т.к. больше шансов ответить без задержки на ввод из-за меньшего количество прослоек и задержек.

Вот именно что «потенциально». А что там на самом деле — никто не знает.

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

Эээ, вы серьезно? Пойти и сменить сервис-провайдера с десятилетней историей из-за отсутствия мобильного клиента? Особенно почтового, учитывая наличие стандартных протоколов?

Пойнт-то как раз в этом: если вы предоставляете сервис, а не приложение, то вы вполне переживете все смены клиентских парадигм — до тех пор, пока парадигма сервиса не изменилась.

Вот возьмем TripIt. У них отвратительный собственный клиент для Windows Phone, настолько отвратительный, что я просто не пользовался этим сервисом с телефона. Но стоило появиться стороннему приложению, как я радостно заплатил денег его автору, и теперь у меня есть приложение на телефоне. При этом услугами самого сервиса я как пользовался, так и пользуюсь, и без них приложение бессмысленно.

X_OSL 17 июл 2015 в 15:29

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

>Опять-таки, зависит от области деятельности.
Да.

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

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

>если вы предоставляете сервис, а не приложение, то вы вполне переживете все смены клиентских парадигм
Если вашим сервисом будут пользоваться — то да. Обычно к сервису нужно предоставить и каких-то клиентов чтобы им пользовались, и тут появляется вопрос о таких средствах разработки этих клиентов, которые бы позволили затратить минимум усилий на поддержку новых платформ.

lair 17 июл 2015 в 15:33

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

А я и не говорил про уход, я говорил про неувеличение на фоне общего роста — что приводит к уменьшению общей доли.

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

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

Обычно к сервису нужно предоставить и каких-то клиентов чтобы им пользовались, и тут появляется вопрос о таких средствах разработки этих клиентов, которые бы позволили затратить минимум усилий на поддержку новых платформ.

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

X_OSL 17 июл 2015 в 16:21

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

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

lair 17 июл 2015 в 18:33

Кто же пишет тяжелые клиенты для мобильников?

Ну вот возьмем тот же TripIt. Это тривиальное CRUD-приложение + уведомления + карта. На десктопе оно никому не сдалось (его и не существует). Остаются планшеты и смартфоны. На Windows (не важно, телефоне или планшете) оно должно выдавать LiveTile (естественно, соответствующих каждому устройству размеров и набора информации), на iOS — интегрироваться с Today Screen. Уведомления и интерфейс — в соответствии с гайдлайнами каждого устройства (на Windows — Modern, на Android — Material, на iOS — не-помню-как-называется).

Вот и что вы собрались в этом кроссплатформенно писать?

X_OSL 17 июл 2015 в 18:49

>Кто же пишет тяжелые клиенты для мобильников?
Если в вашем клиенте всроена рендерилка какихнибудь документов, то уже есть что делать кроссплатформенным. Или же например поддержан каконибудь особый протокол работы с сервером, или у вас там расчеты какие-то выполняются…
Да в любом относительно толстом клиенте, который делает что-то «свое» (а не только вызов функциональности ОС) появляется смысл в кроссплатформенности.

А тривиальные приложения делать кросплатформенными смысла нет.

lair 17 июл 2015 в 19:39

Если в вашем клиенте всроена рендерилка какихнибудь документов, то уже есть что делать кроссплатформенным.

Особенно если эффективные механизмы рендера на каждой платформе отличаются.

Или же например поддержан каконибудь особый протокол работы с сервером

Опять велосипед?

Да в любом относительно толстом клиенте, который делает что-то «свое» (а не только вызов функциональности ОС) появляется смысл в кроссплатформенности.

Я вам выше привел пример приложения. Что в нем делать кроссплатформенным?

lair 17 июл 2015 в 13:54

Dms и PLM системы появились очень давно, и не в вебе… они очень стары…

Тем не менее, сейчас требования к collaborative applications сильно изменились (те же правила разрешения конфликтов). А веб просто радикально изменил правила игры с расстояниями между участниками.

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

А какое у нее сейчас понимание? (видел немного разные трактовки...)

Если сильно упрощать, то структурированные данные, к которым при этом уже неприменимы стандартные подходы классических СУБД,

qw1 15 июл 2015 в 15:25

Часть С++ гемороя ушла, а фаза галопирующего роста IT направления подходит(а может и подошла) к концу. Вполне возможно что все это вызовет переоценку приоритетов.

Похоже, после поколения managed начинает появляться новое поколение языков, таких как go и rust, которые стараются по скорости походить на native, а по безопасности на managed.

Может, лет через 10-15 (вспомним, сколько потребовалось С/С++, чтобы вырасти) появится куча веб-фреймворков на этом поколении.

X_OSL 15 июл 2015 в 15:59

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

vedenin1980 15 июл 2015 в 16:27

Нее, было бы можно допилить С++ никогда бы не появилось ни Java, ни C#, ни go c rust'ом. Проблема вовсе не в библиотеках или синтаксисе, а в том что безопасность и удобство можно сделать только сломав обратную совместимость и просто забанить все опасные фичи (иначе их все равно будут использовать), на что никто не пойдет.

X_OSL 15 июл 2015 в 16:36

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

vedenin1980 15 июл 2015 в 16:47

Не будет, пока в языке есть goto обязательно найдется умник превращающий код в вермешель. Все равно будут использовать тонны старого кода и писать по шаблону. Единственный способ который работает: назвать язык D++/E++, безусловно выкинуть все лишнее и опасное и все начать с нуля, оставив работу с кодом на С++ на уровне подключаемых библиотек. Иначе вместо создания Java допилили бы С++ с варнингами и добавили сборщик уровня на уровне необязательной библиотеки.

X_OSL 15 июл 2015 в 19:01

>Не будет, пока в языке есть goto
Да ладно вам. В С# вполне есть себе goto, просто им не пользуются.

msdn.microsoft.com/ru-ru/library/13940fs2.aspx

Добавтить ворнинг и в С++ пользоваться не будут :)

vedenin1980 15 июл 2015 в 10:43

Изоляция ОС от прикладных приложений конечно есть, но вот изоляция внутри прикладного приложения уже отсутсвует,

Вот объясните как вы предлагаете писать огромные дескоптные приложения с миллионами строк кода, если при описки в одной незначительном модуле может лихорадить всю систему. Как вообще на C++ решается если кто-то начинает перетирать память ваших переменных случайным образом (из-за ошибки в указателе, итераторе и т.п.), а кол-во нового кода слишком велико чтобы его как-то вручную проверить за обозримое время? О каком ООП может идти речь если состояние объектов может начать непредсказуемо меняться от каждого лиха любого разработчика любого модуля?

X_OSL 15 июл 2015 в 15:51

>Как вообще на C++ решается если кто-то начинает перетирать память ваших переменных случайным образом (из-за ошибки в указателе, итераторе и т.п.), а кол-во нового кода слишком велико чтобы его как-то вручную проверить за обозримое время?

Отладка под gflags, с page heap флагами позволят поймать большинство таких проблем

msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspx

qw1 15 июл 2015 в 21:55

А если такая ошибка возникает, когда какой-то юзер вводит кириллицу туда, куда разработчик не ожидает? Наример, ошибочно выделено 20 байт под 20 символов utf-8. И сервер падает только в production и не сразу после события X, а только когда после X выполнили Y (что может произойти через несколько часов после X). Значит, в production нужно всегда сидеть на debug-билдах?

X_OSL 16 июл 2015 в 08:13

Делать фиксированный буфер под utf-8 и не проверять выход за его границы — это просто то как нельзя делать. Это проблема подхода.

Нужно либо передавать размер буфера и проверять его на стороне того кто его заполняет, либо аллоцировать буфер на стороне того кто его заполняет.

qw1 16 июл 2015 в 08:35

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

managed-среды при подобных ошибках сразу роняют сервер и записывают в лог stack trace, что позволяет исправлять ошибки очень быстро.
c++ предлагает только debug билды и это всё?

X_OSL 16 июл 2015 в 20:37

>c++ предлагает только debug билды и это всё?
Не, ну почему, можно добавить логгинг в свое приложение и логить происходяшее там, дабы получать информацию о исключениях и местах где они произошли

Про gflags я говорил уже

Практика code review в принципе тоже позволяет избежать большой части ошибок, которые могут совершить программисты.

Регрессионные «юнит»-тесты тоже вполне могут помочь.

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

Хотя согласен что в managed ловить ошибки проще (но ровно до тех пор пока среда не стала mixed)

qw1 16 июл 2015 в 21:22

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

Проблема в том, что при событии X исключение не возникает, а падает событие Y, которому испортили память.

gandjustas 16 июл 2015 в 22:11

Например утечки памяти в managed средах ловить не так и просто.

Это кто тебе такую глупость сказал?

Утечка памяти в языке с GC может быть по двум причинам:
1) кто-то держит ссылку
2) кто-то «прикрепил» объект и не дает сжимать кучу.

В обоих случаях запуск профайлера памяти сразу покажет кто виноват и как поправить.

Я не видел ни одной утечки в managed коде, для устранения которой понадобилось бы более часа. Только если она не внутри какогонить WPF (таких было довольно много в первой версии, но к 4.5 все известные устранили).

А некторые проблемы с избыточным потреблением ресурсов процессора, без профайлера, могут быть заметно менее очевыдны чем в случае С++.

Что ты имеешь ввиду? Что в C++ не надо пользоваться профайлером, чтобы найти узкое место? Это откровенно глупое заявление.

При некотором навыке в C# можно видеть проблемные для быстродействия места, но профайлер все равно нужен.

X_OSL 17 июл 2015 в 06:52

>Утечка памяти в языке с GC может быть по двум причинам:
>В обоих случаях запуск профайлера памяти сразу покажет кто виноват и как поправить.

То простые случаи. Более неприятные случаи когда:
— Утечки возникают из-за не освобожденных ресурсов системы, особенно взятых импортами из dll системы.
— В неправильной последовательности освобождаются COM объекты ( GC не знает в какой последовательности их освобождать, а типичный дотнет девелопер не приучен чего-либо освобождать, если у него нет метода Dispose)
— Кривой маршалинг при вызове импортов из dll. Тут скорее не утечка памяти, а просто ее порча со всеми вытекающими последствиями не менее страшными, чем на С++, но более неожиданными.
— С WPF ом тоже помню были утечки, которые трудоемко было отловить

>Что ты имеешь ввиду? Что в C++ не надо пользоваться профайлером, чтобы найти узкое место? Это откровенно глупое заявление.
Надо. Но при ревью С++ кода проще найти более тяжелые для выполнения вещи из-за меньшего количества синтетики.
Это скорее к языку. Например код: «instance.Name» на С++ однозначно обратиться к филду, а на С# легко может обратиться к проперти внутри которой может быть засунуты тяжелые вычисления. Были еще какие-то подобные примеры.

Это вроде и мелочи, но несколько увеличивают вероятность пропустить потенциальную трату ресурсов.

gandjustas 17 июл 2015 в 14:24

То простые случаи. Более неприятные случаи когда:
— Утечки возникают из-за не освобожденных ресурсов системы, особенно взятых импортами из dll системы.
— В неправильной последовательности освобождаются COM объекты ( GC не знает в какой последовательности их освобождать, а типичный дотнет девелопер не приучен чего-либо освобождать, если у него нет метода Dispose)

Это все следствие криво написанного нативного кода (внезапно на С++), а вовсе не проблема .NET.

— Кривой маршалинг при вызове импортов из dll. Тут скорее не утечка памяти, а просто ее порча со всеми вытекающими последствиями не менее страшными, чем на С++, но более неожиданными.

Это не проблема C#. Маршалинг хорошо работает при передаче аргументов, аналогично Win32API, если удалось в либе сделать функции, которые плохо поддерживают маршалинг из C#, то это непроблема C#.

— С WPF ом тоже помню были утечки, которые трудоемко было отловить

Отловить утечки в .NET всегда легко, исправить не всегда. Все возможные утечки уже изучены и многие поправлены, так что в реальности не придется долго возиться blog.jetbrains.com/dotnet/2014/09/04/fighting-common-wpf-memory-leaks-with-dotmemory

Это скорее к языку. Например код: «instance.Name» на С++ однозначно обратиться к филду, а на С# легко может обратиться к проперти внутри которой может быть засунуты тяжелые вычисления. Были еще какие-то подобные примеры.

И что? Какую проблему тут ты увидел?

X_OSL 17 июл 2015 в 16:09

>Это все следствие криво написанного нативного кода (внезапно на С++), а вовсе не проблема .NET.

Вообще-то нет. В документации к нативным методам и COM объектам написано как правильно с ними работать, что и как освобождать, просто .net разработчики ее не особо читают, полагая что раз они пишут на .net то он сам все какниюудь разрулит.

>Это не проблема C#.
Да. Это проблема культуры разработки под C#, сам C# тут не причем.

Я лишь привел примеры где отладка C# может представлять заметные проблемы.

lair 17 июл 2015 в 16:14

Я лишь привел примеры где отладка C# может представлять заметные проблемы.

Нет, в отладке там никаких дополнительных (по сравнению с вызовом тех же операций из других мест) проблем нет.

X_OSL 17 июл 2015 в 16:34

Вот не сказал бы, както ловил случайный краш на использовании неправильно отмаршаленной выходной строки — достаточно долго провозился (я же не знал что он из-за этого), причем вероятность его вылезания по debug была очень малой (не вылезал) и без page heap его вообще было не воспроизвести табильно.

Как то раз попадал на «случайное» кэширование ссылки на COM объект в .net классе при использовании Excel через Automation. В результате Excel не закрывался должны образом (не момню, может даже валился), и для того чтобы этого избежать надо было найт эту закэшированную ссылку на COM объект и явно освободить ДО закрытия application объекта.

И там и там причиной ошибки было то, что с вызовами native кода работали так, как будто это обычные .net объекты\методы, что являлось в корне не верным.

(еще раз говорю, что это относится только к случаям общения с native кодом)

gandjustas 17 июл 2015 в 17:09

Ты о чем? Эксель, вызванный через Automation вообще сам не закрывается пока явно Application.Close() не вызовешь. А вызов Application.close гарантировано закрывает excel даже если есть ссылки.

X_OSL 17 июл 2015 в 18:58

>А вызов Application.close гарантировано закрывает excel даже если есть ссылки.
Ага — и сделает ссылки на этот объект битыми — это конечно очень полезно.
Но на сколько помню — нет. excel.exe будет висть до тех пор, пока его объекты не освободят, даже после Application.close

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

gandjustas 17 июл 2015 в 19:23

Битая ссылка — ссылка на объект, который уже освобожден. В C++ такое часто, в c# никогда. В COM полностью зависит от того, как написан этот com.

Excel написан так, что визуальная часть создает еще одну ссылку на com-server, поэтому без явного quit эксель не закрывается. А если ты сделал quit, то com-сервер остается живой пока есть ссылки (это поведение предписано стандартом).

Или ты подумал, что если com вызывается из C#, то он должен работать по другим правилам?

Кстати описанного тобой поведения легко добиться и в C++. Вызови addref и забудь вызвать release и тоже процесс excel останется висеть.

X_OSL 17 июл 2015 в 19:42

>Или ты подумал, что если com вызывается из C#, то он должен работать по другим правилам?

Я такого поведения и ожидал, но вот C#-писатель написавший оригинальный код — явно ожидал что GC ему поможет. Он положил ссылку на объект в мембер класа и подумал что GC за него сам все почистит когда надо будет. И GC вообщем-то почистил на выходе из приложения, (только кажется с крашем, потому что после Close, Release у взятого объекта уже както плохо отработал в полудохлом excel-е)

>Кстати описанного тобой поведения легко добиться и в C++.
Можно, но не по причине веры в GC

gandjustas 17 июл 2015 в 20:30

Причина только одна — автор кода не знал как работает COM и Excel automation. Язык тут совершенно не при чем. Он и в c++ сделал бы ту же ошибку.

lair 17 июл 2015 в 18:34

Все те же проблемы у вас были бы при использовании из любого другого «неродного» языка. Impedance mismatch.

gandjustas 17 июл 2015 в 17:06

Вообще-то на COM есть стандарт как должны работать компоненты. Если твой компонент не следует стандарту, а требует еще разбираться с документацией, то это хреновый компонент. И проблема в нем, а не в .NET.
Жалко что нет никакого способа обязать стандарту соответствовать, вот поэтому и появляются говнокомпоненты, с которыми надо особым образом работать.

Я лишь привел примеры где отладка C# может представлять заметные проблемы.

Ты привел проблемы, вызванные кривым unmanaged кодом, который, кстати, в большинстве случаев на C++.

X_OSL 17 июл 2015 в 16:40

>И что? Какую проблему тут ты увидел?
Тут проблемы нет, тут есть различие — производительность C# в этом вызове «на глаз» оценить сложнее, потомучто синтаксис не дает ответа на вопрос будет тут вызов метода или нет, и чтобы понять это нужно перейти к определению класса.
(мелочь конечно, но различие такое есть)

gandjustas 17 июл 2015 в 17:23

производительность «на глаз»

Это пять, надо записать. Какой смысл тебе в производительности " на глаз"?

А как ты собрался в C++ коде с RAII оценивать производительность «на глаз»? Конструктор объектов вызывает конструкторы вложенных объектов каскадно. Если объекты не указаны в списке инициализации, то тебе надо будет явно пройтись по всем вложенным объектами чтобы понять что они делают. Как «на глаз» такое оценить?

Причем в C++ с RAII такое повсеместно, а в C# 99,9% всех свойств тупо записывают значение в поле класса и не более того.

На самом деле в C++ гораздо больше неявно вызывается кода, чем в C#, поэтому и язык сложнее. В C# все что происходит (влияет на логику программы) программы — явно фигурирует в коде программы. В C++ есть неявный вызов деструкторов, неявные вызовы конструкторов копирования неявное применение перегруженных операторов, неявные преобразования типов при подстановке шаблонов. Эти все неявности дают гораздо больший простор для создания ошибок и просаживания производительности. Спасает в основном только компилятор, который очень эффективный код генерирует.

X_OSL 17 июл 2015 в 18:34

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

Конструкторы копирования принято писать достаточно быстрыми, поэтому данная запись сведется либо к копированию объекта либо к передаче ссылки, но никак не к мрачному перебору огроммного масива и поиску в нем чегонибудь.

Во вторых часто свойства простых типов тоже можно отличить на глаз.
Например вряд-ли какойнибудь XXXId, XXXCount, XXXNumber будет объектом, а не простым типом.

Понятно что все это эвристика, но для конкретного примере — более-менее рабочая эвристика.

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

>неявные вызовы конструкторов копирования
Тут отчасти соглашусь, вызовы бывают не очевидные. Лечится использованием ссылок где допустимо (то есть при анализе кода скорее смотришь на то передается ли объект по ссылке)

> неявное применение перегруженных операторов
Глупый вопрос: а как этого достичь? (кроме случая оператора приведения типа)

> неявные преобразования типов при подстановке шаблонов.
Да, может быть неочевидным…

Вообще верно что и С++ бывает сложным в оценке производительности «на глаз»
Более менее точно на глаз наверное только ассемблер оценивать можно :)

lair 17 июл 2015 в 18:35

Конструкторы копирования принято писать достаточно быстрыми,

Свойства в C# принято писать достаточно быстрыми.

X_OSL 17 июл 2015 в 19:05

>Свойства в C# принято писать достаточно быстрыми.
Мир был бы лучше, если бы все C#-писатели об этом знали :)

gandjustas 17 июл 2015 в 19:25

Все C# писатели об этом знают. А вот те, кто знают C++ и думают что знают С# допускают такие ошибки.

lair 17 июл 2015 в 19:40

Вы, видимо, не улавливаете параллели между вашими претензиями к C# и претензиями gandjustas к C++. Жаль.

X_OSL 17 июл 2015 в 20:26

Понимаете, моя цель не в притензиях, а в более четком понимании того, где лучше использовать С++, а где С# и какие будут перспективы у этого.

Естественно есть не мало вопросов по которым к С++ можно предъявлять притензии симитричные притензиям к С# и наоборот, и видимо оценка кода на глаз — один из них.

lair 17 июл 2015 в 20:33

Понимаете ли, тот факт, что свойства в C# могут иметь за собой код сложнее обращения к полю, никак не влияет на то, где можно использовать этот язык.

X_OSL 17 июл 2015 в 20:39

Да, я согласен с этим.

gandjustas 15 июл 2015 в 09:54

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

Специально для кривого кода придумали fastcgi еще очень давно. А до него успешно работал httpd. Так что проблема «не завалить сервер» на C++ решается давно и успешно.

Более того. Для ASP (который без .NET) до 2005 года существовал немаленький рынок COM (ActiveX) компонент, которые работали в серверном коде на VB и JS. Естественно все эти компоненты были написаны на C++.

Так что риск использования C++ сильно преувеличен.

Возможно ее там уже и нет, к сожалению узнать это точно можно лишь покопавшись на самом сервере.

А заголовки посмотреть?

lair 15 июл 2015 в 09:57

Более того. Для ASP (который без .NET) до 2005 года существовал немаленький рынок COM (ActiveX) компонент, которые работали в серверном коде на VB и JS. Естественно все эти компоненты были написаны на C++.

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

А заголовки посмотреть?

Apache/Coyote 1.1, ака томкат.

gandjustas 15 июл 2015 в 09:38

Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.

Ухты какое откровение. Чем веб такой особенный, что на C++ его не могут осилить? И почему на других языках успешно осиливают?

justmara 15 июл 2015 в 09:46

Пока читал — пытался представить себе, что молго сподвигнуть человека на написание подобного опуса. Потом вспомнил, что мне всё это напоминает

ну очень похоже

vladon 15 июл 2015 в 18:36

На дворе 2015 год, компиляторы уже реализуют фичи C++17, а вы до сих пор пишете «С++0х». Не стыдно?

X_OSL 15 июл 2015 в 21:09

Вообще то нет. Всетаки пока лучше придерживаться С++0х, (С++11), чтобы не попасть на то, что на одной платформе в компиляторе реализовали одни новые фичи, а на другой реализовали другие.

Хотя когда подтянутся — вполне можно и С++14 и может даже С++17

vladon 16 июл 2015 в 07:23

Я не про «придерживаться», а про то, что вы до сих пор называете новый стандарт (C++11), имя которого утвердилось уже лет пять назад — «C++0x».

X_OSL 16 июл 2015 в 08:25

C++11 и C++0x это же вроде синонимы? Да и 5 лет не такой большой срок по меркам истории развития С++.

И самое главное, например в Visual Studio поддерживается только С++11, и то не полностью
blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx
msdn.microsoft.com/en-us/library/hh567368.aspx

Какой смысл ссылаться на C++14 и C++17, если основное средство разработки под Windows их пока не держит?

gouranga 16 июл 2015 в 08:51

Вы бы еще ссылку из прошлого века взяли.

C++11/14/17 Features In VS 2015 RC + C++11/14/17 Features In VS 2015 RTM + constexpr.

Вполне себе поддерживает. Выходит, кстати, через пару дней.

X_OSL 16 июл 2015 в 09:05

Вот когда выйдет, тогда и пишите что «стыдно». А пока что — рано

lair 16 июл 2015 в 09:17

Вообще-то, RC вышел 29 апреля.

X_OSL 16 июл 2015 в 09:28

RC это не релиз. Работать на RC нельзя.
Вообще говоря, с рядом релизов студии работать нельзя до первого сервис пака.

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

lair 16 июл 2015 в 09:30

Вообще-то — можно (и я неоднократно работал). Особенно учитывая, что это не то, с чем вы работаете в продуктиве.

X_OSL 16 июл 2015 в 09:43

Если вы точно уверены, что вам не надо будет выпускаться до того как будут устранены критичные глюки то можно работать и на RC.
Но вот если вам надо будет выпуститься до этого, то вполне возможно придется задерживать релиз, и это является серьезным риском, на мой взгляд.

Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?

lair 16 июл 2015 в 09:51

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

Сначала неплохо бы выяснить, а есть ли критичные глюки.

Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?

Никак не думаю, мне эта тема не интересна.

X_OSL 16 июл 2015 в 10:05

>Сначала неплохо бы выяснить, а есть ли критичные глюки.
Смотря сколько ресурсов надо потратить на это выяснение. И где гарантия что вы найдете все глюки критичные глюки входе этого выяснения?
Есть немалая вероятность что до критичного вы дойдете только к релизу, а там будет уже поздно менять платформу.… Мало радости быть первооткрывателем глюка, пока не набралось достаточно статистики по борьбе с ними…

Хотя это вопрос стратегии конечно, более рискованные стратегии могут быть более «прибыльными».

lair 16 июл 2015 в 10:12

А где гарантия, что все критичные глюки будут найдены к релизу? К следующему релизу? К бесконечно отдаленному от вас релизу?

Пока вы не начнете работать, вы этого не поймете. Ну и вы же так ратовали за кроссплатформенность и переносимость C++ — почему вы так зависите от версии конкретной IDE?

X_OSL 16 июл 2015 в 10:52

>А где гарантия, что все критичные глюки будут найдены к релизу? К следующему релизу? К бесконечно отдаленному от вас релизу?

Вероятность значительно меньше. Эта вероятность снижается с ростом статистики использования продукта. А до того как продукт будет отрелижен статистики по его использованию будет недостаточно, из-за низкой массовости использования.
Через месяц-другой после релиза она наберется, но набирать ее будете не вы, а сотни и тысячи других людей. А это огромное количество человеко-часов, которое вы врядли способны потратить для быстрой оценки RC своими силами.

>Ну и вы же так ратовали за кроссплатформенность и переносимость C++ — почему вы так зависите от версии конкретной IDE?
Кроссплатформенность и переносимость корее всего будет достижима только на условно «предыдущем» релизе, потому что ваш код должен компилироваться компиляторами на других платформах, где самые новые фичи могут быть еще не реализованы.

lair 16 июл 2015 в 10:53

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

Или наоборот были реализованы намного раньше, чем у вас.

X_OSL 16 июл 2015 в 13:40

> Или наоборот были реализованы намного раньше, чем у вас.
В данном случае да, — Visual Studio от остальных платформ.

И в целом соглашусь, что С++11 можно считать новым только судя по Visual Studio.

vladon 16 июл 2015 в 10:23

Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?

Не то чтобы активизировалась, разработка C++11 шла с 2003 года. Но вообще да.

X_OSL 16 июл 2015 в 09:21

(это 2 vladon)

vladon 16 июл 2015 в 10:01

C++ сейчас развивается так, что даже 1 год — это большой срок. Говорить C++0x — это всё равно что называть любой готовый продукт его кодовым названием на этапе бета-теста.

beduin01 16 июл 2015 в 09:56

Кстати на мой взгляд разумным компромиссом между C# и С++ является D. Фактически тот же C# только без .NET и с возможностью линковки с Си кодом.

vladon 16 июл 2015 в 10:02

Только вот кроме Фейсбука его никто и не использует особо.

beduin01 16 июл 2015 в 10:14

Там как раз его особо и не используют. Зато вот к примеру www.sociomantic.com на сколько я знаю почти полностью на D написана (ну разве что сайт наверно все же на чем-то другом).
weka.io тоже судя по их выступлению тоже очень довольны тем, что весь код на Си и скриптах на D переписали.

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

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

Инерция рынка просто очень большая. Заменить С++ на рынке не так то просто.

vladon 16 июл 2015 в 10:21

C++ будет очень трудно заменить на D. Хотя бы из-за наличия GC (что неприемлемо в большинстве ситуаций, где используется С++).

(Спорить о необходимости GC не хочу.)

gandjustas 16 июл 2015 в 20:47

В С++ умные указатели это тоже форма сборки мусора. Причем совсем небыстрая сборка.

vladon 20 июл 2015 в 17:20

Во-первых, это не сборка мусора, а RAII.

Во-вторых, неужели вы хотите сказать, что умные указатели медленнее GC? Ну-ну.

gandjustas 20 июл 2015 в 18:04

Как ни назови — суть не изменится. Если некоторый механизм позволяет вам не освобождать память вручную — это сборка мусора.

А подсчет ссылок, особенно в конкурентной среде — дорогое удовольствие. Если погуглить «smart pointer performence» можно найти даже такое flyingfrogblog.blogspot.ru/2011/01/boosts-sharedptr-up-to-10-slower-than.html

vladon 20 июл 2015 в 18:08

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

Давайте всё-таки в 2015 году ссылаться на статьи не 2011 года и тем более не про стандартную библиотеку. Давно есть make_shared. Вы не учитываете unique_ptr, аналога которого нет в обычных GC-языках.

Вот так:

shared_ptr<cons<T> > xs(new cons<T>());

не пишет никто. Это и есть основная причина потери производительности.

И сравнивать нужно с GC топовых языков, а не нишевого OCaml.

gandjustas 20 июл 2015 в 18:50

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

Такие утверждения надо доказывать. Но если вы считаете, что GC все объекты обходит, то вряд ли вам стоит размышлять на эту тему.

Давайте всё-таки в 2015 году ссылаться на статьи не 2011 года и тем более не про стандартную библиотеку. Давно есть make_shared.

И что? Структура издержек у подсчета ссылок другая, по сравнению с GC. В GC приходится платить за количество мусора в единицу времени. При подсчете ссылок надо платить за каждое присваивание (в том числе передачу параметра в функцию). Если это понимаешь, то легко найти реалистичный сценарий, когда smart_ptr проиграет по скорости GC в .NET и Java.

Вы не учитываете unique_ptr, аналога которого нет в обычных GC-языках.

На одних unique_ptr ни одну интересную программу не напишешь.

И сравнивать нужно с GC топовых языков, а не нишевого OCaml.

У топовых языков и GC получше.

vladon 20 июл 2015 в 18:11

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

Так код не пишут. Это высосанный из пальца синтетический код.

gandjustas 20 июл 2015 в 18:55

Тем не менее C++ рожает медленный код без специальных усилий со стороны программиста. Удивительно!
Причем не Java или C#, а C++.

Я выше уже писал, что дело не в том, как быстро работают указатели в C++ (а они медленные, как и вся система с автоматическим вызовом деструкторов), а в том что на C++ вовсе необязательно использовать динамическую память и большая часть объектов создается на стеке.

vladon 20 июл 2015 в 18:50

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

Не совсем. Умные указатели — это всё же ручное управление памятью. Просто объект на стеке делает всё за забывчивого или невнимательного программиста.

И сборщик мусора собирает только забытую память. RAII собирает всё — от памяти до файлов и сетевых сокетов.

gandjustas 20 июл 2015 в 18:57

Это болтология, лучше почитай, что умные дядьки пишут herbsutter.com/2011/10/25/garbage-collection-synopsis-and-c

И сборщик мусора собирает только забытую память. RAII собирает всё — от памяти до файлов и сетевых сокетов.

Ты удивишься, но GC собирает тоже самое.

Короче бросай писать о том, чего не знаешь.

DancingOnWater 21 июл 2015 в 06:38

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

Суть в том, что в С++ вы всегда можете узнать когда будет вызван деструктор (оставим клинические случаи в стороне). С GC это сделать не сможете.

Ununtrium 16 июл 2015 в 10:02

Очень поверхностный анализ с субъективными передергиваниями. Сравнение языков не под конкретную область задач вообще детский сад.

Отдельных статей требует рассмотрение выбора Java или же интерпретируемых языков. Они будут предпочтительнее, чем С++ или С# в некоторых случаях

Почему Java вдруг оказался в другой категории нежели C#?

X_OSL 16 июл 2015 в 11:48

> Почему Java вдруг оказался в другой категории нежели C#?
На это много причин, хотя на Java я писал мало, но по своему небольшому опыту(недавно Android, и лет 15 назад — портирование кое каких расчетов с Java на С++) могу сказать, что и
— она сильно проигрывает в производительности как С++ так и С#
— ее библиотеки просят рефакторинга. Субъективно, даже boost на С++ выглядит более целостным и логичным

У Java есть некоторые плюсы, но по областям применения С# и С++ пересекаются заметно сильнее чем Java и С++, по крайней мере в разработке под Windows.

Но над развитием Java тоже идет работа, возможно даже она станет значительно лучше…

Зарегистрируйтесь на Хабре, чтобы оставить комментарий