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

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

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

Отдельных статей требует рассмотрение выбора 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
  • +16
    Анализ конечно хороший в статье, но я почувствовал огромный скептицизм и недооцененность в сторону C#.
    • +23
      На мой взгляд, анализ крайне субъективный, и автор вместо конкретных примеров просто переозвучил распространенные стереотипы: C++ побыстрее (и не такой страшный, как кажется), а C# поудобнее (но не настолько удобнее, как кажется).
      • 0
        Анализ безусловно субъективный, но основан на практике по большей части. Я хотел не вдаваться в частности, а предоставить общее видение ситуации. Можно было бы детальнее расписать пункты с конкретными примерами, но думаю это сильно бы утяжелило статью.

        У меня действительно есть некоторый скептицизм относительно C#, возможно он вызван завышенными ожиданиями от С# ранее.
      • 0
        Я понимаю, что болшая часть Windows разработчиков аудитории сайта, предпочитают C# в силу тех или иных причин, я и сам недавно его предпочитал.
        Но я хотел бы зародить сомнения в том, что C# является столь перспективным и показать некоторую недооцененность
        С++, сложившуюся за последние 5-10 лет.
        • +3
          Вот как раз с перспективами у C# (и вообще .net) все неплохо, учитывая, что под перспективами вы понимаете параллельные вычисления, а в .net над этим активно работают.
          • 0
            Параллельные обработки часто упираются в синхронизацию и доступ к ограниченным ресурсам. И тут становится крайне важным быстро обрабатывать такие ситуации, что требует оптимизации. А поскольку возможности по оптимизации managed кода ниже, вполне возможно что это станет узким местом, избавиться от которого можно только перейдя на unmanaged решения.
            • +2
              Параллельные обработки часто упираются в синхронизацию и доступ к ограниченным ресурсам. И тут становится крайне важным быстро обрабатывать такие ситуации, что требует оптимизации

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

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

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

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

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

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

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

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

                      Существуют. Но сколько их в процентах от всего ПО?
                      • 0
                        Все таки интересно какого именно рынка заняли 100% долю LOB приложения.

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

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

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

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

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

                            Можете охарактеризовать сегмент, в который позиционируются LOB приложения? Есть ли примеры внедрений? Было-бы интересно узнать…
                            • +3
                              Я несколько знаком с приложениями для бизнеса, но среди известных мне бизнесов, нет использующих LOB приложения. Из этого могу сделать вывод, что далеко не любому бизнесу они нужны.

                              Серьезно? Ни один известный вам бизнес не использует ERP? CRM? Бухгалтерию в любом виде? Систему управления складом? Интернет-магазин? Систему управления проектами? Систему управления задачами?
                              • 0
                                Я наверное не правильно понял, что вы имеете ввиду под LOB-приложениями. Мне показалось что вы имели ввиду какието специфичные приложения построенные на специфичных технологиях.Я никогда раньше не слышал этот термин, хотя знаком со всеми остальными перечисленными вами терминами.

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

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


                                  en.wikipedia.org/wiki/Line_of_business:

                                  In the context of computing, a «line-of-business application» is one of the set of critical computer applications perceived as vital to running an enterprise.
                                  • 0
                                    Спасибо, понятно) Это видимо достаточно широкий термин.

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

                                    Кстати, особенно неприятны ситуации где синхронизацию избегают там, где делать этого нельзя, тогда проблемы начинают вылезать случайным образом в зависимости от производительности железа и сетевых задержек. (это чуть-чуть офтопик, но наболело)
      • +1
        Спасибо автору. Помогло «окинуть » взглядом основные отличия.
        Хотя не сказано было про отладку кода, здесь то разбежка в скорости будет существеннее.
        • +3
          Пожалуйста.Про отладку я написал в п.5 что С# тут безоговорочно лучше до тех пор пока не нужно отлаживать Mixed код.

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

          Да, я знаю что фанаты С# и Microsoft могут болезненно отнестись к некоторым моим рассуждениям и их количество тут не в пользу моих рассуждений, но я пишу не с целью троллить фанатов, а с целью задуматься о перспективах как С++ так и С# и в конечном счете о перспективах наших приложений и нас в свете их развития.
          • +1
            Я не являюсь фанатом ни того ни другого. И уважительно отношусь к обоим языкам.
            Я сам разработчик в области прикладного и web. Владею навыками как С++ так и шарпа, но прикладное разрабатываю – так уж сложилось на делфях.
            Для меня чужое мнение о выборе языка не является конечно решающим, но считаю полезным для общего просвещения прочесть материал от человека имеющего опыт разработки в обеих сравниваемых им языках.
        • 0
          Выбор инструмента зависит от задачи. Нельзя сравнивать два языка по отношению к абстрактному проекту. И да, некоторые аргументы в статье достаточно спорны.
          Например, странно писать обычное ui-приложение на плюсах под винду, также как и на шарпе кроссплатформенную игру под андроид и айос.
          • +13
            также как и на шарпе кроссплатформенную игру под андроид и айос

            Тысячи их, на фреймворке Unity
            • +7
              Не только Unity. MonoGame тоже используется.
              • 0
                Я сам использовал и Xamarin, и MonoGame, и могу вас заверить, что это не лучшее решение.
                Я же не отрицаю, что нельзя, можно и на плюсах обычное ui-приложение наваять, но этот инструмент не для таких задач.
                А вот банковский клиент на Xamarin под три платформы — самое то.
                • 0
                  Может потому, что моногейм не лучшее решение, а не Xamarin? Знаю несколько игр, написаных на Xamarin (не MG) которые работают очень шустро (и новые фичи в них добавляются очень быстро сразу на все платформы ибо C#).
                • 0
                  сама Unity написана на C++
                  • 0
                    Части .net framework, python и lua написаны на C/C++. Это что-то меняет по отношению к обсуждаемому вопросу?

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

                  Я вас порадую (а может, и огорчу): xamarin.com.
                  • +1
                    xamarin все же не самый лучший выбор для игр
                  • 0
                    UI-приложения бывают разные. Например если это CAD (или другое ресурсоемкое приложение), то исключительно на шарпе он будет очень неэффективный (медленный и часто прожорливый).
                    Бывает такие приложения сводится к компромисному решению, когда в одном приложении собирается нативный код для рендеринга и ресурсоемких задач, а C# для UI.
                    Все это приводит к Mixed коду который отлаживать часто хуже чем нативный C++ код. Про частные проблемы с Mixed кодом можно написать достаточно много, но это за рамками статьи.
                    • +4
                      WPF в Autocad так та…
                      Странное заблуждение по части прожорливости — не плодите объекты бездумно и все будет ок.
                      Такими темпами можно и до ассемблера опуститься. Вот еще на почитать — Numeric performance in C, C# and Java
                      • 0
                        Уверены?
                        forums.autodesk.com/t5/tag/Qt/tg-p www.nixp.ru/news/10377.html да и среди вакансий есть псециалисты по Qt
                        • +1
                          И? с 2009 года морда Autocad перепилена на WPF. MS нанимает спецов по Linux — пилят свой дистр?
                          Можете ради интереса погуглить Autocad + WPF.
                          Интерфейс AutoCad 2009 построен на WPF
                          • 0
                            Autocad перепилена на WPF
                            Чуть точнее — на WPF в нем добавлен рибон и кнопка «пуск» + несколько _новых_ диалогов написаны на WPF. Больше WPF там нет. Примечательно, что далеко не все новые диалоги с 2009 года были построены на WPF. И разумеется к рендерингу сцены WPF не причастен вообще.
                            • +2
                              Одновременно используется одна из новых возможностей упрощенного хостинга Direct3D сцен в рамках приложения для той части, где визуализируются создаваемые модели.


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

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

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

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

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

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

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

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

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

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

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

                                      Активно педалируемая тема — берем V8 и хостим в него наше приложение на JS — Profit.
                                      • 0
                                        Редкое использование 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 лет, а любая графика чуть потяжелее как писалась на С++ так и пишется, врядли это иррационально.
                                        • 0
                                          Вы не думали что просто через одно место написана? Можно и на C++ Написать так, что будет ползать.
                                          Вот небольшой пример — Debunking C# vs C++ Performance

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

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

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

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

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

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

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

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

                                              Google

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

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

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

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

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

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

                                                Вы можете сказать что C# в этом не виноват, что .net в этом тоже не виноват.
                                                Хорошо, а кто тогда виноват в столь низкой производительности WPF?
                                                • +4
                                                  Если вас интересует отладка — Debugging support for .NET Native Preview apps

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

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

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

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

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

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

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

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

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

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

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

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

                                                        Я его профайлил — тормозит обход дерева визуальных элементов и многократные вызовы Measure.Я незнаю зачем так часто и в таком количестве мерить ячейки грида, но я знаю что мой код в этом процессе не вызывался.
                                                        • +3
                                                          Еще раз — как тормоза DevExpress относятся к .Net? И еще раз — тестить производительность надо без флага Debug.

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

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

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

                                                            Вероятно что то недофиксили и забили, как это принято в Microsoft :(
                                                            • +1
                                                              Или вы криво построили дерево контролов, проводите лишние модификации дерева.

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

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

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

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

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

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

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

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

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

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

                                                                    Telerik вполне возможно работает лучше — не знаю — не пробовал…
                                                                    • +2
                                                                      Я сейчас сделал датагрид, в нем 10,000,000 элементов. И ничего не тормозит, виртуализация работает…



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

                                                                      Пожалуйста, покажите уже этот код. Хочу понять, что за мистика такая у вас.
                                                                      • 0
                                                                        А теперь заказчик хочет, чтобы слово Customer было зелёным, а номер за ним — красным. Для этого ячейка темплейтится и в template ставится два TextBlock. Вроде как после этого будет плоховато скроллиться
                                                                        • +2
                                                                          Не будет. Только если ты datatemplate selector применишь, или группировку к элементам и еще в некоторых случаях. А по умолчанию виртуализирует и показывает спокойно хоть миллионы элементов.
                                                                          • 0
                                                                            После TDBGridEh из дельфи, который стабильно даст 60fps при навигации, wpf-ные гриды оставляют плохое впечатление. Сложно объяснить, но как будто интерфейс лагает, уже в раздумьях не погоняешь Selection по строкам, потому что лаг отклика раздражает.
                                                                            • 0
                                                                              Кстати можете ради интереса попробовать UI из FLTK

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

                                                                              Там конечно нельзя по-простому делать всякие WPF-овские красивости и нет биндингов, но UI написанный на ней крайне отзывчивый.
                                                                              • 0
                                                                                К сожалению, на плюсах никто не даст писать gui для enterprise ))
                                                                                • 0
                                                                                  Интересно, почему?
                                                                                  • 0
                                                                                    Молодёжь не умеет писать на древних языках
                                                                                    • 0
                                                                                      Ну «даст/не даст» — это обычно начальство, а оно обычно не такое молодое и дерзкое.
                                                                                      • 0
                                                                                        gui обычно дают писать новичкам, начальство будет из этих соображений решать, на чём его писать
                                                                                        • 0
                                                                                          Это заведомо проигрышная стратегия, вне зависимости от языка.
                                                                                          • 0
                                                                                            Почему? Вместо нудного клепания тупых формочек и отчётов лучше дать новичкам нечто сложное и важное?
                                                                                            • 0
                                                                                              Потому что хороший интерфейс — это не тупые формочки и отчеты.
                                                                                              • 0
                                                                                                Есть масса типовых задач, таких как показать движения по счёту или вывести складские обороты. Интерфейс давно придуман — обычная таблица, ничего лучше не нужно.

                                                                                                Или есть такие скучные направления, как «зарплата и управление персоналом». Там в приложении куча списков сущностей и редакторов для них. Что там можно сделать хорошего и нетупого, кроме как поиграться расположением контролов, размером и цветом кнопочек?
                                                                                                • 0
                                                                                                  Перевести с сущностно-ориентированной парадигмы на задаче-ориентированную, например. Внезапно выяснится, что это далеко не так скучно, как кажется.
                                                                                                  • 0
                                                                                                    Обычно пользователи привыкли работать по стандартам (и это в принципе нормально, годами проверенные способы работы) и от программиста не ждут, что он придумает новые подходы к работе, а если и придумает, скажут — не хотим нового, хотим привычного.
                                                                                                    • 0
                                                                                                      И будут неправы. Хотя, конечно, придумывать новые подходы должен не программист, а UX-дизайнер, но реализовывать-то потом все равно программисту.
                                                                                    • +1
                                                                                      В enterprise отзывчивость интерфейса стоит на одном из последних мест в списке приоритетов.
                                                                                      Ведь тот кто за него платит, и тот кто им пользуется — как правило абсолютно разные люди.
                                                                                      (я возможно немного драматизировал ситуацию, но думаю не сильно)
                                                                                    • 0
                                                                                      К счастью
                                                                                  • 0
                                                                                    У меня на WFP 3.5 не было проблем с производительностью грида, 60FPS на современном (на тот момент) компе.

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

                                                                                    ЗЫ. Не надо WPF запускать в RDP.
                                                                                • 0
                                                                                  И… ничего не поменялось.
                                                                                • 0
                                                                                  Спасибо, что попробовали воспроизвести.

                                                                                  >Какая точно была версия фремворка?
                                                                                  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 использовать разные темплейты для редактирования и просмотра.

                                                                                  Пример в проекте, который я некоторое время не видел, попробую найти его и на его основе него сделать хеловорд, как будет время
                                                                                  • 0
                                                                                    Профайлер непосредственно этот контрол не дергал. В каком смысле что внутри?

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

                                                                                    Больше всего времяни было кажется в базовой реализации 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"
                                                                                    так и вообще визуальное дерево не меняется при перелистывании.
                                                                                    • +1
                                                                                      На самом деле, там регулярно упоминаются какие-то контролы с codeplex. В них вообще что угодно может быть.
                                                                                      • 0
                                                                                        >Остальное и так все было.
                                                                                        и datagridtemplatecolumn-ы были и биндинг на контролы в них?

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

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


                                                                                          i61.tinypic.com/f00uwo.png

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

                                                                                          (почемуто у меня нормально картинка в пост не вставилась :( )
                                                                                          • 0
                                                                                            Да и еще проект тестовый, очень быстро набросан, кода почти нет

                                                                                            s000.tinyupload.com/?file_id=09607171972593390390

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

                                                                                              s30.postimg.org/4lvgfhrnl/Measure.png
                                                                                              • 0
                                                                                                В общемто тут нет ни темплейтных колонок, ни codeplex-а, ни стилей.

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

                                                                                                Виртуализация — включена.
                                                                                        • 0
                                                                                          Показываю код

                                                                                          s000.tinyupload.com/?file_id=09607171972593390390

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

                                                                                          А ниже можно еще найти скриншот профайлера.
                                                                                      • 0
                                                                                        Razaz, я выложил тестовый проект с тормозным гридом (на чистом WPF), и скриншот профайлера во время скрола. Можете посмотреть и вынести свое суждение относительно причин тормозни, былобы очень интересно узнать.
                                            • 0
                                              WPF в Autocad — да это реальность, но там есть и Windows Forms, и MFC даже на html+javascript некоторые контролы написаны.
                                              Qt в виндовом Autocad я не замечал, но возможно они работают над тем чтобы уйти от зоопарка Microsoft контролов, кто знает…
                                              Так или иначе, под MacOS есть своя версия Autocad и она написана не на UI от Microsoft.
                                              • 0
                                                Спору нет. Просто у них скорее всего ядро и морды для каждой платформы — под Win — скорее всего перепиливают на WPF+XAML. Ядро хоть на бэйсике можно написать, один фиг все будет слито на видеокарту для рассчета.
                                        • +7
                                          Дочитал до пункта про отсутствие сборки мусора в С++ и ринулся комментировать, извините.

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

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

                                          Добавлю ещё к выводу: С++ и С# это разные языки с разными задачами. Их бесполезно сравнивать. Вот замените цвет текста у кнопки на С++ и С#. А после нажатия на эту кнопку, производится поиск обратной матрицы размером 100000*100000. И какой язык для этого лучше? ;)
                                          • +6
                                            Меня больше всего поразило, записанный в минус отсутсвие глобальный процедур и функций в C#. Это огромный плюс. Это ООП, какие глобальные процедуры.
                                            • +2
                                              Есть using static же.
                                              • 0
                                                Пока до нас докатится C#6, много еще ждать. Поэтому пока о нем умолчим.
                                                • +3
                                                  Он прекрасно работает даже при использовании .NET 2.0 в качестве целевого фреймворка. Я не вижу ни одной причины не использовать его уже сейчас и начал миграцию всех проектов ещё пару месяцев назад.
                                              • +1
                                                Ну напишите вы статический метод вместо глобальной функции, по сути — то же самое, зато «ООП».
                                              • 0
                                                > На С++ можно скомпилировать приложение БЕЗ рантайма. Это будет извращение похлеще реализации сборщика мусора, но это возможно.

                                                Есть ещё один вариант: слинковать рантайм в свой бинарник, это очень просто, но имеет свои плюсы и минусы
                                                • –10
                                                  в Qt замена цвета кнопки — плевое дело, ну а для матриц есть Eigen. Так что в данном сравнении C# проигрывает C++ по всем статьям.
                                                  • –1
                                                    Да, я несколько не корректно выразился. Разумеется, я имел в виду замену цвета текста кнопки на чистом WinAPI (к С++ вообще никакого отношения, (MF)Сишечный код).
                                                  • +14
                                                    Сборщик мусора нужен чтобы собрать эту статью
                                                    • 0
                                                      1. Может быть он и не нужен, но его отсутсвие влечет дополнительные требования к разработчикам, что так или иначе удорожает разработку.
                                                      2. Это хорошо.

                                                      На счет разних задач С++ и С# я соглашусь. Но вопрос в том где проходит линия раздела этих задач?
                                                      Ведь широкий круг задач успешно решаем и на С++ и на С# соизмеримым количеством времяни разработчика…
                                                      • –3
                                                        В задачах требующих высокой производительности, наличие gc наоборот усложняет разработку
                                                        • 0
                                                          Сильно зависит от задачи. И того, что понимать под производительностью (throughput или latency). В комментариях к этому топику их периодически путают.
                                                          • +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# достаточно.

                                                            • 0
                                                              Хороший комментарий, отражающий давольно полно текущую ситуацию.
                                                              Я бы добавил еще один момент: кроме задачи стоящей в данный момент неплохо бы учитывать и перспективы приложения (что актуально в долгосрочных проектах и относительно крупных) — может стать что оно попадет например в одну из перечисленных категорий.
                                                              • 0
                                                                К счастью, не может. Такие вещи как базы, браузеры и hft не рождаются в процессе эволюции прикладных приложений, всякие плагины тоже. И вообще такие задачи редки, вот вы например что писали на c++?
                                                            • +2
                                                              Apache Cassandra? HBase? Hadoop?
                                                            • 0
                                                              Четкой линии водораздела не существует, выбор технологии решается для каждой задачи(проекта) отдельно. И для этого уж точно не нужно делать «анализ» на пятьсот пунктов. Если это конечно не троллинг ;)
                                                              • 0
                                                                Я часто сталкивался с ситуациями, где выбор падал на C#, даже без мысли относительно анализа и мне не кажется такой подход правильным.
                                                                С другой стороны, я сталкивался и с ситуациями, где С# проекты портировалисть на С++, хотя ранее выбор безоговорочно падал на C#.
                                                                Мне кажется портирование с C# на С++ может стать трендом будущих разработок.

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

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

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

                                                                    PS. Я все же допускаю, что вы из будущего. В котором к власти во всем мире пришел Тиран с фетишизмом к С++. Был издан закон об святой инквизиции неугодных языков.
                                                                    • –5
                                                                      Совсем не факт, что железо будет докупить дешевле. Например даже скромные +500$ на рабочее место в большой компании дадут десятки, а может и сотни тысяч, и это не говоря о потреблении энергии и других конкурентных преимуществах. А повально уходить в облака большие компании пока не торопятся…

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

                                                                      Таким образом перепись критичных к производительности компонентов вполне может стать экономический выгодной. Насчет «тренда», возможно я несколько преувеличил, но думаю что как минимум явление переписи библиотек с С# на С++ будет достаточно распространенным в будущем.
                                                                      • 0
                                                                        +500$ рабочее место(не знаю что за компания такая? со специалистами студентами?) * на количество месяцев потраченное на переписку продукта.
                                                                        Как раз в современном мире как раз тенденция докупить железа. чем нанимать штат специалистов. Да еще и во время портирования не о каких новых фичах и быть не может, а бизнес к такому крайне скептично относиться.
                                                                        • 0
                                                                          Вы наверное неправильно поняли что я написал.
                                                                          Я писал про затраты на железо в +500$ на рабочее место, а не про затраты на разработку. Затраты на разработку будут другими, но если разработчиком многократно меньше чем пользователей они вполне могут окупиться.

                                                                          Да и по поводу переписи продуктов. Продукт может быть дешевле переписать, чем вообще остаться без ниши на рынке.
                                                                        • +1
                                                                          А какой смысл переписывать «библиотеку» с C# на С++? Большая часть внешних зависимостей в .net — инфраструктура, она ничего от этого не выиграет.
                                                                          • 0
                                                                            Зависит от интерфейсов библиотеки и того что именно делает библиотека.
                                                                            Математика например слабо завязана ни инфраструктуру. Работа с файлами может сравнительно легко переведена на схожую C++ инфраструктуру. Работа с не-.net библиотеками «сама просится» к такому переводу.

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

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

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

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

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

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

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

                                                                                    Да и если все это удастся сделать, на потоках С++ параллельное решение все-равно будет работать быстрее…
                                                                                    • 0
                                                                                      Я не про те потоки, которые threads, я про те, которые streams — т.е., про чтение/запись файла.
                                                                                      • +1
                                                                                        Я чаще сталкивался с тем что производительность упирается не в скорость работы stream-a, а в скорость обработки прочитанного из него.

                                                                                        Поэтому и пишу что с файлами часто проблема в производительности обработки, а не в самом I\O.
                                                                                        • +2
                                                                                          Я чаще сталкивался с тем что производительность упирается не в скорость работы stream-a, а в скорость обработки прочитанного из него.

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

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

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


                                                                                                Например?

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

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

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

                                                                                                Архивация — потоковый алгоритм, построение индекса — сортировка, которую за время чтения мегабайта можно успеть 1000 раз выполнить. Само чтение будет занимать малую долю только на очень маленьком файле. Но тогда вообще нет смысла говорить о времени работы.
                                                                                                • 0
                                                                                                  Откуда вы взяли все эти цифры, как вы считали?
                                                                                                  Почему вы пропустили этап создания объектов из прочитанных данных?
                                                                                                  • 0
                                                                                                    Потому что в среднем этот этап занимает пренебрежимо мало времени даже по сравнению с сетевом i/o, не говоря уже о дисковом.
                                                                                                    • 0
                                                                                                      Вот смотрите, HDD умеет отдавать данные со скоростью примерно 80 Mb/s, SSD так вообще 300 Mb/s, эта скорость вполне реальна если просто брать данные с носителя в память как есть.

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

                                                                                                      И да, простой пример: по такой логике копирование архива и распаковка архива должны занимать почти одинаковое время, но это не так.
                                                                                                      • 0
                                                                                                        Вот смотрите, HDD умеет отдавать данные со скоростью примерно 80 Mb/s, SSD так вообще 300 Mb/s, эта скорость вполне реальна если просто брать данные с носителя в память как есть.

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

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

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

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

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

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

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

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

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

                                                                                                          Но мы можем упаковать например какой-нибудь divx\xvid AVI — он практический не сожмется, поэтому разницы времени записи между копированием и распаковкой не будет. Однако почему-то он будет дольше распаковываться, чем просто копироваться…
                                                                                                          • 0
                                                                                                            Упакованный структурированный файл, который нужно разложить в объектную модель, а не storage базы данных формата оптимизированного до такой степени, что времени на его обработку практически не требуется. Конечно там будет все упираться в железо.

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

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

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

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

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

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

                                                                                                          При копировании файла используется как раз потоковая модель, поэтому суммарное время возрастает не сильно (если диски разные).
                                                                                                          • 0
                                                                                                            >HDD 80МБ в секунду? Да вы оптимист, реально для HDD рассчитывать на 10мб в секунду в лучшем случае.
                                                                                                            У меня HDD без проблем выдает 80МБ в секунду. Мне сложно представить где взять HDD, который выдаст только 10мб в секунду. Если только по USB 1.1 его подключить :)
                                                                                                          • 0
                                                                                                            Если так, хотелось бы узнать, в каких именно задачах скорость обработки входного потока в 80 Mb/s-300 Mb/s вызывала проблемы?

                                                                                                            Чтение нежатого видео с диска. Чтение большого PSD с диска. Сканирование большого объема фотографий в поисках нужного тега.
                                                                                                            • 0
                                                                                                              >Чтение нежатого видео с диска.
                                                                                                              Тут упремся в железо без вариантов. Если есть возможность видео лучше пожать.

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

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

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

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

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

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

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

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

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