Как правило, задачи стоят несколько сложнее чем сортировка мегабайта во время чтения.
Да и мегабайт на диске как правило архивированный тем или иным способом, поэтому развернутый в объектную модель может занимать в десятки, а то в сотню раз больше памяти чем занимал на диске.
Типичными задачами будут распокавать, так или иначе интерпретировать сожержимое, собрать из этого содержимого объекты, построить индексы на них или связать их тем или иным способом. Непосредственно чтение файла из этого занимает малую долю.
Это страховка. Я предлагаю минимизировать риск закрытия проекта из-за изменившейся ситуации на рынке.
Возможно данная стратегия мало полезна в проектах до года, но в проектах время развития которых 3-5 лет и более, думаю стратегия впролне оправдана.
Я бы наверное поставил на то, что раньше в стандарт С++ добавят недостающие фичи.
Проблема «некросплатформенности С#» мне кажется не столько технической, сколько системной и отчасти даже политической.
Вот например, зачем Apple будет поддерживать .net framework?
Или зачем Google будет добавлять поддержку .net framework в Android?
Зачем разработчикам ядра линукс протаскивать оптимизацию под .net framework?
Отдельно стоит задаться вопросом почему Microsoft за 15 лет существования .net framework не выпустила не одной его официальной версии под другие платформы?
При этом С++ компилятор для всех этих платформ был всегда, он есть даже для какогонибудь Raspberry Pi и прочих встраиваемых решений, и скорее всего весьма оптимизированный.
Борьба всетаки не с языком, а с некоторыми библиотеками, далеко не все из которых обязательно использовать.
Зачем с ними бороться? Ради производительности, ради кроссплатформенности, ради независимости от фреймворка.
Конечно здесь и сейчас прикладную задачу быстрее решить на C#, и если не думать на перспективу, то это вполне разумный выбор в большинстве проектов которые нужно сдать и забыть.
Но если попробовать спрогнозировать развитие отрасли, то возможно ценность независимости от платформы и производительности окажется выше, чем быстрое решение прикладной задачи?
Редкое использование 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 лет, а любая графика чуть потяжелее как писалась на С++ так и пишется, врядли это иррационально.
Я бы все-таки не стал драматизировать и называть это ужасом:)
Конечно это неприятный момент, но формальный и вполне решаемый.
Если нужно — не так и сложно привести строку к подходящему типу, тем более, что делать это придется только работая со старыми библиотеками.
Да, решено использовать несколько библиотек с разными базовыми типами — их сопряжение достаточно неприятная вещь, и как я писал это недостаток выбора С++.
Стандартные итераторы и строки это строки STL.
Для стандартной многопоточности, есть например en.cppreference.com/w/cpp/thread,
Вообще например тут:
en.cppreference.com/w/cpp
Описаны основные стандартные библиотеки и типы, единственное что для поддержки части из них нужна поддержка С++11 компилятором.
Язык тянет за собой некую инфраструктуру в виде библиотек.
И если рассмотреть mono, то насколько я понимаю инфраструктура будет заметно менее полноценная, чем та что идет с .net под Windows. Далее вопрос сводится к тому, насколько вашему приложению нужна Windows-специфичная инфраструктура.
С С++-же такого перекоса в инфраструктуре между платформами нет.
Это скорее вопрос к тому как написана конкретная библиотека.
В своем же проекте можно использовать те библиотеки и итераторы что устраивают вас.
Совсем не обязательно использовать свои строки если есть строки STL и уж точно плохая идея делать свои строки совсем не совместимыми со стандартными.
Я согласен с тем, что подключив произвольную библиотеку есть шансы на то, что там будут использоваться не стандартные строки и итераторы(об этом я писал в статье в соответствующем разделе), но это вопрос к тем, кто писал эти библиотеки и к истории, в своих же проектах вполне реально придерживаться стандартов.
Хостинг WPF для сцены в Автокаде не используется. Максимум для превью в тултипов, но это вряд-ли можно назвать хостингом Direct3D сцен.
Насчет игр, пока не видел тяжелых 3D игр на C#, все(что я знаю) топовые 3D игры — исключительно С++. Если у вас есть примеры релизов чего-нибудь уровня GTA4,5\Fallout\Battlefield на C# — очень хотелось бы увидеть, напишите пожалуйста.
Десктопные приложения на JS я бы вряд-ли ожидал. Я не спорю, что например на связке HTML+JS и правильном подходе можно достичь производительности не многим меньше чем на связке WPF + C#, но все-таки для interoperability JS мне кажется плохой вариант, да и инфраструктура JS библиотек недотягивает ни до С# ни до С++ в области за пределами написания веб клиентов.
Спасибо, понятно) Это видимо достаточно широкий термин.
Тогда возвращаясь к вопросу о том «минимум синхронизации» используется в LOB приложениях.
Теперь, наконец поняв что вы имели ввиду,- думаю что в любых приложениях пытаются использовать «минимум синхронизации» и это вполне естественно пытаться ее избегать, просто не всегда возможно.
Кстати, особенно неприятны ситуации где синхронизацию избегают там, где делать этого нельзя, тогда проблемы начинают вылезать случайным образом в зависимости от производительности железа и сетевых задержек. (это чуть-чуть офтопик, но наболело)
Я наверное не правильно понял, что вы имеете ввиду под LOB-приложениями. Мне показалось что вы имели ввиду какието специфичные приложения построенные на специфичных технологиях.Я никогда раньше не слышал этот термин, хотя знаком со всеми остальными перечисленными вами терминами.
Правильно ли я понимаю, что это термин чисто маркетинговый, и не связан с какими-то конкретными решениями или технологиями.
Расскажите что именно он значит?
Это просто «в любые приложениях для бизнеса» или что-то другое?
При раскладке файла со ссылками между сущностными записанными в нем, часто нужно выполнять что-то вроде обхода сети.
Это можно делать в потоках, но далеко не всегда можно спланировать равномерную загрузку потоков и избежать необходимости синхронизации, ведь в конце концов прочитанные данные нужно будет как-то связать между собой, и если мы хотим быстрые связи — то прямыми ссылками.
Да и если все это удастся сделать, на потоках С++ параллельное решение все-равно будет работать быстрее…
Autocad перепилена на WPF
Чуть точнее — на WPF в нем добавлен рибон и кнопка «пуск» + несколько _новых_ диалогов написаны на WPF. Больше WPF там нет. Примечательно, что далеко не все новые диалоги с 2009 года были построены на WPF. И разумеется к рендерингу сцены WPF не причастен вообще.
WPF в Autocad — да это реальность, но там есть и Windows Forms, и MFC даже на html+javascript некоторые контролы написаны.
Qt в виндовом Autocad я не замечал, но возможно они работают над тем чтобы уйти от зоопарка Microsoft контролов, кто знает…
Так или иначе, под MacOS есть своя версия Autocad и она написана не на UI от Microsoft.
Я несколько знаком с приложениями для бизнеса, но среди известных мне бизнесов, нет использующих LOB приложения. Из этого могу сделать вывод, что далеко не любому бизнесу они нужны.
Можете охарактеризовать сегмент, в который позиционируются LOB приложения? Есть ли примеры внедрений? Было-бы интересно узнать…
И зачем переписывать математическую библиотеку с C# на C++ — на плюсах своих библиотек мало
Имеется в виду случай, если это ваша библиотека, которую разработали вы для ваших расчетов.
Весь «новый» I/O в .net сделан с учетом TPL
Проблема не в I\O, а в быстрой раскладке файла в тот вид с которым вы сможете работать.
Да и мегабайт на диске как правило архивированный тем или иным способом, поэтому развернутый в объектную модель может занимать в десятки, а то в сотню раз больше памяти чем занимал на диске.
Типичными задачами будут распокавать, так или иначе интерпретировать сожержимое, собрать из этого содержимого объекты, построить индексы на них или связать их тем или иным способом. Непосредственно чтение файла из этого занимает малую долю.
Возможно данная стратегия мало полезна в проектах до года, но в проектах время развития которых 3-5 лет и более, думаю стратегия впролне оправдана.
Проблема «некросплатформенности С#» мне кажется не столько технической, сколько системной и отчасти даже политической.
Вот например, зачем Apple будет поддерживать .net framework?
Или зачем Google будет добавлять поддержку .net framework в Android?
Зачем разработчикам ядра линукс протаскивать оптимизацию под .net framework?
Отдельно стоит задаться вопросом почему Microsoft за 15 лет существования .net framework не выпустила не одной его официальной версии под другие платформы?
При этом С++ компилятор для всех этих платформ был всегда, он есть даже для какогонибудь Raspberry Pi и прочих встраиваемых решений, и скорее всего весьма оптимизированный.
Зачем с ними бороться? Ради производительности, ради кроссплатформенности, ради независимости от фреймворка.
Конечно здесь и сейчас прикладную задачу быстрее решить на C#, и если не думать на перспективу, то это вполне разумный выбор в большинстве проектов которые нужно сдать и забыть.
Но если попробовать спрогнозировать развитие отрасли, то возможно ценность независимости от платформы и производительности окажется выше, чем быстрое решение прикладной задачи?
Это тоже правда, но знаете, мне тут как-то попалась библиотека для чтения и рендера 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 лет, а любая графика чуть потяжелее как писалась на С++ так и пишется, врядли это иррационально.
Конечно это неприятный момент, но формальный и вполне решаемый.
Если нужно — не так и сложно привести строку к подходящему типу, тем более, что делать это придется только работая со старыми библиотеками.
Стандартные итераторы и строки это строки STL.
Для стандартной многопоточности, есть например en.cppreference.com/w/cpp/thread,
Вообще например тут:
en.cppreference.com/w/cpp
Описаны основные стандартные библиотеки и типы, единственное что для поддержки части из них нужна поддержка С++11 компилятором.
Под тяжестью конечно рендер в первую очередь имею ввиду.
Atom, VS Code нативные приложения в Win на XAML+JS — не встречался с этим. не могу судить, если есть примеры приложений обещаю посмотреть.
И если рассмотреть mono, то насколько я понимаю инфраструктура будет заметно менее полноценная, чем та что идет с .net под Windows. Далее вопрос сводится к тому, насколько вашему приложению нужна Windows-специфичная инфраструктура.
С С++-же такого перекоса в инфраструктуре между платформами нет.
В своем же проекте можно использовать те библиотеки и итераторы что устраивают вас.
Совсем не обязательно использовать свои строки если есть строки STL и уж точно плохая идея делать свои строки совсем не совместимыми со стандартными.
Я согласен с тем, что подключив произвольную библиотеку есть шансы на то, что там будут использоваться не стандартные строки и итераторы(об этом я писал в статье в соответствующем разделе), но это вопрос к тем, кто писал эти библиотеки и к истории, в своих же проектах вполне реально придерживаться стандартов.
Насчет игр, пока не видел тяжелых 3D игр на C#, все(что я знаю) топовые 3D игры — исключительно С++. Если у вас есть примеры релизов чего-нибудь уровня GTA4,5\Fallout\Battlefield на C# — очень хотелось бы увидеть, напишите пожалуйста.
Десктопные приложения на JS я бы вряд-ли ожидал. Я не спорю, что например на связке HTML+JS и правильном подходе можно достичь производительности не многим меньше чем на связке WPF + C#, но все-таки для interoperability JS мне кажется плохой вариант, да и инфраструктура JS библиотек недотягивает ни до С# ни до С++ в области за пределами написания веб клиентов.
Тогда возвращаясь к вопросу о том «минимум синхронизации» используется в LOB приложениях.
Теперь, наконец поняв что вы имели ввиду,- думаю что в любых приложениях пытаются использовать «минимум синхронизации» и это вполне естественно пытаться ее избегать, просто не всегда возможно.
Кстати, особенно неприятны ситуации где синхронизацию избегают там, где делать этого нельзя, тогда проблемы начинают вылезать случайным образом в зависимости от производительности железа и сетевых задержек. (это чуть-чуть офтопик, но наболело)
Поэтому и пишу что с файлами часто проблема в производительности обработки, а не в самом I\O.
Правильно ли я понимаю, что это термин чисто маркетинговый, и не связан с какими-то конкретными решениями или технологиями.
Расскажите что именно он значит?
Это просто «в любые приложениях для бизнеса» или что-то другое?
Это можно делать в потоках, но далеко не всегда можно спланировать равномерную загрузку потоков и избежать необходимости синхронизации, ведь в конце концов прочитанные данные нужно будет как-то связать между собой, и если мы хотим быстрые связи — то прямыми ссылками.
Да и если все это удастся сделать, на потоках С++ параллельное решение все-равно будет работать быстрее…
Чуть точнее — на WPF в нем добавлен рибон и кнопка «пуск» + несколько _новых_ диалогов написаны на WPF. Больше WPF там нет. Примечательно, что далеко не все новые диалоги с 2009 года были построены на WPF. И разумеется к рендерингу сцены WPF не причастен вообще.
Qt в виндовом Autocad я не замечал, но возможно они работают над тем чтобы уйти от зоопарка Microsoft контролов, кто знает…
Так или иначе, под MacOS есть своя версия Autocad и она написана не на UI от Microsoft.
Можете охарактеризовать сегмент, в который позиционируются LOB приложения? Есть ли примеры внедрений? Было-бы интересно узнать…
Имеется в виду случай, если это ваша библиотека, которую разработали вы для ваших расчетов.
Весь «новый» I/O в .net сделан с учетом TPL
Проблема не в I\O, а в быстрой раскладке файла в тот вид с которым вы сможете работать.