На старте проекта часто может возникнуть вопрос о выборе средств разработки и если в одних случаях ответ на этот вопрос следует из потребности совместимости с библиотеками и приложениями, то в других ответ не очевиден.
Отдельных статей требует рассмотрение выбора Java или же интерпретируемых языков. Они будут предпочтительнее, чем С++ или С# в некоторых случаях, однако вынесем такие случаи за рамки данной статьи и сфокусируемся на сравнении С++ и С#.
Для ясности обозначу, что под C++ буду понимать unmanaged код, а под C# — managed код. В статье можно было сравнить managed и unmanaged, но это было бы менее полезно практический. А mixed код, хотя он и представляет некоторый интерес, оставим по большей части за рамками данной статьи.
Прошу извинить за некоторую категоричность высказываний, однако, думаю, она требуется для более точного донесения мыслей. Сравнивать буду по критериям, давая по каждому некоторое заключение основанное на личной практике, фундаментальных основах и известному опыту использования. Итак, начнем.
1. Скорость разработки
С# позволяет стартовать разработку быстрее, а это позволяет быстрее получить прототип решения. Скорость разработки на С# на начальных этапах проекта значительно выше по сравнению с С++.
Однако, когда инфраструктура проекта создана, основные подходы и библиотеки выбраны, а билд настроен, скорость разработки на С++ и скорость разработки на С# становятся примерно одинаковыми.
Таким образом, в коротких малобюджетных проектах С# будет иметь преимущество по скорости разработки, но в длинных и относительно дорогих данное преимущество будет незначительным.
2. Кросплатформенность
С++ кросплатформенный по факту, хотя и с некоторыми оговорками, дополнительными затратами, а также бинарной несовместимость между платформами.
C#, по факту, оказался не кросплатформенный, несмотря на существование неофициальных .net окружений под разными платформами и даже потенциальную бинарную совместимость между платформами.
C# спроектирован быть кросплатформенным, однако его развитие не пошло в этом направлении. Поэтому под Windows образовалась достаточно полная .net инфраструктура; на других же платформах равноценной инфраструктуры не появилось.
При этом для разработки на С++ сложилась практически равноценная инфраструктура на большинстве существующих платформ, есть масса библиотек, которые скомпилированы или могут быть скомпилированы под любые существующие платформы. Именно поэтому существует огромное количество кросплатформенных приложений и библиотек разного масштаба, написанных на С++, на ряду с кросплатформенными библиотеками есть и библиотеки специфичные для отдельных платформ. Все это дает практический равноценные шансы для развития приложений на различных платформах.
И хотя С# возможно использовать для построения приложений под не-Windows платформы, проблемы, вызываемые использованием .net в не-Windows окружении, сводят на нет многие преимущества выбора C#. Поэтому рекомендовать его для кроссплатформенного использования можно разве что если код на C# уже написан. При этом надо четко понимать, что в перспективе это будет приносить дополнительные затраты на поддержку.
3. Производительность кода и требовательность к ресурсам
Очевидным является факт того, что возможности по оптимизации unmanaged кода куда шире, чем возможности по оптимизации managed кода. Таким образом, пиковая производительность кода достижима только в unmanaged исполнении, т.е. в пределе, почти любая задача на С++ может быть решена с меньшими требованиями к ресурсам. Поэтому в тяжелых задачах, связанных с обработкой большого количества данных, С++ имеет сильные преимущества перед С#.
Но стоит понимать, что при выборе неправильного подхода, на С++ вполне можно написать код, который будет работать медленнее кода на C#, выполняющего туже задачу.
Если говорить о совокупности субъективных «простоты разработки», «красоты кода» и объективной производительности, то используя C# проще написать код, удовлетворяющий этим критериям одновременно. Однако это не значит, что производительный код на С++ обязательно будет страшным или сложным для восприятия, просто при его написании потребуется более «творческий» подход для удовлетворения перечисленных критериев одновременно.
Фундаментальные основы преимуществ С++ в возможности писать код, который будет выполняться непосредственно процессором, и возможности прямой работы с памятью. Конечно, свобода дает больше возможностей создать себе проблемы, но в ряде случаев это лучше, чем невозможность преодоления потолка производительности. И этот потолок вполне может привести, например, к тому, что под решение задачи, для которого бы хватило одного хорошего сервера, вам придется собирать ферму из нескольких серверов, или же к тому, что ваше приложение будет требовать «топового» железа на задачи, для которых хватило бы железа выпущенного лет 7-10 назад.
4. Библиотеки
Отличие ассортимента С++ и С# библиотек в том, что С++ библиотек больше, они имеют большую историю, за которую стали неплохо отлажены и оптимизированы, часто кросплатформенны, многие с открытым кодом. Однако при всех положительных сторонах С++ библиотеки как имеют очень разную, часто даже архаичную архитектуру, часто не объектный, а структурно-процедурный интерфейс. Связано это с тем, что многое С++ библиотеки это С библиотеки.
Другая неприятная особенность С++ библиотек — это создание и переопределение своих базовых типов. Многие С++ библиотеки заводят свои типы строк, контейнеров, переопределяют некоторые базовые типы. Этому есть логичные объяснения (лучшая производительность, поддержка кросплатформенности, отсутствие подходящих типов на момент написание библиотеки), однако все это не добавляет удобства использования и красоты коду. Базовые же С++ библиотеки дают не так много, как дают стандартные библиотеки С#, поэтому подбор правильных библиотек для проекта С++ — это задача, необходимая даже в сравнительно простых проектах.
Однако не все так страшно, для С++ есть немало и «красивых» библиотек. Да и базовые библиотеки постоянно расширяются. Вопрос часто лишь в том, каких жертв потребует данная красота.
В С# перечисленных выше проблем значительно меньше. Огромное количество библиотек с .net идет в базе, плюс к ним множество свободно доступных библиотек, это покрывает практически все первостепенные задачи разработки под Windows. Наличие большого количества стандартных типов почти избавляет от библиотек, где базовые типы переопределены. И в силу того, что библиотеки С# сравнительно молодые,- интерфейсы библиотек, как правило, лучше вписываются в те или иные шаблоны проектирования, что часто упрощает их изучение.
Однако же при ближайшем рассмотрении велик шанс, что под вашу специфическую задачу С# библиотеки не окажется, более того, может оказаться, что и решать такую задачу на С# достаточно не эффективно, поэтому подобной библиотеки не появится и в будущем, а если и появится, то будет работать недостаточно быстро.
Вторая неприятная особенность библиотек С# в том, что многие из них являются просто оберткой над unmanaged библиотеками, что будет всегда приводить к потерям производительности на конверсиях типов, и создавать дополнительные проблемы отладки и распространения.
5. Удобство отладки
Можно было бы просто сказать, что под Window, С# заметно удобнее отлаживать и на этом остановиться.
Однако если по какой-то причине у вас на ряду с mananged кодом из C# сборки используется unmanаged, то его отладка будет станет более сложная по сравнению с обычной отладкой unmamanged кода из С++.
6. Язык и Синтаксис
С первого взгляда код С++ и С# очень похож внешне. Но многообразие кода на С++ больше, ведь С++ является одновременно и С и С++ и С++0х и все это вы можете использовать одновременно (конечно, если это поддерживает ваш компилятор).
С# же, это только C#, хотя его синтаксис постоянно расширяется. Код на С#, как правило, выглядит проще и лаконичнее, чем код С++ (хотя это не всегда можно было сказать про первые версии С#). Языковые конструкции С++ и С# очень схожи, однако существенные различия можно найти в деталях.
Если С++ можно упрекнуть за отсутствие «в базе» reflection, позднего связывания и сборки мусора. То С# надо упрекнуть за отсутствие полноценных деструкторов, отсутствие полноценных макросов, достаточно грубую настройку наследования, отсутствие константных методов и членов, отсутствие глобальным методов (процедур), очень ограниченную поддержку шаблонов, список можно продолжать… Однако жить без всего этого вполне можно как в случае С++, так и в случае C#.
Синтаксис С#, пожалуй, можно назвать упрощенной версией С++, таким образом С#, как и любое упрощение, одновременно несет и позитивный и негативный эффекты.
Стоит сказать, что более сложный код часто легче пишется и анализируется, если написан более простым языком. С этой позиции, используя С#, меньше шансов допустить ошибку в принципиально сложном коде и больше шансов написать чистый код, обладая теми же ресурсами. Это может быть полезно при решении достаточно сложных, но не требовательных к производительности задач. Однако при этом большее количество «синтетики» в С# делает меньше оценку производительности кода по его «внешнему виду».
7. Стоимость поддержки
В поддержке приложений большой разницы между С++ и С# нет. Хотя стоит понимать, что некоторые баги в приложениях, написанных на C#, средствами .net исправить невозможно и при необходимости их исправить стоимость поддержки может существенно возрасти. Однако если говорить о рефакторинге, то зачастую приложения, написанные на C#, рефакторить несколько дешевле.
8. Риски
Пожалуй, основной риск использования C# — это сильная завязка на Microsoft. Конечно, вряд ли Microsoft куда-то исчезнет в ближайшем будущем, но стоит понимать, что Microsoft — это коммерческая организация, целью которой является извлечение прибыли, а для прибыли нужны продажи своей продукции. Поэтому в интересах Microsoft разворачивать разработку C# и .net так, чтобы это приводило к продажам новой продукции Microsoft. Так что если интересы вашей разработки будут не соответствовать интересам Microsoft, рано или поздно это может привести к проблемам.
Риски использования С++ тоже есть, но это другие риски. Основным я бы назвал проблемы, связанные с бинарной совместимостью библиотек. Если ваши библиотеки не в исходниках, то вам важно чтобы они были совместимы. Например, переход на другой runtime будет возможен только при перестроении или получении новых версий библиотек, работа же нескольких runtime-ов в одном процессе может приводить к проблемам взаимодействия. Все это может существенно удорожить развитие проекта.
Наряду с рисками развития, есть и риски низкокачественного кода. Поскольку С# менее требователен к разработчику, вероятность появления кода низкого качества на С# в среднем выше, чем в случае С++. При критической массе подобного кода это может создать серьезные проблемы в работе приложения.
В случае С++ ситуация с низкокачественных кодом несколько лучше, т.к. шансы на выживание у плохого кода ниже, однако панацеей от плохого кода С++ конечно не является.
9. Самодостаточность приложений
Полной самодостаточности приложений нет ни у C++ ни у С#. Для С++ так или иначе нужен runtime, а для C# .net framework.
Однако хотелось бы отметить, что рантайм С++, как и любая другая библиотека, может быть статический линкован в исполняемый модуль, таким образом исполняемый модуль может содержать все необходимое для работы, и за счет чего станет самодостаточным, в случае С# такое, стандартными средствами не реализуемо.
10. Удобство сборки
Сборка С++ проектов заметно сложнее сборки проектов С#. Однако стоит понимать, что большая сложность предоставляет и дополнительную гибкость, которая рано или поздно может стать полезной вам. Правда до этого момента будет лишь увеличивать расходы вашего времяни.
11. Перспективы
Рассуждения о перспективах это всегда спекуляция. На сегодня и С++ и C# активно развиваются (хотя С++ начал активно развиваться не так давно) Однако что будет дальше?
Меня настораживает факт того, что темпы роста производительности процессоров (по крайней мере в расчете на ядро) заметно снизились и вряд-ли в ближайшем будущем мы увидим их существенный рост. То же самое, думаю, можно сказать и про производительность ввода-вывода.
Все это, скорее всего, создаст запрос на оптимизацию программных продуктов и запрос на параллельные вычисления. Я испытываю некоторый скептицизм относительно того, сможет ли С# удовлетворить все эти запросы.
Выводы
Не могу сказать, что есть универсальный ответ на вопрос «С++ или же С# использовать для очередного проекта?», однако же могу сказать, что в разные периоды своей деятельность я бы по разному отвечал на вопрос о выборе, и если лет 5 назад я бы не рассматривал C++ как предпочтительный выбор, то сейчас в большем количестве случаев склонюсь к тому, чтобы использовать его. Однако, думаю, что для быстрого прототипирования под Windows C# является и, возможно, будет являться предпочтительным решением относительно С++.
Комментарии (484)
prishelec
13.07.2015 16:26+1Спасибо автору. Помогло «окинуть » взглядом основные отличия.
Хотя не сказано было про отладку кода, здесь то разбежка в скорости будет существеннее.
X_OSL Автор
14.07.2015 00:15+3Пожалуйста.Про отладку я написал в п.5 что С# тут безоговорочно лучше до тех пор пока не нужно отлаживать Mixed код.
Вообще забавно что единственный чисто позитивный комментарий жестно заминусован.
Да, я знаю что фанаты С# и Microsoft могут болезненно отнестись к некоторым моим рассуждениям и их количество тут не в пользу моих рассуждений, но я пишу не с целью троллить фанатов, а с целью задуматься о перспективах как С++ так и С# и в конечном счете о перспективах наших приложений и нас в свете их развития.prishelec
14.07.2015 00:42+1Я не являюсь фанатом ни того ни другого. И уважительно отношусь к обоим языкам.
Я сам разработчик в области прикладного и web. Владею навыками как С++ так и шарпа, но прикладное разрабатываю – так уж сложилось на делфях.
Для меня чужое мнение о выборе языка не является конечно решающим, но считаю полезным для общего просвещения прочесть материал от человека имеющего опыт разработки в обеих сравниваемых им языках.
astudent
13.07.2015 16:32Выбор инструмента зависит от задачи. Нельзя сравнивать два языка по отношению к абстрактному проекту. И да, некоторые аргументы в статье достаточно спорны.
Например, странно писать обычное ui-приложение на плюсах под винду, также как и на шарпе кроссплатформенную игру под андроид и айос.
qw1
13.07.2015 16:51+13также как и на шарпе кроссплатформенную игру под андроид и айос
Тысячи их, на фреймворке Unityastudent
14.07.2015 12:15Я сам использовал и Xamarin, и MonoGame, и могу вас заверить, что это не лучшее решение.
Я же не отрицаю, что нельзя, можно и на плюсах обычное ui-приложение наваять, но этот инструмент не для таких задач.
А вот банковский клиент на Xamarin под три платформы — самое то.
Nagg
15.07.2015 12:02Может потому, что моногейм не лучшее решение, а не Xamarin? Знаю несколько игр, написаных на Xamarin (не MG) которые работают очень шустро (и новые фичи в них добавляются очень быстро сразу на все платформы ибо C#).
X_OSL Автор
13.07.2015 22:21UI-приложения бывают разные. Например если это CAD (или другое ресурсоемкое приложение), то исключительно на шарпе он будет очень неэффективный (медленный и часто прожорливый).
Бывает такие приложения сводится к компромисному решению, когда в одном приложении собирается нативный код для рендеринга и ресурсоемких задач, а C# для UI.
Все это приводит к Mixed коду который отлаживать часто хуже чем нативный C++ код. Про частные проблемы с Mixed кодом можно написать достаточно много, но это за рамками статьи.
Razaz
14.07.2015 11:00+4WPF в Autocad так та…
Странное заблуждение по части прожорливости — не плодите объекты бездумно и все будет ок.
Такими темпами можно и до ассемблера опуститься. Вот еще на почитать — Numeric performance in C, C# and Java
DancingOnWater
14.07.2015 11:15Уверены?
forums.autodesk.com/t5/tag/Qt/tg-p www.nixp.ru/news/10377.html да и среди вакансий есть псециалисты по QtRazaz
14.07.2015 11:23+1И? с 2009 года морда Autocad перепилена на WPF. MS нанимает спецов по Linux — пилят свой дистр?
Можете ради интереса погуглить Autocad + WPF.
Интерфейс AutoCad 2009 построен на WPFX_OSL Автор
14.07.2015 11:31Autocad перепилена на WPF
Чуть точнее — на WPF в нем добавлен рибон и кнопка «пуск» + несколько _новых_ диалогов написаны на WPF. Больше WPF там нет. Примечательно, что далеко не все новые диалоги с 2009 года были построены на WPF. И разумеется к рендерингу сцены WPF не причастен вообще.Razaz
14.07.2015 11:39+2Одновременно используется одна из новых возможностей упрощенного хостинга Direct3D сцен в рамках приложения для той части, где визуализируются создаваемые модели.
Только сейчас весь гугл закакан туториалами о том как хостить WPF в автокаде во всех возможных местах) Если научились делать игры на C# так что GC не мешает, то уж UI нарисовать — не проблема. В целом, я бы на вашем месте обсуждал тему десктопных приложений на JS, так как в 90% случаев C#+Java не оставят шансов C++ на сервере и клиенте(ИМХО).
X_OSL Автор
14.07.2015 13:08Хостинг WPF для сцены в Автокаде не используется. Максимум для превью в тултипов, но это вряд-ли можно назвать хостингом Direct3D сцен.
Насчет игр, пока не видел тяжелых 3D игр на C#, все(что я знаю) топовые 3D игры — исключительно С++. Если у вас есть примеры релизов чего-нибудь уровня GTA4,5\Fallout\Battlefield на C# — очень хотелось бы увидеть, напишите пожалуйста.
Десктопные приложения на JS я бы вряд-ли ожидал. Я не спорю, что например на связке HTML+JS и правильном подходе можно достичь производительности не многим меньше чем на связке WPF + C#, но все-таки для interoperability JS мне кажется плохой вариант, да и инфраструктура JS библиотек недотягивает ни до С# ни до С++ в области за пределами написания веб клиентов.Razaz
14.07.2015 13:34У вас есть исходники Автокада?
C# for Gaming
«Тяжесть игры» это что? Если вы про рендер — то спору нет. Но тут и C++ не всегда хорош) Если про логику — то разницы особой нет. Вон на Unity шлепают фигалионы игр. Как Мигель договорится то и в UE появится поддержка C#.
C# прекрасно уживается вместе с C++ как в движках так и в тулинге и на серверах.
ORLY?
Atom, VS Code нативные приложения в Win на XAML+JS?
X_OSL Автор
14.07.2015 14:15Зачем исходники, когда есть дизассемблер, Spy++ и reflector ?:)
Под тяжестью конечно рендер в первую очередь имею ввиду.
Atom, VS Code нативные приложения в Win на XAML+JS — не встречался с этим. не могу судить, если есть примеры приложений обещаю посмотреть.Razaz
14.07.2015 14:33Я не берусь судить весь их codebase по Spy++ )
Редкое использование C# в рендеринге в первую очередь из-за необходимости RAII и нежелательности доп. интеропа. Тут уж разные платформы и особо ничего не попишешь(разве что Unsafe, но расходы на интероп остаются)
Но и тут уже есть прогресс — Paradox 3D Engine Trailer
Paradox Game Engine. Плюс не списывайте со счетов .Net native. Поглядим еще как пойдет ;)
Активно педалируемая тема — берем V8 и хостим в него наше приложение на JS — Profit.X_OSL Автор
14.07.2015 16: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.07.2015 12:58Вы не думали что просто через одно место написана? Можно и на C++ Написать так, что будет ползать.
Вот небольшой пример — Debunking C# vs C++ Performance
У C++ нет явных преимуществ без RAII и возможности работы с памятью. Небольшой оверхед есть из-за рефлекшена, но он же иногда помогает компилятору лучше оптимизировать код чем на C++. Плюс советую посмотреть .Net Native.
С++ нишевое решение для специфических задач, где необходим очень жесткий контроль ресурсов, да и то при большом желании — unsafe в помощь.
В общем можете почитать достаточно подробные ответы на SO — C++ performance vs. Java/C#
X_OSL Автор
15.07.2015 13:50-1>Вы не думали что просто через одно место написана?
Никакой другой .Net библиотеки решающей ту же задачу я не нашел. Вообще.
>Вот небольшой пример — Debunking C# vs C++ Performance
Это же чистая синтетика в вакууме, работающая сама с собой.
В реальных же задачах нужно достаточно часто работать с системой, где и случаются основные провалы у С# на маршалинге
>.Net Native.
Интересно. Пара глупых вопросов по нему: как его потом дебажить? И можно ли заставить студию строить прямо в него, а не в IL?
>В общем можете почитать достаточно подробные ответы на SO — C++ performance vs. Java/C#
Кажется читал как-то, но ссылка хорошая, спасибо.Razaz
15.07.2015 14:18+3И? Причем тут выводы о быстродействии .Net на основе левой либы?
Это пример, показывающий что говнокодить можно везде, и вы, возможно сталкивались с этим. Делать выводы на основе этого — глупо.
Google
X_OSL Автор
15.07.2015 15:09Насчет поиска в google, я как вы наверное догадались искал, просто читать всю выборку в поисках особенностей построения и дебага достаточно долго. Поэтому и задал вам вопросы, как человеку вероятно использующего данную технологию.
Односложных ответов мне бы хватило, что сэкономило бы немного и вашего время и моего времени, но тут ваше право.
>И? Причем тут выводы о быстродействии .Net на основе левой либы?
Я видел и другие библиотеки .net, которые не поразили меня своей производительностью.
Например возьмем WPF, вы тоже скажете что это пример говнокода?
Если нет, то почему у нее такая низкая производительность?
Попробуйте создать какой-нибудь форматированный датагрид с тысячей-другой элементов. Навигация по ячейкам этого грида будет идти крайней медленно, вы можете шаманить с отключением и включением виртуализации, но сильно это не поможет отзывчивость приложения будет никакой.
Или например WPF рибон, в каком-нибудь автокаде или вашем приложении. Почему переключение между табами идет так долго?
А если взять какую-нибудь библиотеку WPF контролов, например DevExpress, то там с производительностью все будет еще раза в 2 хуже.
Вы можете сказать что C# в этом не виноват, что .net в этом тоже не виноват.
Хорошо, а кто тогда виноват в столь низкой производительности WPF?Razaz
15.07.2015 15:38+4Если вас интересует отладка — Debugging support for .NET Native Preview apps
С чего вы взяли что у WPF низкая производительность? На нем например пишется софт для трейдеров в Дойче Банке ЕМНИП?
Вы серьезно? Для начала соберите свой софт без флага Debug ;)
Не берите DevExpress. Возьмите Telerik или напишите свое.
Вы серьезно думаете что в медленном переключении табов виноват .Net? Еще раз — если вы сталкивались с посредственными результатами — не означает, что .Net медленный. Это то же самое, что сказать — C++ медленный, так как игры на нем тормозят.
X_OSL Автор
15.07.2015 16:38-4>С чего вы взяли что у WPF низкая производительность?
Из собственной практики, я даже примеры привел.
>На нем например пишется софт для трейдеров в Дойче Банке ЕМНИП?
Я очень сильно этому удивился. Может это попил какой-то…
>Telerik
Вполне возможно он заметно быстрее DevExpress, но базовую тормозню WPF он вряд-ли уберет.
>Если вы сталкивались с посредственными результатами — не означает, что .Net медленный
Не подскажите альтернативную UI библиотеку под .net без проблем с производительностью?Razaz
15.07.2015 17:33+3Ваша практика — контрол от DevExpress?
Попил в Дойче — это даже не смешно.
Еще раз повторю — торомозит не WPF, а товарищи, пихающие в ObservableCollection миллион записей по одной.
X_OSL Автор
15.07.2015 18:34>контрол от DevExpress
У DevExpress медленно работали Tabbed groups, Grid, Property Grid
Чего там в Дойче я не знаю, но у меня тормозит именно WPF, например у моем обычном wpf датагриде нет никаких ObservableCollection, но как только там появляется больше 1000-2000 элементов он начинает тормозить.
Я его профайлил — тормозит обход дерева визуальных элементов и многократные вызовы Measure.Я незнаю зачем так часто и в таком количестве мерить ячейки грида, но я знаю что мой код в этом процессе не вызывался.Razaz
15.07.2015 22:28+3Еще раз — как тормоза DevExpress относятся к .Net? И еще раз — тестить производительность надо без флага Debug.
Может надо понять почему он тормозит при 2000+ элементах? У нас в админке по 10к+ транзакций без тормозов показываются, а у вас простой грид тупит. Может искать проблему в своем коде?
Вот ответ на ваш вопрос — Performance issue with “Measure”
Обычный баг для которого уже давно есть хотфикс. При чем тут .Net то? Как лишние вызовы метода стали являться мерилом производительности платформы?X_OSL Автор
15.07.2015 22:39Спасибо конечно, но эти фиксы не помогают. Проблема с вызовом UIElement.Measure вылезает даже на последних версиях фреймворка, где все фиксы уже включены.
Вероятно что то недофиксили и забили, как это принято в Microsoft :(Razaz
15.07.2015 22:46+1Или вы криво построили дерево контролов, проводите лишние модификации дерева.
Может перестанете кидаться голословными утверждениями? После того как вы сделали вывод о тормозах .Net по частому вызову метода Measure в WPF — я бы рекомендовал вам внимательно присмотреться к своему коду.
WPF MeasureOverride called multiple times after multiple PropertyChanged notifications
Optimizing Performance: Layout and Design
X_OSL Автор
15.07.2015 23:14Да тут собственно и дерева то нет. Я же говорю, только обычный родной WPF датагрид. В нем штук 10 колонок, некоторые из них на основе DataTemplate c одним простым контролом (комбобоксом или datetime picker или numericupdown из codeplex) внутри, остальные колонки стандартные.
Из своего кода только установка ItemSource обычным листом из 1000-2000 элементов и xaml разметка.
И вот этого уже хватает чтобы контрол скролился с сильными лагами, а в профайлере были многочисленные вызовы Measure.
Код смотрели многократно — нету там ничего особенного.Razaz
15.07.2015 23:21+1Как нет? Вы точно понимаете как устроен WPF? У кого Measure то дергается? В ответ на какое событие?
Если это грид DevExpress — то к ним и пишите на форум. Опять же WPF и .Net То тут каким местом?
Не поленился, скачал демку Telerik — 1 млн. записей отфильтровались за ~400ms и плавно скролятся.
X_OSL Автор
15.07.2015 23:53Кроме грида на форме ничего не было, поэтому дерево только грида.
Measure дергается по всей видимости для ячеек грида в ответ на попытку скролить содержимое.
Это стандартный датагрид WPF.
(C DevExpress отдельные проблемы)
Telerik вполне возможно работает лучше — не знаю — не пробовал…
gouranga
16.07.2015 00:48+2Я сейчас сделал датагрид, в нем 10,000,000 элементов. И ничего не тормозит, виртуализация работает…
Какая точно была версия фремворка? Как вы добавляли элементы? Просто datagrid.ItemsSource = somelist? Что было внутри того контрола numericupdown смотрели? Как правильно заметил Razaz: Measure у какого элемента дергался и после чего? Если фреймворк был >= 4.5, то какой стоял VirtualizationMode?
Пожалуйста, покажите уже этот код. Хочу понять, что за мистика такая у вас.qw1
16.07.2015 00:58А теперь заказчик хочет, чтобы слово Customer было зелёным, а номер за ним — красным. Для этого ячейка темплейтится и в template ставится два TextBlock. Вроде как после этого будет плоховато скроллиться
gandjustas
16.07.2015 03:04+2Не будет. Только если ты datatemplate selector применишь, или группировку к элементам и еще в некоторых случаях. А по умолчанию виртуализирует и показывает спокойно хоть миллионы элементов.
qw1
16.07.2015 12:18После TDBGridEh из дельфи, который стабильно даст 60fps при навигации, wpf-ные гриды оставляют плохое впечатление. Сложно объяснить, но как будто интерфейс лагает, уже в раздумьях не погоняешь Selection по строкам, потому что лаг отклика раздражает.
X_OSL Автор
16.07.2015 12:36Кстати можете ради интереса попробовать UI из FLTK
Это кросплатформенная С++ библиотека, кстати разработка по ней вполне жива
www.fltk.org/index.php
Там конечно нельзя по-простому делать всякие WPF-овские красивости и нет биндингов, но UI написанный на ней крайне отзывчивый.qw1
16.07.2015 17:22К сожалению, на плюсах никто не даст писать gui для enterprise ))
lair
16.07.2015 17:39Интересно, почему?
qw1
16.07.2015 18:32Молодёжь не умеет писать на древних языках
lair
16.07.2015 18:33Ну «даст/не даст» — это обычно начальство, а оно обычно не такое молодое и дерзкое.
qw1
16.07.2015 19:16gui обычно дают писать новичкам, начальство будет из этих соображений решать, на чём его писать
lair
16.07.2015 19:42Это заведомо проигрышная стратегия, вне зависимости от языка.
qw1
16.07.2015 21:42Почему? Вместо нудного клепания тупых формочек и отчётов лучше дать новичкам нечто сложное и важное?
lair
16.07.2015 21:50Потому что хороший интерфейс — это не тупые формочки и отчеты.
qw1
16.07.2015 22:16Есть масса типовых задач, таких как показать движения по счёту или вывести складские обороты. Интерфейс давно придуман — обычная таблица, ничего лучше не нужно.
Или есть такие скучные направления, как «зарплата и управление персоналом». Там в приложении куча списков сущностей и редакторов для них. Что там можно сделать хорошего и нетупого, кроме как поиграться расположением контролов, размером и цветом кнопочек?lair
16.07.2015 22:24Перевести с сущностно-ориентированной парадигмы на задаче-ориентированную, например. Внезапно выяснится, что это далеко не так скучно, как кажется.
qw1
17.07.2015 00:13Обычно пользователи привыкли работать по стандартам (и это в принципе нормально, годами проверенные способы работы) и от программиста не ждут, что он придумает новые подходы к работе, а если и придумает, скажут — не хотим нового, хотим привычного.
lair
17.07.2015 00:47И будут неправы. Хотя, конечно, придумывать новые подходы должен не программист, а UX-дизайнер, но реализовывать-то потом все равно программисту.
X_OSL Автор
16.07.2015 18:33+1В enterprise отзывчивость интерфейса стоит на одном из последних мест в списке приоритетов.
Ведь тот кто за него платит, и тот кто им пользуется — как правило абсолютно разные люди.
(я возможно немного драматизировал ситуацию, но думаю не сильно)
gandjustas
16.07.2015 13:08У меня на WFP 3.5 не было проблем с производительностью грида, 60FPS на современном (на тот момент) компе.
Если чето лагает надо запускать профайлер и смотреть что. Скорее всего перерисовка в несколько слоев.
ЗЫ. Не надо WPF запускать в RDP.
X_OSL Автор
16.07.2015 08: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.07.2015 11: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.07.2015 11:54+1На самом деле, там регулярно упоминаются какие-то контролы с codeplex. В них вообще что угодно может быть.
X_OSL Автор
16.07.2015 12:12>Остальное и так все было.
и datagridtemplatecolumn-ы были и биндинг на контролы в них?
>В общем, я думаю что где-то у вас в коде зарылась ошибка. С виртуализацией такой DataGrid вообще не тормозит — визуальное дерево обновляется только для того, чтобы покрыть видимую область.
Видимо нужно найти время и тот проект, и выцепить грид оттудаX_OSL Автор
16.07.2015 19:27+1А вот кстати воспроизвел, на обычном гриде, даже без темплейтных колонок.
Вот скриншот
i61.tinypic.com/f00uwo.png
Снапшута профайлера во время скроллинга вертикальным скроллером вверх и вниз. Лаги при этом страшные(без профайлера разумеется)
(почемуто у меня нормально картинка в пост не вставилась :( )X_OSL Автор
16.07.2015 19:36Да и еще проект тестовый, очень быстро набросан, кода почти нет
s000.tinyupload.com/?file_id=09607171972593390390
Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.
X_OSL Автор
16.07.2015 19:44Перезалил скриншот профайлера, тот както плохо открывается
s30.postimg.org/4lvgfhrnl/Measure.png
X_OSL Автор
16.07.2015 20:05В общемто тут нет ни темплейтных колонок, ни codeplex-а, ни стилей.
Тут вообще ничего нет, только сгенеренные данные, и достаточно много колонок (автогенеренные колонки я не выключал)
Виртуализация — включена.
X_OSL Автор
16.07.2015 20:51Показываю код
s000.tinyupload.com/?file_id=09607171972593390390
Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.
А ниже можно еще найти скриншот профайлера.
X_OSL Автор
16.07.2015 22:49Razaz, я выложил тестовый проект с тормозным гридом (на чистом WPF), и скриншот профайлера во время скрола. Можете посмотреть и вынести свое суждение относительно причин тормозни, былобы очень интересно узнать.
X_OSL Автор
14.07.2015 11:24WPF в Autocad — да это реальность, но там есть и Windows Forms, и MFC даже на html+javascript некоторые контролы написаны.
Qt в виндовом Autocad я не замечал, но возможно они работают над тем чтобы уйти от зоопарка Microsoft контролов, кто знает…
Так или иначе, под MacOS есть своя версия Autocad и она написана не на UI от Microsoft.Razaz
14.07.2015 11:31Спору нет. Просто у них скорее всего ядро и морды для каждой платформы — под Win — скорее всего перепиливают на WPF+XAML. Ядро хоть на бэйсике можно написать, один фиг все будет слито на видеокарту для рассчета.
maaGames
13.07.2015 16:33+7Дочитал до пункта про отсутствие сборки мусора в С++ и ринулся комментировать, извините.
1. Сборщик мусора в С++ НЕ НУЖЕН! Точка.
2. Если (ЕСЛИ!!!) сборщик мусора в С++ всё-таки нужен (прям необходим, ага, RAII для слабаков, дайте сборщик мусора, даже два), то этот самый сборщик мусора вполне можно реализовать самостоятельно. Т.к. самостоятельно реализовать сборщик мусора такой программист не сможет (такой — которому нужен сборщик мусора), то его можно взять из библиотеки Loki, например. Александреску не только с шаблонами извращается. Его вкусы могут показаться… хотелось вставить картинку про 50 оттенков, но лучше не буду.)
Пока писал комментарий, случайно прочитал пункт 9. Опровергну. На С++ можно скомпилировать приложение БЕЗ рантайма. Это будет извращение похлеще реализации сборщика мусора, но это возможно.
Добавлю ещё к выводу: С++ и С# это разные языки с разными задачами. Их бесполезно сравнивать. Вот замените цвет текста у кнопки на С++ и С#. А после нажатия на эту кнопку, производится поиск обратной матрицы размером 100000*100000. И какой язык для этого лучше? ;)BOBS13
13.07.2015 16:50+6Меня больше всего поразило, записанный в минус отсутсвие глобальный процедур и функций в C#. Это огромный плюс. Это ООП, какие глобальные процедуры.
kekekeks
13.07.2015 18:34+2Есть using static же.
BOBS13
13.07.2015 18:36Пока до нас докатится C#6, много еще ждать. Поэтому пока о нем умолчим.
kekekeks
13.07.2015 18:38+3Он прекрасно работает даже при использовании .NET 2.0 в качестве целевого фреймворка. Я не вижу ни одной причины не использовать его уже сейчас и начал миграцию всех проектов ещё пару месяцев назад.
stepik777
14.07.2015 01:33+1Ну напишите вы статический метод вместо глобальной функции, по сути — то же самое, зато «ООП».
atd
13.07.2015 16:54> На С++ можно скомпилировать приложение БЕЗ рантайма. Это будет извращение похлеще реализации сборщика мусора, но это возможно.
Есть ещё один вариант: слинковать рантайм в свой бинарник, это очень просто, но имеет свои плюсы и минусы
DancingOnWater
13.07.2015 16:55-10в Qt замена цвета кнопки — плевое дело, ну а для матриц есть Eigen. Так что в данном сравнении C# проигрывает C++ по всем статьям.
maaGames
13.07.2015 17:15-1Да, я несколько не корректно выразился. Разумеется, я имел в виду замену цвета текста кнопки на чистом WinAPI (к С++ вообще никакого отношения, (MF)Сишечный код).
X_OSL Автор
13.07.2015 22:281. Может быть он и не нужен, но его отсутсвие влечет дополнительные требования к разработчикам, что так или иначе удорожает разработку.
2. Это хорошо.
На счет разних задач С++ и С# я соглашусь. Но вопрос в том где проходит линия раздела этих задач?
Ведь широкий круг задач успешно решаем и на С++ и на С# соизмеримым количеством времяни разработчика…stepanp
13.07.2015 22:39-3В задачах требующих высокой производительности, наличие gc наоборот усложняет разработку
grossws
14.07.2015 04:00Сильно зависит от задачи. И того, что понимать под производительностью (throughput или latency). В комментариях к этому топику их периодически путают.
gandjustas
14.07.2015 05:03+3А можно пример, какие задачи вы имеете ввиду? И какую производительность вы имеете ввиду?
Я видел несколько задач, в которых 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.07.2015 07:19Хороший комментарий, отражающий давольно полно текущую ситуацию.
Я бы добавил еще один момент: кроме задачи стоящей в данный момент неплохо бы учитывать и перспективы приложения (что актуально в долгосрочных проектах и относительно крупных) — может стать что оно попадет например в одну из перечисленных категорий.gandjustas
14.07.2015 19:47К счастью, не может. Такие вещи как базы, браузеры и hft не рождаются в процессе эволюции прикладных приложений, всякие плагины тоже. И вообще такие задачи редки, вот вы например что писали на c++?
stepanp
13.07.2015 22:45Четкой линии водораздела не существует, выбор технологии решается для каждой задачи(проекта) отдельно. И для этого уж точно не нужно делать «анализ» на пятьсот пунктов. Если это конечно не троллинг ;)
X_OSL Автор
13.07.2015 22:56Я часто сталкивался с ситуациями, где выбор падал на C#, даже без мысли относительно анализа и мне не кажется такой подход правильным.
С другой стороны, я сталкивался и с ситуациями, где С# проекты портировалисть на С++, хотя ранее выбор безоговорочно падал на C#.
Мне кажется портирование с C# на С++ может стать трендом будущих разработок.
Хотя конечно можете считать это троллингом:) Но я правда думаю что вероятность развития трэнда по переходу с С# на С++ достаточно высока.stepanp
13.07.2015 23:08Тренд по переводу проектов с шарпов на плюсы может возникнуть вследствие тренда бездумного выбора языка под проект. Сталкивался с ситуациями когда выбор падал на С++ просто «патамушта не люблю сишарп» или «не люблю языки с gc» или «проприетарщина отстой».
X_OSL Автор
13.07.2015 23:30Видимо я сталкивался с ситуациями, где бездумно выбирали С# «патамушта можно писать быстрее», и вообще «все что надо есть».
И этот расчет был верен по своему. Если бы в 2000х годах производительность железа росла бы также как м в 90х, никаких С++ 0x мы бы не увидели. Но реальный рост производительности сильно замедлился…
nomit
14.07.2015 06:30+5Мне кажется портирование с C# на С++ может стать трендом будущих разработок.
Ох уж эти сказочки! Ох уж эти сказочники!
Вы как будто с другой планеты. Вряд ли заказчики будут платить за такое, дешевле докупить оперативки или уйти в облака, чем переписывать проект с одного языка на другой. Причем необходимость такая может понадобится только в реал-тайм системах требующих молниеносный отклик, но во первых такие системы скорей всего уже написаны на языке под конкретное железо, а если нет то их на столько малый объем, что назвать это портирование, с С# на С++, тредом язык не повернется сказать.
PS. Я все же допускаю, что вы из будущего. В котором к власти во всем мире пришел Тиран с фетишизмом к С++. Был издан закон об святой инквизиции неугодных языков.X_OSL Автор
14.07.2015 09:52-5Совсем не факт, что железо будет докупить дешевле. Например даже скромные +500$ на рабочее место в большой компании дадут десятки, а может и сотни тысяч, и это не говоря о потреблении энергии и других конкурентных преимуществах. А повально уходить в облака большие компании пока не торопятся…
Да и подумайте сами, что такое облако? Это в конечном счете это то же железо, но удаленное и в аренде, то есть проблемы с облаком те же, но лежат на компании которая держит облако и так или иначе будут отражены в стоимости аренды облака, а стоимость аренды будет влиять на затраты.
Таким образом перепись критичных к производительности компонентов вполне может стать экономический выгодной. Насчет «тренда», возможно я несколько преувеличил, но думаю что как минимум явление переписи библиотек с С# на С++ будет достаточно распространенным в будущем.nomit
14.07.2015 09:58+500$ рабочее место(не знаю что за компания такая? со специалистами студентами?) * на количество месяцев потраченное на переписку продукта.
Как раз в современном мире как раз тенденция докупить железа. чем нанимать штат специалистов. Да еще и во время портирования не о каких новых фичах и быть не может, а бизнес к такому крайне скептично относиться.X_OSL Автор
14.07.2015 10:22Вы наверное неправильно поняли что я написал.
Я писал про затраты на железо в +500$ на рабочее место, а не про затраты на разработку. Затраты на разработку будут другими, но если разработчиком многократно меньше чем пользователей они вполне могут окупиться.
Да и по поводу переписи продуктов. Продукт может быть дешевле переписать, чем вообще остаться без ниши на рынке.
lair
14.07.2015 10:04+1А какой смысл переписывать «библиотеку» с C# на С++? Большая часть внешних зависимостей в .net — инфраструктура, она ничего от этого не выиграет.
X_OSL Автор
14.07.2015 10:48Зависит от интерфейсов библиотеки и того что именно делает библиотека.
Математика например слабо завязана ни инфраструктуру. Работа с файлами может сравнительно легко переведена на схожую C++ инфраструктуру. Работа с не-.net библиотеками «сама просится» к такому переводу.
Конечно для .net есть некоторая уникальная инфраструктура, но все-таки многое из .net инфраструктуры имеет адекватные аналоги для С++ (что не всегда верно в обратном направлении)lair
14.07.2015 10:52Математика например слабо завязана ни инфраструктуру.
И зачем переписывать математическую библиотеку с C# на C++ — на плюсах своих библиотек мало?
Работа с файлами может сравнительно легко переведена на схожую C++ инфраструктуру.
Весь «новый» I/O в .net сделан с учетом TPL, и переписать это на C++ (с сохранением внешнего интерфейса) просто не выйдет (точнее, будет неоправданно дорого).X_OSL Автор
14.07.2015 11:09И зачем переписывать математическую библиотеку с C# на C++ — на плюсах своих библиотек мало
Имеется в виду случай, если это ваша библиотека, которую разработали вы для ваших расчетов.
Весь «новый» I/O в .net сделан с учетом TPL
Проблема не в I\O, а в быстрой раскладке файла в тот вид с которым вы сможете работать.lair
14.07.2015 11:10+1Проблема не в I\O, а в быстрой раскладке файла в тот вид с которым вы сможете работать.
И это принципиально непотоковая задача?X_OSL Автор
14.07.2015 12:12При раскладке файла со ссылками между сущностными записанными в нем, часто нужно выполнять что-то вроде обхода сети.
Это можно делать в потоках, но далеко не всегда можно спланировать равномерную загрузку потоков и избежать необходимости синхронизации, ведь в конце концов прочитанные данные нужно будет как-то связать между собой, и если мы хотим быстрые связи — то прямыми ссылками.
Да и если все это удастся сделать, на потоках С++ параллельное решение все-равно будет работать быстрее…lair
14.07.2015 12:14Я не про те потоки, которые threads, я про те, которые streams — т.е., про чтение/запись файла.
X_OSL Автор
14.07.2015 12:31+1Я чаще сталкивался с тем что производительность упирается не в скорость работы stream-a, а в скорость обработки прочитанного из него.
Поэтому и пишу что с файлами часто проблема в производительности обработки, а не в самом I\O.lair
14.07.2015 12:35+2Я чаще сталкивался с тем что производительность упирается не в скорость работы stream-a, а в скорость обработки прочитанного из него.
Ну вот а у меня в опыте ситуация обычно строго обратная (причем как в опыте программиста, так и в опыте пользователя). Отсюда и разница в подходах.
gandjustas
14.07.2015 19:53За время чтения с диска одного мегабайта можно около 1000 раз отсортировать этот мегабайт в памяти. Поэтому упереться в обработку можно только на очень маленьких файлах. Но тогда и время обработки очень маленькое будет.
X_OSL Автор
14.07.2015 20:07Как правило, задачи стоят несколько сложнее чем сортировка мегабайта во время чтения.
Да и мегабайт на диске как правило архивированный тем или иным способом, поэтому развернутый в объектную модель может занимать в десятки, а то в сотню раз больше памяти чем занимал на диске.
Типичными задачами будут распокавать, так или иначе интерпретировать сожержимое, собрать из этого содержимого объекты, построить индексы на них или связать их тем или иным способом. Непосредственно чтение файла из этого занимает малую долю.gandjustas
14.07.2015 22:06Как правило, задачи стоят несколько сложнее чем сортировка мегабайта во время чтения.
Например?
Да и мегабайт на диске как правило архивированный тем или иным способом, поэтому развернутый в объектную модель может занимать в десятки, а то в сотню раз больше памяти чем занимал на диске.
Большинство алгоритмов архивирования потоковые, им не надо читать весь файл. То есть вполне можно разархивировать во время чтения.
Типичными задачами будут распокавать, так или иначе интерпретировать сожержимое, собрать из этого содержимого объекты, построить индексы на них или связать их тем или иным способом. Непосредственно чтение файла из этого занимает малую долю.
Архивация — потоковый алгоритм, построение индекса — сортировка, которую за время чтения мегабайта можно успеть 1000 раз выполнить. Само чтение будет занимать малую долю только на очень маленьком файле. Но тогда вообще нет смысла говорить о времени работы.X_OSL Автор
14.07.2015 22:30Откуда вы взяли все эти цифры, как вы считали?
Почему вы пропустили этап создания объектов из прочитанных данных?lair
14.07.2015 22:42Потому что в среднем этот этап занимает пренебрежимо мало времени даже по сравнению с сетевом i/o, не говоря уже о дисковом.
X_OSL Автор
15.07.2015 09:01Вот смотрите, HDD умеет отдавать данные со скоростью примерно 80 Mb/s, SSD так вообще 300 Mb/s, эта скорость вполне реальна если просто брать данные с носителя в память как есть.
И вы хотите сказать что сжатый структурированный структурированный поток данных распаковывается и раскладывается в объектную модель параллельно процессу чтения, с той-же скоростью? Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?
И да, простой пример: по такой логике копирование архива и распаковка архива должны занимать почти одинаковое время, но это не так.
vedenin1980
15.07.2015 09: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.07.2015 09:57> если HDD/SSD не занят другими процессами
Я именно об этом и говорю. Не надо занимать другими процессами — и у вас будет производительность, а если полезете в параллель — получите падение производительности везде, так как железо будет дольше переключаться, чем передавать вам данные. (кстати с SSD ситуация лучше в этом плане)
> Базы данных, интеграция, любые высоконагруженные приложения ВСЕГДА утыкаются в скорость чтения с диска
Я разбирал другой пример. Упакованный структурированный файл, который нужно разложить в объектную модель, а не storage базы данных формата оптимизированного до такой степени, что времени на его обработку практически не требуется. Конечно там будет все упираться в железо.
>Распаковка архива в памяти выполняется намного быстрее чтения с диска почти всегда (есть совсем уж медленные форматы, но их в интеграции не используют), основное замедление происходит когда пытаешься записать распакованный архив на диск.
Я согласен с тем что сравнение с копированием не совсем корректное, если объем распакованных данных много больше упакованных.
Но мы можем упаковать например какой-нибудь divx\xvid AVI — он практический не сожмется, поэтому разницы времени записи между копированием и распаковкой не будет. Однако почему-то он будет дольше распаковываться, чем просто копироваться…vedenin1980
15.07.2015 10:10Упакованный структурированный файл, который нужно разложить в объектную модель, а не storage базы данных формата оптимизированного до такой степени, что времени на его обработку практически не требуется. Конечно там будет все упираться в железо.
Я тоже про это говорил, на самом деле объектная модель в памяти создается быстро были бы данные, забить 10 Гб объектами меньше чем за секунду не так сложно.
gandjustas
15.07.2015 11:08HDD 80МБ в секунду? Да вы оптимист, реально для HDD рассчитывать на 10мб в секунду в лучшем случае. А ssd вам еще никто не даст, все SSD давно под sql server задействованы.
10МБ в секунду не означает, что мы секунду ждем, в потом 10мб обрабатываем. Мы читаем 100КБ, а пока ждем буфера обрабатываем предыдущие 100КБ прочитанных.
То есть суммарное время при потоковой обработке растет незначительно.
И да, простой пример: по такой логике копирование архива и распаковка архива должны занимать почти одинаковое время, но это не так.
В большинстве архиваторов распаковка это — чтение всего архива в память, работа алгоритма распаковки, запись кучи отдельных файлов на диск. Самая долгая операция — запись.
При копировании файла используется как раз потоковая модель, поэтому суммарное время возрастает не сильно (если диски разные).X_OSL Автор
15.07.2015 19:57>HDD 80МБ в секунду? Да вы оптимист, реально для HDD рассчитывать на 10мб в секунду в лучшем случае.
У меня HDD без проблем выдает 80МБ в секунду. Мне сложно представить где взять HDD, который выдаст только 10мб в секунду. Если только по USB 1.1 его подключить :)
lair
15.07.2015 11:30Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?
Чтение нежатого видео с диска. Чтение большого PSD с диска. Сканирование большого объема фотографий в поисках нужного тега.X_OSL Автор
15.07.2015 20:07>Чтение нежатого видео с диска.
Тут упремся в железо без вариантов. Если есть возможность видео лучше пожать.
>Сканирование большого объема фотографий в поисках нужного тега.
Есть смысл построить индекс на теги. Или хотябы испрользовать SSD, на HDD это будет работать более-менее быстро только на втором поиске, когда он прокэшируется.lair
15.07.2015 20:44Тут упремся в железо без вариантов. Если есть возможность видео лучше пожать.
Что камера отдала, с тем и работаем.
Есть смысл построить индекс на теги.
Есть-то есть, только индекс (а) тоже надо построить, это время и (б) он все равно будет ограничивающим фактором по скорости.X_OSL Автор
15.07.2015 22:15>Что камера отдала, с тем и работаем.
можно попробовать брать поток в память прямо с камеры по USB\Firewire (или как она подключается), сжимать и уже потом класть на диск…
>Есть-то есть, только индекс (а) тоже надо построить, это время и (б) он все равно будет ограничивающим фактором по скорости.
Индекс конечно решение неоднозначное. Если сканирование нужно проводить всегда для разных множеств фотографий — то лучше наверное просто взять SSD и все.
А если надо многократно сканировать надо одни и теже фотографии, которые могут немного меняться, то индекс должен бы окупиться, если правильно прописать его обновление.lair
15.07.2015 22:17можно попробовать брать поток в память прямо с камеры по USB\Firewire (или как она подключается), сжимать и уже потом класть на диск…
И мы будем ограничены в скорости сразу двух I/O, круто.
А если надо многократно сканировать надо одни и теже фотографии, которые могут немного меняться, то индекс должен бы окупиться, если правильно прописать его обновление.
Да какая разница, окупится ли он, достаточно того, что все равно скорость работы будет ограничена скоростью I/O, а не вычислений.X_OSL Автор
15.07.2015 22:28>И мы будем ограничены в скорости сразу двух I/O, круто.
Я не вижу вашей задачи полностью. Но если I/O камеры заметно быстрее чем I/O диска, то при надлежащем сжатии(если мы его потянем по cpu) мы будет ограничены только I/O камеры, так как количество данных для записи на диск станет многократно меньше и его I/O с этим легко справится.
И это разумеется позволит работать быстрее чем с диском.
Но все это только в случае если I/O действительно быстрее I/O диска.
>Да какая разница, окупится ли он, достаточно того, что все равно скорость работы будет ограничена скоростью I/O, а не вычислений.
Да, разумеется, но в этой задаче, и вычислений то особых нет, тут в основном только I/O и выполняется…lair
15.07.2015 22:33Типичная задача «открой видеоредактор и смонтируй что-нибудь». Но, собственно, вы просили привести пример, когда I/O — ботлнек. Вот вам их несколько не напрягаясь.
И я сегодня весь день на них натыкаюсь.X_OSL Автор
15.07.2015 23:01Такие задачи тоже бывают конечно, в основном при обработке сырых данных.
Кстати, если вы не выжимаете предельную скорость из вашего HDD, то С++ думаю помог бы ее выжать. А если выжимаете и так, то тут либо другое железо поможет, либо читать можно какнибудь с уровнем детализации «через кадр» (в несжатом стриме наверное достаточно просто пропустить кадр или несколько и добрать их когда они будут очень нужны)lair
15.07.2015 23:03+1Кстати, если вы не выжимаете предельную скорость из вашего HDD, то С++ думаю помог бы ее выжать.
Вот это ваше «думаю» — оно на чем основано? Почему вы думаете, что другие языки на это не способны?X_OSL Автор
15.07.2015 23:28-3С++ будет работать через меньшее количество прослоек, как с 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.07.2015 23:38+1Вот только в C# есть такая милая штука, как прозрачное взаимодействие с IOCP, которая позволит мне активировать обработчики ровно в то время, когда новый чанк данных дочитался.
Но самый, конечно, интересный вопрос — это какую именно долю производительности при потоковом чтении я буду терять на всех упомянутых вами «обертках».X_OSL Автор
16.07.2015 00:01Собственно говоря в ReadFileEx есть OVERLAPPED чтение и lpCompletionRoutine
msdn.microsoft.com/ru-ru/library/windows/desktop/aa365468(v=vs.85).aspx
Что, как я понимаю, тоже позволит активировать ваш обработчик.
На счет доли производительности… Смотря как часто этот код выполняется, чем чаще, тем больше будет доля…lair
16.07.2015 00:10+2Собственно говоря в ReadFileEx есть OVERLAPPED чтение и lpCompletionRoutine
msdn.microsoft.com/ru-ru/library/windows/desktop/aa365468(v=vs.85).aspx
Что, как я понимаю, тоже позволит активировать ваш обработчик.
Ну, во-первых, нет, completion routine — это не IOCP (что, кстати, показывает, что вы с этим не работали). А во-вторых, каково количество прыжков и ужимок, которое мне на это понадобится, по сравнению с простым async/await-кодом в C#?
Смотря как часто этот код выполняется, чем чаще, тем больше будет доля…
А вот и нет. Если время выполнения обработчика чанка будет значительно меньше времени чтения следующего чанка с диска, то общее время обработки будет лишь слегка превышать общее время чтения (если быть точным, на время обработки одного чанка). Просто потому, что я буду обрабатывать предыдущий чанк во время чтения следующего.
Если, конечно, выполняемая операция — потоковая.X_OSL Автор
16.07.2015 00:22>Ну, во-первых, нет, completion routine — это не IOCP (что, кстати, показывает, что вы с этим не работали).
C IOCP я и правда не работал — необходимости в этом не было… видимо имеется ввиду это
msdn.microsoft.com/ru-ru/library/windows/desktop/aa363862(v=vs.85).aspx
>А во-вторых, каково количество прыжков и ужимок, которое мне на это понадобится, по сравнению с простым async/await-кодом в C#?
Это уж вопрос к тому насколько вам принципиально написать этот кусок (чуть?) быстрее. Безусловно прыжков и ужимок будет больше, но это будут ваши прыжки и ужимки, о которых вы точно будете знать что они делают, а не прыжки и ужимки дотнета.
>Если время выполнения обработчика чанка будет значительно меньше времени чтения следующего чанка с диска, то общее время обработки будет лишь слегка превышать общее время чтения
Я имел ввиду количество вызовов необходимых для инициализации чтения чанка.lair
16.07.2015 00:25Безусловно прыжков и ужимок будет больше, но это будут ваши прыжки и ужимки, о которых вы точно будете знать что они делают, а не прыжки и ужимки дотнета.
А это одного порядка вещи. Вы настолько же не знаете, что внутри себя делаетReadFile, насколько я — как именноReadAsyncделает свое волшебство.
Я имел ввиду количество вызовов необходимых для инициализации чтения чанка.
Мой аргумент остается — мне достаточно синхронизировать эти вызовы таким образом, чтобы диск читался линейно, а потери были пренебрежимыми на фоне собственно чтения.
Нет, ну правда, сколько процентов от времени чтения мегабайтного чанка будет занимать оверхед? А десятимегабайтного?X_OSL Автор
16.07.2015 19:59>А это одного порядка вещи. Вы настолько же не знаете, что внутри себя делает ReadFile, насколько я — как именно ReadAsync делает свое волшебство.
C одной лишь разницей,- я знаю что ReadAsync(и любое другое дотнетовское чтение файла) в конечном счете вызовет ReadFile
>Нет, ну правда, сколько процентов от времени чтения мегабайтного чанка будет занимать оверхед? А десятимегабайтного?
При больших чанках процент очень малый. И если в работе с памятью оверхеда не будет, то смысла в переходе на С++ конкретно для этой задачи мало.lair
16.07.2015 21:59C одной лишь разницей,- я знаю что ReadAsync(и любое другое дотнетовское чтение файла) в конечном счете вызовет ReadFile
Ну да… наверное. В той версии, в которой вы посмотрели. Вы не знаете (а) с какими параметрами (б) от чего они зависят (ц) что будет в следующей версии (д) что будет на соседней платформе. И самое главное — вы все равно не знаете, что внутриReadFile.
При больших чанках процент очень малый.
А малыми на таких задачах никто и не читает. Что, собственно, и показывает нам некоторое преувеличение важности C++.
gandjustas
16.07.2015 03:30+2ReadFileEx например можно вызывать и из 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.07.2015 09:28>А думаешь FileStream.Read делает что-то сильно другое?
Нет, не сильно, просто машинного кода в нем будет исполнено больше во время этого вызова
>Думаешь в STL обвязок меньше? Или ты под каждую платформу свои нативные методы вызываешь в кроссплатформенном языке?
В простом чтении из файла обвязок меньше. Еще меньше обвязок в вполне кросплатформенном fread.
Но конкретно IOCP в STL нет.
Возможно только в Boost.Asio будет что-то подобное.
Я думаю IOCP лучше прописать под каждую платформу, т.к. IOCP платформо-зависимая фича, которая в таком виде есть только в Windows, на других платформах есть схожие, но другие фичи.
Опять таки, реализация IOCP в Mono будет совсем другой и по всей видимости обернута еще большим количеством кода.
>Короче не думай что ты умнее людей, которые писали .NET, особенно BCL. Это не так с вероятностью 100%.
Я не спорю, конкретно BCL — действительно хорошо написан, но часто он решает более общую задачу чем требуется, что будет всегда немного отжирать дополнительного времени в рантайме.
gandjustas
15.07.2015 22:12+11. Сборщик мусора в С++ НЕ НУЖЕН! Точка.
Подсчет ссылок это тоже форма сборки мусора. Но очень низкий уровень языка C++ позволяет генерировать гораздо меньше мусора, чем managed языка.
Добавлю ещё к выводу: С++ и С# это разные языки с разными задачами. Их бесполезно сравнивать. Вот замените цвет текста у кнопки на С++ и С#. А после нажатия на эту кнопку, производится поиск обратной матрицы размером 100000*100000. И какой язык для этого лучше? ;)
Очевидно C, без плюсов ;)
DancingOnWater
13.07.2015 16:49-4как-то на тостере я сравнивал оба языка ( 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.07.2015 19:18+5Но на этом все.
Небесконечное время компиляции, отсутствие .h-файлов, несравнимая по человечности отладка и диагностика ошибок, LINQ в целом и применительно к БД и XML в частности, лямбды, итераторы, async/await, Unicode.maaGames
13.07.2015 21:15Будто в С++ нет лямбд, итераторов и юникода. Можно хоть по-русски, кроме здравого смысла никто слова против не скажет. async в новом стандарте подтягивают.
ostapbender
14.07.2015 00:55+1Про лямбды и итераторы сказал тут по соседству, а про Юникод даже не смешно. Думаю, было понятно, что Юникод должен поддерживаться не на уровне
ВыходнойПоток << "Меня зовут " << имя;
а таки на уровне поддержки его стандартной библиотекой и рантаймом. И вот тут все становится ожидаемо печальным.DancingOnWater
14.07.2015 10:40в STL: wstring, u16string, u32string — все есть, все прекрасно.
В Qt Qstring поддерживает из коробки. Что вам еще надо?ostapbender
14.07.2015 11:26+2в STL: wstring, u16string, u32string — все есть, все прекрасно.
Вы, наверное, издеваетесь:
typedef basic_string<char16_t> u16string
Что «прекрасного» есть в std::basic_string? Про Юникод она знает чуть меньше, чем ничего: ни Code Point'ов, ни графем, ни нормализации. Как «класс строка» она нежизнеспособна.DancingOnWater
14.07.2015 14:41Ну и в string BP C# этого нет, а то, что вы хотите есть в ICU, Boost.Locale или Qt
grossws
14.07.2015 17:25В utf16 же не бывает суррогатных пар, правда?
DancingOnWater
15.07.2015 08:46Отношение к суррогатным парам неоднозначное, вот Javascript их не поддерживает
grossws
15.07.2015 13:30Какое может быть неоднозначное? Если используется utf16 и нет поддержки суррогатов — то unicode в полной мере не поддерживается.
DancingOnWater
13.07.2015 21:43-10LINQ-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.07.2015 22:11+5var e = list.GetEnumerator() и тадам e.Current ==null, а чтобы получить первое значение нужно сказать e.MoveNext(). Кто мне сможет чем разработчики руководствовались?
Тем, что (а) итератор может быть пустым и (б) первое значение еще сто лет может быть никому не нужно.DancingOnWater
14.07.2015 09:43Если итератор пустой (сиречь ссылается на пустую коллекцию) то в C++ он равен end и проблем никаких. Получить итератор и не начать проход по коллекции — нарушение принципа объявление переменной там где это надо. но не раньше.
Поясню чуть шире: допустим мне по какой-то причине не подходит foreach и я вынужден использовать for,
Пишем такой код:
for (var iterator = list.GetEnumerator(); iterator.HasNext(); iterator.MoveNext()){
Обработка
}
На основе опыта, основанного на доступе по индексу я ожидаю, что если я попал в тело цикла, то для начало работы с элементом мне больше телодвижений делать не надо нарушается. Причины такой логической нестыковки не понятны.lair
14.07.2015 11:15+3Если итератор пустой (сиречь ссылается на пустую коллекцию) то в 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.07.2015 11:29>>Просто ваш опыт здесь не применим (а должен быть?).
Согласен, что да. может и не быть. Но это не упрощает написание кода, а только усложняет.
>> (а) у итератора нет HasNext
Посыпаю голове пеплом.
>>… кроме необходимости его на это проверить.
using(var iterator = list.GetIterator())
{
while(iterator.MoveNext())
{
//обработка
}
}
Да-да, но получается, что используете цикл с предусловием в любом случае, не всегда это идет коду на пользу. Ну и сама конструкция разрастается в монстра, если у меня коллекция из коллекций.
Иными словами, основной мой посыл: «работа с итераторами в C# проще, чем в C++» требует серьезных примеров.lair
14.07.2015 11:34+1Согласен, что да. может и не быть. Но это не упрощает написание кода, а только усложняет.
Это проблемы вашего опыта, а не 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.07.2015 12:04-1>>Вот вам один простой пример:
М-да, тостер не торт, увы…
>>Это проблемы вашего опыта, а не C#/.net.
И да и нет. Да — это проблема моего опыта, тут спора нет. Но это и проблема и C#, т.к. нарушение общего стиля увеличивает количество ошибок в коде новичков, а мы вроде как хотим это избежать.lair
14.07.2015 12:07+3И да и нет. Да — это проблема моего опыта, тут спора нет. Но это и проблема и C#, т.к. нарушение общего стиля увеличивает количество ошибок в коде новичков, а мы вроде как хотим это избежать.
Нет никакого «общего стиля». Есть конкретный стиль C#, в котором итераторы обрабатываются единообразно, и там у новичков проблем нет. А если кто переучивается с другого языка, то это его дело — не тащить в новый язык нерелевантный опыт из старого.DancingOnWater
14.07.2015 12:24-1В одном и том же языке схожие сущности должны обрабатываться схожим образом. Именно это понимаю под общим стилем. Индекс в цикле это такой же итератор.
Но ниже дали совсем схожий код. Так что и тут в целом серьезных вопросов нетlair
14.07.2015 12:26+3Индекс в цикле это такой же итератор.
Упс, нет. В этом ваша ошибка. Индекс в цикле — это не итератор (по крайней мере, в C#), это отдельная парадигма.DancingOnWater
14.07.2015 13:55А по-подробнее?
lair
14.07.2015 14:23+3Индекс — это произвольный доступ. Он (предположительно) имеет сложность O(1), он повторяем, вы (обычно) можете как прочитать, так и записать элемент.
А перечислитель (раз уж мы полезли в терминологические тонкости) — это последовательный доступ, с непредсказуемой сложностью, и (в конкретном .net) — без возможности записи, т.е., вам выдали элемент из последовательности, и повлиять на саму последовательность вы не можете никак.
ostapbender
14.07.2015 00:50+3А, например, OData? Тот же LINQ, но поверх HTTP.
.h-файл — атавизм, который адепты C/C++ пытаются всячески оправдывать; пользы от них — ни на грош. а мороки — уйма: те же разъезжающиеся сигнатуры, нарушение DRY и вообще масса способов отстрелить разные куски комиссарского тела. (И позвольте, к слову, заметить, что класс «в тысячи строк кода» — явный антипаттерн; но да что уж). Так вот все современные IDE для современных статически типизированных языков умеют замечательно показывать публичный контракт класса вместе с документацией.
Про итератор сказали уже, но вообще странно слышать претензии к простым и понятным .NET'ным итераторам от C++-разработчика с зоопарком begin(), end(), iterator, reverse_iterator и т.д. И вообще — Iterators Must Go.
Лямбды с Dangling Reference'ами прэлэстны, право слово.
Ну и сравнивать библиотечную подпорку для асинхронного программирования в C++ со встроенной в C# поддержкой оного — несколько за граньюDancingOnWater
14.07.2015 10: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.07.2015 10:57+1Код вызова:
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.07.2015 11:34>>Вот оно и видно, что не пробовали. Так на TPL писать противопоказано. Вот правильный вариант:
Благодарю, добавил в избранное. Действительно проще.
>> Вот только задачи (Task) в TPL — это не обертка над потоками, а абстракция уровнем выше, поэтому ваше рассуждение тут немного не применимо.
Ну так и future это тоже абстракция уровнем выше.lair
14.07.2015 11:38+1Ну так и future это тоже абстракция уровнем выше.
По факту, future (скажем, в Scala) и task в TPL — это одно и то же.DancingOnWater
14.07.2015 11: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.07.2015 12:02+3Вы не понимаете.
awaitв C# — это не синтаксический сахар кtask.Result(который, в свою очередь, ведет себя так же, какQFuture::result()). Ваш макрос приведет к тому, что поток, в котором идет выполнение, будет заблокирован до получения результата из future. Аawaitвыпихивает весь остаток метода в continuation, причем аккуратно захватывая используемые объекты и следя за жизненным циклом.
(в этом, собственно, различия между реализацией во внешней библиотеке и поддержкой на уровне языка)DancingOnWater
14.07.2015 12:10Понял. Согласен, это очень удобно. Для плюсов аналог еще надо придумать.
DancingOnWater
15.07.2015 09:03Утро вечера мудренее. На Qt это проблема решается, с единственным условием — после выполнения вызова кода поток попадает в цикл событий. Думаю, что для C# это тоже должно быть справедливо. Итоговый синтаксис будет выглядеть как-то так:
TextBox.Text << await (WebClient().DownloadStringTaskAsync(«microsoft.com»));
Есесно await определен существенно иначе, чем я делал до этогоlair
15.07.2015 11:33Здесь есть ровно один важный вопрос: что происходит с потоком, в котором мы находимся до вызова этой строчки?
DancingOnWater
15.07.2015 11:39Вопроса не понял, что может происходить с потоком до того как вы сделали вызов?
lair
15.07.2015 11:41+1Я имею в виду: вот у нас шел вызов метода до написанной вами строчки, он был в каком-то потоке. Вы вызвали ваш
await— что стало с потоком?DancingOnWater
15.07.2015 11:44Так это все-таки после. А ничего не происходит, поток не блокируется и продолжает исполняться, но в конце-концов должен попасть в цикл событий
lair
15.07.2015 11:47А что в нем исполняется?
DancingOnWater
15.07.2015 12:07в нем это где? в потоке или цикле событий?
lair
15.07.2015 12:09Для начала — в потоке.
DancingOnWater
15.07.2015 12:31Поток есть поток, как он дошел до вы зова не важно. Поток вызывает метод асинхронно и продолжает любую свою работу. По завершению асинхронной задачи он выстрелит сигналом в исходный поток. Этот сигнал попадет в очередь событий потока исходного.
Чтоб извлечь его надо попасть в цикл событий. Цикл событий это стандартный для Qt QEventLoop: бесконечный цикл с очередью событий, который он потокобезопасно извлекает.
Возможно, данный пример не совсем корректен, т.к. я представлял не проперти, а поле, т.е. переменную, у которой можно получить указатель.
Чтоб получить указатель на функцию, похоже, придется чуток повозиться, вытанцовывая вокруг std::function и, возможно, синтаксический сахар станет чуть горше. Но это надо обдумать.lair
15.07.2015 12:35Поток вызывает метод асинхронно и продолжает любую свою работу.
Что значит «поток вызывает метод»? Нет такой операции, поток может либо выполнять какой-то код, либо не выполнять его (сидеть в пуле).
Нет, я серьезно вас не понимаю.
void someFunc() { //some code //мы в потоке 1 TextBox.Text << await (WebClient().DownloadStringTaskAsync("http://microsoft.com")); //что стало с потоком 1? какой конкретно код он выполняет? куда делся код, находящийся ниже по функции? //some code }DancingOnWater
15.07.2015 13:10Мы выполняем операцию асинхронно, т.е. мы входим в тело макроса await, делает ряд подготовительных приседаний, а после вызова QtConcurrent:run мы выходим из макроса; дальше исполняется код ниже по тексту
lair
15.07.2015 13:20Код «ниже по тексту» выполняется после завершения await или до него? Если после, то за счет чего останавливается выполнение кода между «до» и «после»?
DancingOnWater
15.07.2015 13:34WebClient().DownloadStringTaskAsync(«microsoft.com») выполняется в отдельном потоке. он не ждет родительский от слова вообше, Он может быть выполнен как «до» захода родительского в somecode, так и «после». Значение TextBox.Text будет инициализировано только после того, как попадет в eventloop, а попасть он может черт знает где: как в самом somecode, так и после него.
lair
15.07.2015 13:37Code1(); TextBox.Text << await (WebClient().DownloadStringTaskAsync("http://microsoft.com")); Code2();
В какой момент будет выполнено обращение к сайту по отношению кCode1иCode2? Из ваших слов у меня создается ощущение, что послеCode1, но в произвольный момент по отношению кCode2(т.е., в том числе и после выполненияCode2). Я правильно вас понял, или как-то иначе это устроено?DancingOnWater
15.07.2015 14:02+1Ну да, асинхронный вызов предполагает же, что основная работа идет в другом потоке со всеми вытекающими. Или я не прав?
lair
15.07.2015 14:11+1Вы просто не понимаете, как работает 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.07.2015 14:28+1Более того, при вызове await еще и не создаются потоки, если все правильно написано: habrahabr.ru/post/216659
lair
15.07.2015 14:33Там «все сложно». В зависимости от того, что у вас реально в операции, потоки могут создаваться, а могут не создаваться. Если у вас IO-bound, то скорее всего, потока — как и описанно по вашей ссылке — не будет. Но это не единственный сценарий.
Собственно, Стивен Клири именно поэтому предлагает разделять собственно асинхронность и параллелизм, и подчеркивает, что async/await в первую очередь направлен на асинхронность, но позволяет работать и с параллелизмом, что порождает кучу путаницы.
DancingOnWater
15.07.2015 14:42-1>>Вы просто не понимаете, как работает async/await в C#.
Я это честно признал, т.к. не щупал. А сейчас пытаюсь понять по вашему описанию
>>а полностью останавливается, не занимая потока
Эм… поток это набор инструкций, они либо выполняются либо нет и третьего не дано. Соответственно поток либо выполняется, либо блокирован.
Но спасибо, ваш пример и пример из msdn прояснил ситуацию. Это уже сложнее, чем я думал, но если я снова придумаю ответ чамберлену, то это уже будет отдельная статья. Т.к. тут придется сидеть — думать.
p.S. Создание тысячи потоков и быстро можно только из пула потоков, тут все понятно.
Razaz
15.07.2015 14:44Поток возвращается в пул. А работа которую он выполнял — останавливается. При получения события о завершении асинхронной операции — этот или другой поток могут продолжить выполнять работу.
lair
15.07.2015 14:46Эм… поток это набор инструкций, они либо выполняются либо нет и третьего не дано. Соответственно поток либо выполняется, либо блокирован.
Либо в нем нет ни одной инструкции, и он тихо лежит в idle. Вот именно это и делаетawaitв C# — он выходит из метода в этой точке, возвращая управление системе, и вешает «остаток» метода (в виде continuation) на «когда-нибудь потом».
Это уже сложнее, чем я думал, но если я снова придумаю ответ чамберлену, то это уже будет отдельная статья. Т.к. тут придется сидеть — думать.
Я искренне думаю, что без переписывания кода вам это не удастся. Компилятор C# генерит там большую и красивую стейт-машину с кучей деталей.DancingOnWater
15.07.2015 15:03>>и вешает «остаток» метода (в виде continuation) на «когда-нибудь потом».
Т.е. код показанный вами выполняется после завершения await… но при этом, поток уходит в пул.
>>Я искренне думаю, что без переписывания кода вам это не удастся. Компилятор C# генерит там большую и красивую стейт-машину с кучей деталей
ну как варианты:
1) мы свершаем прыжок в конец функции, при это сохраняем состоянии стека и указатель на текущую инструкцию… Громоздко и сложно.
2) Проще блокировать поток, если за время блокировки пул потоков переполнится, то выводя такой поток из пула, а на его месте создаем новый, по окончании метода этот же поток убивается.lair
15.07.2015 15:05Т.е. код показанный вами выполняется после завершения await… но при этом, поток уходит в пул.
Приблизительно так. Если шедулер считает, что задача быстрая, то она может быть выполнена синхронно.
мы свершаем прыжок в конец функции, при это сохраняем состоянии стека и указатель на текущую инструкцию… Громоздко и сложно.
Вот поэтому и не получится без рерайтинга.
Проще блокировать поток, если за время блокировки пул потоков переполнится, то выводя такой поток из пула, а на его месте создаем новый, по окончании метода этот же поток убивается.
Потоки стоят ресурсов (и немалых), поэтому вы быстро упретесь в ограничения.
Razaz
15.07.2015 15:40+1Проще блокировать поток, если за время блокировки пул потоков переполнится, то выводя такой поток из пула, а на его месте создаем новый, по окончании метода этот же поток убивается.
100к запросов к серверу в секунду с I\O? Что вы там будете блокировать?DancingOnWater
15.07.2015 15:47100к запросов в секунду, это значит у нас на обработку операции отведено не более 10^-5с, в таком темпе попытка вызвать поток из пула — уже дорогая операция.
Razaz
15.07.2015 16:05Да не. Вон новый asp.net 800к+ способен обработать до оптимизаций на 12 портах. Benchmarks. А теперь повторю вопрос — что вы собираетесь блокировать?
DancingOnWater
15.07.2015 16:16И вы считаете, что там такая ситуация:
Пришел запрос — вызывается поток из пула — обрабатывается запрос — возвращается поток в пул.
Вместо: пришел запрос — помещается в очередь на обработку — обрабатывается запрос- удаляется из очереди?Razaz
15.07.2015 16:27пришел запрос — вызывается поток — начинает обработку до первого await — возвращается в пул для обработки других запросов — континюэйшен после await вызывается в том же или другом потоке из пула и завершает обработку — возвращается в пул.
DancingOnWater
15.07.2015 20:39Если так, то получается, что мы дергаем пул 1.6 млн раз за секунду. Усатая сила, вместо того, чтоб чуток пораскинуть мозгами пользуем мощь компилятора.
Razaz
15.07.2015 22:31Что значит «дергаем»? Пораскиньте и запилите pull-request. При чем тут .Net или C++ тогда?
DancingOnWater
16.07.2015 10:36Прошу прощения за то, что не ясно выразил свою мысль.
10^-5 c — это фактически стоимость вызова потока из пула. Соответсвенно, если мы в потоке идущей с частотой в 100 кГц запрашиваем поток из пула, то ничего другого мы сделать уже не сумеем. И если у нас именно такие нагрузки на сервер. то логичнее было бы не останавливать и возвращать их в поток, а брать запрос из очереди.
>>При чем тут .Net или C++ тогда?
Холивар здесь не причем. Любой язык это набор инструментов со своими границами применимости. И конкретно здесь мне интересно знать для await\async и рядом связанных.
Этот механизм, как мне показали, удобен для асинхронных вызовов. Целевая ниша асинхронных вызовов: не частые внешние запросы, но с возможной(!) длительной обработкой.
Вся хитрость тех примеров, что привел привел уважаемый lair и ребята из msdn заключаемся в том, что этот код, который в плюсах нужно было бы запускать в другом потоке, можно записать в вызывающем.
Массу нюансов, который при этом механизм поглощает, конечно, впечатляет. НО это означает, что перед программистом гайка и у него вместо целого набора ключей один универсальный. Удобно, согласен, но на основе этого заявлять, что инструментарий не сравним — нельзя.Razaz
16.07.2015 11:52Вы поставите 100к запросов в секунду в очередь и начнете ее последовательно разбирать?
С чего вы взяли что асинхронность для не частых внешних вызовов? Хитрости в примерах нет. В зависимости от таск шэдулера выполнение будет проходить в том или другом потоке.
Этот механизм позволяет писать код, для достижения производительности, поддерживаемости и общего качества которого, потребуется значительно больше ресурсов, а выхлоп от этого будет минимален и в текущих реалиях совершенно не рационален.
lair
16.07.2015 11:54+2И конкретно здесь мне интересно знать для 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 однажды поняли, что для того, чтобы система была отзывчивой, нужно по максимуму избегать блокирующих операций — и решили сделать все, чтобы программисту (а) было удобно писать в неблокирующем стиле и (б) было сложно писать в блокирующем. Второе удалось хуже, чем первое, но мы только в начале пути.
Wyrd
15.07.2015 15:03>> Я это честно признал, т.к. не щупал. А сейчас пытаюсь понять по вашему описанию
Чтобы понять как это работает попробуйте пописать код через Task.ContinueWith, Microsoft.Async и т.п. в MSVS 2010.
Там нету ключевых слов async/await, что СИЛЬНО усложняет код, но позволяет понять что же все-таки за этими словами кроется (хотя бы приблизительно).lair
15.07.2015 15:06Да я, когда мне нужен контроль, и в свежей студии пишу с
ContinueWith, это так… доставляет.
А вообще, у Липперта есть хороший цикл статей про continuations (на которых все это построено).
ostapbender
14.07.2015 11:31var 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.07.2015 11:41Спасибо, добавил в избранное.
>>.Т.е. нарушение DRY (да, я ленив) при использовании .h-файлов — это нормально?
Давайте не будем молиться на эмперические правила. Если уж так, то partial классы в C#, которые генерируются Дизайнером на лету это тоже DRY.Основная цель DRY — избежать ошибок в рантайме. Разделение на объявление и определение к этому не способно привести.
>>Зачем сначала заставлять разносить объявление и определение, а потом подтыкать это подпорками в IDE?
Ну а не является ли подобной подпоркой контракт в IDE?
X_OSL Автор
13.07.2015 23:15-4Время компиляции компенсируется временем в рантайме. В среднем .net приложение примерно на столько дольше запускается насколько быстрее компилируется, относительно соизмеримого нативного приложения.
Отладка и диагностика ошибок, как и писал безусловно лучше в C#, но только пока вы не вышли за managed код.
Остальные фичи в С++ на тоже есть, только в виде библиотек. Например все перечисленное вами легко покрывает boost. Не хотите boost? Есть много других.ostapbender
14.07.2015 00:59+2Как вы лихо подменили время в рантайме временем запуска. И нет, прямой корреляции между «размером» приложения и временем запуска нет.
«Поддержка фич в виде библиотек» — это путь PHP. «У нас нет нормального синтаксиса создания массивов, но зато есть функция!». Так и в С++: «язык не поддерживает нормальную работу со строками, Юникод, итераторы и кучу всего еще, но зато у нас есть Boost!».X_OSL Автор
14.07.2015 10:06Вы правы, .net библиотеки не обязаны инициализироваться на старте приложения, и если так, то время старта .net приложения действительно может быть небольшим.
Время запуска будет соизмеримым, только если для инициализации нужно выполнить достаточно много .net кода на старте приложения, это важный момент и я его не отметил. Однако среди множества .net библиотек немало тех, которые так или иначе надо инициализировать на старте приложения.
И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
STL есть в базе, везде и никаких boost-ов для этого не нужно.ostapbender
14.07.2015 11:34И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
STL есть в базе, везде и никаких boost-ов для этого не нужно.
Напоминаю: мы сравниваем в первую очередь языки, а не библиотеки. Ну да ладно. Строки — ужасны, итераторы — покажите мне встроенный в язык foreach и yield.X_OSL Автор
14.07.2015 13:22Каким образом то, что строки и итераторы являются сущностями не языка, а библиотек делает их ужасными?
lair
14.07.2015 13:25+2Таким, что разные библиотеки могут реализовывать их по-разному, и итератор из одной не запихнешь в другую.
(проyieldуже все написали)X_OSL Автор
14.07.2015 13:39Это скорее вопрос к тому как написана конкретная библиотека.
В своем же проекте можно использовать те библиотеки и итераторы что устраивают вас.
Совсем не обязательно использовать свои строки если есть строки STL и уж точно плохая идея делать свои строки совсем не совместимыми со стандартными.
Я согласен с тем, что подключив произвольную библиотеку есть шансы на то, что там будут использоваться не стандартные строки и итераторы(об этом я писал в статье в соответствующем разделе), но это вопрос к тем, кто писал эти библиотеки и к истории, в своих же проектах вполне реально придерживаться стандартов.lair
14.07.2015 14:15В своем же проекте можно использовать те библиотеки и итераторы что устраивают вас.
Теперь мне надо сопрягать итераторы из одной библиотеки с теми, что устраивают меня из другой библиотеки. Заводно, правда?
Я согласен с тем, что подключив произвольную библиотеку есть шансы на то, что там будут использоваться не стандартные строки и итераторы(об этом я писал в статье в соответствующем разделе), но это вопрос к тем, кто писал эти библиотеки и к истории, в своих же проектах вполне реально придерживаться стандартов.
А что такое «стандартный итератор» в C++? Или стандартная строка с поддержкой Unicode? Или стандартная многопоточность?X_OSL Автор
14.07.2015 14:37Да, решено использовать несколько библиотек с разными базовыми типами — их сопряжение достаточно неприятная вещь, и как я писал это недостаток выбора С++.
Стандартные итераторы и строки это строки STL.
Для стандартной многопоточности, есть например en.cppreference.com/w/cpp/thread,
Вообще например тут:
en.cppreference.com/w/cpp
Описаны основные стандартные библиотеки и типы, единственное что для поддержки части из них нужна поддержка С++11 компилятором.lair
14.07.2015 15:03+1Вот вам и ответ, почему то, что строки и итераторы — не сущности языка, ужасно.
X_OSL Автор
14.07.2015 16:13-1Я бы все-таки не стал драматизировать и называть это ужасом:)
Конечно это неприятный момент, но формальный и вполне решаемый.
Если нужно — не так и сложно привести строку к подходящему типу, тем более, что делать это придется только работая со старыми библиотеками.lair
14.07.2015 16:56+1Да почти все в программировании «вполне решаемо», только зачем этим заниматься, когда можно решать конкретные прикладные задачи вместо борьбы с языком?
X_OSL Автор
14.07.2015 18:43Борьба всетаки не с языком, а с некоторыми библиотеками, далеко не все из которых обязательно использовать.
Зачем с ними бороться? Ради производительности, ради кроссплатформенности, ради независимости от фреймворка.
Конечно здесь и сейчас прикладную задачу быстрее решить на C#, и если не думать на перспективу, то это вполне разумный выбор в большинстве проектов которые нужно сдать и забыть.
Но если попробовать спрогнозировать развитие отрасли, то возможно ценность независимости от платформы и производительности окажется выше, чем быстрое решение прикладной задачи?lair
14.07.2015 18:53+2Борьба всетаки не с языком, а с некоторыми библиотеками, далеко не все из которых обязательно использовать.
А без них язык начинает проигрывать в легкодоступной функциональности.
Конечно здесь и сейчас прикладную задачу быстрее решить на C#, и если не думать на перспективу, то это вполне разумный выбор в большинстве проектов которые нужно сдать и забыть. Но если попробовать спрогнозировать развитие отрасли, то возможно ценность независимости от платформы и производительности окажется выше, чем быстрое решение прикладной задачи?
Это же типичная предварительная оптимизация — вы не знаете ни понадобится ли вам отвязываться от платформы, ни понадобится ли вам такая производительности, ни куда будет развиваться отрасль, но предлагаете здесь и сейчас пожертвовать реальной скоростью разработки, которая позволит выйти на рынок и/или оценить жизнеспособность продукта.X_OSL Автор
14.07.2015 19:55-1Это страховка. Я предлагаю минимизировать риск закрытия проекта из-за изменившейся ситуации на рынке.
Возможно данная стратегия мало полезна в проектах до года, но в проектах время развития которых 3-5 лет и более, думаю стратегия впролне оправдана.lair
14.07.2015 21:11А вы способны предсказать такое изменение рынка через 3-5 лет, при котором ваш нынешний проект закроется из-за того, что он на C#, хотя сейчас он со всем справляется?
Мне вот что-то ни одного примера в голову не приходит.X_OSL Автор
14.07.2015 21:37Я могу нарисовать массу апокалиптических сценариев, если угодно:
1. Сильная реорганизация, смена приоритетов в Микрософте и следующая за ней заморозка развития .net. (MFC они неоднократно замораживали, некоторые платформы хоронили заживо, нельзя исключать что .net-у тоже достанется)
2. Переход заказчика на что-то вроде Эльбруса (сценарий конечно фантастический, но может когото он и постигнет) Да и кто знает какие платформы появятся через 3-5 лет…
3. Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)
4. Желание заказчика перейти на «зеленые технологии» с потреблением 20w на рабочее место (а вдруг?)
Можно придумать и еще чтонибудь. Я бы дал примерно 30% на то что один из пунктов может случиться в течении 3-5 лет и нанести серъезный урон проекту.lair
14.07.2015 22:12+3Сильная реорганизация, смена приоритетов в Микрософте и следующая за ней заморозка развития .net.
Ну так mono же (да и вообще Open Source). А за время, за которое оно протухнет, можно успеть смигрировать куда угодно.
Переход заказчика на что-то вроде Эльбруса (сценарий конечно фантастический, но может когото он и постигнет) Да и кто знает какие платформы появятся через 3-5 лет…
А разработчику на C++ этот переход обойдется бесплатно? Не верю. Что уж говорить про неизвестные платформы.
Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)
Такие вещи видны не вдруг, и решаются заранее. И да, .net-приложения прекрасно масштабируются горизонтально.
Желание заказчика перейти на «зеленые технологии» с потреблением 20w на рабочее место (а вдруг?)
.net тут никак не мешает.
Я бы дал примерно 30% на то что один из пунктов может случиться в течении 3-5 лет и нанести серъезный урон проекту.
Я вот в .net что-то вроде 12-ти лет, и за все это время ни с одним проектом ничего подобного не произошло. Более того, я в разное время имел дело с несколькими проектами возрастом более 5 лет, и с ними тоже ничего такого не происходило даже приблизительно.X_OSL Автор
14.07.2015 23:06mono — лучше чем ничего, но честно говоря немного страшновато использовать его в уомерческих проектах. Может это излишняя параноя.
А разработчику на C++ этот переход обойдется бесплатно?
нет, но заметно дешеале.
.net-приложения прекрасно масштабируются горизонтально
Тут вопрос куда упремся и того насколько верно мы предсказали изменение объемов данных у заказчика.
.net тут никак не мешает.
Вы возможно не часто пользовались .net приложениями на какихнибудь Atom-ах…
Я вот в .net что-то вроде 12-ти лет, и за все это время ни с одним проектом ничего подобного не произошло.
У вас очень удачная статистика, у меня есть другая. Например года 3 назад в моей статистике прошла волна закрытий ASP.NET проектов, предназначенных для «внутреннего пользования» и некоторые библиотеки были переписаны с C# на С++ в целях повышения производительности и совместимости с iOS\MACOS.
И я пока не уверен, что все худшее для .net, в моей статистике, уже позади.lair
14.07.2015 23:47+3нет, но заметно дешеале
На основании чего вы делаете этот вывод? Вы лично делали такие миграции для обоих языков?
Тут вопрос куда упремся и того насколько верно мы предсказали изменение объемов данных у заказчика.
А это в любом случае произойдет, вне зависимости от платформы.
Вы возможно не часто пользовались .net приложениями на какихнибудь Atom-ах…
Зато я пользуюсь ими на телефоне.
Например года 3 назад в моей статистике прошла волна закрытий ASP.NET проектов, предназначенных для «внутреннего пользования» и некоторые библиотеки были переписаны с C# на С++ в целях повышения производительности и совместимости с iOS\MACOS.
В разных компаниях или в одной?
И я пока не уверен, что все худшее для .net, в моей статистике, уже позади.
Эта уверенность — как и моя — ни на чем не основана. Мы можем только смотреть на то, что делает MS, а делает он многое.X_OSL Автор
15.07.2015 09:20>На основании чего вы делаете этот вывод? Вы лично делали такие миграции для обоих языков?
Я видел начальный, конечный результат и потраченное на это время в том и другом случае.
>Зато я пользуюсь ими на телефоне.
У вас наверное WinPhone)
> В разных компаниях или в одной?
Закрытие ASP.NET проектов в двух разных, миграция C# на С++ в другой.
>Мы можем только смотреть на то, что делает MS, а делает он многое
Да, это безусловно важно. Мне кажется они будут пытаться увеличить прибыль, которая падает уже несколько кварталов подряд
www.microsoft.com/investor/EarningsAndFinancials/Earnings/PressReleaseAndWebcast/FY15/Q3/default.aspx
Это показывает, что-то неправильно в их стратегии развития, и они безусловно как-то попытаются это исправить, вопрос в том как именно…lair
15.07.2015 11:34У вас наверное WinPhone)
Да, у меня Windows Phone, и у меня нет ни одного нарекания на его производительность.
Закрытие ASP.NET проектов в двух разных
Чем это было обосновано?X_OSL Автор
15.07.2015 19:23>Чем это было обосновано?
В обоих случаях ASP.NET приложения были слишком ориентированы на исползование в Windows окружениии под IE.
И когда доля Windows и IE в целевом сегменте начала резко падать, оказалось не рентабельным делать эти приложения работающими на остальных браузерах, включая мобильные платформы.
То есть можно сказать что развитие мобильных платформ явилось причиной по которой данные приложения потеряли свою долю на рынке.lair
15.07.2015 20:46+1В обоих случаях ASP.NET приложения были слишком ориентированы на исползование в Windows окружениии под IE.
Ээээ, внезапно выясняется, что asp.net в частности и .net вообще тут ни при чем, потому что они вообще никак не влияют на то, в каком браузере используется результат. Более того, и три, и пять лет назад уже вовсю был asp.net mvc, в котором вообще полный контроль за получающимся HTML (и в нем же, кстати, есть серверная адаптация под браузер, включая мобильные платформы).
Так что конкретно эта судьба могла бы постигнуть любую (подчеркиваю, любую) серверную платформу. А конкретный C++, как вы же признались, для веба еще и не подходит…X_OSL Автор
15.07.2015 21:22> внезапно выясняется, что asp.net в частности и .net вообще тут ни при чем,
Не совсем, на сколько я понял, asp.net был одной из немногих технологий позволявших завязаться на IE на столько сильно. Хотя конечно, никто не заставлял использовать такие его «приемущества», но видимо из-за них asp.net и был выбран.
> Так что конкретно эта судьба могла бы постигнуть любую (подчеркиваю, любую) серверную платформу. А конкретный C++, как вы же признались, для веба еще и не подходит…
Я ни где и не рекомендовал использовать С++ для веба. Однако, если бы эти проекты были реализованы ввиде клиентов и сервера например на С++, а не в виде интернет приложений, то они имели бы намного больше шансов ожить на мобильных платформах в виде отдельных приложений.
Другое дело, что это абсолютно другая ветка развития и в крайне сослагательном наклонении.lair
15.07.2015 21:35+2Не совсем, на сколько я понял, asp.net был одной из немногих технологий позволявших завязаться на IE на столько сильно. Хотя конечно, никто не заставлял использовать такие его «приемущества», но видимо из-за них asp.net и был выбран.
Типичная ошибка архитектуры, не имеющая отношения к выбранной технологии.
Однако, если бы эти проекты были реализованы ввиде клиентов и сервера например на С++, а не в виде интернет приложений, то они имели бы намного больше шансов ожить на мобильных платформах в виде отдельных приложений.
Вы это серьезно? Адаптация веб-приложения под мобильник обычно сводится к другому html-коду, а приложения надо писать и ощутимо продумывать.
А чем, по-вашему, серверная часть на C++ отличается от веб-бекэнда на C++, что первое на нем писать можно, а второе — нет?
В общем и целом этот ваш пример вот никак не показывает ущербность C# с точки зрения перспектив (он вообще не был ограничивающим фактором в этом случае, ошибка была совершенно в другом).X_OSL Автор
16.07.2015 23:14>Типичная ошибка архитектуры, не имеющая отношения к выбранной технологии.
Скорее ошибка оценки перспектив рынка. Если бы мобильные платформы не развились, проекты вероятно жили бы и по сей день.
>А чем, по-вашему, серверная часть на C++ отличается от веб-бекэнда на C++, что первое на нем писать можно, а второе — нет?
Серверная часть С++ может быть написана со своим протоколом, это может сильно снизить трафик и упростить «парсинг» пакетов.
>В общем и целом этот ваш пример вот никак не показывает ущербность C# с точки зрения перспектив
Да, но пример и не был призван иллюстрировать ущербность C#. Пример показывает риски связанные с завязкой приложения на одну платформу.
Во втором из тех двух проектов, завязки на IE были не очень сильные и там даже успели адаптироваться под другние браузеры, но получилась ситуация в которой мобильные приложения стали удобнее, чем их веб решение поэтому рынок стал теряться и проект сворачиваться.lair
17.07.2015 00:46Скорее ошибка оценки перспектив рынка. Если бы мобильные платформы не развились, проекты вероятно жили бы и по сей день.
Это в любом случае ошибка архитектуры. Чтобы получить такое веб-приложение, которое нельзя легко адаптировать под другой браузер, нужно долго и последовательно совершать ошибки.
Серверная часть С++ может быть написана со своим протоколом, это может сильно снизить трафик и упростить «парсинг» пакетов.
Очередной велосипед? Чем вам существующих протоколов мало, вот уж нужды типовых приложений они покрывают с головой.
Пример показывает риски связанные с завязкой приложения на одну платформу.
То, что вы описываете — не технологическая проблема.
Во втором из тех двух проектов, завязки на IE были не очень сильные и там даже успели адаптироваться под другние браузеры, но получилась ситуация в которой мобильные приложения стали удобнее, чем их веб решение поэтому рынок стал теряться и проект сворачиваться.
И опять-таки, мобильное приложение к существующему сайту написать несложно, WebAPI из asp.net выставляется легко, все мобильные клиенты умеют есть REST API.X_OSL Автор
17.07.2015 09:24>Чтобы получить такое веб-приложение, которое нельзя легко адаптировать под другой браузер, нужно долго и последовательно совершать ошибки.
Да. Либо выбрать стратегию, которая из «кривой архитектуры» извлекает экономию в краткосрочном периоде.
>Очередной велосипед? Чем вам существующих протоколов мало, вот уж нужды типовых приложений они покрывают с головой.
Если подходящий протокол с его реализацией найдется — конечно стоит взять его.
> То, что вы описываете — не технологическая проблема.
И да и нет. Это проблема затачивания приложения под фичи, которые существуют только на одной платформе. Она может возникнуть конечно не только с ASP.NET, это проблема подхода. Просто ASP.NET тогда оказался самым дешевым способом
> И опять-таки, мобильное приложение к существующему сайту написать несложно, WebAPI из asp.net выставляется легко, все мобильные клиенты умеют есть REST API.
Вероятно когда спохватились, было уже недостаточно ресурсов для адаптации. Да и приложение похоже было слишком ориентировано на работу в локалке с большим трафиком и хорошим пингом к серверу, что не хорошо для мобильной версии.lair
17.07.2015 11:32Если подходящий протокол с его реализацией найдется — конечно стоит взять его
… а учитывая, что для веба все подходящие протоколы давно реализованы под все приличные языки, я что-то не вижу отличий для C++ в этом разрезе. Не сходится.
В общем, все это возвращает нас к началу дискуссии: при правильных архитектурных решениях C# сейчас является не более «опасным» с точки зрения будущего языком, чем C++.X_OSL Автор
17.07.2015 13:11>В общем, все это возвращает нас к началу дискуссии: при правильных архитектурных решениях C# сейчас является не более «опасным» с точки зрения будущего языком, чем C++.
Язык сам по себе не причем, но выбор С# часто тянет за собой выбор инфраструктуры и библиотек, которые «внезапно» оказываются существуют только под Windows. И это уже ведет к рискам.
Например: я собираюсь писать на С#, но не хочу завазываться на Windows. На чем мне писать UI? Если я из-за красивостей и биндинга (выгодных моей разработке) выберу WPF, то путь на другие платформы у меня будет отрезан, с Winforms ситуация не на много лучше, только без красивостей и биндинга и с некой реализацией winapi на mono, в 100% идентичность оригиналу которой я не верю.
Gtk#? Как-то страшновато, да и функционал до WPF не додягивает, хорошо если покроет Winforms.
И кроме UI можно найти еще направления, где для С# есть инфраструктура под Windows, для которой нет аналогов на других платформах.
Но парадокс в том, что именно ради нее часто и выбирают C#, отрубая путь на другие платформы.
Например вы выбрали IOCP. Замечательная штука, но на других платформах ее нет в таком виде, и она будет реализована через другие механизмы(по сути будет эмулироваться) поэтому будет по-другому работать.
Для вашей задачи это «по-другому» возможно будет приемлемо, но когда таких «по-другому» накапливается критическая масса, то это может вызвать критические проблемы.
Вы можете сказать, что на С++ тоже можно завязаться на платформо-зависимую и все проблемы будут теже самые.
Да, это правда, но разница в том, что для С++ есть практики и рекомендации как писать «кросплатформенно», а для C# такие практики не пропагандируются (разве что не тянуть импорты из dll) потому что такого рода пропаганда не выгодна Microsoft. Выгода Microsoft в максимально глубоком и сильно связанном подсаживании на свою платформу.lair
17.07.2015 13:17И это уже ведет к рискам.
Риски надо осознавать.
Но парадокс в том, что именно ради нее часто и выбирают C#, отрубая путь на другие платформы.
Во-первых, а зачем не в UI многоплатформенность? Во-вторых, как раз не в UI .net ведет себя лучше (а теперь — еще лучше) на других платформах.
Например вы выбрали IOCP. Замечательная штука, но на других платформах ее нет в таком виде, и она будет реализована через другие механизмы(по сути будет эмулироваться) поэтому будет по-другому работать.
Вы не понимаете. Я не выбрал IOCP, я выбрал асинхронный I/O. На вин-платформе (причем не на каждой) это будет сделано через IOCP, а на других платформах — через другие механизмы. Не эмуляцию IOCP, а именно нативные механизмы нижележащей системы, дающие асинхронный I/O.
для C# такие практики не пропагандируются (разве что не тянуть импорты из dll) потому что такого рода пропаганда не выгодна Microsoft.
То-то MS официально объявила о выходе .net для других платформ, разбиении фреймворка и так далее. Наверное, чтобы усилить то, что им не выгодно.
Выгода Microsoft в максимально глубоком и сильно связанном подсаживании на свою платформу.
Вопрос в том, что считать платформой MS.X_OSL Автор
17.07.2015 13:59-1>как раз не в UI .net ведет себя лучше (а теперь — еще лучше) на других платформах.
Как же без UI на десктопе?
>Вы не понимаете. Я не выбрал IOCP, я выбрал асинхронный I/O.
То есть вы в целом были готовы к тому что работа асинхронного I/O может отличаться на разных платформах.
В конкретно вашем случае это отличие скорее всего вполне приемлемо, но врядли так будет во всех платформо-зависимых решениях…
>То-то MS официально объявила о выходе .net для других платформ, разбиении фреймворка и так далее.
Прошло 15 лет с появления .net и первого обещания MS о том что кросплатформенность будет и вот уже «MS официально объявила».
Объявление конечно это не может не радовать, но когда же уже он выйдет и какие библиотеки в нем будут? Почему именно сейчас?
> Вопрос в том, что считать платформой MS.
Думаю это в первую очередь то что приносит продажи MSlair
17.07.2015 16:02+1как раз не в UI .net ведет себя лучше (а теперь — еще лучше) на других платформах.
Как же без UI на десктопе?
Так я не про десктоп.
То есть вы в целом были готовы к тому что работа асинхронного I/O может отличаться на разных платформах.
Что значит «отличаться»? Наблюдаемое мной поведение отличаться не будет, а детали его реализации меня интересуют мало. В этом, вообще-то, весь смысл абстракции.
Объявление конечно это не может не радовать, но когда же уже он выйдет и какие библиотеки в нем будут? Почему именно сейчас?
Если честно, то мне все равно. Лично меня устраивает тот факт, что конкретно используемый мной сервис работает и на Windows, и на Linux, причем на втором чуть ли не лучше. При этом он (сервис) написан на .net (с небольшими вкраплениями JS).
nomit
18.07.2015 07:51Ну скажите пожалуйста где вы видели нормальный кроссплатформенный UI который поддерживает все фишки любой платформы? И не надо сейчас про QT с его QML, там тоже есть костыли и не все так идеально.
X_OSL Автор
18.07.2015 10:14>Ну скажите пожалуйста где вы видели нормальный кроссплатформенный UI который поддерживает все фишки любой платформы?
А мне не нужны ВСЕ фишки ЛЮБОЙ платформы. Мне нужно чтобы у UI было низкое время отклика и достаточное количество контролов в базе. Поддержка биндингов была бы плюсом, но жить можно и без нее (биндинги всеравно тянут MVVM, который хотя и приносит свои плюсы, но сильно раздувает код)
Для десктопа же очень много вариантов кросплатформенного UI.
Мобильный UI (и только UI) не вижу смысла делать кросплатформенным
lair
17.07.2015 13:24+1А, кстати, о кросс-платформенности.
If it isn't tested, it's broken.
Если вы не тестируете приложение регулярно на всех платформах — оно не кроссплатформенное. Вы готовы каждый раз, когда вы пишете UI, запускать его в двух-трех-пяти ОС?X_OSL Автор
17.07.2015 14:19-2Тестировать приложение надо перед релизом.
И да — конечно надо, на каждой платформе, если релиз на несколько платформ.
Однако это не значит что во время разработки вы должны каждое изменение проверять на всех платформах. Если писать более менее кросплатформенно, то этапа тестирования перед релизом должно бы хватить.lair
17.07.2015 16:03+3Тестировать приложение надо перед релизом.
С какой частотой у вас «релизы»?
Если писать более менее кросплатформенно,
А как определить, кроссплатформенно ли вы пишете?X_OSL Автор
17.07.2015 16:21>С какой частотой у вас «релизы»?
Зависит от проекта и продукта, как правило от 4 месяцев до года, иногда больше.
>А как определить, кроссплатформенно ли вы пишете?
Есть некоторые стандарты и правила. Если коротко, суть их в том, что на С++ вы должны использовать только библиотеки включенные в стандарт С++ и кросплатформенные библиотеки, а всякие API операционной системы не использовать.lair
17.07.2015 16:25+2Зависит от проекта и продукта, как правило от 4 месяцев до года, иногда больше.
Предположим, раз в год. А сколько у вас период тестирования «перед релизом»?
Если коротко, суть их в том, что на С++ вы должны использовать только библиотеки включенные в стандарт С++ и кросплатформенные библиотеки, а всякие API операционной системы не использовать.
Для GUI работает? Например, high-DPI в Windows и MacOS одинаково себя ведет?X_OSL Автор
17.07.2015 16:45>Предположим, раз в год. А сколько у вас период тестирования «перед релизом»?
Месяца 3-4.
>Для GUI работает? Например, high-DPI в Windows и MacOS одинаково себя ведет?
Например для Qt должно бы работать…
doc-snapshots.qt.io/qt5-5.4/highdpi.htmllair
17.07.2015 16:51+3Предположим, раз в год. А сколько у вас период тестирования «перед релизом»?
Месяца 3-4.
Угу. Восемь месяцев что-то писали, потом выяснили, что не работает под линуксом, на исправление нужно, скажем половина от этого — это четыре месяца. Когда будем тестировать то, что исправили?
(короткие итерации и CI не просто так придумали)
Например для Qt должно бы работать…
doc-snapshots.qt.io/qt5-5.4/highdpi.html
Вот то-то и оно, что «должно». А в реальности там танцы с бубнами.
(или, скажем, обнаружение removable drives — тоже совершенно по-разному себя ведет)
KvanTTT
14.07.2015 23:39+23. Возросшие, со времянем эксплуатации, объемы данных и вычислений при недостатчном росте производительности железа (наиболее вероятный сценарий в случае если за эти 3-5 лет количество данных сильно увеличивается)
Если в начале с проектом все было хорошо в плане производительности, то потом не важно будет, какая технология используется, потому что при увеличении данных важно продумывать архитектуру и сами алгоритмы (например, с помощью эвристик добиться субэкспоненциальной или даже полиномиальной сложности вместо экспоненциальной), а не низкоуровневые оптимизации, которые практически ничего не дадут.
Ну и за остальные «апокалиптические сценарии» я бы не дал и процента.X_OSL Автор
15.07.2015 09:27Мне кажется некорректно противопоставлять высокоуровневую оптимизации и низкоуровневую. Они не исключают друг друга, а дополняют.
vladon
15.07.2015 21:51Строго говоря, строк в языке C# тоже нет, это системная библиотека. Различайте язык и стандартную библиотеку и для C# тогда тоже.
qw1
16.07.2015 00:46Когда серия конкатенаций оператором + компилируется в один вызов Concat с соответствующим числом параметров, это уже поддержка на уровне языка, а не библиотека…
Garrett
13.07.2015 16:52С# с огромным опозданием, но делает шаги в кроссплатформенность. Когда прибудет? Пока сложно сказать
dordzhiev
13.07.2015 19:55+2Судя по их GitHub, все хорошо + еще под FreeBSD делают. Надеюсь скоро зарелизят.
X_OSL Автор
14.07.2015 19:36-1Я бы наверное поставил на то, что раньше в стандарт С++ добавят недостающие фичи.
Проблема «некросплатформенности С#» мне кажется не столько технической, сколько системной и отчасти даже политической.
Вот например, зачем Apple будет поддерживать .net framework?
Или зачем Google будет добавлять поддержку .net framework в Android?
Зачем разработчикам ядра линукс протаскивать оптимизацию под .net framework?
Отдельно стоит задаться вопросом почему Microsoft за 15 лет существования .net framework не выпустила не одной его официальной версии под другие платформы?
При этом С++ компилятор для всех этих платформ был всегда, он есть даже для какогонибудь Raspberry Pi и прочих встраиваемых решений, и скорее всего весьма оптимизированный.
nomit
13.07.2015 18:33+48. Риски
Вообще в корне не верно, какая завязка, на что? На язык? — ну так вроде по другому и не может быть. На платформу .net? — так она вроде всегда была бесплатна, сейчас даже исходники открывают(или открыли уже). Ну VS? ну вас не кто не заставляет ей пользоваться есть уйма других(тут про качество речи не идет). Какая еще завязка? Разве что на ОС есть завязка.X_OSL Автор
13.07.2015 22:37-3Вероятно вы невнимательно читали. Я же написал: Основной риск — завязка на Microsoft и его интересы.
X_OSL Автор
14.07.2015 01:05-1Может ли минусующий объяснить, почему он считает что комерческие интересы Микрософта никогда не станут риском для его разработки на C#?
(А относительно исходников .net — пока не увидел ничего кроме того, что и так показывает рефлектор, как думаю многим понятно, наиболее интересная и полезная для переносимостии окружения часть исходников связана с нативной его частью)
nomit
14.07.2015 05:56+2Вероятно так можно хоть чему добавить риск. Разработка на Java — риск попасть в зону интересов оракла. Используешь линукс — Торвальдс сидит и злобно улыбается — тоже риск? Используешь хоть что — разработчик сидит и думает как бы тебя нагреть. Вывод пишем все сами с нуля тогда у нас интересы будут только наши.
X_OSL Автор
14.07.2015 10:15Я не разбирал в статье разработку на Java, о чем отдельно написал. И вы абсолютно правы в том, что риски есть и от использования линукса и от многого другого.
Я скорее разбираю вопрос минимизации рисков. И если вы будете иметь возможность уйти на другую платформу — вы безусловно минимизируете риски связанные с «неправильным развитием» вашей платформы.nomit
14.07.2015 10:34Какая платформа имеет возможность(позволяет) уйти с себя на другую платформу? Таких чудес не бывает, это бесполезный пункт.
Приведите факты или пример, а так получается абстрактный конь сами знаете в чем.X_OSL Автор
14.07.2015 11:00Если вы пишите приложение на С++ _не_ завязываясь на платформо-зависимые функции (а это не так и сложно, поверьте) то вы получаете поддержку всех платформ под которые можно собрать ваше приложение. Например С++ библиотека может быть собрана из одного кода под Windows, Macos, Linux, Android, iOS, да хоть под ось и железо своей разработки, главное чтобы под них был компилятор С++.
.
Да, возможно в паре-тройке мест вам придется сделать что-то средствами специфичными для определенной платформы. И да, для полноценного приложения вам скорее всего придется на каждой платформе написать некоторый UI, родными для платформы средствами (хотя например можно написать кросплатформенный UI на Qt).
Но вы всегда сможете уйти на другую платформу при необходимости, и это не будет стоит катастрофично дорого.nomit
14.07.2015 13:26Не совсем понимаю, при чем тут язык? Вроде как весь вопрос стоял, что выбрать язык C++ или С#. А сейчас все сводится к компилятору. Ну так под различные оси есть mono. Я думал вы про «платформу» как о неком стэки технологий, а не ОС.
X_OSL Автор
14.07.2015 13:45Язык тянет за собой некую инфраструктуру в виде библиотек.
И если рассмотреть mono, то насколько я понимаю инфраструктура будет заметно менее полноценная, чем та что идет с .net под Windows. Далее вопрос сводится к тому, насколько вашему приложению нужна Windows-специфичная инфраструктура.
С С++-же такого перекоса в инфраструктуре между платформами нет.
qw1
14.07.2015 19:33Это если в ходе разработки не прекращать тестировать, оптимизировать и вылавливать грубли одновременно на всех платформах. Так, чтобы 5 лет сидели на Windows и писали «кроссплатформенно», и вдруг скомпилили под MacOS и всё работает как раньше — не бывает.
X_OSL Автор
14.07.2015 20:19Необязательно постоянно «не прекращать тестировать, оптимизировать и вылавливать грубли одновременно на всех платформах»,
При необходимости поддержки MacOS, если 5 лет сидели на Windows и писали «кроссплатформенно» вам придется потратить условно 3-6 месяцев на вылавливание платформо зависимых граблей. (этих граблей не более 10% от общего количества граблей, т.е. большинство багов вылезают на всех платформах)
Если же вы 5 лет присали под Windows не «кроссплатформенно», то вам придется переписывать огромное количество кода и тратить уже годы на поддержку MacOS (тут конечно многое зависит от того, как много специфичной Windows функциональности было притянуто за эти 5 лет)
gandjustas
14.07.2015 01:38+7Почему же нету сотен новых проектов на C++ и их дофига на managed языках?
Почему при всех хорошести C++ его не используют для всего? Не секрет, что большая часть разработки это веб, и для бекэнда массово используются только managed языки.
Почему на «кроссплатфомренном» C++ нельзя написать один код, который заработает на всех мобильных устройствах, а на C# таки можно (см Xamarin).
Если для C++ так много библиотек, то почему нету единого репозитария? В nuget из 39 тысяч пакетов только 419 находится по запросу «C++» и 10 000 по запросу ".NET". А как найти нужные библиотеки для С++ без nuget?
Почему такая сильная завязка на Microsoft, если компилятор и .NET есть в открытом доступе, а код на C++ под винду не соберешь без SDK, который ставится со студией?
Короче слишком много желаемого выдается за действительное.X_OSL Автор
14.07.2015 07:49-5C# популярнее потомучто его использовани экономический выгодно на ранних стадиях проекта, и да следствием этого является то, что на нем пишут больше относительно небольших проектов поэтому их много.
И, вообще говоря, для сборки C++ под Windows, совсем не обязательно ставить студию. Да и SDK скачиваются с сайта микрософта вполне свободно.gandjustas
14.07.2015 19:59+2То есть c# все таки больше подходит для большинства проектов. В чем смысл поста тогда?
X_OSL Автор
14.07.2015 20:45-2Смысл поста в том, чтобы избежать огульных суждений при выборе средств разработки.
Как вы определили это «большинство» проектов? Терминами «нету сотен новых проектов» и «дофига»?
Есть ли у вас статистика по их востребованности и окупаемости?
И да, возвращаясь к вашему предидущему посту.
На С++ можно писать код, который заработает на всех мобильных устройствах.
Для веб бэкэнда используется в основном php, но я кстати пробовал писать веб бэкэнд на С++, это вполне реально, но я бы наверное не стал рекомендовать его.
Насчет процента пакетов nuget для С++, может быть дело просто в том что nuget ориентирован на .net, а не на С++?lair
14.07.2015 21:14+2Для веб бэкэнда используется в основном php
Вы это серьезно? Вы на StackOverflow никогда не были?X_OSL Автор
14.07.2015 21:45-1Я исхожу из статистики
w3techs.com/technologies/overview/programming_language/all
w3techs.com/technologies/comparison/pl-aspnet,pl-phplair
14.07.2015 22:16+2Может не стоит, все-таки, приравнивать веб-бэкенды к веб-сайтам? А то под php-бэкендами внезапно окажутся сотни блогов, написанных на WordPress и Drupal.
И отдельно надо понимать, что эта статистика вообще не покрывает приложения «для внутреннего пользования».X_OSL Автор
14.07.2015 22:43-3Если мы говорим о применении php в интернете, то мне кажется статистика достаточно адекватна.
То что на одном движке собрана масса сайтов-клонов и то что есть сотни блогов, движки которых на php вряд-ли ее искажают.
Ведь никто не мешает писать сайты-клоны на ASP.NET, никто не мешает создавать хостинги блогов на ASP.NET, то что их мало — это врадли вина метода измерения.
Если говорить внутриенних сайтах, работающих в локальной сети организации, то да — эта статистика не адекватна для сайтов внутреннего пользования. Но где мы можем найти статистику по ним?lair
14.07.2015 23:45+2Ведь никто не мешает писать сайты-клоны на ASP.NET, никто не мешает создавать хостинги блогов на ASP.NET
Но зачем, если эта ниша уже занята PHP?X_OSL Автор
15.07.2015 09:43-3На самом деле вопрос скорее в том почему ниша оказалась занята 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.07.2015 11:16+1На самом деле вопрос скорее в том почему ниша оказалась занята PHP?
По историческим причинам. ASP.NET был еще в зародыше когда появились wordpress, drupal, joomla, phpBB и куча других движков. Нормальные средства для создания сайтов ASP.NET получил только в 2009 год, с выходом MVC3. Тогда и появились первые CMS на .NET.
Короче asp.net отстал от пыха примерно на 10 лет в этой области. Но даже при этом имеет огромную долю рынка.
ЗЫ. Снижение доли — больше делают сайтов (в основном лэндингов) на PHP, а не на asp.net. В количественном выражении asp.net не падает.
lair
15.07.2015 11:41+2На самом деле вопрос скорее в том почему ниша оказалась занята PHP?
Потому что он проще в изучении.
Первые версии ASP появились примерно в тоже время что и первые версии PHP, да и к моменту выхода ASP.NET, нишу еще нельзя было назвать занятой.
Не надо смешивать asp и asp.net, между ними общего только половина названия.
Поэтому как пользователь могу лишь сказать что сайты на PHP по какой-то причине работали достаточно быстро, а на ASP.NET — медленно…
Это какое-то ваше субъективное ощущение, подтверждения которому я не встречал ни в своем опыте, ни в объективных оценках.
Но на самом деле ваша фундаментальная ошибка в том, что вы смешиваете сайты и веб-приложения, хотя у них совершенно разный подход. asp.net по моему личному вкусу для сайтов подходит плохо. А веб-приложений в интернете, очевидно, существенно меньше.
gandjustas
14.07.2015 22:17+1Оо.
Эти графики говорят что несколько десятков миллионов сайтов работает на C#, а C++ попал в категорию менее 0.01%.
ЗЫ. Я думал сайтов на ASP.NET поменьше.
gandjustas
14.07.2015 22:14+2Смысл поста в том, чтобы избежать огульных суждений при выборе средств разработки.
В самом посте кроме огульных суждений ничего нет.
Как вы определили это «большинство» проектов?
По статистике на HH, github, monster.
На С++ можно писать код, который заработает на всех мобильных устройствах.
Ага, только код не будет ничего рисовать, обрабатывать ввод, поучать по сети и читать\писать в постоянную память. То есть бесполезный код. А на C# можно можно полноценное приложение сделать.
Для веб бэкэнда используется в основном php, но я кстати пробовал писать веб бэкэнд на С++, это вполне реально, но я бы наверное не стал рекомендовать его.
Для приложений в основном используются managed языки ;)
Если говорим про веб, то это не только публичные сайты (привет StackOwerflow), но и корпоративные приложения, а их на .NET чуть менее, чем дофига и в бесконечное число раз больше, чем подобных решений на C++.
почему бы не стал рекомендовать C++ для бекенда? Наверное потому что такой хороший язык, да?
Насчет процента пакетов nuget для С++, может быть дело просто в том что nuget ориентирован на .net, а не на С++?
Что значит «ориентирован»? там есть пакеты и для C++, только их мало.
vedenin1980
15.07.2015 10:16+51. Скорость разработки — неверно, чудес не бывает, 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.07.2015 11:34-4>очевидным является тот факт что сборщики мусора делают автоматическую оптимизацию (сборку копированием, уплотнение объектов в памяти), что повышает производительность,
Я чаще встречался с другим поведением сборщика мусора. Фундаментально сборщик мусора решает очень общую задачу, поэтому даже при идеальной реализации у него меньше шансов ее решить оптимально, чем у не-кривой ручной реализации, написанной под конкретную задачу. Менеджер памяти далеко не всегда может предсказать что захочет ваш код в следующий момент, а вы — можете.
>в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое вручную
Это печально, но думаю поправимо.
>сейчас производительность машинных кодов вообще дело десятое для 99% бизнес приложений: чтение с диска, чтение с сети, работа с БД, параллельное выполнение, dead lock'и, плохая архитектура — все куда более страшные причины
Многое из перечисленного следствие изначально непросчитанной архитектуры и выбора технологий, то есть эти проблемы не возникают внезапно… Сам по себе переход на unmanaged языки их конечно не решит, но и трудоемкость выправления таких приложений может быть соизмерима с их переписью.
>Вы правда верите что столько сил потрачено для разработку Java и С# когда был такой замечательный универсальный C++ просто так? Все не умели считать и думать?
Любые траты сил можно сравнить с инвестициями, а инвестиции, с рациональной точки зрения, привлекает ожидание роста. Пока на горизонте был рост производительности заниматься «ловлей блох» в с низкоуровневой оптимизацией не было смысла, это было бы просто убыточно потому что более производительное железо появлялось быстрее, чем писался оптимизированный код.
Для той рыночной ситуации такая стратегия была вполне разумна, по крайней мере для не очень больших проектов, но рыночная ситуация постоянно меняется.
Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)lair
15.07.2015 11:38+4поэтому даже при идеальной реализации у него меньше шансов ее решить оптимально, чем у не-кривой ручной реализации, написанной под конкретную задачу.
Вопрос в том, где вы возьмете программиста, способного написать не-кривую реализацию сборки мусора, причем на постоянной основе.
Многое из перечисленного следствие изначально непросчитанной архитектуры и выбора технологий, то есть эти проблемы не возникают внезапно…
Просто в некоторых технологиях шанс их возникновения меньше.
Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)
Ну вот StackOverflow уже семь лет, и он никуда не уходит.
vedenin1980
15.07.2015 12:02Кстати, не знаете ли вы проектов с ожидаемым временем развития 10-20 лет и более, написанных на Java? (или C#, было бы интересно посмотреть на них..)
Пожалуйста, один из продуктов над которым я когда-то работал — NetCracker, существует уже 20 лет с самого рождения Java, практически лидер BSS и OSS в телекоммуникационной области (большая тройка РФ его тоже использует). Размеры продукта наверное десятки миллионов строк кода, базы терабайты данных. Ближайшие лет 10-20 точно проживет. Ну или Apache Hadoop — лидер направления bigdata, широко использовался гуглом, написан на Java, как ни странно ставит собой цель максимально быстрой обработки гигантских объемов данных. На самом деле, их море.
vedenin1980
15.07.2015 12:18Я чаще встречался с другим поведением сборщика мусора.
Вы знаете все сборщики мусора во всех языках? В одной Java их несколько сотен, причем многие open source.
Фундаментально сборщик мусора решает очень общую задачу, поэтому даже при идеальной реализации у него меньше шансов ее решить оптимально, чем у не-кривой ручной реализации, написанной под конкретную задачу. Менеджер памяти далеко не всегда может предсказать что захочет ваш код в следующий момент, а вы — можете.
Проблема в том что это можно и сказать про компилятор С++, он же тоже решает общую задачу оптимизации и если писать на ассемблере будет быстрее.
Это печально, но думаю поправимо.
Проблема в том что сборщики мусора в Java и C# придумывали и отлаживали годами тысячи программистов. В теории написать лучше и быстрее в частном случае можно, но вопрос какими силами и какими ресурсами.
Многое из перечисленного следствие изначально непросчитанной архитектуры и выбора технологий, то есть эти проблемы не возникают внезапно… Сам по себе переход на unmanaged языки их конечно не решит, но и трудоемкость выправления таких приложений может быть соизмерима с их переписью.
То есть к проблемам архитектуры добавить проблемы unmanaged языков (я их описывал выше)? Минус к минусы дает плюс только в математике и то не всегда…
Для той рыночной ситуации такая стратегия была вполне разумна, по крайней мере для не очень больших проектов, но рыночная ситуация постоянно меняется.
Улыбнуло, большие проекты отлично живут на Java и C#.
Пока на горизонте был рост производительности заниматься «ловлей блох» в с низкоуровневой оптимизацией не было смысла, это было бы просто убыточно потому что более производительное железо появлялось быстрее, чем писался оптимизированный код.
Я правильно пока процессоры были слабые на их производительность можно было забивать, а как они стали быстрыми их производительность стало вдруг очень важна.
grossws
15.07.2015 13:42Apache Tomcat — с 1999 (15 лет), Jetty — с 1995 (20 лет). Всё ещё развиваются и останавливаться не собираются.
X_OSL Автор
15.07.2015 10:31-5> Ага, только код не будет ничего рисовать, обрабатывать ввод, поучать по сети и читать\писать в постоянную память. То есть бесполезный код. А на 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.07.2015 11:24+3Я не уверен, что приложение работающее с системой через кучу прослоек, и пытающееся использовать одинаковый 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.07.2015 11:45-6> Про кучу прослоек ты сам придумал.
Даже .net на Windows прослойка. И я с вами, на «ты» пока что не переходил, извольте это учитывать в ваших постах.
>пример кода на Qt, который без директив условной компиляции
Директивы условной компиляции в С++ используются даже в базовых заголовках. Примером кода можно привести массу, но примеров целостного приложения без директив условной компиляции вы не найдете.
>Вообще ссылаться на википедию в профессиональной дискуссии — все равно что считать надписи на заборе за доказательства теорем. Показывет ваш уровень.
Разве в википедии написана не правда?
Знаете, по степени агрессивности ваших высказываний мне кажется что вы тут на зарплате от Микрософта, и просто рекламируете его технологии, я прав?
Еще раз. Nuget не интегрирован ни с одной средой разработки С++ кроме тех, что распространяет микрософт. Это достаточно для того чтобы считать его не ориентированным на С#/gandjustas
15.07.2015 12:36+2Даже .net на Windows прослойка.
Что значит «прослойка»? .NET компилируется в машинный код и исполняется непосредственно процессором.
Xamarin код тоже компилируется в нативный, для WinPhone и Android JIT, а iOS — AOT.
Директивы условной компиляции в С++ используются даже в базовых заголовках. Примером кода можно привести массу, но примеров целостного приложения без директив условной компиляции вы не найдете.
Мне все равно что в заголовках. Главное чтобы твой код был единым, а не огромным #ifdef IOS…
Пример все еще жду.
Разве в википедии написана не правда?
На заборе написано «Вася — лох, Оля — шлюха», тоже вполне может быть правдой. Только цивилизованный человек не станет на это ссылаться.
Знаете, по степени агрессивности ваших высказываний мне кажется что вы тут на зарплате от Микрософта, и просто рекламируете его технологии, я прав?
Нет, МС мне не платит.
Еще раз. Nuget не интегрирован ни с одной средой разработки С++ кроме тех, что распространяет микрософт.
Еще раз: это не мешает использовать nuget где угодно.
Например npm (Node Package Manager) вообще не интегрирован со средами разработки (ну кроме новой VS), а его прекрасно используют везде.
Но ты зря прицепился к nuget. Вопрос то начался с кучи библиотек для C++. Можешь показать ссылку где эту кучу можно увидеть?
X_OSL Автор
15.07.2015 13:03-4>.NET компилируется в машинный код и исполняется непосредственно процессором.
Это только пока вашему коду ничего не нужно от системы. Когда что-то требуется .net код идет к системе через прослойки.
>Еще раз: это не мешает использовать nuget где угодно.
Вы правда в верите в то, что отсутствие интеграции не влияет на вероятность использования nuget?
(мы же говорили не о том, что его нельзя использовать, а о том насколько он репрезентативен как источник для количества С++ библиотек)
>Можешь показать ссылку где эту кучу можно увидеть?
Эта «куча» не собрана в одном месте. Правда. Есть много платных и бесплатных библиотек, но нету репозитория где бы они все были. Это конечно недостаток инфраструктуры, но не значит что библиотек нет.
Их просто сложнее искать т.к. они не собраны в одну кучу.vedenin1980
15.07.2015 13:39+4Это только пока вашему коду ничего не нужно от системы. Когда что-то требуется .net код идет к системе через прослойки.
Вы не поняли, в нативный код компилируется вообще все, вся платформа Net/Java. Нет, конечно C# или Java код пойдет к системе через прослойки называемые Windows API чтобы создать UI, а что у С++ есть какой-то черный вход для этого?X_OSL Автор
15.07.2015 14:41>у С++ есть какой-то черный вход для этого?
Для С++ вызов того же winapi не отличается от родного вызова, то есть может быть написан без конверсий вообще, вот собственно и весь черный ход)
vedenin1980
15.07.2015 14:58да, для нативного кода тоже самое, тут вопрос чей компилятор лучше оптимизирует. Вообще не понимаю я ваши заморочки с производительностью десктопных приложений: если на Java или C# возникнет узкое место именно в скорости кода, кто мешает взят/написать нативную библиотеку и тупо её подключить? Причем память библотеки можно изолировать, оптимизировать именно саму библиотеку и т.п… Зачем ставить телегу впереди лошади и заниматься предварительной оптимизацией?
gandjustas
15.07.2015 14:36+3Если рассматривать Xamarin, то:
В iOS идет напрямую (внезапно!)
В Windows Phone тоже напрямую (C# компилируется в вызовы функций WinRT)
В Android код обращается к java-либам, так же как любое приложение на android.
Вы правда в верите в то, что отсутствие интеграции не влияет на вероятность использования nuget?
Конечно, влияет только наличие пакетов. Для .NET дофига пакетов в nuget, он и используется. Для C++ нету пакетов, их вообще нету ни в одном пакетном менеджере. Наверное потому что пакетов\библиотек так много ;)
Эта «куча» не собрана в одном месте.
Тогда откуда уверенность что это вообще куча, а не кучка?X_OSL Автор
15.07.2015 14:52-3>В iOS идет напрямую (внезапно!)
Прямо без конверсий типы .net ложатся на типы iOS?
>В Android код обращается к java-либам, так же как любое приложение на android.
На самом деле модули Android NDK могут делать вызовы напрямую, без Java
>Тогда откуда уверенность что это вообще куча, а не кучка?
Скажем так. Практический под любую _общую_ задачу (например задачу уровня реализованных в .net) мне удавалось найти библиотеку на С++ с помощью google :)
Конечно я не все задачи пробовал, но если вы найдете общую задачу для которой нет библиотек на С++, но есть на С# было бы о ней очень интересно узнать.gandjustas
15.07.2015 15:27Прямо без конверсий типы .net ложатся на типы iOS?
Вся конверсия выполняется при компиляции
На самом деле модули Android NDK могут делать вызовы напрямую, без Java
Тока почему-то все пишут на жабе.
Практический под любую _общую_ задачу (например задачу уровня реализованных в .net) мне удавалось найти библиотеку на С++ с помощью google :)
Давай проверим.
Нужно три вещи:
1) Библиотека, которая позволит писать один и тот же код для UI и сетевых вызовов на мобильном устройстве.
2) Библиотека, которая позволит сделать сервер, принимающий такие запросы, и обрабатывающий их асинхронно (не блокируя потоки в ожидании).
3) Библиотека, которая позволит работать с данными в базе типизированно, чтобы не приходилось клеить строки руками и тоже асинхронно, чтобы поток не висел в ожидании, пока выполняется вызов.DancingOnWater
15.07.2015 15:52-2Qt
Razaz
15.07.2015 16:06+1QT на сервере для асинхронной обработки?
DancingOnWater
15.07.2015 16:25-1Вас это смущает?
gandjustas
15.07.2015 16:27Наверное всем хочется увидеть пример.
Заодно пример Qt под WindowsPhoneDancingOnWater
15.07.2015 21:43>> Заодно пример Qt под WindowsPhone
С версии 5.3.
И да, я сосвсем забыл: а есть ли C# для QNX\Blackberry?
X_OSL Автор
15.07.2015 16:09-2>Вся конверсия выполняется при компиляции
Ведь неправда же. Это невозможно реализовать, ведь на этапе компиляции еще нет данных для конверсии, они появляются только в рантайме. Вы же не с константными параметрами вызовы делаете.
>Тока почему-то все пишут на жабе.
Кому нужно по-быстрому написать, а производительность приложения не критична — пишут. Их большинство возможно, но никак уж не «все».
По библиотекам насчет Qt поддерживаю — решает все эти задачи.
По второму пункту еще могу предложить Boost.Asio.
А типизированный доступ к базам данных есть даже в древнейшем odbc (хотя конкретно для него пул для асинхронного запуска придется написать руками :( )lair
15.07.2015 16:14gandjustas под «типизированным доступом» имеет в виду ORM, и его в ODBC нет (хотя для Qt, в принципе, есть).
X_OSL Автор
15.07.2015 16:53А в качестве ORM без QT — можно например использовать ODB или, как легкое решение, — SOCI
gandjustas
15.07.2015 16:26+1Ведь неправда же. Это невозможно реализовать, ведь на этапе компиляции еще нет данных для конверсии, они появляются только в рантайме. Вы же не с константными параметрами вызовы делаете.
Почему нет данных?
Теоретически ты глядя на код на языке X можешь написать аналогичный на языке Y. А вот Xamarin делает это практически, конвертируя .NET в код для iOS.
Кому нужно по-быстрому написать, а производительность приложения не критична — пишут.
Ты правда думаешь, что если переписать android приложение на C++, то оно будет быстрее работать? Ты вообще в курсе, что главный показатель скорости работы приложения для пользователя — отзывчивость. И ты уж точно в курсе, что нет в C++ средств делать асинхронный код, который не заставляет пользователя ждать пока программа получит данные с сервера. То есть переписав тупо все на C++ ты получишь более медленное приложение с точки зрения пользователя.
Больших расчетов все равно не будет в этом приложении, их нет смысла делать на устройстве.
Их большинство возможно, но никак уж не «все».
Все это больше 95%, у оставшихся 5% обычно задачи сильно специфические, что нет смысла рассматривать.X_OSL Автор
15.07.2015 16:47-4>Теоретически ты глядя на код на языке X можешь написать аналогичный на языке Y. А вот Xamarin делает это практически, конвертируя .NET в код для iOS.
Если конвертировать до компиляции, то да, это реально, но я бы не стал называть .net приложением, то что получится в результате этой конвертации. И я не уверен что конверсия кода до компиляции это очень эффективный подход…
>если переписать android приложение на C++, то оно будет быстрее работать?
Если в приложении есть участки критичные к производительности то их перепись на С++ ускорит приложение.
>нет в C++ средств делать асинхронный код
Это ложь. В С++ можно создавать потоки и запускать в них асинхронно все что вам нужно.gandjustas
15.07.2015 16:57+1Если конвертировать до компиляции, то да, это реально, но я бы не стал называть .net приложением, то что получится в результате этой конвертации.
Какая разница как ты стал бы называть. По факту единый код пишется на C# для всех платформ.
А .NET Native, который вообще превращает код приложения в C++ и конвертирует в нем ты как стал бы называть? По сути ведь вся разработка ведется на C# и пользователь может и не знать что там под капотом.
Если в приложении есть участки критичные к производительности то их перепись на С++ ускорит приложение.
Такой участок один — человек. Надо не заставлять его ждать, делая приложение отзывчивым в любых условиях. Ты хоть представляешь как сделать так, чтобы приложение на C++ не тупило пока получает данные по сети. Причем кроссплатформенно?
Это ложь. В С++ можно создавать потоки и запускать в них асинхронно все что вам нужно.
Только это не асинхронный код ;)X_OSL Автор
15.07.2015 17:15+1Хорошо, перейду на ты, если тебе так проще
>Ты хоть представляешь как сделать так, чтобы приложение на C++ не тупило пока получает данные по сети. Причем кроссплатформенно?
Элементарно. Используй потоки они кросплатформенны (#include )
>Только это не асинхронный код ;)
Чем же он не асинхронный? И какой-же он тогда? синхронный?qw1
15.07.2015 18:08Настоящий асинхронный код на Си это классический select в BSD Sockets или появившийся позже epoll. Такая же забавная штука, как писать в стиле ООП на языках, его не поддерживающих, руками вызывая «виртуальные» функции через таблицу методов.
lair
15.07.2015 11:31+2Очень мало веб фреймворков для С++,
Так почему их мало-то?X_OSL Автор
15.07.2015 11:53Писать для web на С++ всегда было дороже чем на любом другом языке, думаю это главная причина.
lair
15.07.2015 11:54(ну, не на любом, это вы преувеличиваете)
Но почему дороже, если у него так много достоинств? И почему тогда в других областях на нем писать не дороже?X_OSL Автор
15.07.2015 12:09Я не писал что на С++ в других областях писать «не дороже».
Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.
И кстати, С++ — используется для веба например на ebay.com, посмотрите код его страниц, они достаточно часто обращается к некой eBayISAPI.dll :) Но я не уверен что это хороший пример того как надо делать.lair
15.07.2015 12:11+1Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.
Я же спросил: почему дороже-то? Что такого в вебе, что C++ не справляется, и что не критично в других областях?
И кстати, С++ — используется для веба например на ebay.com, посмотрите код его страниц, они достаточно часто обращается к некой eBayISAPI.dll
Ну во-первых, исапи не обязательно писать на C++. Во вторых, там вообще не факт, что есть живая ISAPI, а не редирект.
lair
15.07.2015 12:32+1Кстати, простое гугление показывает что фронт-енд eBay работает на java (под томкатом), так что на самом деле никакого исапи (и никакой DLL) там нет, разве что они зачем-то хостят томкат в IIS (извращенцы).
gandjustas
15.07.2015 12:40Так делали раньше, чтобы статику с IIS отдавать, а isapi проксировал запросы к томкату. Тоже самое я видел в старой версии LiveLink (OpenText).
lair
15.07.2015 12:42+1Но сейчас там точно не так, статику они отдают с других серверов по большей части. Мне, если честно, кажется, что там реально адрес «потому что так сложилось». Внутри в любом случае томкат.
X_OSL Автор
15.07.2015 12:47-2> Что такого в вебе, что C++ не справляется, и что не критично в других областях?
Мне кажется в первую очередь это нетерпимость к кривому коду. На C++ вполне можно завалить сервер кривым кодом, а это очень большой риск для веб сервера.
Managed-же языки, как правило, не в состоянии завалить сервер, вероятно это одна из основных причин, почему они предпочтительнее.
>Во вторых, там вообще не факт, что есть живая ISAPI, а не редирект.
Возможно ее там уже и нет, к сожалению узнать это точно можно лишь покопавшись на самом сервере.lair
15.07.2015 12:54+1Мне кажется в первую очередь это нетерпимость к кривому коду. На C++ вполне можно завалить сервер кривым кодом, а это очень большой риск для веб сервера.
Это же должно бы быть верно для операционных систем, которые тем не менее на неуправляемых языках регулярно пишут. И для СУБД (аналогично). И, наконец, для прикладных серверов. И даже для мобильных устройств (вообще, краш телефона из-за ошибки приложения — очень печальное дело). Неужели в C++ до сих пор не научились адекватно делать изоляцию? (вообще странно, судя по операционным системам — научились)
Managed-же языки, как правило, не в состоянии завалить сервер, вероятно это одна из основных причин, почему они предпочтительнее.
Так это, опять-таки, верно для любого устройства, не только веб-сервера. Не понятно, в чем исключительность.X_OSL Автор
15.07.2015 13:37Изоляция ОС от прикладных приложений конечно есть, но вот изоляция внутри прикладного приложения уже отсутсвует, а веб сервер это прикладное приложение, пусть даже и сервис. И завалить его из кода выполняемого на сервере можно. (хотя думаю что при должном старании можно завалить и iis из asp.net кода, но вероятность написания такого кода для стандартных задач невысока)
С другой стороны можно просто перезапустить сервер чтобы обойти проблему… возможно она не такая страшная.
Возможно еще роль в распространении PHP (и других managed сред) для Web сыграло отсутствие для С++ библиотек, которые позволяют быстро решать задачи web разработки,
на момент роста Web-а. То есть 15 лет назад, задачи парсинга, работы с XML и регулярными выражениями на С++ решались существенно дороже, особенно если говорить о кросплатформенном решении, а не использовании
За 15 лет конечно библиотек решающих все эти задачи стало намного больше, но ниша уже была занята, возможно дело в этом…lair
15.07.2015 13:40+1но вот изоляция внутри прикладного приложения уже отсутсвует, а веб сервер это прикладное приложение
Во-первых, вам уже написали, что она вполне присутствует и реализуема. Во-вторых, даже если вы правы, то почему так сделано? Неужели нельзя было сделать изоляцию? Очевидно, что можно — почему не сделали?
То есть 15 лет назад, задачи парсинга, работы с XML и регулярными выражениями на С++ решались существенно дороже
Это типовые задачи для программирования вообще — и вы говорите, что они решаются на C++ дороже, чем на других языках? Вы уверены?
За 15 лет конечно библиотек решающих все эти задачи стало намного больше, но ниша уже была занята, возможно дело в этом…
Или в чем-то совершенно другом — например, в том, что предполагаемые преимущества от использования C++ не оправдывают всего связанного с ним геморроя?X_OSL Автор
15.07.2015 17:05>Неужели нельзя было сделать изоляцию? Очевидно, что можно — почему не сделали?
Если реализовывать изоляцию, то она сделает из С++ кода управляемый код, и все возможные преимущества будут съедены этой «изоляцией», т.е. издержки производительности от изоляции сведут на нет ее смысл.
>Это типовые задачи для программирования вообще — и вы говорите, что они решаются на C++ дороже, чем на других языках? Вы уверены?
Я говорю что они раньше, 15 лет назад, решались заметно дороже. Сейчас ситуация другая, 15 лет назад даже boost-а не было…
>Или в чем-то совершенно другом — например, в том, что предполагаемые преимущества от использования C++ не оправдывают всего связанного с ним геморроя?
Да. На тот момент совокупное решение было именно таким. Но с того момента прошло немало времени, мир несколько изменился. Часть С++ гемороя ушла, а фаза галопирующего роста IT направления подходит(а может и подошла) к концу. Вполне возможно что все это вызовет переоценку приоритетов.lair
15.07.2015 17:09Тогда почему сейчас, по вашим словам, мало хороших и удобных веб-фреймворков на C++? Раз все так изменилось?
X_OSL Автор
15.07.2015 18:45>Тогда почему сейчас, по вашим словам, мало хороших и удобных веб-фреймворков на C++? Раз все так изменилось?
Фреймворки уже написаны по большей части и пока они справляются, оптимизировать их нет нужды. Поэтому и вкладываться в оптимизацию на C++ пока нету резона.
Запрос на оптимизацию такого рода, видимо еще не созрел.lair
15.07.2015 18:50Ну то есть C++ в вебе не используется не из-за каких-то сложностей, а потому, что он там никому не нужен, я правильно вас понял?
X_OSL Автор
15.07.2015 19:04Сложности всетаки некоторые тоже есть.
Но основная причина, действительно в том что в вебе С++ пока не нужен.lair
15.07.2015 20:42Так, любопытный вывод. А теперь давайте вспомним, что веб — это одно из современных пристанищ высокой нагрузки, и немедленно возникает вопрос: в каких же отраслях он нужен, если в вебе не нужен?
DancingOnWater
15.07.2015 21:33Apache, NGNIX — они написаны на Си…
lair
15.07.2015 21:36Это все-таки инфраструктура.
X_OSL Автор
15.07.2015 21:50-1А, кстати о инфраструктуре на C#, например Sharepoint 2013
Написан на C#, но как-же он тормозит…
На машине с 24Gb памяти и SSD на гигабитной локальной сетке ПУСТАЯ страничка с его сайта открывается секунд 5. А на холодную так вообще минуту ждать можно.
Конечно ему рекомендована ферма, а машина с 24 гигами это что-то вроде минималки, но мне сложно представить, зачем для решаемых им задач столько ресурсов…lair
15.07.2015 22:04Что вы с ним делали, что он так тормозит? У нас он на копеечной виртуалке работал быстрее.
X_OSL Автор
15.07.2015 23:40Честно говоря ничего особенного не делал с ним.
Единственное, когда я аттачился к нему дебагером, он периодический(хотя и не так часто) handled валился с какойто ошибкой аутентификации, толи ферму искал и не находил, толи еще что-то — уже не помню точно.
Может дело в конфигурации, но она у меня была дефолтная standalone, машина была в домене…
Может он и правда постоянно в фоне подваливался чем тормозил любые обработки, но врядли на столько. Еще создавалось ощущение что дольше чем надо подфисает на WCF коммуникациях между своими компонентами (дебажил его под рефлектором, поэтому код его видел — т.к. большая часть шарепоинта .net)… опять таки — незнаю почему…
gandjustas
16.07.2015 03:39+2Тормозит шарик ровно потому что внутрях сидит код на C++, которому уже более 10 лет, в нем полно багов и костылей, самописный парсер и генератор XML (который умудряется проглатывать невалидный XML и выдавать такой же). Запросы в базу кстати этот же код генерирует, поэтому то, что касается получения и записи данных тормозит просто нереально.
А на холодную так вообще минуту ждать можно.
А это работает парсер-генератор, который все контролы ascx компилирует при поднятии пула. Причем сам парсер-генератор написан на C++.
Кстати уже есть подобный парсер для вебформ на новом C# компиляторе, который работает в 4-5 раз быстрее (сам замерял). Увы к шарику его прикрутить нельзя.
А в 2013 версии еще подключичи Distributed Cache, который имеет ядро на C++ и которомоу потребовалось три патча, чтобы поправить все учтечки памяти.
Кстати после патчинга и настройки кеша страницы открываются не более одной секунды. И на одном сервере может держать 40-50 страниц в секунду (оклоло 200 запросов в секунду), на каждый запрос обрабатывая права пользоваеля.
Почти каждая самописная система с таким функционалом, которую я видел, валилась уже на пяти запросах.X_OSL Автор
16.07.2015 09:38>Тормозит шарик ровно потому что внутрях сидит код на C++
>А это работает парсер-генератор, который все контролы ascx компилирует при поднятии пула. Причем сам парсер-генератор написан на C++.
Может быть…
>А в 2013 версии еще подключичи Distributed Cache, который имеет ядро на C++ и которомоу потребовалось три патча, чтобы поправить все учтечки памяти.
Вот кстати часть исключений точно была с ним связана, правда происходили они в managed коде, но это могла быть и обертка. Кэш у меня не был настроен (его вообще обязательно настраивать?)
>Почти каждая самописная система с таким функционалом, которую я видел, валилась уже на пяти запросах.
А есть ли примеры более менее известных, для сравнения?gandjustas
16.07.2015 09:53Кэш у меня не был настроен (его вообще обязательно настраивать?)
Чтобы быстро работало — да. Иначе каждая страница по 3-5 сек.
А есть ли примеры более менее известных, для сравнения?
Битрикс Корп Портал. На таких же мощностях довольно сильно тупит при 200 RPS и холодный старт небыстрый.X_OSL Автор
16.07.2015 14:24>Чтобы быстро работало — да. Иначе каждая страница по 3-5 сек.
Кстати, а что можно почитать по правильной конфигурации кэша дла Sharepoint 2013?
>Битрикс Корп Портал
Спасибо, интересная информация.gandjustas
16.07.2015 17: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 Автор
15.07.2015 21:39-1Думаю в вебе высокую нагрузку пока побеждают другими способами и эти способы пока окупаются, не знаю как долго такая ситуация сохранится. Возможно достаточно долго.
Если говорить об областях где без С++ никак
Однозначно С++ нужен в CAD отрасли пока все кады которые мне попадались имели С++-ный рендер, и С++- ную модель данных, по сути на .net были только элементы UI.
В задачах решаемых продуктами Adobe, C++ очень уместен. Во превых потомучто продукты собираются примерно из одних исходников как минимум под MacOS и Windows, а во вторых потомучто производительность и отвывчивость UI там имеет большое значение, это как никак рабочие инструменты.
Конечно в топовых 3D играх с достаточно сложными моделями и графикой. Ни одной такой на .net не попадалось.
В реализации нектороых сервисов по обработке файлов ряда форматов.
Банально, но в разработке операционных систем.
В разработке встраимого ПО, там как правило и вариантов других нет.
Я думаю можно найти и другие отрасли, но это состояние потребностей на данный момент, вопрос как оно изменится в перспективе…lair
15.07.2015 21:43Думаю в вебе высокую нагрузку пока побеждают другими способами и эти способы пока окупаются, не знаю как долго такая ситуация сохранится. Возможно достаточно долго.
Какими «другими»?
Но вообще, если вы обратите внимание, то вы назвали некий хоть и объемный, но, на самом деле — не такой уж и большой (по сравнению с «разработкой вообще») сегмент рынка. И далеко не все разработчики сейчас в это попадут (даже если они работают с десктопом, что тоже нынче нечасто). Это просто как иллюстрация границ применимости вашего поста и выводов в нем.X_OSL Автор
15.07.2015 21:56>Какими «другими»?
Думаю затратами на железо, энергию и место где все это железо находится.
>Это просто как иллюстрация границ применимости вашего поста и выводов в нем.
Да. Но это на данный момент, особый интерес представляет как развитие пойдет дальше. В железе наметилась стагнация, к чему она нас приведет?lair
15.07.2015 22:06Думаю затратами на железо, энергию и место где все это железо находится.
И почему эти способы неприменимы там, где вы продвигаете C++? Для справки, машина, на которой я работаю с весьма маленькими по современным меркам фотографиями, греется, жужжит и жрет энергию как не в себя. А это, заметим, софт от Adobe, который, по вашим словам, должен бы быть отзывчивым и все такое.
Да. Но это на данный момент, особый интерес представляет как развитие пойдет дальше. В железе наметилась стагнация, к чему она нас приведет?
Я вот про эту стагнацию слышу уже давно, но все никак ее не вижу. Может, покажете?
gandjustas
16.07.2015 03:47+3Однозначно С++ нужен в CAD отрасли пока все кады которые мне попадались имели С++-ный рендер, и С++- ную модель данных, по сути на .net были только элементы UI.
Я видел AutoCad на WPF, который вполне прилично работал
В реализации нектороых сервисов по обработке файлов ряда форматов.
Бред полнейший. Все парсеры на .NET умеют генерировать код, который распарсенные файлы раскладывает в структуры, не заставляя на каждое поле пересчитывать смещения. Умножив это на IO через IOCP, про который половина программистов C++ даже не в курсе, получаем гораздо более быстрые парсеры на .NET. При условии конечно, что руки растут не оттуда же, откуда и ноги.
В разработке встраимого ПО, там как правило и вариантов других нет.
Проснись. На intel edison пишут вообще на NodeJS.
Ты банально повторяешь штампы 2005 года. А на дворе 2015…X_OSL Автор
16.07.2015 10:58> Я видел AutoCad на WPF, который вполне прилично работал
Я такого AutoCad-а ни разу не видел :) во всех все что я видел от 2009 до 2016-го ядро чтения файла было написано на С++, рендеринг тоже, а на WPF была написана только некоторая часть UI. (В UI там вообще зоопарк)
> Проснись. На intel edison пишут вообще на NodeJS.
Справедливости ради да, NodeJS используется как средство разработки встраимого ПО, правда не уверен что это подойдет для любых платформ.
> Ты банально повторяешь штампы 2005 года. А на дворе 2015…
Некоторые вещи изменились с 2005, некоторые нет… конечно что-то я не знаю.
Но раз все так хорошо, зачем развивают С++, откуда вообще эти планы на С++17?gandjustas
16.07.2015 12:47Справедливости ради да, NodeJS используется как средство разработки встраимого ПО, правда не уверен что это подойдет для любых платформ.
Ок, а для каких НЕ пойдет?
Кстати MC обещает что везде, где работает NodeJS можно будет запустить .NET Core.
Но раз все так хорошо, зачем развивают С++, откуда вообще эти планы на С++17?
Спрос-то есть, а язык до выхода C++11 устарел аж на 15 лет. К C++17 язык догонит сегодняшние современные языки.X_OSL Автор
16.07.2015 12:58-3>Ок, а для каких НЕ пойдет?
Не скажу точно. Вообще, если он написан на С, то вполне возможно пойдет почти везде, только если на очень дохлом железе в ресурсы упрется.
>К C++17 язык догонит сегодняшние современные языки.
Да, скорее всего. И дальше будет вопрос как разовьются современные языки к моменту выхода C++17.
Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет? Особенно если производительность железа не сильно вырастет…gandjustas
16.07.2015 13:05+3Не скажу точно.
Ты продолжаешь поражать, ты даже не знаешь в каком эмбеде обязательно нужен C++, но продолжаешь утверждать, что это для C++ это важная область.
Кстати большинство эмбеда ранее (до 2010 года) было на C без плюсов. Так что странно что ты в контексте C++ говоришь про эмбед.
Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет?
Очень сомневаюсь. managed платформы развиваются быстрее, а программисты до сих пор — самые дорогие компоненты софтверных решений.
Скорее для C++ так и останется область системного софта и всяких плагинов\COM. При этом новые языки типа GO или Rust будут отжимать из этой области. Ну может еще сложная математика останется.
Особенно если производительность железа не сильно вырастет…
Ты удивишься, но десктопная программа 95% времени ждет действия пользователя, а серверы более 80% активного времени занимаются склейкой строк для генерации ответов на HTTP.X_OSL Автор
16.07.2015 13:43>Кстати большинство эмбеда ранее (до 2010 года) было на C без плюсов.
Да, это правда, и наверное кстати так С без плюсов и останется в ряде эмбеда.
Я бы правда не стал говорить что большинство, но действительно много эмбеда используют C причем зачастую вкупе со статической работой с памятью. С++ добавляет некоторый оверхед относительно С, и на дохлом эмбеде это проявляется.
>Ты удивишься, но десктопная программа 95% времени ждет действия пользователя, а серверы более 80% активного времени занимаются склейкой строк для генерации ответов на HTTP.
Да не, не удивлюсь — тут все вполне логично. Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.lair
16.07.2015 13:48Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.
Вот только у десктопной пользователь один, а у серверной — десятки тысяч, и отклик нужен каждому.
gandjustas
16.07.2015 17:51+1Я бы правда не стал говорить что большинство, но действительно много эмбеда используют C причем зачастую вкупе со статической работой с памятью. С++ добавляет некоторый оверхед относительно С, и на дохлом эмбеде это проявляется.
Мне довелось работать с тремя устройствами. Два не поддерживали C++ вообще, а для еще одного был C++ компилятор, но на форумах все говорили, что не надо использовать C++, только C.
Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.
Какие-то расчеты, то никто в здравом уме не будет их запускать в UI потоке. Поэтому быстрый отклик получается когда используешь асинхронные операции, чтобы в UI потоке не ждать пока прочитается файл или выполнится запрос к веб-сервису.
Посмотри на Outlook — там как раз он много бегает в Exchange из UI потока и умудряется дико тупить не загружая процессор и не расходуя память. И кстати Outlook на C++ написан и там самописный движок хранения писем в pst, который умудряется 30-мегабайтный файл обрабатывать по полминуты на 8-ядерном ноуте (это к вопросу о парсинге).X_OSL Автор
16.07.2015 18:57>Посмотри на Outlook — там как раз он много бегает в Exchange из UI потока и умудряется дико тупить не загружая процессор и не расходуя память.
Outlook странная софтина, мне кажется если ее нормально переписать с нуля, то можно получить продукт работающий заметно быстрее и отзывчевее, причем тут даже не так важно на чем его переписывать, главное перетрясти архитектуру.
Да и вообще, если говорить о производительности офиса,
Могу сказать что например ворд из Офис 2007 работает на десктопном core i7 c 16 Гб не быстрее(по мноим ощущениям даже медленнее) чем ворд из Офис 97 на ноутбучном PIII 700 с 380Мб памяти.
Это касается и отклика на ввод пользователя и запуска приложения, причем я бы не сказал, что отличиями функционала этих двух продуктов можно объяснить такую разницу во времяни отклика.gandjustas
16.07.2015 20:48Ну вот, получается C++ — вовсе не гарантия отзывчивости приложения. Офис-то на С++ весь написан, а особой шустротой и отзывчивостью не отличается. Кстати именно отзывчивость обещают в первую очередь починить в 2016.
X_OSL Автор
16.07.2015 21:07Конечно не гарантия.
Если поставить заведомо дурные приоритеты разработки, то испортить можно любой продукт на любом языке.
>Кстати именно отзывчивость обещают в первую очередь починить в 2016.
Хорошо-бы.
lair
16.07.2015 13:13Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет? Особенно если производительность железа не сильно вырастет…
У вас нет никакого способа это угадать. Но судя по тому, куда идут «большие игроки» — нет, не станет. If anything, станет только менее актуальным.X_OSL Автор
16.07.2015 23:25> судя по тому, куда идут «большие игроки»
Каких именно «игроков» вы имеете ввиду, и куда они идут, по вашему мнению?lair
17.07.2015 00:50Например, гугл с го, твиттер со скалой, мозилла с растом. Они все идут в сторону повышения абстракции и упрощения тех или иных аспектов современного программирования.
X_OSL Автор
17.07.2015 09:37>гугл с го, твиттер со скалой, мозилла с растом
Но это только «большие игроки» веба. Есть еще немало «больших игроков» десктоп-приложений. Они по большей части сидят на С++ и исправно переходят на более свежие компиляторы, поддерживают новые платформы.
Даже Микрософт пока не спешит переводить свои десктопные продукты на .net…
(конечно кое-что из дотнета в них есть, но вот например не-WPF рибоны в офисе у меня зародили сомнения в том, что микрософт уверен в перспективности технологии)
Да и хром от гугла, равно как и firefox от мозилы врядли будет переписан на что-то отличное от С++ (это если говорить о десктопных приложениях)
>Они все идут в сторону повышения абстракции и упрощения тех или иных аспектов современного программирования.
Безусловно, все развивающиеся средства разработки к этому так или иначе идут…lair
17.07.2015 11:40+1Есть еще немало «больших игроков» десктоп-приложений. Они по большей части сидят на С++ и исправно переходят на более свежие компиляторы, поддерживают новые платформы.
А-га. Вот возьмем, например, Apple — эти долго и упорно работали с Objective-C, а недавно выкатили — и всем пропагандируют Swift.
Или Adobe. Внезапно, от 40 до 60 (по разным источникам) процентов Lightroom (это такое весьма графически интенсивное приложение) написано на Lua.
Даже Микрософт пока не спешит переводить свои десктопные продукты на .net…
Одно дело переводить, другое дело — писать новые. Кстати, MS как-то признал, что даже куски Windows написаны на C#.
не-WPF рибоны в офисе у меня зародили сомнения в том, что микрософт уверен в перспективности технологии
А по поводу WPF у многих есть такие сомнения (просто не надо путать WPF и .net), у него действительно был продолжительный период упадка.
Но понимаете, основной пойнт даже не в этом. Основной пойнт в том, что чистые десктопные приложения понемногу вымирают, их область применения не растет (в отличие от отрасли в целом).X_OSL Автор
17.07.2015 12: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.07.2015 12:53Декстопные приложение уходят на Workstation, где им и место ну и плюс игры.
Что вы понимаете под «workstation»?
плюс игры.
По поводу игры консоли (и куча мобильных игр) тоже бы с вами поспорили.
Пока Workstation на вебе есть в лучшем случае для бухгалтеров и документооборота.
Для всего энтерпрайза, если быть точным.
Даже офис приложения на вебе не смог занять нишу офиса в виде приложения для десктопов и мобильных устройств.
Да ладно вам. Я перестал дома (и на ноутбуке) пользоваться десктопным клиентом для почты.
Но, еще раз повторюсь: это все старые отрасли применения, по сравнению с ситуацией, скажем, десять лет назад — ничего нового не появилось. Или я пропустил что-то?
DancingOnWater
17.07.2015 10:23Не согласен по поводу Rust, он не идет по пути повышения абстрактности, он делает «рефакторинг» C++.
Скорее он идет по пути более глубинного понимания того, что творит программист, разбивая большие абстракции на более мелкие и требуя уточнения там, где это необходимо.lair
17.07.2015 11:46Я тут не буду с вами спорить, я недостаточно хорошо знаю Rust для этого. Но у меня по короткому знакомству создалось ощущение, что он, по крайней мере, дает частично другой набор абстракций, нежели C++.
DancingOnWater
17.07.2015 11:59Это да, но введений новых абстракций не тянет за собой какие-то накладных расходы. Т.е. основной принцип С\C++ — ты не платишь за то, что не используешь соблюден полностью.
Нуи есть возможность перейти на более низкий уровень абстракции — вновь вернуться к указателям, или даже ассемблерному коду, опять же, не жертвуя производительностью.
X_OSL Автор
17.07.2015 13:33> Что вы понимаете под «workstation»?
> Для всего энтерпрайза, если быть точным.
Согласен — термин не очень конкретный.
Я имел ввиду рабочие места дизайнеров, конструкторов, разработчиков ПО, и думаю не только их. А чьи рабочие места в вашем понимании входят в энтерпрайз, почему конструктора например не входят?
>Да ладно вам. Я перестал дома (и на ноутбуке) пользоваться десктопным клиентом для почты.
А как насчет Word, Excel, Visio? Кстати наверняка на смартфоне вы используете приложение клиента, а не веб интефейс. А если так, — не задумывались, — почему?
>Но, еще раз повторюсь: это все старые отрасли применения, по сравнению с ситуацией, скажем, десять лет назад — ничего нового не появилось. Или я пропустил что-то?
Да, это старые области применения, они развились и сейчас в них происходят не революционные, а эволюционные изменения. Но так ли много новых именно областей появилось для энтерпрайз?lair
17.07.2015 16:09Что вы понимаете под «workstation»?
Я имел ввиду рабочие места дизайнеров, конструкторов, разработчиков ПО, и думаю не только их.
Тогда ваша формулировка «Декстопные приложение уходят на Workstation, где им и место» лишена смысла.
А чьи рабочие места в вашем понимании входят в энтерпрайз, почему конструктора например не входят?
Просто конструкторов — от всего энтерпрайза — очень мало в процентном соотношении. Но да, я был не прав, что я их не учел. А так — вся учетная деятельность, управление процессами, управление производством, любая совместная деятельность.
А как насчет Word, Excel, Visio?
Из всего этого я если и пользуюсь, то вордом, да и то чаще проще зайти в гдокс или офис-онлайн.
Кстати наверняка на смартфоне вы используете приложение клиента, а не веб интефейс. А если так, — не задумывались, — почему?
Потому что у него более удобный интерфейс и интеграция с телефонными сервисами. Но при этом оно (кроме дополнительного локального кэша) больше ничем не отличается от веб-приложения, там даже внутри те же самые апи задействованы.
Но так ли много новых именно областей появилось для энтерпрайз?
Мобильные приложения, например. Вообще распределенная, удаленная и совместная работа. Big Data в ее нынешнем понимании.X_OSL Автор
17.07.2015 16:39>Тогда ваша формулировка «Декстопные приложение уходят на Workstation, где им и место» лишена смысла.
Наверное я плохо сформулировал, имел ввиду что среди Декстопных приложений остаются только нужные на Workstation, а приложения более уместные на планшетах и телефонах — отмирают на десктопе. Но при этом и Workstation приложения не появляются на мобильных устройствах, то есть рынок просто делится.
>Потому что у него более удобный интерфейс и интеграция с телефонными сервисами.
И именно поэтому веб приложения проигрывают многим десктопным приложениям. Еще можно добавить отзывчивость интерфейса. Я кстати думаю что именно приложения для смартфонов и планшетов отобрали часть рынка у веб приложений.
>Вообще распределенная, удаленная и совместная работа.
Dms и PLM системы появились очень давно, и не в вебе… они очень стары…
>Big Data в ее нынешнем понимании.
А какое у нее сейчас понимание? (видел немного разные трактовки...)lair
17.07.2015 16:48Наверное я плохо сформулировал, имел ввиду что среди Декстопных приложений остаются только нужные на Workstation, а приложения более уместные на планшетах и телефонах — отмирают на десктопе.
Что, собственно, подтверждает мой тезис об уменьшении доли десктопа на рынке.
Но при этом и Workstation приложения не появляются на мобильных устройствах, то есть рынок просто делится.
Это неправда: игры.
И именно поэтому веб приложения проигрывают многим десктопным приложениям
Именно десктопным — нет (если мы про приложения, не требующие какой-то специальной графики, да и то).
Еще можно добавить отзывчивость интерфейса.
Нельзя. Почему вы считаете, что отзывчивость интерфейса у нативного приложения выше?
Я кстати думаю что именно приложения для смартфонов и планшетов отобрали часть рынка у веб приложений.
Во-первых, не отобрали — просто теперь помимо гмейла в браузере на десктопе я пользуюсь еще и гмейлом в приложении на планшете. И поэтому, во-вторых, с точки зрения гмейла как сервиса рынок увеличился. По большому счету, не важно, на чем сделан фронт-энд распределенной системы, бэкенд все равно надо писать, и он съедает подавляющее количество усилий.X_OSL Автор
17.07.2015 17:11> Это неправда: игры.
С ними все не однозначно. Часть игр удобных под тач, и не требующих продвинутого ввода действительно идет на мобильные платформы, но для немалой части отсутствие мышки и клавиатуры или хотябы джойстика, а также маленький экран сильно портит геймплей.
>если мы про приложения, не требующие какой-то специальной графики
Мы не только про них) Если говорить о приложениях без особой графики и особо продвинутого UI, то да — веб в них имеет свою долю. Но и не все так просто. Если приложение должно что-то делать с данными на вашей файловой системе (а таких приложений не так и мало) то веб приложения начинают сильно проигрывать.
>Почему вы считаете, что отзывчивость интерфейса у нативного приложения выше?
Она потенциально может быть выше, т.к. больше шансов ответить без задержки на ввод из-за меньшего количество прослоек и задержек.
Хотя например некоторые WFP контролы работают медленнее подобных написанных на HTLM + JS. Поэтому в сравнении веб это может быть не так и плохо по отзывчивости, но врядли на wpf в этом вопросе стоит равняться.
>Во-первых, не отобрали
Это только потому что у gamail есть и мобильный и веб клиенты. А вот если бы не было, то может вы бы и перешли на другую почту, ради удобства мобильного пользования.lair
17.07.2015 17:22С ними все не однозначно.
С ними все однозначно — есть игры и для мобильных устройств, и для десктопов. Иногда разные, иногда одни и те же, иногда companions.
Если приложение должно что-то делать с данными на вашей файловой системе (а таких приложений не так и мало) то веб приложения начинают сильно проигрывать.
Опять-таки, зависит от области деятельности. С развитием распределенных хранилищ таких приложений все меньше и меньше.
Она потенциально может быть выше, т.к. больше шансов ответить без задержки на ввод из-за меньшего количество прослоек и задержек.
Вот именно что «потенциально». А что там на самом деле — никто не знает.
Это только потому что у gamail есть и мобильный и веб клиенты. А вот если бы не было, то может вы бы и перешли на другую почту, ради удобства мобильного пользования.
Эээ, вы серьезно? Пойти и сменить сервис-провайдера с десятилетней историей из-за отсутствия мобильного клиента? Особенно почтового, учитывая наличие стандартных протоколов?
Пойнт-то как раз в этом: если вы предоставляете сервис, а не приложение, то вы вполне переживете все смены клиентских парадигм — до тех пор, пока парадигма сервиса не изменилась.
Вот возьмем TripIt. У них отвратительный собственный клиент для Windows Phone, настолько отвратительный, что я просто не пользовался этим сервисом с телефона. Но стоило появиться стороннему приложению, как я радостно заплатил денег его автору, и теперь у меня есть приложение на телефоне. При этом услугами самого сервиса я как пользовался, так и пользуюсь, и без них приложение бессмысленно.X_OSL Автор
17.07.2015 18:29>С ними все однозначно — есть игры и для мобильных устройств, и для десктопов. Иногда разные, иногда одни и те же, иногда companions.
Имено так.
>Опять-таки, зависит от области деятельности.
Да.
Иными словами имеет место быть сегментация, а не уход с десктопа. То что подходит больше для десктопа остается на нем, а то что больше для мобильных платформ — идет на них.
>Особенно почтового, учитывая наличие стандартных протоколов?
Согласен, этот пример плохой. Стандарное приложение для почты вполне подойдет. Однако если бы это был какойнибудь менее стандартный сервис на котором вы не так плотно сидите, типа планировщика, листа покупок или еще чегонибудь то вполне возможно это былобы аргументом. Скажем так, для меня было бы аргументом.
>если вы предоставляете сервис, а не приложение, то вы вполне переживете все смены клиентских парадигм
Если вашим сервисом будут пользоваться — то да. Обычно к сервису нужно предоставить и каких-то клиентов чтобы им пользовались, и тут появляется вопрос о таких средствах разработки этих клиентов, которые бы позволили затратить минимум усилий на поддержку новых платформ.lair
17.07.2015 18:33Иными словами имеет место быть сегментация, а не уход с десктопа. То что подходит больше для десктопа остается на нем, а то что больше для мобильных платформ — идет на них.
А я и не говорил про уход, я говорил про неувеличение на фоне общего роста — что приводит к уменьшению общей доли.
Согласен, этот пример плохой. Стандарное приложение для почты вполне подойдет. Однако если бы это был какойнибудь менее стандартный сервис на котором вы не так плотно сидите, типа планировщика, листа покупок или еще чегонибудь то вполне возможно это былобы аргументом.
Планировщик — такой же плохой пример (потому что есть стандартные же протоколы). А листы покупок… ну да, правильно, это очень засиженный сегмент, конкуренция высока, хотите жить — вертитесь.
Обычно к сервису нужно предоставить и каких-то клиентов чтобы им пользовались, и тут появляется вопрос о таких средствах разработки этих клиентов, которые бы позволили затратить минимум усилий на поддержку новых платформ.
Это заведомо неправильный подход. Нужно сначала задуматься о таком сервисе, который позволит затратить минимум усилий на поддержку произвольных клиентов.X_OSL Автор
17.07.2015 19:21>Это заведомо неправильный подход. Нужно сначала задуматься о таком сервисе, который позволит затратить минимум усилий на поддержку произвольных клиентов.
Я не спорю с тем, что сначала нужно думать о сервисе. Я говорю о том, что клиентов всеравно придется писать. Если клиент будет простой, то можно и не заботиться о кросплатформенности, а написать везде свои.
А если клиент тяжелый, то писать под каждую платформу будет уже трудоемко.lair
17.07.2015 21:33Кто же пишет тяжелые клиенты для мобильников?
Ну вот возьмем тот же TripIt. Это тривиальное CRUD-приложение + уведомления + карта. На десктопе оно никому не сдалось (его и не существует). Остаются планшеты и смартфоны. На Windows (не важно, телефоне или планшете) оно должно выдавать LiveTile (естественно, соответствующих каждому устройству размеров и набора информации), на iOS — интегрироваться с Today Screen. Уведомления и интерфейс — в соответствии с гайдлайнами каждого устройства (на Windows — Modern, на Android — Material, на iOS — не-помню-как-называется).
Вот и что вы собрались в этом кроссплатформенно писать?X_OSL Автор
17.07.2015 21:49>Кто же пишет тяжелые клиенты для мобильников?
Если в вашем клиенте всроена рендерилка какихнибудь документов, то уже есть что делать кроссплатформенным. Или же например поддержан каконибудь особый протокол работы с сервером, или у вас там расчеты какие-то выполняются…
Да в любом относительно толстом клиенте, который делает что-то «свое» (а не только вызов функциональности ОС) появляется смысл в кроссплатформенности.
А тривиальные приложения делать кросплатформенными смысла нет.lair
17.07.2015 22:39Если в вашем клиенте всроена рендерилка какихнибудь документов, то уже есть что делать кроссплатформенным.
Особенно если эффективные механизмы рендера на каждой платформе отличаются.
Или же например поддержан каконибудь особый протокол работы с сервером
Опять велосипед?
Да в любом относительно толстом клиенте, который делает что-то «свое» (а не только вызов функциональности ОС) появляется смысл в кроссплатформенности.
Я вам выше привел пример приложения. Что в нем делать кроссплатформенным?
lair
17.07.2015 16:54Dms и PLM системы появились очень давно, и не в вебе… они очень стары…
Тем не менее, сейчас требования к collaborative applications сильно изменились (те же правила разрешения конфликтов). А веб просто радикально изменил правила игры с расстояниями между участниками.
Раньше, скажем, никому не приходило в голову требовать от шеститерабайтного архива документов доступности в браузере в любой точке России.
А какое у нее сейчас понимание? (видел немного разные трактовки...)
Если сильно упрощать, то структурированные данные, к которым при этом уже неприменимы стандартные подходы классических СУБД,
qw1
15.07.2015 18:25+1Часть С++ гемороя ушла, а фаза галопирующего роста IT направления подходит(а может и подошла) к концу. Вполне возможно что все это вызовет переоценку приоритетов.
Похоже, после поколения managed начинает появляться новое поколение языков, таких как go и rust, которые стараются по скорости походить на native, а по безопасности на managed.
Может, лет через 10-15 (вспомним, сколько потребовалось С/С++, чтобы вырасти) появится куча веб-фреймворков на этом поколении.X_OSL Автор
15.07.2015 18:59Возможно, хотя возможно и то что допилят синтаксис и набор стандартных библиотек в С++, сделав его более безопасным и удобным.
vedenin1980
15.07.2015 19:27+1Нее, было бы можно допилить С++ никогда бы не появилось ни Java, ни C#, ни go c rust'ом. Проблема вовсе не в библиотеках или синтаксисе, а в том что безопасность и удобство можно сделать только сломав обратную совместимость и просто забанить все опасные фичи (иначе их все равно будут использовать), на что никто не пойдет.
X_OSL Автор
15.07.2015 19:36Можно сделать уровень ворнингов, который будет валить компиляцию при условии использования опасных фич, это думаю достаточно просто.
vedenin1980
15.07.2015 19:47+1Не будет, пока в языке есть goto обязательно найдется умник превращающий код в вермешель. Все равно будут использовать тонны старого кода и писать по шаблону. Единственный способ который работает: назвать язык D++/E++, безусловно выкинуть все лишнее и опасное и все начать с нуля, оставив работу с кодом на С++ на уровне подключаемых библиотек. Иначе вместо создания Java допилили бы С++ с варнингами и добавили сборщик уровня на уровне необязательной библиотеки.
X_OSL Автор
15.07.2015 22:01+1>Не будет, пока в языке есть goto
Да ладно вам. В С# вполне есть себе goto, просто им не пользуются.
msdn.microsoft.com/ru-ru/library/13940fs2.aspx
Добавтить ворнинг и в С++ пользоваться не будут :)
vedenin1980
15.07.2015 13:43+2Изоляция ОС от прикладных приложений конечно есть, но вот изоляция внутри прикладного приложения уже отсутсвует,
Вот объясните как вы предлагаете писать огромные дескоптные приложения с миллионами строк кода, если при описки в одной незначительном модуле может лихорадить всю систему. Как вообще на C++ решается если кто-то начинает перетирать память ваших переменных случайным образом (из-за ошибки в указателе, итераторе и т.п.), а кол-во нового кода слишком велико чтобы его как-то вручную проверить за обозримое время? О каком ООП может идти речь если состояние объектов может начать непредсказуемо меняться от каждого лиха любого разработчика любого модуля?X_OSL Автор
15.07.2015 18:51>Как вообще на C++ решается если кто-то начинает перетирать память ваших переменных случайным образом (из-за ошибки в указателе, итераторе и т.п.), а кол-во нового кода слишком велико чтобы его как-то вручную проверить за обозримое время?
Отладка под gflags, с page heap флагами позволят поймать большинство таких проблем
msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspxqw1
16.07.2015 00:55+2А если такая ошибка возникает, когда какой-то юзер вводит кириллицу туда, куда разработчик не ожидает? Наример, ошибочно выделено 20 байт под 20 символов utf-8. И сервер падает только в production и не сразу после события X, а только когда после X выполнили Y (что может произойти через несколько часов после X). Значит, в production нужно всегда сидеть на debug-билдах?
X_OSL Автор
16.07.2015 11:13Делать фиксированный буфер под utf-8 и не проверять выход за его границы — это просто то как нельзя делать. Это проблема подхода.
Нужно либо передавать размер буфера и проверять его на стороне того кто его заполняет, либо аллоцировать буфер на стороне того кто его заполняет.qw1
16.07.2015 11:35+2Есть проблема — программисты пишут код с ошибками. Надо с ней бороться. Рассуждать о походах бесполезно, код пишут живые люди.
managed-среды при подобных ошибках сразу роняют сервер и записывают в лог stack trace, что позволяет исправлять ошибки очень быстро.
c++ предлагает только debug билды и это всё?X_OSL Автор
16.07.2015 23:37>c++ предлагает только debug билды и это всё?
Не, ну почему, можно добавить логгинг в свое приложение и логить происходяшее там, дабы получать информацию о исключениях и местах где они произошли
Про gflags я говорил уже
Практика code review в принципе тоже позволяет избежать большой части ошибок, которые могут совершить программисты.
Регрессионные «юнит»-тесты тоже вполне могут помочь.
Конечно все это не панацея, но справедливости ради и в managed средах бывают сложно вылавливыемае ошибки. Например утечки памяти в managed средах ловить не так и просто.
А некторые проблемы с избыточным потреблением ресурсов процессора, без профайлера, могут быть заметно менее очевыдны чем в случае С++.
Хотя согласен что в managed ловить ошибки проще (но ровно до тех пор пока среда не стала mixed)qw1
17.07.2015 00:22Не, ну почему, можно добавить логгинг в свое приложение и логить происходяшее там, дабы получать информацию о исключениях и местах где они произошли
Проблема в том, что при событии X исключение не возникает, а падает событие Y, которому испортили память.
gandjustas
17.07.2015 01:11+3Например утечки памяти в managed средах ловить не так и просто.
Это кто тебе такую глупость сказал?
Утечка памяти в языке с GC может быть по двум причинам:
1) кто-то держит ссылку
2) кто-то «прикрепил» объект и не дает сжимать кучу.
В обоих случаях запуск профайлера памяти сразу покажет кто виноват и как поправить.
Я не видел ни одной утечки в managed коде, для устранения которой понадобилось бы более часа. Только если она не внутри какогонить WPF (таких было довольно много в первой версии, но к 4.5 все известные устранили).
А некторые проблемы с избыточным потреблением ресурсов процессора, без профайлера, могут быть заметно менее очевыдны чем в случае С++.
Что ты имеешь ввиду? Что в C++ не надо пользоваться профайлером, чтобы найти узкое место? Это откровенно глупое заявление.
При некотором навыке в C# можно видеть проблемные для быстродействия места, но профайлер все равно нужен.X_OSL Автор
17.07.2015 09:52>Утечка памяти в языке с GC может быть по двум причинам:
>В обоих случаях запуск профайлера памяти сразу покажет кто виноват и как поправить.
То простые случаи. Более неприятные случаи когда:
— Утечки возникают из-за не освобожденных ресурсов системы, особенно взятых импортами из dll системы.
— В неправильной последовательности освобождаются COM объекты ( GC не знает в какой последовательности их освобождать, а типичный дотнет девелопер не приучен чего-либо освобождать, если у него нет метода Dispose)
— Кривой маршалинг при вызове импортов из dll. Тут скорее не утечка памяти, а просто ее порча со всеми вытекающими последствиями не менее страшными, чем на С++, но более неожиданными.
— С WPF ом тоже помню были утечки, которые трудоемко было отловить
>Что ты имеешь ввиду? Что в C++ не надо пользоваться профайлером, чтобы найти узкое место? Это откровенно глупое заявление.
Надо. Но при ревью С++ кода проще найти более тяжелые для выполнения вещи из-за меньшего количества синтетики.
Это скорее к языку. Например код: «instance.Name» на С++ однозначно обратиться к филду, а на С# легко может обратиться к проперти внутри которой может быть засунуты тяжелые вычисления. Были еще какие-то подобные примеры.
Это вроде и мелочи, но несколько увеличивают вероятность пропустить потенциальную трату ресурсов.gandjustas
17.07.2015 17:24+1То простые случаи. Более неприятные случаи когда:
— Утечки возникают из-за не освобожденных ресурсов системы, особенно взятых импортами из 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.07.2015 19:09-4>Это все следствие криво написанного нативного кода (внезапно на С++), а вовсе не проблема .NET.
Вообще-то нет. В документации к нативным методам и COM объектам написано как правильно с ними работать, что и как освобождать, просто .net разработчики ее не особо читают, полагая что раз они пишут на .net то он сам все какниюудь разрулит.
>Это не проблема C#.
Да. Это проблема культуры разработки под C#, сам C# тут не причем.
Я лишь привел примеры где отладка C# может представлять заметные проблемы.lair
17.07.2015 19:14+1Я лишь привел примеры где отладка C# может представлять заметные проблемы.
Нет, в отладке там никаких дополнительных (по сравнению с вызовом тех же операций из других мест) проблем нет.X_OSL Автор
17.07.2015 19:34-2Вот не сказал бы, както ловил случайный краш на использовании неправильно отмаршаленной выходной строки — достаточно долго провозился (я же не знал что он из-за этого), причем вероятность его вылезания по debug была очень малой (не вылезал) и без page heap его вообще было не воспроизвести табильно.
Как то раз попадал на «случайное» кэширование ссылки на COM объект в .net классе при использовании Excel через Automation. В результате Excel не закрывался должны образом (не момню, может даже валился), и для того чтобы этого избежать надо было найт эту закэшированную ссылку на COM объект и явно освободить ДО закрытия application объекта.
И там и там причиной ошибки было то, что с вызовами native кода работали так, как будто это обычные .net объекты\методы, что являлось в корне не верным.
(еще раз говорю, что это относится только к случаям общения с native кодом)gandjustas
17.07.2015 20:09+1Ты о чем? Эксель, вызванный через Automation вообще сам не закрывается пока явно Application.Close() не вызовешь. А вызов Application.close гарантировано закрывает excel даже если есть ссылки.
X_OSL Автор
17.07.2015 21:58-1>А вызов Application.close гарантировано закрывает excel даже если есть ссылки.
Ага — и сделает ссылки на этот объект битыми — это конечно очень полезно.
Но на сколько помню — нет. excel.exe будет висть до тех пор, пока его объекты не освободят, даже после Application.close
С точки зрения COM тут все правильно. Если кто-то взял объект, то пока его не отпустят удалять его нельзя, а соотвественно нельзя и закрывать приложение в котором живет этот взятый объект.gandjustas
17.07.2015 22:23Битая ссылка — ссылка на объект, который уже освобожден. В C++ такое часто, в c# никогда. В COM полностью зависит от того, как написан этот com.
Excel написан так, что визуальная часть создает еще одну ссылку на com-server, поэтому без явного quit эксель не закрывается. А если ты сделал quit, то com-сервер остается живой пока есть ссылки (это поведение предписано стандартом).
Или ты подумал, что если com вызывается из C#, то он должен работать по другим правилам?
Кстати описанного тобой поведения легко добиться и в C++. Вызови addref и забудь вызвать release и тоже процесс excel останется висеть.X_OSL Автор
17.07.2015 22:42-2>Или ты подумал, что если com вызывается из C#, то он должен работать по другим правилам?
Я такого поведения и ожидал, но вот C#-писатель написавший оригинальный код — явно ожидал что GC ему поможет. Он положил ссылку на объект в мембер класа и подумал что GC за него сам все почистит когда надо будет. И GC вообщем-то почистил на выходе из приложения, (только кажется с крашем, потому что после Close, Release у взятого объекта уже както плохо отработал в полудохлом excel-е)
>Кстати описанного тобой поведения легко добиться и в C++.
Можно, но не по причине веры в GCgandjustas
17.07.2015 23:30+2Причина только одна — автор кода не знал как работает COM и Excel automation. Язык тут совершенно не при чем. Он и в c++ сделал бы ту же ошибку.
lair
17.07.2015 21:34+1Все те же проблемы у вас были бы при использовании из любого другого «неродного» языка. Impedance mismatch.
gandjustas
17.07.2015 20:06+2Вообще-то на COM есть стандарт как должны работать компоненты. Если твой компонент не следует стандарту, а требует еще разбираться с документацией, то это хреновый компонент. И проблема в нем, а не в .NET.
Жалко что нет никакого способа обязать стандарту соответствовать, вот поэтому и появляются говнокомпоненты, с которыми надо особым образом работать.
Я лишь привел примеры где отладка C# может представлять заметные проблемы.
Ты привел проблемы, вызванные кривым unmanaged кодом, который, кстати, в большинстве случаев на C++.
X_OSL Автор
17.07.2015 19:40-1>И что? Какую проблему тут ты увидел?
Тут проблемы нет, тут есть различие — производительность C# в этом вызове «на глаз» оценить сложнее, потомучто синтаксис не дает ответа на вопрос будет тут вызов метода или нет, и чтобы понять это нужно перейти к определению класса.
(мелочь конечно, но различие такое есть)gandjustas
17.07.2015 20:23+3производительность «на глаз»
Это пять, надо записать. Какой смысл тебе в производительности " на глаз"?
А как ты собрался в C++ коде с RAII оценивать производительность «на глаз»? Конструктор объектов вызывает конструкторы вложенных объектов каскадно. Если объекты не указаны в списке инициализации, то тебе надо будет явно пройтись по всем вложенным объектами чтобы понять что они делают. Как «на глаз» такое оценить?
Причем в C++ с RAII такое повсеместно, а в C# 99,9% всех свойств тупо записывают значение в поле класса и не более того.
На самом деле в C++ гораздо больше неявно вызывается кода, чем в C#, поэтому и язык сложнее. В C# все что происходит (влияет на логику программы) программы — явно фигурирует в коде программы. В C++ есть неявный вызов деструкторов, неявные вызовы конструкторов копирования неявное применение перегруженных операторов, неявные преобразования типов при подстановке шаблонов. Эти все неявности дают гораздо больший простор для создания ошибок и просаживания производительности. Спасает в основном только компилятор, который очень эффективный код генерирует.
X_OSL Автор
17.07.2015 21:34-4>Конструктор объектов вызывает конструкторы вложенных объектов каскадно. Если объекты не указаны в списке инициализации, то тебе надо будет явно пройтись по всем вложенным объектами чтобы понять что они делают. Как «на глаз» такое оценить?
Конструкторы копирования принято писать достаточно быстрыми, поэтому данная запись сведется либо к копированию объекта либо к передаче ссылки, но никак не к мрачному перебору огроммного масива и поиску в нем чегонибудь.
Во вторых часто свойства простых типов тоже можно отличить на глаз.
Например вряд-ли какойнибудь XXXId, XXXCount, XXXNumber будет объектом, а не простым типом.
Понятно что все это эвристика, но для конкретного примере — более-менее рабочая эвристика.
>В C++ есть неявный вызов деструкторов
Надо просто знать что он вызыватеся на удалении объекта или выходе его из области видимоти, это не сложное правило.
>неявные вызовы конструкторов копирования
Тут отчасти соглашусь, вызовы бывают не очевидные. Лечится использованием ссылок где допустимо (то есть при анализе кода скорее смотришь на то передается ли объект по ссылке)
> неявное применение перегруженных операторов
Глупый вопрос: а как этого достичь? (кроме случая оператора приведения типа)
> неявные преобразования типов при подстановке шаблонов.
Да, может быть неочевидным…
Вообще верно что и С++ бывает сложным в оценке производительности «на глаз»
Более менее точно на глаз наверное только ассемблер оценивать можно :)lair
17.07.2015 21:35+4Конструкторы копирования принято писать достаточно быстрыми,
Свойства в C# принято писать достаточно быстрыми.X_OSL Автор
17.07.2015 22:05>Свойства в C# принято писать достаточно быстрыми.
Мир был бы лучше, если бы все C#-писатели об этом знали :)gandjustas
17.07.2015 22:25+3Все C# писатели об этом знают. А вот те, кто знают C++ и думают что знают С# допускают такие ошибки.
lair
17.07.2015 22:40+2Вы, видимо, не улавливаете параллели между вашими претензиями к C# и претензиями gandjustas к C++. Жаль.
X_OSL Автор
17.07.2015 23:26Понимаете, моя цель не в притензиях, а в более четком понимании того, где лучше использовать С++, а где С# и какие будут перспективы у этого.
Естественно есть не мало вопросов по которым к С++ можно предъявлять притензии симитричные притензиям к С# и наоборот, и видимо оценка кода на глаз — один из них.
gandjustas
15.07.2015 12:54Мне кажется в первую очередь это нетерпимость к кривому коду. На C++ вполне можно завалить сервер кривым кодом, а это очень большой риск для веб сервера.
Специально для кривого кода придумали fastcgi еще очень давно. А до него успешно работал httpd. Так что проблема «не завалить сервер» на C++ решается давно и успешно.
Более того. Для ASP (который без .NET) до 2005 года существовал немаленький рынок COM (ActiveX) компонент, которые работали в серверном коде на VB и JS. Естественно все эти компоненты были написаны на C++.
Так что риск использования C++ сильно преувеличен.
Возможно ее там уже и нет, к сожалению узнать это точно можно лишь покопавшись на самом сервере.
А заголовки посмотреть?lair
15.07.2015 12:57+1Более того. Для ASP (который без .NET) до 2005 года существовал немаленький рынок COM (ActiveX) компонент, которые работали в серверном коде на VB и JS. Естественно все эти компоненты были написаны на C++.
Хуже того, я такой компонент самолично писал, так что действительно все неплохо было. Хотя и муторно в отладке до невозможности.
А заголовки посмотреть?
Apache/Coyote 1.1, ака томкат.
gandjustas
15.07.2015 12:38+2Но в других областях «доплата» за использование С++,- заметно меньше чем в вебе.
Ухты какое откровение. Чем веб такой особенный, что на C++ его не могут осилить? И почему на других языках успешно осиливают?
justmara
15.07.2015 12:46+5Пока читал — пытался представить себе, что молго сподвигнуть человека на написание подобного опуса. Потом вспомнил, что мне всё это напоминает
ну очень похоже
vladon
15.07.2015 21:36На дворе 2015 год, компиляторы уже реализуют фичи C++17, а вы до сих пор пишете «С++0х». Не стыдно?
X_OSL Автор
16.07.2015 00:09Вообще то нет. Всетаки пока лучше придерживаться С++0х, (С++11), чтобы не попасть на то, что на одной платформе в компиляторе реализовали одни новые фичи, а на другой реализовали другие.
Хотя когда подтянутся — вполне можно и С++14 и может даже С++17vladon
16.07.2015 10:23Я не про «придерживаться», а про то, что вы до сих пор называете новый стандарт (C++11), имя которого утвердилось уже лет пять назад — «C++0x».
X_OSL Автор
16.07.2015 11:25C++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.07.2015 11:51+2Вы бы еще ссылку из прошлого века взяли.
C++11/14/17 Features In VS 2015 RC + C++11/14/17 Features In VS 2015 RTM + constexpr.
Вполне себе поддерживает. Выходит, кстати, через пару дней.X_OSL Автор
16.07.2015 12:05-4Вот когда выйдет, тогда и пишите что «стыдно». А пока что — рано
lair
16.07.2015 12:17+3Вообще-то, RC вышел 29 апреля.
X_OSL Автор
16.07.2015 12:28-3RC это не релиз. Работать на RC нельзя.
Вообще говоря, с рядом релизов студии работать нельзя до первого сервис пака.
Конечно риск дело благородное, но использовать сырые продукты для работы я бы крайне не рекомендовал.lair
16.07.2015 12:30+1Вообще-то — можно (и я неоднократно работал). Особенно учитывая, что это не то, с чем вы работаете в продуктиве.
X_OSL Автор
16.07.2015 12:43-3Если вы точно уверены, что вам не надо будет выпускаться до того как будут устранены критичные глюки то можно работать и на RC.
Но вот если вам надо будет выпуститься до этого, то вполне возможно придется задерживать релиз, и это является серьезным риском, на мой взгляд.
Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?lair
16.07.2015 12:51+1Если вы точно уверены, что вам не надо будет выпускаться до того как будут устранены критичные глюки то можно работать и на RC.
Сначала неплохо бы выяснить, а есть ли критичные глюки.
Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?
Никак не думаю, мне эта тема не интересна.
X_OSL Автор
16.07.2015 13:05>Сначала неплохо бы выяснить, а есть ли критичные глюки.
Смотря сколько ресурсов надо потратить на это выяснение. И где гарантия что вы найдете все глюки критичные глюки входе этого выяснения?
Есть немалая вероятность что до критичного вы дойдете только к релизу, а там будет уже поздно менять платформу.… Мало радости быть первооткрывателем глюка, пока не набралось достаточно статистики по борьбе с ними…
Хотя это вопрос стратегии конечно, более рискованные стратегии могут быть более «прибыльными».lair
16.07.2015 13:12+3А где гарантия, что все критичные глюки будут найдены к релизу? К следующему релизу? К бесконечно отдаленному от вас релизу?
Пока вы не начнете работать, вы этого не поймете. Ну и вы же так ратовали за кроссплатформенность и переносимость C++ — почему вы так зависите от версии конкретной IDE?X_OSL Автор
16.07.2015 13:52>А где гарантия, что все критичные глюки будут найдены к релизу? К следующему релизу? К бесконечно отдаленному от вас релизу?
Вероятность значительно меньше. Эта вероятность снижается с ростом статистики использования продукта. А до того как продукт будет отрелижен статистики по его использованию будет недостаточно, из-за низкой массовости использования.
Через месяц-другой после релиза она наберется, но набирать ее будете не вы, а сотни и тысячи других людей. А это огромное количество человеко-часов, которое вы врядли способны потратить для быстрой оценки RC своими силами.
>Ну и вы же так ратовали за кроссплатформенность и переносимость C++ — почему вы так зависите от версии конкретной IDE?
Кроссплатформенность и переносимость корее всего будет достижима только на условно «предыдущем» релизе, потому что ваш код должен компилироваться компиляторами на других платформах, где самые новые фичи могут быть еще не реализованы.lair
16.07.2015 13:53ваш код должен компилироваться компиляторами на других платформах, где самые новые фичи могут быть еще не реализованы.
Или наоборот были реализованы намного раньше, чем у вас.X_OSL Автор
16.07.2015 16:40> Или наоборот были реализованы намного раньше, чем у вас.
В данном случае да, — Visual Studio от остальных платформ.
И в целом соглашусь, что С++11 можно считать новым только судя по Visual Studio.
vladon
16.07.2015 13:23Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?
Не то чтобы активизировалась, разработка C++11 шла с 2003 года. Но вообще да.
vladon
16.07.2015 13:01C++ сейчас развивается так, что даже 1 год — это большой срок. Говорить C++0x — это всё равно что называть любой готовый продукт его кодовым названием на этапе бета-теста.
beduin01
16.07.2015 12:56Кстати на мой взгляд разумным компромиссом между C# и С++ является D. Фактически тот же C# только без .NET и с возможностью линковки с Си кодом.
vladon
16.07.2015 13:02Только вот кроме Фейсбука его никто и не использует особо.
beduin01
16.07.2015 13:14Там как раз его особо и не используют. Зато вот к примеру www.sociomantic.com на сколько я знаю почти полностью на D написана (ну разве что сайт наверно все же на чем-то другом).
weka.io тоже судя по их выступлению тоже очень довольны тем, что весь код на Си и скриптах на D переписали.
Еще какие-то конторы тоже используют, пусть и не как основной язык.
У меня среди знакомых много народу на него перешло. Правда им работа позволяет самим инструмент выбирать. Пока что никаких нареканий не слышал, ну разве что кроме того, что нативного GUI все еще нет.
Сам я тоже где это можно Питон им на работе заменяю т.к. мне гораздо проще работать со статически типизированным компилируемым языком, чем с не типизированным скриптовым.
Инерция рынка просто очень большая. Заменить С++ на рынке не так то просто.vladon
16.07.2015 13:21C++ будет очень трудно заменить на D. Хотя бы из-за наличия GC (что неприемлемо в большинстве ситуаций, где используется С++).
(Спорить о необходимости GC не хочу.)
gandjustas
16.07.2015 23:47В С++ умные указатели это тоже форма сборки мусора. Причем совсем небыстрая сборка.
vladon
20.07.2015 20:20-1Во-первых, это не сборка мусора, а RAII.
Во-вторых, неужели вы хотите сказать, что умные указатели медленнее GC? Ну-ну.gandjustas
20.07.2015 21:04Как ни назови — суть не изменится. Если некоторый механизм позволяет вам не освобождать память вручную — это сборка мусора.
А подсчет ссылок, особенно в конкурентной среде — дорогое удовольствие. Если погуглить «smart pointer performence» можно найти даже такое flyingfrogblog.blogspot.ru/2011/01/boosts-sharedptr-up-to-10-slower-than.htmlvladon
20.07.2015 21:08-1Простое освобождение памяти не может быть медленнее регулярного запуска GC с проходом по всем объектам, т.е. по сути тому же подсчёту ссылок + огромный оверхед на обход.
Давайте всё-таки в 2015 году ссылаться на статьи не 2011 года и тем более не про стандартную библиотеку. Давно есть make_shared. Вы не учитываете unique_ptr, аналога которого нет в обычных GC-языках.
Вот так:
shared_ptr<cons<T> > xs(new cons<T>());
не пишет никто. Это и есть основная причина потери производительности.
И сравнивать нужно с GC топовых языков, а не нишевого OCaml.gandjustas
20.07.2015 21:50+2Простое освобождение памяти не может быть медленнее регулярного запуска GC с проходом по всем объектам, т.е. по сути тому же подсчёту ссылок + огромный оверхед на обход.
Такие утверждения надо доказывать. Но если вы считаете, что GC все объекты обходит, то вряд ли вам стоит размышлять на эту тему.
Давайте всё-таки в 2015 году ссылаться на статьи не 2011 года и тем более не про стандартную библиотеку. Давно есть make_shared.
И что? Структура издержек у подсчета ссылок другая, по сравнению с GC. В GC приходится платить за количество мусора в единицу времени. При подсчете ссылок надо платить за каждое присваивание (в том числе передачу параметра в функцию). Если это понимаешь, то легко найти реалистичный сценарий, когда smart_ptr проиграет по скорости GC в .NET и Java.
Вы не учитываете unique_ptr, аналога которого нет в обычных GC-языках.
На одних unique_ptr ни одну интересную программу не напишешь.
И сравнивать нужно с GC топовых языков, а не нишевого OCaml.
У топовых языков и GC получше.
vladon
20.07.2015 21:11И ему правильно в комментариях говорят: основное время тратится не на умные указатели, а на выделение мелких порций памяти.
Так код не пишут. Это высосанный из пальца синтетический код.gandjustas
20.07.2015 21:55Тем не менее C++ рожает медленный код без специальных усилий со стороны программиста. Удивительно!
Причем не Java или C#, а C++.
Я выше уже писал, что дело не в том, как быстро работают указатели в C++ (а они медленные, как и вся система с автоматическим вызовом деструкторов), а в том что на C++ вовсе необязательно использовать динамическую память и большая часть объектов создается на стеке.
vladon
20.07.2015 21:50Если некоторый механизм позволяет вам не освобождать память вручную — это сборка мусора.
Не совсем. Умные указатели — это всё же ручное управление памятью. Просто объект на стеке делает всё за забывчивого или невнимательного программиста.
И сборщик мусора собирает только забытую память. RAII собирает всё — от памяти до файлов и сетевых сокетов.gandjustas
20.07.2015 21:57-1Это болтология, лучше почитай, что умные дядьки пишут herbsutter.com/2011/10/25/garbage-collection-synopsis-and-c
И сборщик мусора собирает только забытую память. RAII собирает всё — от памяти до файлов и сетевых сокетов.
Ты удивишься, но GC собирает тоже самое.
Короче бросай писать о том, чего не знаешь.DancingOnWater
21.07.2015 09:38+1Сборщик мусора — это механизм управления памяти, который не контролирует программист. Подсчет ссылок — необходимый признак, но недостаточный.
Суть в том, что в С++ вы всегда можете узнать когда будет вызван деструктор (оставим клинические случаи в стороне). С GC это сделать не сможете.
Ununtrium
16.07.2015 13:02Очень поверхностный анализ с субъективными передергиваниями. Сравнение языков не под конкретную область задач вообще детский сад.
Отдельных статей требует рассмотрение выбора Java или же интерпретируемых языков. Они будут предпочтительнее, чем С++ или С# в некоторых случаях
Почему Java вдруг оказался в другой категории нежели C#?X_OSL Автор
16.07.2015 14:48> Почему Java вдруг оказался в другой категории нежели C#?
На это много причин, хотя на Java я писал мало, но по своему небольшому опыту(недавно Android, и лет 15 назад — портирование кое каких расчетов с Java на С++) могу сказать, что и
— она сильно проигрывает в производительности как С++ так и С#
— ее библиотеки просят рефакторинга. Субъективно, даже boost на С++ выглядит более целостным и логичным
У Java есть некоторые плюсы, но по областям применения С# и С++ пересекаются заметно сильнее чем Java и С++, по крайней мере в разработке под Windows.
Но над развитием Java тоже идет работа, возможно даже она станет значительно лучше…
BOBS13
Анализ конечно хороший в статье, но я почувствовал огромный скептицизм и недооцененность в сторону C#.
impwx
На мой взгляд, анализ крайне субъективный, и автор вместо конкретных примеров просто переозвучил распространенные стереотипы: C++ побыстрее (и не такой страшный, как кажется), а C# поудобнее (но не настолько удобнее, как кажется).
X_OSL Автор
Анализ безусловно субъективный, но основан на практике по большей части. Я хотел не вдаваться в частности, а предоставить общее видение ситуации. Можно было бы детальнее расписать пункты с конкретными примерами, но думаю это сильно бы утяжелило статью.
У меня действительно есть некоторый скептицизм относительно C#, возможно он вызван завышенными ожиданиями от С# ранее.
X_OSL Автор
Я понимаю, что болшая часть Windows разработчиков аудитории сайта, предпочитают C# в силу тех или иных причин, я и сам недавно его предпочитал.
Но я хотел бы зародить сомнения в том, что C# является столь перспективным и показать некоторую недооцененность
С++, сложившуюся за последние 5-10 лет.
lair
Вот как раз с перспективами у C# (и вообще .net) все неплохо, учитывая, что под перспективами вы понимаете параллельные вычисления, а в .net над этим активно работают.
X_OSL Автор
Параллельные обработки часто упираются в синхронизацию и доступ к ограниченным ресурсам. И тут становится крайне важным быстро обрабатывать такие ситуации, что требует оптимизации. А поскольку возможности по оптимизации managed кода ниже, вполне возможно что это станет узким местом, избавиться от которого можно только перейдя на unmanaged решения.
lair
… или перехода на решения с минимумом синхронизации. На десктопе это, правда, в меньшей степени критично, на мой вкус, но тут вообще все очень занятно даже с банальной точки зрения «а зачем нам столько производительности».
X_OSL Автор
Мне кажется минимум синхронизации возможен только в очень изолированных задачах (чисто математичаских например). Однако даже в чистой математике сложно обойтись без ввода-вывода данных, то есть без коммуникации с другими потоками или ресурсами ввода вывода.
Далее, если говорить о приложениях для пользователя — всегда есть метрика отзывчивости приложения на ввод пользователя. В таких ситуациях многопоточность может больше мешать чем помогать, ведь в пределе для максимально быстрого отклика (в виде результата, а не в виде прогрессбара) лучше иметь один поток с максимальным доступом к ресурсам, чем несколько толкающихся друг с другом потоков.
В целом, я конечно согласен, что по возможности нужно переходить на решения с минимумом синхронизации, но мои опасения в том, что перейти на них можно далеко не везде.
lair
А тем не менее, сейчас такие решения активно используются для LOB-приложений.
Пожалуйста, не путайте отзывчивость (т.е., скорость отклика приложения на действия пользователя) с производительностью (т.е., скоростью получения им результата).
X_OSL Автор
Посмотрим какую долю и какого рынка займут LOB-приложения.
Я не путаю отзывчивость и производительность, я говорю что часто для отзывчивости важна производительность. Ведь существуют операции где нельзя показывать прогрессбар, а нужно сразу реагировать на ввод, например изменением модели или каких-то параметров сцены.
lair
Уже заняли, стопроцентную. LOB — line-of-business, приложение, выполняющее основные задачи предприятия.
Существуют. Но сколько их в процентах от всего ПО?
X_OSL Автор
Все таки интересно какого именно рынка заняли 100% долю LOB приложения.
Относительно частоты задач где очень желательна быстрая реакция приложения: CAD область, работа с музыкой и видео, веб браузеры, терминалы ввода данных, игры, думаю кстати что если из проектов по созданию дополненой реальности что-то выстрелит — то там определенно реакция будет критична.
Какой процент таких задач в ПО? Возмонж не очень большой, но далеко не нулевой. И если критично избежать ощущения тормознутости приложения, эти задачи придется решать…
lair
Рынка приложений для бизнеса, очевидно. Как игры заняли 100% рынка игр.
В браузерах и терминалах ввода данных есть I/O, которое доминирует (должно доминировать) над процессорным временем. И здесь — с точки зрения скорости реакции — платформа, которая умеет нативно (и прозрачно для программиста) работать с IOCP в ощутимом выигрыше.
X_OSL Автор
Я несколько знаком с приложениями для бизнеса, но среди известных мне бизнесов, нет использующих LOB приложения. Из этого могу сделать вывод, что далеко не любому бизнесу они нужны.
Можете охарактеризовать сегмент, в который позиционируются LOB приложения? Есть ли примеры внедрений? Было-бы интересно узнать…
lair
Серьезно? Ни один известный вам бизнес не использует ERP? CRM? Бухгалтерию в любом виде? Систему управления складом? Интернет-магазин? Систему управления проектами? Систему управления задачами?
X_OSL Автор
Я наверное не правильно понял, что вы имеете ввиду под LOB-приложениями. Мне показалось что вы имели ввиду какието специфичные приложения построенные на специфичных технологиях.Я никогда раньше не слышал этот термин, хотя знаком со всеми остальными перечисленными вами терминами.
Правильно ли я понимаю, что это термин чисто маркетинговый, и не связан с какими-то конкретными решениями или технологиями.
Расскажите что именно он значит?
Это просто «в любые приложениях для бизнеса» или что-то другое?
lair
Я же вам сразу написал:
en.wikipedia.org/wiki/Line_of_business:
X_OSL Автор
Спасибо, понятно) Это видимо достаточно широкий термин.
Тогда возвращаясь к вопросу о том «минимум синхронизации» используется в LOB приложениях.
Теперь, наконец поняв что вы имели ввиду,- думаю что в любых приложениях пытаются использовать «минимум синхронизации» и это вполне естественно пытаться ее избегать, просто не всегда возможно.
Кстати, особенно неприятны ситуации где синхронизацию избегают там, где делать этого нельзя, тогда проблемы начинают вылезать случайным образом в зависимости от производительности железа и сетевых задержек. (это чуть-чуть офтопик, но наболело)