Если вы пишите приложение на С++ _не_ завязываясь на платформо-зависимые функции (а это не так и сложно, поверьте) то вы получаете поддержку всех платформ под которые можно собрать ваше приложение. Например С++ библиотека может быть собрана из одного кода под Windows, Macos, Linux, Android, iOS, да хоть под ось и железо своей разработки, главное чтобы под них был компилятор С++.
.
Да, возможно в паре-тройке мест вам придется сделать что-то средствами специфичными для определенной платформы. И да, для полноценного приложения вам скорее всего придется на каждой платформе написать некоторый UI, родными для платформы средствами (хотя например можно написать кросплатформенный UI на Qt).
Но вы всегда сможете уйти на другую платформу при необходимости, и это не будет стоит катастрофично дорого.
Зависит от интерфейсов библиотеки и того что именно делает библиотека.
Математика например слабо завязана ни инфраструктуру. Работа с файлами может сравнительно легко переведена на схожую C++ инфраструктуру. Работа с не-.net библиотеками «сама просится» к такому переводу.
Конечно для .net есть некоторая уникальная инфраструктура, но все-таки многое из .net инфраструктуры имеет адекватные аналоги для С++ (что не всегда верно в обратном направлении)
Вы наверное неправильно поняли что я написал.
Я писал про затраты на железо в +500$ на рабочее место, а не про затраты на разработку. Затраты на разработку будут другими, но если разработчиком многократно меньше чем пользователей они вполне могут окупиться.
Да и по поводу переписи продуктов. Продукт может быть дешевле переписать, чем вообще остаться без ниши на рынке.
Я не разбирал в статье разработку на Java, о чем отдельно написал. И вы абсолютно правы в том, что риски есть и от использования линукса и от многого другого.
Я скорее разбираю вопрос минимизации рисков. И если вы будете иметь возможность уйти на другую платформу — вы безусловно минимизируете риски связанные с «неправильным развитием» вашей платформы.
Вы правы, .net библиотеки не обязаны инициализироваться на старте приложения, и если так, то время старта .net приложения действительно может быть небольшим.
Время запуска будет соизмеримым, только если для инициализации нужно выполнить достаточно много .net кода на старте приложения, это важный момент и я его не отметил. Однако среди множества .net библиотек немало тех, которые так или иначе надо инициализировать на старте приложения.
И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
STL есть в базе, везде и никаких boost-ов для этого не нужно.
Совсем не факт, что железо будет докупить дешевле. Например даже скромные +500$ на рабочее место в большой компании дадут десятки, а может и сотни тысяч, и это не говоря о потреблении энергии и других конкурентных преимуществах. А повально уходить в облака большие компании пока не торопятся…
Да и подумайте сами, что такое облако? Это в конечном счете это то же железо, но удаленное и в аренде, то есть проблемы с облаком те же, но лежат на компании которая держит облако и так или иначе будут отражены в стоимости аренды облака, а стоимость аренды будет влиять на затраты.
Таким образом перепись критичных к производительности компонентов вполне может стать экономический выгодной. Насчет «тренда», возможно я несколько преувеличил, но думаю что как минимум явление переписи библиотек с С# на С++ будет достаточно распространенным в будущем.
C# популярнее потомучто его использовани экономический выгодно на ранних стадиях проекта, и да следствием этого является то, что на нем пишут больше относительно небольших проектов поэтому их много.
И, вообще говоря, для сборки C++ под Windows, совсем не обязательно ставить студию. Да и SDK скачиваются с сайта микрософта вполне свободно.
Хороший комментарий, отражающий давольно полно текущую ситуацию.
Я бы добавил еще один момент: кроме задачи стоящей в данный момент неплохо бы учитывать и перспективы приложения (что актуально в долгосрочных проектах и относительно крупных) — может стать что оно попадет например в одну из перечисленных категорий.
Может ли минусующий объяснить, почему он считает что комерческие интересы Микрософта никогда не станут риском для его разработки на C#?
(А относительно исходников .net — пока не увидел ничего кроме того, что и так показывает рефлектор, как думаю многим понятно, наиболее интересная и полезная для переносимостии окружения часть исходников связана с нативной его частью)
Все таки интересно какого именно рынка заняли 100% долю LOB приложения.
Относительно частоты задач где очень желательна быстрая реакция приложения: CAD область, работа с музыкой и видео, веб браузеры, терминалы ввода данных, игры, думаю кстати что если из проектов по созданию дополненой реальности что-то выстрелит — то там определенно реакция будет критична.
Какой процент таких задач в ПО? Возмонж не очень большой, но далеко не нулевой. И если критично избежать ощущения тормознутости приложения, эти задачи придется решать…
Пожалуйста.Про отладку я написал в п.5 что С# тут безоговорочно лучше до тех пор пока не нужно отлаживать Mixed код.
Вообще забавно что единственный чисто позитивный комментарий жестно заминусован.
Да, я знаю что фанаты С# и Microsoft могут болезненно отнестись к некоторым моим рассуждениям и их количество тут не в пользу моих рассуждений, но я пишу не с целью троллить фанатов, а с целью задуматься о перспективах как С++ так и С# и в конечном счете о перспективах наших приложений и нас в свете их развития.
Посмотрим какую долю и какого рынка займут LOB-приложения.
Я не путаю отзывчивость и производительность, я говорю что часто для отзывчивости важна производительность. Ведь существуют операции где нельзя показывать прогрессбар, а нужно сразу реагировать на ввод, например изменением модели или каких-то параметров сцены.
Мне кажется минимум синхронизации возможен только в очень изолированных задачах (чисто математичаских например). Однако даже в чистой математике сложно обойтись без ввода-вывода данных, то есть без коммуникации с другими потоками или ресурсами ввода вывода.
Далее, если говорить о приложениях для пользователя — всегда есть метрика отзывчивости приложения на ввод пользователя. В таких ситуациях многопоточность может больше мешать чем помогать, ведь в пределе для максимально быстрого отклика (в виде результата, а не в виде прогрессбара) лучше иметь один поток с максимальным доступом к ресурсам, чем несколько толкающихся друг с другом потоков.
В целом, я конечно согласен, что по возможности нужно переходить на решения с минимумом синхронизации, но мои опасения в том, что перейти на них можно далеко не везде.
Видимо я сталкивался с ситуациями, где бездумно выбирали С# «патамушта можно писать быстрее», и вообще «все что надо есть».
И этот расчет был верен по своему. Если бы в 2000х годах производительность железа росла бы также как м в 90х, никаких С++ 0x мы бы не увидели. Но реальный рост производительности сильно замедлился…
Время компиляции компенсируется временем в рантайме. В среднем .net приложение примерно на столько дольше запускается насколько быстрее компилируется, относительно соизмеримого нативного приложения.
Отладка и диагностика ошибок, как и писал безусловно лучше в C#, но только пока вы не вышли за managed код.
Остальные фичи в С++ на тоже есть, только в виде библиотек. Например все перечисленное вами легко покрывает boost. Не хотите boost? Есть много других.
Параллельные обработки часто упираются в синхронизацию и доступ к ограниченным ресурсам. И тут становится крайне важным быстро обрабатывать такие ситуации, что требует оптимизации. А поскольку возможности по оптимизации managed кода ниже, вполне возможно что это станет узким местом, избавиться от которого можно только перейдя на unmanaged решения.
Я часто сталкивался с ситуациями, где выбор падал на C#, даже без мысли относительно анализа и мне не кажется такой подход правильным.
С другой стороны, я сталкивался и с ситуациями, где С# проекты портировалисть на С++, хотя ранее выбор безоговорочно падал на C#.
Мне кажется портирование с C# на С++ может стать трендом будущих разработок.
Хотя конечно можете считать это троллингом:) Но я правда думаю что вероятность развития трэнда по переходу с С# на С++ достаточно высока.
Я понимаю, что болшая часть Windows разработчиков аудитории сайта, предпочитают C# в силу тех или иных причин, я и сам недавно его предпочитал.
Но я хотел бы зародить сомнения в том, что C# является столь перспективным и показать некоторую недооцененность
С++, сложившуюся за последние 5-10 лет.
1. Может быть он и не нужен, но его отсутсвие влечет дополнительные требования к разработчикам, что так или иначе удорожает разработку.
2. Это хорошо.
На счет разних задач С++ и С# я соглашусь. Но вопрос в том где проходит линия раздела этих задач?
Ведь широкий круг задач успешно решаем и на С++ и на С# соизмеримым количеством времяни разработчика…
.
Да, возможно в паре-тройке мест вам придется сделать что-то средствами специфичными для определенной платформы. И да, для полноценного приложения вам скорее всего придется на каждой платформе написать некоторый UI, родными для платформы средствами (хотя например можно написать кросплатформенный UI на Qt).
Но вы всегда сможете уйти на другую платформу при необходимости, и это не будет стоит катастрофично дорого.
Математика например слабо завязана ни инфраструктуру. Работа с файлами может сравнительно легко переведена на схожую C++ инфраструктуру. Работа с не-.net библиотеками «сама просится» к такому переводу.
Конечно для .net есть некоторая уникальная инфраструктура, но все-таки многое из .net инфраструктуры имеет адекватные аналоги для С++ (что не всегда верно в обратном направлении)
Я писал про затраты на железо в +500$ на рабочее место, а не про затраты на разработку. Затраты на разработку будут другими, но если разработчиком многократно меньше чем пользователей они вполне могут окупиться.
Да и по поводу переписи продуктов. Продукт может быть дешевле переписать, чем вообще остаться без ниши на рынке.
Я скорее разбираю вопрос минимизации рисков. И если вы будете иметь возможность уйти на другую платформу — вы безусловно минимизируете риски связанные с «неправильным развитием» вашей платформы.
Время запуска будет соизмеримым, только если для инициализации нужно выполнить достаточно много .net кода на старте приложения, это важный момент и я его не отметил. Однако среди множества .net библиотек немало тех, которые так или иначе надо инициализировать на старте приложения.
И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
STL есть в базе, везде и никаких boost-ов для этого не нужно.
Да и подумайте сами, что такое облако? Это в конечном счете это то же железо, но удаленное и в аренде, то есть проблемы с облаком те же, но лежат на компании которая держит облако и так или иначе будут отражены в стоимости аренды облака, а стоимость аренды будет влиять на затраты.
Таким образом перепись критичных к производительности компонентов вполне может стать экономический выгодной. Насчет «тренда», возможно я несколько преувеличил, но думаю что как минимум явление переписи библиотек с С# на С++ будет достаточно распространенным в будущем.
И, вообще говоря, для сборки C++ под Windows, совсем не обязательно ставить студию. Да и SDK скачиваются с сайта микрософта вполне свободно.
Я бы добавил еще один момент: кроме задачи стоящей в данный момент неплохо бы учитывать и перспективы приложения (что актуально в долгосрочных проектах и относительно крупных) — может стать что оно попадет например в одну из перечисленных категорий.
(А относительно исходников .net — пока не увидел ничего кроме того, что и так показывает рефлектор, как думаю многим понятно, наиболее интересная и полезная для переносимостии окружения часть исходников связана с нативной его частью)
Относительно частоты задач где очень желательна быстрая реакция приложения: CAD область, работа с музыкой и видео, веб браузеры, терминалы ввода данных, игры, думаю кстати что если из проектов по созданию дополненой реальности что-то выстрелит — то там определенно реакция будет критична.
Какой процент таких задач в ПО? Возмонж не очень большой, но далеко не нулевой. И если критично избежать ощущения тормознутости приложения, эти задачи придется решать…
Вообще забавно что единственный чисто позитивный комментарий жестно заминусован.
Да, я знаю что фанаты С# и Microsoft могут болезненно отнестись к некоторым моим рассуждениям и их количество тут не в пользу моих рассуждений, но я пишу не с целью троллить фанатов, а с целью задуматься о перспективах как С++ так и С# и в конечном счете о перспективах наших приложений и нас в свете их развития.
Я не путаю отзывчивость и производительность, я говорю что часто для отзывчивости важна производительность. Ведь существуют операции где нельзя показывать прогрессбар, а нужно сразу реагировать на ввод, например изменением модели или каких-то параметров сцены.
Далее, если говорить о приложениях для пользователя — всегда есть метрика отзывчивости приложения на ввод пользователя. В таких ситуациях многопоточность может больше мешать чем помогать, ведь в пределе для максимально быстрого отклика (в виде результата, а не в виде прогрессбара) лучше иметь один поток с максимальным доступом к ресурсам, чем несколько толкающихся друг с другом потоков.
В целом, я конечно согласен, что по возможности нужно переходить на решения с минимумом синхронизации, но мои опасения в том, что перейти на них можно далеко не везде.
И этот расчет был верен по своему. Если бы в 2000х годах производительность железа росла бы также как м в 90х, никаких С++ 0x мы бы не увидели. Но реальный рост производительности сильно замедлился…
Отладка и диагностика ошибок, как и писал безусловно лучше в C#, но только пока вы не вышли за managed код.
Остальные фичи в С++ на тоже есть, только в виде библиотек. Например все перечисленное вами легко покрывает boost. Не хотите boost? Есть много других.
С другой стороны, я сталкивался и с ситуациями, где С# проекты портировалисть на С++, хотя ранее выбор безоговорочно падал на C#.
Мне кажется портирование с C# на С++ может стать трендом будущих разработок.
Хотя конечно можете считать это троллингом:) Но я правда думаю что вероятность развития трэнда по переходу с С# на С++ достаточно высока.
Но я хотел бы зародить сомнения в том, что C# является столь перспективным и показать некоторую недооцененность
С++, сложившуюся за последние 5-10 лет.
2. Это хорошо.
На счет разних задач С++ и С# я соглашусь. Но вопрос в том где проходит линия раздела этих задач?
Ведь широкий круг задач успешно решаем и на С++ и на С# соизмеримым количеством времяни разработчика…