Комментарии 412
На C++ ты пишешь код, который быстро работает.
Достаточно спорно, вернее это совсем не так. Подобные утверждения создают путаницу и только вредят C++, да и объективности как таковой. Правильно говорить, что на C++ ты можешь написать код, который быстро работает. А вот на дотнете не всегда. Дизайн языка/язык в общем виде, как и уровень его пользователей, определяют тот набор возможностей(и от языка, который даёт возможности. И от программиста, который хочет и может использовать). И уже это вкупе даёт ту самую производительность.
Если программист не знает как пользоваться возможностями, либо знает, а язык не позволяет — ничего не получится. И C++(современный) хоть и даёт практически безграничные возможности(относительно, конечно), но первую часть тезиса никто не отменял.
Сожалею, что я не смог донести, насколько сейчас всё хорошо и быстро развивается, и насколько современный C++ отличается от того, что вы, судя по всему, видели. Понятно, что есть и проблемы тоже.
И это чистая правда. Причём это сложно донести не только людям со стороны, но и множеству программистов на самом C++.
мда… утверждать что Шарп лучше потому что на нём мордочки можно быстрее рисовать чем на тролтеховской куте и они красивее получаются… я в 2005-2010 гг. рисовал в борландовском билдере такие, что и сейчас не всегда получаются. с ворованными девелоперекспрессовскими компонентами, с наборами джедивцл, фастрепортом это было просто, быстро и красиво. но как можно приравнивать мордочки и качество языка?
Ну, честно говоря, если уж писать "наскоро" GUI на Qt, то я бы стал писать его на Qt Quick, а не на плюсовых виджетах, а к этому GUI на Qt Quick уже подключать какую-то "рабочую" логику уже на плюсах, благо делается это элементарно. У меня был небольшой опыт написания гуя и на C# (WPF+XAML), и мне Qt Quick понравился больше.
Ну, спорное заявление..)) Ооочень спорное.
Ну, я про себя пишу. Для меня, например, вопрос возможности переиспользования одного и того же кода и на десктопе и на мобилках довольно важен. Qt мне такую возможность в значительной степени обеспечивает и на Windows, и на Linux с MacOS, и на почившем в бозе Windows Phone, и на Android с iOS. WPF — это только платформы MS, ну по крайней мере в свое время так было, может, сейчас с этим получше, но в одном из соседних обсуждений мне говорили, что лучше с этим не стало.
Какой-нибудь Xamarin для вас тоже не вариант?
P.S.Ну и по хорошему надо будет посмотреть что в плане кроссплатформа нам реально сможет дать .Net 5.0
Ну голый Xamarin, насколько я помню, это просто обёртка из классов поверх возможностей целевой платформы, то есть, условно, для Android будет один код, для iOS — другой. Xamarin Forms вроде как облегчает этот вопрос, но… только для Android, iOS и UWP, насколько я понимаю. Linux с MacOS в пролёте.
Ну если вы вот прямо под все ОС пишите, то тогда C# действительно менее удобен. Как минимум на данный момент уж точно.
Если говорить о кроссплатформенности, то корректно говорить о .NET Core, а он работает и на Linux, и на MacOS. Но стоит упомянуть что пока кроссплатформенный WPF Microsoft не завезли (только для Windows).
Но если сильно хочется всё таки иметь кроссплатформенный UI (Win, Linux, MacOS), на C#, да ещё и XAML-like синтаксисом формочек, то есть, уже какое-то время, AvaloniaUI.
А если хочется чтобы основная кодовая база была единой для всех платформ, что для .NET Core, что для Xamarin, то для этого прямая дорога в .NET Standard library. Пишите библиотеку, и можете её подключить и использовать в любой .NET среде — NET Framework, NET Core, Xamarin, Mono (а вместе с тем и Unity3D, который может работать хоть на консоли). Таким образом C#'ом можно покрыть практически все платформы (за исключением конечно же Embedded), при этом в моих руках всё удобство и гибкость С# и тд.
Практически все платформы, это полторы? ))))
Мне как бы не особо интересно «написание библиотек», мне интересна такая разработка продукта, в процессе которой я мог бы переиспользовать как можно больше ВСЕГО кода продукта, в том числе UI (в идеале 100%) при переводе его с платформы на платформу. Авалонию я не пробовал, но вот здесь мне писали, что она очень сырая, да и поддержка мобильных платформ там, насколько я вижу, числится как экспериментальная.
Простите, а куда вы собственно пишете всю бизнес-логику без библиотек? Прям в main()? :)
Если говорить про переиспользование кода, то пишется всё под .NET Standard, и переиспользуйте где хотите. По UI, AvaloniaUI покрывает десктоп (один UI на все платформы), и Xamarin Forms покрывает мобильные платформы (опять же — один UI для Android, iOS, UWP).
В итоге мы имеем общий код, спокойно переиспользуемый на любой платформе, плюс переиспользуемый UI (отдельно для десктопа, отдельно для мобильных платформ).
Касательно авалонии в частности, то не видел чтобы её рассматривали для мобильных платформ ибо позиционируется этот фреймворк как замена WPF под .NET Core. И для мобильных платформ, как я уже упоминал, есть Xamarin Forms (один проект работает для всех платформ). Насчёт «сырости» я не хочу судить, так как проект в котором я его использовал, в плане UI, был довольно ненагруженный, и текущего уровня авалонии хватает за глаза — и графики построить, и рендерить картинки любой сложности, и при этом не задумываться про платформу на которой это всё собирается.
Мне честно даже очень интересно какие use-case'ы пока не может покрыть C#. Как уже говорилось это разработка под Embedded платформы (сюда же микроконтроллеры), и ещё High-Performance calculations. Есть ещё какие-то варианты?
Если говорить про переиспользование кода, то пишется всё под .NET Standard, и переиспользуйте где хотите. По UI, AvaloniaUI покрывает десктоп (один UI на все платформы), и Xamarin Forms покрывает мобильные платформы (опять же — один UI для Android, iOS, UWP).
В итоге мы имеем общий код, спокойно переиспользуемый на любой платформе, плюс переиспользуемый UI (отдельно для десктопа, отдельно для мобильных платформ).
Касательно авалонии в частности, то не видел чтобы её рассматривали для мобильных платформ ибо позиционируется этот фреймворк как замена WPF под .NET Core. И для мобильных платформ, как я уже упоминал, есть Xamarin Forms (один проект работает для всех платформ). Насчёт «сырости» я не хочу судить, так как проект в котором я его использовал, в плане UI, был довольно ненагруженный, и текущего уровня авалонии хватает за глаза — и графики построить, и рендерить картинки любой сложности, и при этом не задумываться про платформу на которой это всё собирается.
Мне честно даже очень интересно какие use-case'ы пока не может покрыть C#. Как уже говорилось это разработка под Embedded платформы (сюда же микроконтроллеры), и ещё High-Performance calculations. Есть ещё какие-то варианты?
Ну вот я ниже в качестве примера привел ссылку на продукт, который сейчас написан на C++ и Qt, и доступен под Windows, Linux, MacOS, под которые он собирается ну практически со 100% переиспользованием кодовой базы, ну и плюс имеет «облегченный» вариант для мобилок (Android, iOS) на тех же технологиях, которые тоже шарят между собой кодовую базу. Возможно, конечно, это у вас пойдет по графе «high performance calculations» (а их там есть, это да).
Интересный продукт, мы чем-то похожим в университете занимались, с моделями сердца работали и ещё какими-то органами (их срезы и модели в виде облаков точек).
Касательно тех критериев что вы описали в том комментарии, я считаю что это можно сделать на C#, и общую кодовую базу (.NET Standard), и UI хоть под десктоп и под мобилки (AvaloniUI + XamarinForms), при этом ни на шаг не уходя от C#.
Тут я вижу только 2 подводных камня:
1. HPC — а для предложенного вами приложения это, я считаю, самый критичный момент
2. Движок для рендера
Насчёт первого, я думаю бОльшую часть можно покрыть с использованием ILGPU (буквально веткой ниже пару слов написал об этом). Не думаю что можно абсолютно всё покрыть, всё таки в шарпе ещё не всё радужно с векторизацией как хотелось бы.
Для второй проблемы, есть два варианта. Это использование OpenGL(OpenTK) или любой другой плюсовой библиотеки для рендеринга, ну или честный .NET вариант (таких примеров правда не видел). То бишь данный момент нас так или иначе тянет к решениям на плюсах.
Либо, использование Unity3D в качестве UI. При этом данный вариант решает проблему как UI кроссплатформенности вообще (один 'UI' под все платформы), так и вычислений (используя Compute Shaders, который тоже в итоге кроссплатформенный и кроссжелезный).
Но боюсь что Unity не подходит для «кровавого enterprise'а», хотя если сильно захотеть…
Звучит такое решение конечно самоуверенно, да и я не знаю какие в вашем продукте есть подводные камни, какая архитектура и тд. Но если отвечать на вопрос что можно ли такое сделать на C#, я придерживаюсь мнения что да, это возможно.
Касательно тех критериев что вы описали в том комментарии, я считаю что это можно сделать на C#, и общую кодовую базу (.NET Standard), и UI хоть под десктоп и под мобилки (AvaloniUI + XamarinForms), при этом ни на шаг не уходя от C#.
Тут я вижу только 2 подводных камня:
1. HPC — а для предложенного вами приложения это, я считаю, самый критичный момент
2. Движок для рендера
Насчёт первого, я думаю бОльшую часть можно покрыть с использованием ILGPU (буквально веткой ниже пару слов написал об этом). Не думаю что можно абсолютно всё покрыть, всё таки в шарпе ещё не всё радужно с векторизацией как хотелось бы.
Для второй проблемы, есть два варианта. Это использование OpenGL(OpenTK) или любой другой плюсовой библиотеки для рендеринга, ну или честный .NET вариант (таких примеров правда не видел). То бишь данный момент нас так или иначе тянет к решениям на плюсах.
Либо, использование Unity3D в качестве UI. При этом данный вариант решает проблему как UI кроссплатформенности вообще (один 'UI' под все платформы), так и вычислений (используя Compute Shaders, который тоже в итоге кроссплатформенный и кроссжелезный).
Но боюсь что Unity не подходит для «кровавого enterprise'а», хотя если сильно захотеть…
Звучит такое решение конечно самоуверенно, да и я не знаю какие в вашем продукте есть подводные камни, какая архитектура и тд. Но если отвечать на вопрос что можно ли такое сделать на C#, я придерживаюсь мнения что да, это возможно.
Про ILGPU я прочел, да. Но, насколько я вижу, это CUDA only, а значит, только NVIDIA. Там, вроде, стоит красная галочка напротив AMD, но красная — это значит «когда-то в будущем». Ну и там не только и не столько рендеринг, сколько именно реально тяжелые вычисления при всяких там автоматических сегментациях, например, для чего и нужны собственно CUDA и OpenCL, а также при отсутствии нужных карточек это должно делаться и на CPU, причем как можно более эффективно. Не знаю, как у C# с этим. И насколько там будут эффективны compute shaders у unity — тоже вопрос. Ну ОК.
«А вот на дотнете не всегда.»
— и как выглядит это «не всегда», мне интересно?
У нас есть свой 3Д рендер, куча математики, процессинг высокополигональной геометрии и всё, таки, быстро работает. У мелко-мягких bing. Единственное где возникают проблемы это c gpu. Тут без плюсов пока сложно, а гибридайзером (или чем-то подобным) пользоваться не особо хочется.
А вообще, это глупый спор… всегда использовались параллельно и никто не страдал…
— и как выглядит это «не всегда», мне интересно?
У нас есть свой 3Д рендер, куча математики, процессинг высокополигональной геометрии и всё, таки, быстро работает. У мелко-мягких bing. Единственное где возникают проблемы это c gpu. Тут без плюсов пока сложно, а гибридайзером (или чем-то подобным) пользоваться не особо хочется.
А вообще, это глупый спор… всегда использовались параллельно и никто не страдал…
К слову о GPU на С# и необходимость в С++. Есть такая здоровская библиотека для .NET Core, называется ILGPU. Она позволяет писать код, прям на С#, который потом выполняется на GPU (либо на CPU если карта не поддерживается), при этом без использования С++ и без необходимости знать синтаксис шейдеров.
Конечно же, имеются ограничения и недочёты. Нельзя использовать ссылочные типы данных (ни классы, ни массивы), только структуры и встроенные в ILGPU типы. Последний раз когда я работал с этой библиотекой, там была поддержка только карт NVidia, ну и дебаг возможен был только при запуске кода на CPU либо танцы с бубнами в профилировщике от NVidia.
Так что стоит сказать что и в этом направлении C# двигается (хоть и силами скромного комьюнити).
P.S. очень уж порадовало то, что эта штука в итоге кроссплатформенная, и оооочень много времени сэкономило, так как данные были большие (гиперспектральные изображения на 5--700 МБ), и некоторые расчёты могли занимать 40 минут на CPU (против 3-4 секунд на GPU, и откуда взялся этот выигрыш в 600 раз я не осмелюсь объяснять).
Конечно же, имеются ограничения и недочёты. Нельзя использовать ссылочные типы данных (ни классы, ни массивы), только структуры и встроенные в ILGPU типы. Последний раз когда я работал с этой библиотекой, там была поддержка только карт NVidia, ну и дебаг возможен был только при запуске кода на CPU либо танцы с бубнами в профилировщике от NVidia.
Так что стоит сказать что и в этом направлении C# двигается (хоть и силами скромного комьюнити).
P.S. очень уж порадовало то, что эта штука в итоге кроссплатформенная, и оооочень много времени сэкономило, так как данные были большие (гиперспектральные изображения на 5--700 МБ), и некоторые расчёты могли занимать 40 минут на CPU (против 3-4 секунд на GPU, и откуда взялся этот выигрыш в 600 раз я не осмелюсь объяснять).
Когда говорят о кроссплатформенности, то нет смысла рассматривать сферический язык в вакууме, потому что в современном мире мало кому нужен язык сам по себе, без фреймворков, библиотек и среды разработки.
Попробуйте-ка закодить, собрать и запустить бинарник с WPF-окошком, не выходя из Linux.
А то так и Objective-C можно считать кроссплатформенным, только за пределами Apple-платформ он неюзабелен.
Попробуйте-ка закодить, собрать и запустить бинарник с WPF-окошком, не выходя из Linux.
А то так и Objective-C можно считать кроссплатформенным, только за пределами Apple-платформ он неюзабелен.
Вы выбрали изначально не кроссплатформенный пример. Точно так же и на плюсах нельзя закодить какое-нибудь MFC-окошко, не выходя из Linux (что, имхо, не говорит в пользу MFC, но вряд ли годится в качестве аргумента против плюсов).
А давайте теперь рассмотрим кроссплатформенный пример. На плюсах мы возьмём портабельную технологию Qt, а на C# — портабельную технологию Avalonia. И… ну, у нас выйдет закодить бинарник с окошком, не выходя из Linux. С некоторыми приседаниями мы его тут же заодно скомпилируем под Windows и macOS.
Что дальше? Какие выводы можно сделать, и нужно ли их делать?
xamarin
avalonia ui
сейчас почти любой язык предложит целую кучу технологий
которые предложат кроссплатформенность во всех возможных сферах
avalonia ui
сейчас почти любой язык предложит целую кучу технологий
которые предложат кроссплатформенность во всех возможных сферах
Почему же тогда даже сама MS предпочитает писать кроссплатформенные приложения (Skype, Visual Code) на Electron? Наверное, с кроссплатформенностью .NET не всё так здорово?
С кроссплатформенностью GUI там всё совсем плохо. То есть формально окошки и кнопки можно сделать одной библиотекой, но товарного вида под всеми тремя системами (Win, Linux, Mac) добиться очень тяжело.
Насчет VSCode Eleсtron был обоснованным выбором, ибо прежде всего оно затачивалось под web разработку на js/ts. Eleсtron позволил быстро нарастить базу плагинов, так как стало просто интегрировать существующие инструменты из npm.
В том же sublime есть множество плагинов, которые являются лишь python оберткой над v8 для использования возможностей js библиотек.
Да и в целом VSCode работает достаточно шустро, пока не открывать в нем файлы с очень длинными строками.
Ну а Skype… Просто представим, что оно закрылось и больше не существует.
В том же sublime есть множество плагинов, которые являются лишь python оберткой над v8 для использования возможностей js библиотек.
Да и в целом VSCode работает достаточно шустро, пока не открывать в нем файлы с очень длинными строками.
Ну а Skype… Просто представим, что оно закрылось и больше не существует.
Потому что сначала они разрабатывали вебовский редактор кода Monaco Editor для VS Online, а потом оказалось, что его можно упаковать в виде десктопного приложения...
Весь спор похож на спор про автомобили с автоматической и механической коробками передач :) Нет ничего плохого в том, чтобы выбрать для комфортной городской езды в плотном потоке автомобиль с автоматической коробкой передач. Да больше расход топлива (читай ресурсов компьютера), да некоторая потеря контроля за поведением автомобиля (читай сборщик мусора), но в свою задачу решает и позволяет совершать более безопасные манёвры. Но если уж ты участвуешь в гонке, в которой трасса известна (читай знаешь какое железо), и фиксированное количество автомобилей (известные условия задачи), то уж придется сесть за механику, чтобы выжать из автомобиля максимум :)
При этом никто не мешает, ессно, и по городу ехать на механике и на гонке использовать затюненный автомат :)
Я в целом согласен с вашим комментарием, но думаю вот что.
Помимо описанных вами различий, есть ещё много нюансов вроде «сколько стоит ремонт разных коробок передач». И люди могут заранее о таких нюансах вообще не задумываться, а потом говорить «чёрт, для меня это приоритетно, знал бы — сделал бы другой выбор».
Поэтому на такие нюансы полезно проливать свет. А подобные споры как раз их и проливают: «вот сломается твоя автоматика — разоришься». Разумеется, из этого не следует «механика всегда лучше», но это ценная информация. И читать такие споры, по-моему, стоит не как «что лучше», а как полезную информацию о различиях.
Помимо описанных вами различий, есть ещё много нюансов вроде «сколько стоит ремонт разных коробок передач». И люди могут заранее о таких нюансах вообще не задумываться, а потом говорить «чёрт, для меня это приоритетно, знал бы — сделал бы другой выбор».
Поэтому на такие нюансы полезно проливать свет. А подобные споры как раз их и проливают: «вот сломается твоя автоматика — разоришься». Разумеется, из этого не следует «механика всегда лучше», но это ценная информация. И читать такие споры, по-моему, стоит не как «что лучше», а как полезную информацию о различиях.
Для быстрой реализации сложных концепций ИМХО Ruby/Python предпочтительней — это я к тому, что в большом проекте и 2 языков мало
Анатолий: Мне кажется, что C# движется в сторону плюсов, он пытается отвоевать их рынок. А вот плюсы уже не движутся никуда.
Сергей: Откуда это? Что значит «плюсы не движутся никуда»?
После такого выпада, конструктивный диалог закончился. Да и до этого момента выглядел как просто троллирование плюсов.
Я еще ни разу не видел конструктивных бесед ЯзыкХ вс ЯзыкУ :)
Были такие беседы на моей памяти. Но в целом я не понимаю зачем ибо выбор языка должен исходить из условий стоящей задачи и доступных возможностей.
Да почему же. На мой взгляд это совсем не исключено и зависит скорее от того кто спорит.
Правда я бы сказал что и сравнивать наверное надо не любые "сферические языки в вакууме", а языки более-менее "эквивалентные" в контексте какой-то конкретной задачи. Тогда вполне себе конструктивные дискуссии часто получаются.
Полезно ещё и знание, а на каком языке X сделан сам язык Y
Часть вопросов, тогда, сами отвалятся. :)
Часть вопросов, тогда, сами отвалятся. :)
Мне понравилось в графике расположение GO.
Довольно приятно расположен.
Довольно приятно расположен.
Дмитрий: Это очередная проблема. Есть у нас подход типа «модули». И я бы со своей колокольни сказал: ребята, мы переходим на модули и макросы больше не будут поддерживаться вообще никак. Более того, давайте со следующей версии, если включаешь модули, то отключаются макросы глобально везде. Вот это был бы мой подход. К сожалению, никто о таких кардинальных шагах не думает.
Сергей: Почему, о них думают. Но их не поддерживает комитет. Наверное, есть причины. Но я тебе предлагают сделать proposal. Это же открытое всё.
Дмитрий: Мы же понимаем, что это обречённый proposal. И обречён он по той причине, что никто не хочет внезапно сказать «надо переписывать»: допустим, в STL используются макросы, надо от них избавиться. Нужно, чтобы кто-то сделал волевое решение, сел и избавился от всех макросов.
Бгыгы. Объясняю почему не трогают макросы и почему proparsal обречён: Как мне подключить
P.S. «Магию» в Boost тоже стоит посмотреть ибо это фактически кусок STL feature или extented — как угодно можно назвать, но без Boost тяжко, а подключается он просто.
Как мне генерировать в коде имена переменных и функций? Где статическая рефлексия?
Всё это есть тут:
cppx.godbolt.org
Можно собрать себе среду.
Я попробовал, мне понравилось.
Бгыгы. Объясняю почему не трогают макросы и почему proparsal обречён: Как мне подключить модуль хидер в зависимости от платформы под которую это собирается?Точно так же, как это делается в тех языках, где модулей нет. И если вам где-то не хватает метаданных, напомню что это одна из проблем, которые модули могут теоретически решить. Conditional compilation на базе модулей — это плохо, помимо всего прочего это превращает код в нечитаемую кашу из
#ifdefКак мне генерировать в коде имена переменных и функций?Вы сейчас снова жалуетесь на тот функционал который, помимо того что он нишевый, не решается только путем макросов. В C#, например, можно автоматически присвоить переменной значение, равное названию вызываемого метода. Это делается на уровне кода, а не на уровне макросов. То что метаданные еще не подвезли это просто еще одна проблема, которую нужно решать вместо того чтобы натягивать сову на глобус.
“Магию” в Boost тоже стоит посмотреть ибо это фактически кусок STL feature или extented — как угодно можно назвать, но без Boost тяжко, а подключается он просто.Любая “магия” (например, использование Boost PP) плохо читается и понимается, что приводит к вполне очевидным maintenance costs.
Вы сейчас снова жалуетесь на тот функционал который, помимо того что он нишевый, не решается только путем макросов.
То что метаданные еще не подвезли это просто еще одна проблема, которую нужно решать вместо того чтобы натягивать сову на глобус.
Ну да, всё так, а с учётом факта что в плюсы сейчас вливают успешно появившееся лет 10 назад, а кое что появилось и раньше, либо в других языках либо в куче внутренних pragma от компиляторов, то трогать макросы
Кстати говоря constexpr выражения уже кое где позволили заменить макросы нормальным кодом, это уже очень хорошо и это правильное движение.
Весь диалог типичный троллинг.
В мусор егоб
> в плюсах сейчас занимаются вещами, которые должны были появиться 10 лет назад.
Я бы сказал 20 лет назад. Когда-то работал в ЦЕРНе, в команде ROOT (https://root.cern.ch/).
Уже тогда у нас был C++ интерпретатор, Reflection, всевозможные контейнеры, тесный контакт с Страустрапом. Уже тогда обсуждалось, как добавить все эти фичи в стандарт C++.
Но, воз и ныне там.
Сейчас для «низкоуровневого» программирования (видео, DirectShow, MF, COM, железки) пользую C++. Для всего остального — C#.
Мои любимые продукты DeExpress, Resharper.
Я бы сказал 20 лет назад. Когда-то работал в ЦЕРНе, в команде ROOT (https://root.cern.ch/).
Уже тогда у нас был C++ интерпретатор, Reflection, всевозможные контейнеры, тесный контакт с Страустрапом. Уже тогда обсуждалось, как добавить все эти фичи в стандарт C++.
Но, воз и ныне там.
Сейчас для «низкоуровневого» программирования (видео, DirectShow, MF, COM, железки) пользую C++. Для всего остального — C#.
Мои любимые продукты DeExpress, Resharper.
Уже тогда у нас был C++ интерпретатор
То, что С++ нужно сейчас и просто «интерпретатор» — это разные вещи.
Reflection
Уровня «обойти поля пода»? Это тоже не то, что требуется от С++.
Уже тогда обсуждалось, как добавить все эти фичи в стандарт C++.
Да, но тогда это было позором. Эта была попытка напихать чего-то невнятного лишь бы напихать, но о чудо — комитет одумался.
Для С++ не подходят решения других языков, но не это главное — подобных решений нигде не было и нет. Где есть компилтайм-рефлексия? Да нигде, а где есть — там на уровне языка существуют одни поды(либо чуть-чуть больше). Откуда всё это брать?
За примерами далеко ходить ненужно. Достаточно посмотреть чем были концепты тогда, чем они являются сейчас. Я бы не хотел иметь то, что было раньше.
И можно только порадоваться за С++, что комитет выбрать путь решения глобальных проблем, а не затыкания как попало локальных дыр. И лучше пусть не будет ничего, чем появится что-то убогое, что закроет путь чему-то адекватному.
Тоже самое касается и рефлексии. Достаточно посмотреть на то, чем она была тогда(но уже тогда она была по-сути уникальной в своём роде. Даже в каком-нибудь D пошли по пути наименьшего сопротивления — сделали eval) и чем является сейчас. Лично мне и сейчас не нравится и противник ODR и всего, что с ним связано. В этом плане тот же шарп мне ближе.
Я не хочу троллить.
Свою миллионную линию кода на C++ я уже написал.
Тем не менее, последние 10 лет работы на C#, убеждают меня, что C# на 101% более продвинутый язык развитие которого не стоит на месте (в отличии от C++).
На пример, мне нравятся те фичи, которые появятся в C#8 (хотя сам «застрял» на 4.5 ).
++
>И можно только порадоваться за С++, что комитет выбрать путь решения >глобальных проблем, а не затыкания как попало локальных дыр.
Когда я говорил про «тесный контакт со Страустрапом» — это означает,
что были и продолжаются личные контакты, и Страустрап не раз приводил наш проект в качестве успешного проекта написанного на C++
Вот цитата из вики
"
ROOT разрабатывался как высокопроизводительная вычислительная библиотека, необходимая для обработки данных Большого Адронного Коллайдера, поток которых достигает нескольких петабайт в год. С 2009 года ROOT используется в подавляющем большинстве экспериментов физики высоких энергий; абсолютное большинство современных результатов и иллюстраций в этой области науки получено именно с использованием ROOT.
Включение в пакет интерпретатора C++ CINT значительно увеличило гибкость пакета, так как позволило использовать средства ROOT в интерактивном режиме или посредством написания скриптов, что сделало его похожим на MATLAB.
"
Более 10 лет назад комитет планировал ввести в стандарт C++, как интерпретатор, так и рефлексию.
Сам я когда-то написал apache module, который позволял исполнять C++ скрипты на серверной части. Что обеспечивало веб-интеграцию.
Именно по этому пути двигался C#.
+++
PowerShell — обеспечивает интеграцию C# с операционной системой.
Свою миллионную линию кода на C++ я уже написал.
Тем не менее, последние 10 лет работы на C#, убеждают меня, что C# на 101% более продвинутый язык развитие которого не стоит на месте (в отличии от C++).
На пример, мне нравятся те фичи, которые появятся в C#8 (хотя сам «застрял» на 4.5 ).
++
>И можно только порадоваться за С++, что комитет выбрать путь решения >глобальных проблем, а не затыкания как попало локальных дыр.
Когда я говорил про «тесный контакт со Страустрапом» — это означает,
что были и продолжаются личные контакты, и Страустрап не раз приводил наш проект в качестве успешного проекта написанного на C++
Вот цитата из вики
"
ROOT разрабатывался как высокопроизводительная вычислительная библиотека, необходимая для обработки данных Большого Адронного Коллайдера, поток которых достигает нескольких петабайт в год. С 2009 года ROOT используется в подавляющем большинстве экспериментов физики высоких энергий; абсолютное большинство современных результатов и иллюстраций в этой области науки получено именно с использованием ROOT.
Включение в пакет интерпретатора C++ CINT значительно увеличило гибкость пакета, так как позволило использовать средства ROOT в интерактивном режиме или посредством написания скриптов, что сделало его похожим на MATLAB.
"
Более 10 лет назад комитет планировал ввести в стандарт C++, как интерпретатор, так и рефлексию.
Сам я когда-то написал apache module, который позволял исполнять C++ скрипты на серверной части. Что обеспечивало веб-интеграцию.
Именно по этому пути двигался C#.
+++
PowerShell — обеспечивает интеграцию C# с операционной системой.
С++ тоже на месте не стоит. Но да, я наверное соглашусь что особенно в последнее время Microsoft стал очень активно развивать С#. Как впрочем и другие свои языки/фреймворки и всю сопутствующую "инфраструктуру"/тулинг.
> Microsoft стал очень активно развивать С#
Когда-то я достаточно едко высказывался о Мише де Икаса, когда он начинал свой Mono, с GUI на основе Gtk++. Как я был не прав!
Но, именно Mono позволило портировать C# на Linux, iOS, Android.
Когда-то я достаточно едко высказывался о Мише де Икаса, когда он начинал свой Mono, с GUI на основе Gtk++. Как я был не прав!
Но, именно Mono позволило портировать C# на Linux, iOS, Android.
Но да, я наверное соглашусь что особенно в последнее время Microsoft стал очень активно развивать С#
microsoft и с++ начали активно развивать, но, чисто статистически, лучше бы они этого не делали
Свою миллионную линию кода на C++ я уже написал.
Это не то, что нужно как-то выделять. В целом, возможно поэтому вам непонятно развитие С++(и как следствие современный С++).
Тем не менее, последние 10 лет работы на C#, убеждают меня, что C# на 101% более продвинутый язык развитие которого не стоит на месте (в отличии от C++).
Напихать сахара и рантайм-фичей ничего не стоит. С++ подобным не занимается. И далее какие-то странные тезисы без какой-либо аргументации.
На пример, мне нравятся те фичи, которые появятся в C#8 (хотя сам «застрял» на 4.5 ).
Типичное «хорошо там, где нас нет».
Когда я говорил про «тесный контакт со Страустрапом» — это означает,
что были и продолжаются личные контакты, и Страустрап не раз приводил наш проект в качестве успешного проекта написанного на C++
Из этого ничего не следует. Строуструп не священная корова и никогда кем-то, кто занимается С++ на фундаментальном уровне не являлся. Он всегда занимался популяризацией и доступностью С++, а не какими-либо теоретическими, либо практическими изысканиями.
И сейчас Строуструп работает именно на тем, что-бы искоренить подобное вашим представление. Которые где-то когда-то что-то писали на C++, которые лишь номинально являются С++, а реально си с классами.
C++ после 0x фундаментально изменился и всё, что вы знали до — уже ничего не значит. Весь ваш опыт до — уже ничего не значит. И core guidelines призваны изжить этот опыт, вынести его за рамки С++ и никогда не называть это C++, дабы не обманывать ни себя, ни других.
Включение в пакет интерпретатора C++ CINT значительно увеличило гибкость пакета, так как позволило использовать средства ROOT в интерактивном режиме или посредством написания скриптов, что сделало его похожим на MATLAB.
Это так же ничего не значит. Это попытка дать студентом очередной питон. Это не какое-то фундаментальное направление С++. К тому же, сама реализация подобного достаточно тривиальна на фоне того, что разрабатывается для С++ сейчас.
Более 10 лет назад комитет планировал ввести в стандарт C++, как интерпретатор, так и рефлексию.
Я уже на это отвечал. Рефлексии нигде нет и никто не знает как она должна выглядеть для вводных С++. С++ здесь занимает передовые позиции. Интерпретатор достаточно примитивная вещь, которая мало кому нужна.
С++ занимается развитием статических возможностей, возможностей мета-программирования и прочим подобным. Интерпретатор, скрипты и прочее — это совершенно иной подход, который не совместим с базовыми концепциями С++. Да, в какой-то мере что-то подобное имеет смысл поддержать, но это не приоритетно.
Задача статического языка прежде всего обеспечить фундаментальное свойство статики «собралось — работает». Это не питон и тут подобные проблемы не должны решаться реплом.
Что обеспечивало веб-интеграцию.
Именно по этому пути двигался C#.
Я не знаю каким образом скрипты дают какую-то веб-интеграцию и что это значит, но это так же не приоритетное направление С++.
PowerShell — обеспечивает интеграцию C# с операционной системой.
И что это должно значить? Лично меня не интересует ни эта «операционная система», ни какая-то интеграция в ней. Моё отношение к сему — есть ваше отношение к С++(вернее к тому, что вы неправильным образом называете С++).
мой последний комментарий втему
> Интерпретатор достаточно примитивная вещь, которая мало кому нужна.
Это не примитивная вещь.
Когда четверть века назад Masaharu Goto (мой друг Маса) решил написать C++ интерпретратор (CINT), все в один голос уверяли, что это невозможно сделать.
А, он сделал. Конечно, за это время была проделана большая теоретическая работа по алгоритмам написания интерпретатора и сейчас это сделать гораздо проще.
Если бы 20 лет назад приняли C++ интерпретратор,
то все эти питоны, баши, пых-пыхи, пёрлы оказались в мусорной корзине истории.
Все заменил бы C++
Это именно тот путь (единый язык для любой задачи, везде C#) по которому пошли мелко-мягкие, и несомненно, это позволило им сделать прорыв в технологии программирования.
Не видеть этого может только человек страдающий когниктивным диссонансом.
> Рефлексии нигде нет и никто не знает как она должна выглядеть для вводных С++
Именно благодаря «рефлексии» был пойман Бизон Хиггинса, заполнена самая большая база данных в мире. Я имею ввиду данные с Большого Адронного Коллайдера. Это, так называемый, ROOT data format, который на 101% основан на «рефлексии».
++
Хочу добавить последние 2 копейки…
Когда один из «экспертов» говорит
«Я тут хотел уточнить. Я про C# мало знаю, сам трогал его очень давно, в самых первых версиях»
дискуссию на этом можно было бы и закончить!
> Интерпретатор достаточно примитивная вещь, которая мало кому нужна.
Это не примитивная вещь.
Когда четверть века назад Masaharu Goto (мой друг Маса) решил написать C++ интерпретратор (CINT), все в один голос уверяли, что это невозможно сделать.
А, он сделал. Конечно, за это время была проделана большая теоретическая работа по алгоритмам написания интерпретатора и сейчас это сделать гораздо проще.
Если бы 20 лет назад приняли C++ интерпретратор,
то все эти питоны, баши, пых-пыхи, пёрлы оказались в мусорной корзине истории.
Все заменил бы C++
Это именно тот путь (единый язык для любой задачи, везде C#) по которому пошли мелко-мягкие, и несомненно, это позволило им сделать прорыв в технологии программирования.
Не видеть этого может только человек страдающий когниктивным диссонансом.
> Рефлексии нигде нет и никто не знает как она должна выглядеть для вводных С++
Именно благодаря «рефлексии» был пойман Бизон Хиггинса, заполнена самая большая база данных в мире. Я имею ввиду данные с Большого Адронного Коллайдера. Это, так называемый, ROOT data format, который на 101% основан на «рефлексии».
++
Хочу добавить последние 2 копейки…
Когда один из «экспертов» говорит
«Я тут хотел уточнить. Я про C# мало знаю, сам трогал его очень давно, в самых первых версиях»
дискуссию на этом можно было бы и закончить!
Решил таки продолжить…
Сегодня прослушал отличный доклад, про отличную либу, которая реализует рефлексию на C++ (14).
channel9.msdn.com/Events/CPP/CppCon-2016/CppCon-2016-C14-Reflections-Without-Macros-Markup-nor-External-Tooling
github.com/apolukhin/magic_get
Она уже часть boost.
Ждем, когда станет частью языка.
Сегодня прослушал отличный доклад, про отличную либу, которая реализует рефлексию на C++ (14).
channel9.msdn.com/Events/CPP/CppCon-2016/CppCon-2016-C14-Reflections-Without-Macros-Markup-nor-External-Tooling
github.com/apolukhin/magic_get
Она уже часть boost.
Ждем, когда станет частью языка.
У меня сломался Console.Beep() в C# + Windows + RDP.
Поплюсуйте, пожалуйста, на GitHub!
github.com/dotnet/corefx/issues/41437
Поплюсуйте, пожалуйста, на GitHub!
github.com/dotnet/corefx/issues/41437
Кстати, в C++ он тоже должен быть сломан. Я не проверял.
Проверил. Сломан и там.
github.com/dotnet/corefx/issues/41437#issuecomment-536646193
github.com/dotnet/corefx/issues/41437#issuecomment-536646193
По поводу КДПВ: лучше бы взяли Саб-Зиро и Рейна из Ultimate Mortal Kombat 3, и тогда не пришлось бы перекрашивать Скорпиона.
Для меня немного странная постановка вопроса и немного странная дискуссия. Сам в своё время начинал на С/С++, а потом всё больше и больше ушёл в С#. И для меня это просто немного разные "инструменты".
И сравнивать их это как сравнивать ну скажем топор и молоток. Вроде в чём-то похожие и местами один может худо-бедно заменить другой, но на мой взгляд не особо логично пытаться выяснить кто из них "лучше".
Анатолий: Мне, кстати, недавно попалась отличная статейка, где автор на разных языках (около 10) написал низкоуровневый драйвер — network driver для 10-гигабитной карточки Intel. От C до Swift, JS, Python и, естественно, C#. Если мы посмотрим на эти графики, которые у него получились, то C# на больших батчах (когда нивелируются расходы на запуск) идёт вровень с C и Rust.
Ну вот зачем упоминать этот позор. Как можно называть её отличной? Как можно говорить:
Если мы посмотрим на эти графики, которые у него получились, то C# на больших батчах (когда нивелируются расходы на запуск) идёт вровень с C и Rust.
Если кратко — это очередной ахренительный бенчмарк типа этой нетленки. Время идёт, а люди так и бенчат ffi на больших батчах. И ладно если первое имеет какой-то смысл(правда это нужно заявлять сразу, что мы бенчим именно ffi), то второе — это уже дно. Большие батчи нужны для уменьшения влияния ffi, но какой смысл бенчить ffi и при этом уменьшать его влияние? Какой смысл от быстрого ffi, если производится 1000 вызовов в секунду? Никто не знает.
Нужно сразу пресекать подобные заявления. А особенно неверные выводы из них. Несколько базовых тезисов:
1) Никто никакие драйвера не писал. Есть некое api, которые всё делает и железка его «поддерживает» — это api может получать данные из железки. Есть другое api, при помощи которого можно писать данные в определённое место, а далее само ядро всё разрулит. Т.е. вся логика драйвера существует в ядре, написана на си. Этот же «драйвер» просто конфигуратор + memcpy.
2) Почему-то во всех подобных бенчмарках за кадром остаётся самое важное? Что вообще в коде на разных языках происходит? Что там вообще выполняется? Как это выглядит.
За примером далеком ходить ненужно — достаточно взять упомянутый rust. Из тысячи строк на си — там получилось в 10(если не больше) раз больше кода. Почти весь этот код — unsafe-блоки с ffi к си. Где, собственно, rust и какой-то драйвер? Где та самая выразительность? Ради чего мы сменили шило на мыло?
3) Неверная идентификация проблемы. Правильные результаты там показывает именно начало графика. Проблемы C# обусловлены ни какой-то неведомой «когда нивелируются расходы на запуск» глупость, а вполне очевидными вещами.
Если упростить, то ситуация следующая. Ядро вызывает юзерпейс, далее всё это доходит до шарпа/раста/го(везде номинально есть «бесплатный» ffi), далее уже этот шарп/раст/го вызывает сишную логику, которая копирует данные и обеспечивает всё остальное.
Соответственно, всё сразу становится на свои места. Чем больший кусок данных мы пробрасываем через шарп/раст/го — тем меньше раз мы обращаемся к ним и тем меньше мы теряем на оверхеде. Т.е. по-сути чем правее — тем меньше шарпа/раста/го. А значит, что отсылка на правую часть графика — это призыв отказаться от шарпа/го/возможно и раста.
Возможно, в некоторых моментах вы и правы, но мне кажется критика теста не вполне обоснована.
Драйвер в первую очередь это софт, реализующий какой-либо стандартизированный интерфейс, для того чтобы ОС могла как-то унифицированно общаться с огромным зоопарком железячных устройств. Обычный фасад, у которого понятное определенной ОСи лицо, и вызовы железного API определенной железяки (чаще всего через прерывания либо другую командную шину) или API драйвера более низкого уровня (например Video BIOS) под капотом. И совсем не обязательно это должен быть код, который байты по одному шлет в LPT порт. Уже много лет как придумана и активно используется в драйверописании такая замечательная штука как DMA. Собственно, очень многие драйверы, включая драйверы дисков, звуковых, сетевых и видео карт, занимаются в основном именно тем, что вы описали, — конфигурируют DMA буферы, напихивают в них данные и вызывают железячную команду «сделать хорошо». Поэтому пример который вы критикуете — драйвер в самом прямом понимании этого слова.
Линка над картинкой ведет на репу на гитхабе, где вполне можно почитать код и понять что делает та или иная реализация. И какие костыли использует — зачастую комментарии в коде или readme файлы явно указывают на них. В реализации на C# стек пакетов, все буферы (кроме DMA области) — менеджд код. Цикл обработки Tx/Rx, работа с PCI — тоже. Ясно, что полно unsafe (иначе невозможно работать с указателями в C#). Но в целом — вполне себе понятный C# код, без засилья маршаллинга, использования библиотек ядра и прочих грязных извращений.
Насчет размеров батчей и их влияния на производительность я бы тоже поспорил. С точки зрения драйвера, при большем размере батча нужно выделить больше буферов, создать больше дескрипторов и скопировать больше данных, но зато реже. И меньше PCI вызовов нужно делать чтобы передать то же самое количество пакетов. Так что повышение производительности с увеличением числа батчей свидетельствует лишь о дороговизне PCI вызовов, на что, собственно, и указывается в тексте статьи, поясняющей исследование. Причем судя по форме графика, вызовы PCI влияют на любую реализацию приблизительно одинаково, выходя к оптимуму на размере батча в 32-64 для всех языков. Так же ваша гипотеза плохо накладывается на тот факт, что дальнейшее увеличение числа батчей в итоге негативно сказывается на производительности (к сожалению, в оригинальной статье не указывается конкретное число, но я думаю, что эффект должен быть уже начиная с 1024, хотя может зависеть от железа).
Я согласен, что данный тест скорее показывает что на С#/Rust/Go/etc. можно писать драйвера с приемлемой производительностью. Так же, он позволяет грубо сравнить производительность тестируемых языков с C/C++ в определенном классе задач, типичном для С. Но в целом, все эти «20 мегапопугаев в секунду» в итоге ничего не говорят о языке и/или его применимости в задачах другого типа. Но в целом, да, тест приведен, возможно, не совсем к месту. Но от этого он сам не становится некорректным.
Драйвер в первую очередь это софт, реализующий какой-либо стандартизированный интерфейс, для того чтобы ОС могла как-то унифицированно общаться с огромным зоопарком железячных устройств. Обычный фасад, у которого понятное определенной ОСи лицо, и вызовы железного API определенной железяки (чаще всего через прерывания либо другую командную шину) или API драйвера более низкого уровня (например Video BIOS) под капотом. И совсем не обязательно это должен быть код, который байты по одному шлет в LPT порт. Уже много лет как придумана и активно используется в драйверописании такая замечательная штука как DMA. Собственно, очень многие драйверы, включая драйверы дисков, звуковых, сетевых и видео карт, занимаются в основном именно тем, что вы описали, — конфигурируют DMA буферы, напихивают в них данные и вызывают железячную команду «сделать хорошо». Поэтому пример который вы критикуете — драйвер в самом прямом понимании этого слова.
Линка над картинкой ведет на репу на гитхабе, где вполне можно почитать код и понять что делает та или иная реализация. И какие костыли использует — зачастую комментарии в коде или readme файлы явно указывают на них. В реализации на C# стек пакетов, все буферы (кроме DMA области) — менеджд код. Цикл обработки Tx/Rx, работа с PCI — тоже. Ясно, что полно unsafe (иначе невозможно работать с указателями в C#). Но в целом — вполне себе понятный C# код, без засилья маршаллинга, использования библиотек ядра и прочих грязных извращений.
Насчет размеров батчей и их влияния на производительность я бы тоже поспорил. С точки зрения драйвера, при большем размере батча нужно выделить больше буферов, создать больше дескрипторов и скопировать больше данных, но зато реже. И меньше PCI вызовов нужно делать чтобы передать то же самое количество пакетов. Так что повышение производительности с увеличением числа батчей свидетельствует лишь о дороговизне PCI вызовов, на что, собственно, и указывается в тексте статьи, поясняющей исследование. Причем судя по форме графика, вызовы PCI влияют на любую реализацию приблизительно одинаково, выходя к оптимуму на размере батча в 32-64 для всех языков. Так же ваша гипотеза плохо накладывается на тот факт, что дальнейшее увеличение числа батчей в итоге негативно сказывается на производительности (к сожалению, в оригинальной статье не указывается конкретное число, но я думаю, что эффект должен быть уже начиная с 1024, хотя может зависеть от железа).
Я согласен, что данный тест скорее показывает что на С#/Rust/Go/etc. можно писать драйвера с приемлемой производительностью. Так же, он позволяет грубо сравнить производительность тестируемых языков с C/C++ в определенном классе задач, типичном для С. Но в целом, все эти «20 мегапопугаев в секунду» в итоге ничего не говорят о языке и/или его применимости в задачах другого типа. Но в целом, да, тест приведен, возможно, не совсем к месту. Но от этого он сам не становится некорректным.
Собственно, очень многие драйверы, включая драйверы дисков, звуковых, сетевых и видео карт, занимаются в основном именно тем, что вы описали, — конфигурируют DMA буферы, напихивают в них данные и вызывают железячную команду «сделать хорошо». Поэтому пример который вы критикуете — драйвер в самом прямом понимании этого слова.
Нет. И даже тут множество проблем. Конфигурирует ядро, через ядерное api, данные пропихивает ядро, обрабатывает ядро, вызывается ядро через сишный рантайм, взывает команду ядро. Т.е. в ядре работа с подобного рода устройствами уже почти реализована и обобщена.
Когда кто-то имеет ввиду драйверы — имеют ввиду именно драйверы. Драйверы в целом. Не «давайте из юзерспейса повызываем си через ffi». К тому же, даже это не всегда работает. Хотя казалось бы — что там может так сливать, но вот оно — может.
В реализации на C# стек пакетов, все буферы (кроме DMA области) — менеджд код.
От того оно и сливает. По поводу работы с памятью — она там явно не та, которая используется обычно.
Цикл обработки Tx/Rx, работа с PCI — тоже.
Там никакой логики нет, там всё примитивно — один шарповый синтаксический мусор и value-типы. Но даже тут оно умудряется сливать.
Какой смысл в шарпе? Что-бы написать «как на си», но при этом хуже чем на си? Если даже в таком явно подложном кейсе такие проблемы — что же там будет, если попробовать реализовать что-то действительно сложное.
Ясно, что полно unsafe (иначе невозможно работать с указателями в C#). Но в целом — вполне себе понятный C# код, без засилья маршаллинга, использования библиотек ядра и прочих грязных извращений.
А что же такое /sys, хотя это не библиотека да, но api ядра. К тому же, как я уже говорил выше — это не понятный C# код. Это банальный си раздутый синтаксисом шарпа и содержащий всякие заморочки.
Я не понимаю вашу логику. Какой смысл брать шарп и писать «как на си»? Это имеет какой-то сакральный смысл? Я этого никогда не понимал. Для людей из мира си — подобные вещи привычны, подобная работа с памятью привычна, подобные api привычны. Что мы получаем используя шарп? Мы получаем выразительность? Нет. Мы уходим от каких-то проблем? Нет — мы их создаём. Мы используем шарп в привычном виде? Нет. Мы получаем тот же результат? Нет. Что мы получаем?
Насчет размеров батчей и их влияния на производительность я бы тоже поспорил. С точки зрения драйвера, при большем размере батча нужно выделить больше буферов, создать больше дескрипторов и скопировать больше данных, но зато реже. И меньше PCI вызовов нужно делать чтобы передать то же самое количество пакетов. Так что повышение производительности с увеличением числа батчей свидетельствует лишь о дороговизне PCI вызовов, на что, собственно, и указывается в тексте статьи, поясняющей исследование. Причем судя по форме графика, вызовы PCI влияют на любую реализацию приблизительно одинаково, выходя к оптимуму на размере батча в 32-64 для всех языков. Так же ваша гипотеза плохо накладывается на тот факт, что дальнейшее увеличение числа батчей в итоге негативно сказывается на производительности (к сожалению, в оригинальной статье не указывается конкретное число, но я думаю, что эффект должен быть уже начиная с 1024, хотя может зависеть от железа).
Я не понимаю к чему вы и зачем это пишите? Вы нигде не опровергли мою гипотезу — только подтвердили её.
Очевидно, что на любых вызовах есть оверхед. Каким образом наличие оверхеда снизу что-то говорит об оверхеде сверху? Зачем вы пытаетесь манипулировать? К тому же, вы зачем-то пытаетесь меня обмануть.
Си выходит на максимум ещё на 8-16, когда как шарп не выходит никогда. Куда-то он выходит — только 128-256, но даже тут оверхед есть. То, что «другие языки» так же растут — это так же очевидно. Оверхед на ffi и на саму логику языков размазываются по батчу.
По поводу «эффект должен быть» — это глупость. Как мы уже выяснили — существует две компоненты. Компонента снизу и сверху, ведь си точно так же растёт и оверхед там тоже есть, как и есть он железе. таким образом ничего не мешает это компоненте снизу начать проявлять себя и снижать производительность. Когда как компонента сверху может уже либо совсем не влиять, либо влиять меньше. К тому же — наличие эффекта не означает, что он одинаково влияет на все языки.
К тому же, размер батча увеличивает летенси и где-то это может критично.
Я согласен, что данный тест скорее показывает что на С#/Rust/Go/etc. можно писать драйвера с приемлемой производительностью.
Из этого горе-теста ничего этого не следует. К тому же — удобно вы трактуете для себя приемлемость. Питонисты тоже скажу, что для них их производительность приемлемая.
К тому же, раст в данном случае лучше вообще не упоминать. Там всё очень плохо в этой реализации. Если версию на шарпе ещё можно с натяжкой назвать «версией на шарпе», то вас про раст так не сказать. Го я не смотрел, но меня не особо го/шарп интересуют.
Так же, он позволяет грубо сравнить производительность тестируемых языков с C/C++ в определенном классе задач, типичном для С.
Не позволяет. Это фейковый бенчмарк, который ничего не бенчит. К тому же, вы только что поймали себя в ловушку. Если до этого тезиса вы могли бы говорить, что мои рассуждения об:
Когда кто-то имеет ввиду драйверы — имеют ввиду именно драйверы. Драйверы в целом. Не «давайте из юзерспейса повызываем си через ffi». К тому же, даже это не всегда работает. Хотя казалось бы — что там может так сливать, но вот оно — может.
Надуманы, но вы действительно сделали то, что я и говорил. Вы начали экстраполировать результаты этого позора на класс задач. Я не буду комментировать состоятельность этих заявлений — она попросту нулевая. Если даже в таком подложном бенчмарке, который ничего не бенчит и слить там попросту невозможно — вся тройка сливает — это полное фиаско.
Но в целом, все эти «20 мегапопугаев в секунду» в итоге ничего не говорят о языке и/или его применимости в задачах другого типа. Но в целом, да, тест приведен, возможно, не совсем к месту. Но от этого он сам не становится некорректным.
Становится. Он некорректен целиком и полностью. Как я уже писал — он ничего не бенчит. Вообще, примерный аналог подобного я показал выше. У него так же много защитников, которые пытаются экстраполировать эти результаты на вычисления.
Во всех подобных бенчмарках надо чётко понимать — что мы бенчим и что выполняет основную работу. В конечном итоге, как я и сказал — этот бенчмарк бенчит ffi и сишный рантайм. Он не бенчит ничего иного. Хотя даже как бенчмарк ffi он плох. Он плох во всём.
Исходя из того насколько сильно его форсят, насколько удобные там результаты, насколько несостоятелен он сам по себе — я могу с достаточной долей уверенности предположить — возможно это целенаправленный вброс, либо попросту глупость. Но пусть будет глупость.
Я согласен, что данный тест скорее показывает что на С#/Rust/Go/etc. можно писать драйвера с приемлемой производительностью.
Насколько понимаю, драйвер должен работать в режиме kernel mode, а эти языки обеспечивают только user mode. То есть есть накладные расходы на переключение между режимами при каждом чихе. Чистый kernel mode возможен только на С и ассемблере. Даже С++ не может работать в этом режиме понормальному.
Rust и плюсы могут работать в чистом kernel mode, нужно лишь отключить фичи рантаймов.
Ну и учитывая специфику, не увлекаться шаблонами.
По мне все эти споры больше дело вкуса. Мне допустим Java кажется намного логичнее C# из-за меньшего количества сущностей, и ничего не могу поделать.
Последние изменения стандарта C++, как мне кажется — попытки исправить проблемы которые привнесло метапрограммирование.
А ещё я на днях посмотрел пост про развитие стандарта C, прямо все больше и больше люблю С, очень стройный и логичный язык.
Вот ссылка, кому интересно.
Последние изменения стандарта C++, как мне кажется — попытки исправить проблемы которые привнесло метапрограммирование.
Странное заявление. Как можно исправить проблемы метапрограммирования добавив его ещё больше? Клин клином? Проблемой С++ было(и есть) малое кол-во метапрограммирования и малое ко-во фич. А так же, проблемой С++ является его изначальный дизайн со множеством скрытой семантики и откровенных дыр, но такой дизайн присущ всем ЯП.
А ещё я на днях посмотрел пост про развитие стандарта C, прямо все больше и больше люблю С, очень стройный и логичный язык.
Видео запоздало лет на 20. Всё это(и больше) всегда было в gnuc(который стандарт де-факто в мире си), откуда и перебралось в стандарт, причём почти всё перебралось ещё те самое 10-20 лет назад.
Как можно исправить проблемы метапрограммирования, добавив его ещё больше?
Сделав код проще и понятнее, пусть и за счёт усложнения самого языка.
Сделав код проще и понятнее, пусть и за счёт усложнения самого языка.
Ну дак там говорится не о сложности мета-программирования(хотя тезис уже спорный — где есть ещё более простое мета-программирование? В D? Мне лично не особо оно нравится и выглядит, опять же для меня, ужасно), а о самом мета-программировании.
К тому же именно мета-программирование сделало из C++ то, чем он является и решило множество проблем везде и всюду. Тезис абсолютно некорректен. А то, что его можно упростить и улучшить — да, конечно. Но тезис всё равно некорректный.
хотя тезис уже спорный — где есть ещё более простое мета-программирование?
Ну да, ассемблер простой. Но программы писать на нём почему-то сложно. Поэтому люди придумали высокоуровневые языки.
Кстати, именно в C++ мета-программирование называть простым у меня язык не поворачивается. Концептуально всё просто, но из-за большого количества подводных камней получается уже сложно.
Мне допустим Java кажется намного логичнее C# из-за меньшего количества сущностей, и ничего не могу поделать.
В java до сих пор нет checked arithmetics.
int foo = Integer.MAX_VALUE + 1; // тут должно быть исключение, а его нет. источник трудноуловимых отсроченных ошибок
Мне допустим Java кажется намного логичнее C# из-за меньшего количества сущностей, и ничего не могу поделать.
А мне Java не нравится из-за ограниченных языковых возможностей по сравнению с C#. Даже структур нет и полноценных дженериков.
Аналогично кому-то будет нравиться Go за простоту, а кому-то C++ — за возможности.
А по мне самый лучший ЯП, это тот который ты лучше освоил.
Я освоил Basic разлива УК-НЦ по максимуму, и я гарантирую, что это не лучший язык даже среди тру-бейсиков.
Та ладно таких веселых васиков больше нигде нет. Если в видеопамять по отрицательному адресу писать оно рисует отам вверху экрана, где типа верхней строки состояния. И убрать то что нарисовал никакими комадами clear и т.д. не уберешь. только ребут ну или опять же программно затереть. Информатичку чуть инфаркт не хватил когда она там логотип IBM увидела и убрать не шмогла.
Ага, Форт, тут и метапрограммирование и разделение синтаксиса и семантики и низко-высокоровневые слои применения языка, но увы слишком много отличий от майнстрима и корпоративного использования. :)
Хотел бы я посмотреть как придёт самсунг и скажет мелкософту что этой фичи в новом дотнете не будет. Практически весь c# контролируется мелкософтом, любой форк, предлагающий координальные изменения будет раздавлен в течение пары дотнетовских версий. Опять же под линь и мак никто не пишет на c#, несмотря на xamarin. Все понимают что это язык одной компании под одну операционку, но продолжают утверждать, что он кроссплатформенный и его развитие распределено.
Под одну операционку это ныне замороженный (is done) .NET 4.8.
А актуальный .NET ныне — это Core 2.2/3.0 для бек-енд разработки, которую ведут обычно под Windows, но таргетируют как для Windows, так и для Linux.
И сейчас Core прямо выстрелил — после многих и многих лет застоя стартовало много бек-енд проектов на рынке.
Ну а с кроссплатформенной разработкой, похоже, в итоге не сложилось. И надо ли? Есть много других современных средств.
Можно писать на vscode под линуксами, но debuger придется от самсунга прикручивать, либо пользоваться проприетарным от микрософт в комплекте с vscode.
Rider под linux работает не намного хуже, чем под wndows. А в чем-то даже лучше.
Уже лучше. EF Core 3.0 имеет еще более допиленный Change Tracker, Code First, и чуток лучший парсер Expression Tree, но это не значит лучший SQL. Использовать ли это в продакшине, хотя нет, использовать ли это для высоких нагрузок — решать вам.
Как это не завезли??? Видать «конкуренты» до сих пор абстрактной «фигней» над абстрактным хранилищем страдают.
Для жаждущих пока только для 2.1, на след неделе докручу к 3.0, а то немножко там нарефакторили и надо легкий тюнинг — linq2db.EntityFrameworkCore
Редко меня можно удивить SQL запросом который я не могу на LINQ написать.
Для жаждущих пока только для 2.1, на след неделе докручу к 3.0, а то немножко там нарефакторили и надо легкий тюнинг — linq2db.EntityFrameworkCore
Редко меня можно удивить SQL запросом который я не могу на LINQ написать.
Мое мнение, что когда в запросах доходит дело до GROUP BY и прочие UNION, то в большинстве случаев я хочу дернуть хранимку чтобы быть уверенным, что оно работает как я хотел.
Лично я 2 года в продакшене использую EF Core и не было того, чтобы я сделать не смог. Не всегда элегантно, но работало. Плюс перформанс, если использовать AsNoTracking весьма хорош, по сравнению с обычным или упаси Боже, нхибернейтом.
Лично я 2 года в продакшене использую EF Core и не было того, чтобы я сделать не смог. Не всегда элегантно, но работало. Плюс перформанс, если использовать AsNoTracking весьма хорош, по сравнению с обычным или упаси Боже, нхибернейтом.
Может еще и оконные функции вспомним? И, думаю, никогда или не очень скоро будет поддерживаться. Разрабатывают EF Core очень квалифицированные специалисты, но к реальной разработке высоконагруженных систем, имеющие далекое отношение. По этому не удивляйтесь поставленным приоритетам.
Причем тут высокая нагрузка (особенно с Union, ага). Ни разу не видел, чтобы ОРМ использовали для высокой нагрузки. Для этого просто дергаем хранимку/вьюху из базы, где ее пишет DBD, а не EF с горы. Да, это гораздо медленнее в разработке, но когда я думаю про хайлоад, я подразумеваю, что деньги на ДБД и время на нормальную разработку есть.
AsNotraking снижает потребление памяти в классических REST сценариях, когда по-сути, контекст живет только время обработки реквеста. Мы просто не кэшируем в памяти всю эту хрень.
А в чем были именно сложности перехода? Есть конечно костыли до сих пор, но особых сложностей я не видел.
А в чем были именно сложности перехода? Есть конечно костыли до сих пор, но особых сложностей я не видел.
Пропал Model First подход. Это, конечно же, был наиболее неудобный из всех подходов, но переписать легаси всё равно не так просто.
Пропали инструменты для автоматизации Database First — подхода.
То, что раньше делалось через edmx, теперь надо делать через DbModelBuilder. Стало намного проще, но все старые костыли снова в мусорку.
Entity SQL тоже пропал, запросы надо переписывать
Довольно неудобно, что сам EF Core вроде как для .NET Standard написан, но вот для миграций нужен .NET Core и никак иначе.
Потому EF не может. Хранимки это и есть костыли. Шаг влево, шаг вправо — FromSql или хранимки. Выигрыш использования LINQ слегка пропал. Если в инструменте сплошные ограничения, я чувствую себя как на минном поле. Но ниче, потом так и рождаются сертифицированные специалисты — они знали, они плавали.
Это Вы из какого года нам пишете?
Сообщество очень активно участвует в разработке с 2014 года, причем изменения далеко не минорные. Например, привнесение платформенных SIMD в 3.0 сделано не разработчиком MS, насколько я знаю. И форки при таком подходе не нужны абсолютно, более того — они вредны.
У .NET есть куча ужасных косяков со скоростью в некоторых системных вещах.
Например получения и обработка всех файлов в директории.
На WinAPI эта часть может работать до 10 раз быстрее, чем на truъ .NET-е.
В итоге C++ CLI для таких задач лучше всего (боль маршалинья всех WinAPI на C# невыносима)
Например получения и обработка всех файлов в директории.
На WinAPI эта часть может работать до 10 раз быстрее, чем на truъ .NET-е.
В итоге C++ CLI для таких задач лучше всего (боль маршалинья всех WinAPI на C# невыносима)
При этом если учесть что шарп это вооще не C а ява++ то все становится на свои места. Это не какой не С++++ а Simula-67++++.
Ну а если к этому присовокупить что GC полностью устарел по состоянию на конец 60-х потому что для ООП не дает вообще никакой автоматизации и в купе с неумением статической композиции и размещения временных объектов на стеке, полностью исключают многопоточность, превращая ее в эмуляцию однопотока на многоядерном проце, дженерики не позволяют определять алгебру над сущностями, модули паскалевского разлива не позволяют иметь несколько реализаций к одному заголовку и несколько заголовков к одной библиотеке…
Ну в общем сразу становится ясно почему С++ наиболее высокоуровневый язык на сегодняшний день. А то что быстрый и годен для системного уровня — ну так получилось.
Ну а если к этому присовокупить что GC полностью устарел по состоянию на конец 60-х потому что для ООП не дает вообще никакой автоматизации и в купе с неумением статической композиции и размещения временных объектов на стеке, полностью исключают многопоточность, превращая ее в эмуляцию однопотока на многоядерном проце, дженерики не позволяют определять алгебру над сущностями, модули паскалевского разлива не позволяют иметь несколько реализаций к одному заголовку и несколько заголовков к одной библиотеке…
Ну в общем сразу становится ясно почему С++ наиболее высокоуровневый язык на сегодняшний день. А то что быстрый и годен для системного уровня — ну так получилось.
Вроде как шутки про GC уже давно deprecated
размещения временных объектов на стеке, полностью исключают многопоточность
Вообщето C# умеет размещать объекты на стеке правда только struct. И как это мешает многопоточности?
В стандартной библиотеке классы которой и используются в основном как временные каков процент оных struct?
А любой new при создании их на эмулированном общем стеке (это то что ошибочно называют кучей в шарпе) требует синхронизации доступа к указателю оного стека. Т.е. все потоки выстраиваются в очередь на каждом шагу.
При размещении же объектов на аппаратном стеке, который для каждого потока свой, такая синхронизация не требует. При этом в реалиях плюсов свою субкучу для каждого потока иметь — ну это вопрос зависящий только от необходимости такой субкучи для конкретной задачи, и вся автоматика управления жизненным циклом для такой субкучи продолжает работать в штатном режиме.
В отличии от шарпа где и с организацией субкучи поплясать с бубном придется и GC в ней работать точно не будет.
А любой new при создании их на эмулированном общем стеке (это то что ошибочно называют кучей в шарпе) требует синхронизации доступа к указателю оного стека. Т.е. все потоки выстраиваются в очередь на каждом шагу.
При размещении же объектов на аппаратном стеке, который для каждого потока свой, такая синхронизация не требует. При этом в реалиях плюсов свою субкучу для каждого потока иметь — ну это вопрос зависящий только от необходимости такой субкучи для конкретной задачи, и вся автоматика управления жизненным циклом для такой субкучи продолжает работать в штатном режиме.
В отличии от шарпа где и с организацией субкучи поплясать с бубном придется и GC в ней работать точно не будет.
Мне кажется, вы застряли где-то на уровне .NET 1.0.
Ну да ведь в параллельных потоках обязательно нужно выделять новые объекты, нельзя же работать с существующими или использовать локфри пулы, или сотню других алгоритмов.
хм… Интересно где вы подобное прочитали? Вообще вопрос выделения памяти в С# довольно таки сложный (хотя по вашему он простой и тупой как 5 копеек), они используют столько уловок, что выделение памяти в C# работает быстрее нежели родной и горячо любимый malloc, и я почему то более чем уверен, что аллокация в C# локфри, особенно если учитывать как легко пишутся лофри аллокаторы (из собственного опыта написания локфри аллокаторов)
И да, чуть не забыл, структурные переменные в C# которые на стеке создаются без new
А любой new при создании их на эмулированном общем стеке (это то что ошибочно называют кучей в шарпе) требует синхронизации доступа к указателю оного стека.
хм… Интересно где вы подобное прочитали? Вообще вопрос выделения памяти в С# довольно таки сложный (хотя по вашему он простой и тупой как 5 копеек), они используют столько уловок, что выделение памяти в C# работает быстрее нежели родной и горячо любимый malloc, и я почему то более чем уверен, что аллокация в C# локфри, особенно если учитывать как легко пишутся лофри аллокаторы (из собственного опыта написания локфри аллокаторов)
И да, чуть не забыл, структурные переменные в C# которые на стеке создаются без new
что выделение памяти в C# работает быстрее нежели родной и горячо любимый malloc
Единичный new в шарпе иногда быстрее. Но только исключительно за счет гигантского отложенного оверхеда. При этом если учесть тот факт что вызовать new в плюсах надо в сотни раз реже чем в шарпе то как бы шарп в этом плане отстает в десятки раз. Это при том что глобальный new в плюсах не предназначен для создания мелких единичных объектов хотя и может для этого использоваться. В основном он используется для создания субкуч выделение из которых идет по оптимальному для обслуживаемой структуры данных алгоритму.
работает быстрее нежели родной и горячо любимый malloc
в синтетическом тесте который использует менее 50мб предвыделенной памяти для там нескольких тысяч распределений когда плюсы отгрызают эту память у оси постранично и с игнорированием того факта что в плюсах вместо эти нескольких тысяч вызовов new достаточно одного который выполняется в тысячи раз быстрее даже с отгрызанием памяти?
Ну да ведь в параллельных потоках обязательно нужно выделять новые объекты, нельзя же работать с существующими или использовать локфри пулы, или сотню других алгоритмов.ну к примеру вектора складывать, матрицы перемножать и т.д. и т.п. И промежуточные результаты таких операций как не крути а временные объекты.
Вообще вопрос выделения памяти в С# довольно таки сложный (хотя по вашему он простой и тупой как 5 копеек)
Да нет там никаких уловок. Просто смещается указатель на конец эмулированного стека. Поэтому сам new и быстрый всегда O(1), а у плюсов глобальный new O(1) только на полностью нефрагментированной куче, на фрагментрированной O (Log (n)) от количества свободных дыр. Но зато имеет постоянный гигантский оверхед по содержанию живых объектов, пропорциональный O(n) от живых объектов, в отличии от плюсов которые тратятся только на рождение и похороны, причем преимущественно массовые. Это уже не говоря про отложенный оверхед на абсолютно бесполезную в системе со страничной организацией виртуальной памяти дефрагментацию, без которой GC жить не может, и этого «быстрого» new тоже не будет.
Ох лол, и вы говорите это просто. Дефрагментация памяти, бесполезная, да вот только благодаря ей C# сильно обгоняет С++ в выделении памяти, а ещё делает вычисления более кэшфрендли.
Дефрагментация памяти, бесполезная, да вот только благодаря ей C# сильно обгоняет С++ в выделении памятиЗато очень сильно отстает в хранении.
а ещё делает вычисления более кэшфрендли.
Этой байке уже реально 70 лет. Только не кеш френдли а минимизирует перемотку перфоленты. У вас ОЗУ до сих пор на перфоленте? Алииния кеша она как не крути 64 байта. А за ними промах.
что аллокация в C# локфри, особенно если учитывать как легко пишутся лофри аллокаторы (из собственного опыта написания локфри аллокаторов)
Локфри она может быть только из разных субкуч/пулов а соответсвенно должен быть механизм явного назначения субкучи/пула потоку.
И как понимаю GC с объектами выделенными из этих пулов тоже не дружит?
Gen0 у каждого потока свой, если что
у системных потоков в которых каллбеки от ядра приходят тоже?
У вас нет доступа к системным потокам из пользовательского кода.
Колбэки от ядра могут приходить только в пользовательские потоки.
Колбэки от ядра могут приходить только в пользовательские потоки.Т.е. только через синхронизацию потоков. Толку тогда от этого эмулированного мультистека, если работа без синхронизации потоков не обеспечивается в принципе?
Это, если что, ограничение самой операционной системы, а не языка/фреймворка.
Это, если что, ограничение самой операционной системы, а не языка/фреймворка.Та нет таки фреймверка. Все калбеки api приходят ни разу не в вызывающем потоке. И вообще не разу не в потоке создаваемом пользовательским кодом. При этом по одному и тому же хендлу разные вызова одного и того же каллбека могут приходить в разных потоках.
И вообще не разу не в потоке создаваемом пользовательским кодом.
Неверно. Колбэки приходят в потоки, создаваемые пользовательским кодом.
Неверно. Колбэки приходят в потоки, создаваемые пользовательским кодом.
А вы их средствами чистого winapi когда нибудь вообще получали что так утверждаете? В главный поток окна они попадают совсем другим спсобом — подкапотный обработчик фреймверка в вызываемый в потоке api, записывает параметры вызова и отправляет их мессаджем. А уже поток обрабатывающий сообщения вызывает делегата.
Конечно, получал. И если вы почитаете документацию по функциям WinAPI, вызывающим колбэки, то там всё будет написано, что и где вызывается.
Вот, например:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfileex
Колбэк вызовется в текущем потоке, если он будет в alertable state — т.е. в состоянии Sleep/Wait.
Колбэк вызовется в текущем потоке, если он будет в alertable state — т.е. в состоянии Sleep/Wait.
Вообще то каллбеки ставят не для того чтобы их в слипе ждать. Особенно когда вопрос касается дуплексного сетевого ввода-вывода. При этом к примеру от той же WinHTTP каллбеки всегда в другом потоке приходят.
Вообще то каллбеки ставят не для того чтобы их в слипе ждать. Особенно когда вопрос касается дуплексного сетевого ввода-вывода.
А переключение контекста бесплатное, ага. То-то однопоточная асинхронщина показывает высокую эффективность под большой нагрузкой.
При этом к примеру от той же WinHTTP каллбеки всегда в другом потоке приходят.
В случае WinHTTP колбэки вызываются в пуле потоков, создаваемым самой либой в пользовательском режиме. Просто эта либа некоторые вещи делает за вас, внутри неё примитивы те же самые.
А .NET перехватывает создание потоков через DLL_THREAD_ATTACH и корректно их инициализирует, чтобы пользователь мог не думать о CLR и GC вообще.
зачем явно то назначать? И без явного всё работать будет, в любой функции в любом месте можно получить id потока в котором она работает.
пишутся лофри аллокаторы (из собственного опыта написания локфри аллокаторов)
т.е. и 20 лет помучались и поняли таки что памятью надо управлять вручную, хотя это было доказано еще 50 лет назад?
Ну в общем если шарп до ума довести то однозначно плюсы получатся.
Интересно сколько времени у шарперов займет понять что кроме ручного управления памятью еще и автоматика управления жизненным циклом нужна, которая в плюсах уже лет сорок есть?
Не, это из С++ опыта, я просто плюсовик, С++ мой любимый язык, обожаю метапрограммирования и ненормальное программирование, C# на самом деле в работе не использую, но честно признаю (ибо сам тестил) что в C# выделение памяти работает намного быстрее стандартного малока.
Вы про IDisposable чтоли который в C# очень очень давно появился?
автоматика управления жизненным циклом нужна, которая в плюсах уже лет сорок есть?
Вы про IDisposable чтоли который в C# очень очень давно появился?
Я про автоматическое управление жизненным циклом. Про автоматическую деинициализацию объекта при выходе его из скопа/деинициализации содержащего его объекта. Именно это позволяет кастомизируемо решать задачу автоматического управления как ресурсами/объектами так и взаимосвязями объектов. Память при этом рассматривается как вид ресурса.
GC этого не умеет от слова совсем. Да и задачу управления буферами памяти GC решает только в случае если задача управления взаимосвязями полностью решена. иначе течет косвенными утечками. Ручное же решение задачи управления взаимосвязями ничем не отличается от ручных вызовов delete и при этом делает GC абсолютно ненужным.
GC этого не умеет от слова совсем. Да и задачу управления буферами памяти GC решает только в случае если задача управления взаимосвязями полностью решена. иначе течет косвенными утечками. Ручное же решение задачи управления взаимосвязями ничем не отличается от ручных вызовов delete и при этом делает GC абсолютно ненужным.
Структуры удаляются, у IDisposable вызывается dispose при выходе из using. Где нужно управлять ресурсами этого хватает за глаза.
Вообще то к примеру хэндл окна (даже упрятанный под кучу оберток) или видеопамять это такой же ресурс. Они у вас типа не разу не долгоживущими объектами каким то образом стали? А файлы? А косвенно владеемые ресурсы? из Dispose ручками высвобождаете? Зачем GC нужен если нужно все равно по дереву удаляемых проходить вручную всегда а то беда беда будет? И чем ручное написание using отличается от ручного вызова delete? Автоматика где?
И это вопросы не языка. Это вопросы обеспечения деинициализации объектов по правилам ООП, которые не зависят от языка. Абсолютно очевидно что GC абсолютно бесполезен для имплементации этих правил. Потому что предназначен для решения абсолютно противоположной задачи. При этом имплементация этих правил делает GC абсолютно ненужным, потому что аналогична вызову GC.Collect после каждого изменения ссылки, при этом гораздо эффективнее GC, поскольку не имеет постоянных накладных расходов на содержание живых, только на вынос мертвых который необходимо производить и при наличии GC.
И это вопросы не языка. Это вопросы обеспечения деинициализации объектов по правилам ООП, которые не зависят от языка. Абсолютно очевидно что GC абсолютно бесполезен для имплементации этих правил. Потому что предназначен для решения абсолютно противоположной задачи. При этом имплементация этих правил делает GC абсолютно ненужным, потому что аналогична вызову GC.Collect после каждого изменения ссылки, при этом гораздо эффективнее GC, поскольку не имеет постоянных накладных расходов на содержание живых, только на вынос мертвых который необходимо производить и при наличии GC.
Ваш бред в голове сложно комментировать.
Давайте сначала вы ответите на вопрос. Сколько кода в продакшн вы непосредственно написали и когда последний раз это было?
Давайте сначала вы ответите на вопрос. Сколько кода в продакшн вы непосредственно написали и когда последний раз это было?
Ваш бред в голове сложно комментировать.Когда вы крайний раз правила по которым ООП функциклит в голове освежали? Вы с ними вообще знакомы? А теорию графов изучали? А анализ графов взаимосвязей в вашей задаче когда призоводите до написания кода или после? А то вы похоже вообще просто не в теме что такое ООП и чем задачи управления памятью отличается от задачи управления жизненым циклом и задачи управления взаимосвязями.
Вы знаете, я код пишу в прод, а не читаю мистические правила времен советских вузов.
Вы знаете, я код пишу в прод, а не читаю мистические правила времен советских вузов.
Вообще то человек который анализирует задачу описывает ее в терминах той или иной методологии проектировани и потом реализует ее в коде называется инженер-программист.
А вот те которые академиев не кончали и сначала на клавиши жамкают те не код в продакшин пишут а баги быдлокодят.
На всякий случай, вы разговариваете с к.т.н. по 05.13.06.
Поэтому поверьте, я в программирование как теоретически, так и практически разбираюсь лучше вашего.
И поверьте человеку, который 14 лет пишет код в продакшн, а не блокчей очередной юзает: ваши представления о программировании лютейший ТРЭШ.
Поэтому поверьте, я в программирование как теоретически, так и практически разбираюсь лучше вашего.
И поверьте человеку, который 14 лет пишет код в продакшн, а не блокчей очередной юзает: ваши представления о программировании лютейший ТРЭШ.
Поэтому поверьте, я в программирование как теоретически, так и практически разбираюсь лучше вашего.От это крутые к.т.н пошли которые с моделью акторов не знакомы.
И поверьте человеку, который 14 лет пишет код в продакшнт.е. до уровня проектирования системы по научным методика с последующей реализацией ее в коде даже за 14 лет не доросли? Вот потому вам и некогда — вынуждены постоянно обкостыливать грабли которые сами же и заложили.
Я не знаю что у вас за образование, и есть ли оно вообще, факт что читать вы так и не научились. Потому что вы оппонируете на какие-то вещи которые сами и придумали. А для .Net есть Akka, если уж вам так интересно.
В реальном мире системы проектируется не по научным методикам, а по бизнес методикам, потому что ЗП платит бизнес. Вы можете сказать бизнесу, что вы создаете гениальный фундаментальный фреймворк на Си, поэтому ваша задача будет решена через 5 лет. Но я уверен, что очень быстро вы отправитесь на мороз.
Спорить тут абсолютно бесполезно, потому что очевидно, что вы не разрабатывали софт для/в коммерческих компаний. Пока нет примеров ваших Гениальных проектов с научными методиками, спорить можно прекращать.
В реальном мире системы проектируется не по научным методикам, а по бизнес методикам, потому что ЗП платит бизнес. Вы можете сказать бизнесу, что вы создаете гениальный фундаментальный фреймворк на Си, поэтому ваша задача будет решена через 5 лет. Но я уверен, что очень быстро вы отправитесь на мороз.
Спорить тут абсолютно бесполезно, потому что очевидно, что вы не разрабатывали софт для/в коммерческих компаний. Пока нет примеров ваших Гениальных проектов с научными методиками, спорить можно прекращать.
GC этого не умеет от слова совсем.
GC этого не должен уметь по определению. Память не является тем ресурсом, который должен быть обязательно освобождён по выходу из scope. А что должно быть освобождено обязательно — освобождается явно. Сейчас даже scope-based using добавили, чтобы сделать это ещё более удобным.
Я про автоматическое управление жизненным циклом. Про автоматическую деинициализацию объекта при выходе его из скопа/деинициализации содержащего его объекта.
При программировании многопоточных приложений на C++ я на практике сталкивался с ситуациями, когда подобное поведение оказывалось нежелательным, а управление памятью становилось весьма сложным и тяжёлым с нагромождением shared_ptr/weak_ptr и проблемами с циклическими зависимостями. В C# же такой проблемы нет.
а управление памятью становилось весьма сложным и тяжёлым с нагромождением shared_ptr/weak_ptr и проблемами с циклическими зависимостями.
ООП не пробовали использовать? В нем проблем с циклическими зависимостями нет.
А причём тут ООП? Ну вот есть два объекта, каждый из которых ссылается на другой. Они сами не удалятся.
А причём тут ООП? Ну вот есть два объекта, каждый из которых ссылается на другой. Они сами не удалятся.
Ну дак это уже нарушение правил предметной области. Т.е. сама такая ситуация это уже баг. Потому что деинициализация объектов в таком случае не может быть произведена вовремя. Поэтому правила построения связей такую ситуацию полностью исключают.
В ООП нет понятия нужен/не нужен. Есть понятие может/не может продолжать существование. При этом одной из причин невозможности продолжать существование есть разрыв связи типа копозиция. Т.е. нет препятсвующих удалению. Есть ответсвенные за удаление которые удаляют вместе с собой объекты на которые ссылаются. И смена ответсвенного невозможна, он назначается при создании. А соответсвенно и образоваие такого кольца тоже. При разрыве внешней связи произойдет уничтожение обоих объектов.
Ну дак это уже нарушение правил предметной области. Т.е. сама такая ситуация это уже баг. Потому что деинициализация объектов в таком случае не может быть произведена вовремя. Поэтому правила построения связей такую ситуацию полностью исключают.
Извините меня но что за чушь вы тут несёте? Два обьекта с ссылками друг на друга встречаются в любом ООП языке сплошь и рядом и никаким багом не являются.
Да возьмите любое банальное parent<->сhild отношение и вот вам уже пример такой пары.
Двухсвязанный список же.
Извините меня но что за чушь вы тут несёте?То просто вы не въехали в суть того как это работает в ООП. чилд композирован в парента. т.е он не может существовать без парента. Разрыв этой ссылки приводит к мгновенному и перманентному уничтожению чилда. Кстати так о птичках это не циклическая а двунаправленная ссылка. И по сути в ООП все ссылки двунаправлены. И никакие счетчики не нужны.
Два обьекта с ссылками друг на друга встречаются в любом ООП языке сплошь и рядом и никаким багом не являются.
Багом они станут если оторвутся. Т.е. если дед потеряет ссылку на парента. Но поскольку потертеря этой ссылки по правилам то й же композиции ведет к перманентному удалению парента то и парент и чилд тут же будут удалены.
Вот так кстати все и фурычит в той же дельфе. Все на таких двунаправленных ссылках. И именно это обеспечивает возможности широкого использования биндинга и как следствие преимущественно визуальной разработки бизнеслогики
То просто вы не въехали в суть того как это работает в ООП. чилд композирован в парента. т.е он не может существовать без парента. Разрыв этой ссылки приводит к мгновенному и перманентному уничтожению чилда
И снова какой-то бред. У меня совершенно спокойно могут быть ещё и отдельные ссылки на пэрента и на чайлда. Но вот если я их уберу и оставлю только их ссылки на друг друга, то по вашей логике они навсегда останутся в памяти....
Багом они станут если оторвутся.
Происходит сплошь и рядом. Вполне себе умышленно и тоже никаким багом не является…
И снова какой-то бред. У меня совершенно спокойно могут быть ещё и отдельные ссылки на пэрента и на чайлда. Но вот если я их уберу и оставлю только их ссылки на друг друга, то по вашей логике они навсегда останутся в памяти....А теперь представьте что они все двунаправленные. Т.е. объект при уничтожении обнуляет/вычищает из контейнеров все оставшиеся на него ссылки.
Ну вот поэтому то что с GС раньше или позже начинает течь как минимум ресурсами а то и косвенными утечками. Потому что объекты не деинициализируются как это предписывают делать правила ООП.
Опять какие-то ваши фантазии и абсолютное непонимание того как работает GC. GC в такой ситуации совершенно спокойно убирает оба объекта.
в такой ситуации совершенно спокойно убирает оба объекта.GC уберет буфера памяти занимаемые объектами, а не объекты. Он вообще объектами не управляет, только буферами памяти. При этом вопрос наличия сторонней ссылки на объекты точно так же придется разруливать и при использовании GC, у которого при наличии такой дополнительной ссылки с альтернативной трассой на рут и происходит коственная утечка. Решается это опять же или ограниченым по функциональности частным случаем со слабыой ссылкой, либо общим случаем с двунаправленно связью с инстантным оповещением ссылающегося.
Т.е. вопрос с необходимостью в слабых ссылка опять же не из языка и способа управления памятью растет, а из правил ООП которые предусматриваю два типа связей — композицию и агрегацию. При этом поведение жестких ссылок с GC перевернуто по сравнению с композицией на 180 градусов, а несвоевременная и даже негарантированная деинициализация объектов и является причиной несоответсвия модели акторов, что и является причиной всех граблей. Имплементровать же в автоматическое поведение ссылок в соответствии с моделью акторов GC не может от слова совсем, в отличии от современной автоматики, потому что разрабатывался в 1959-ом и предназачнен для управления пассивными буферами памяти, а не активными моделями сущностей предметной области, которыми являются объекты в терминах ООП.
Память не является тем ресурсом, который должен быть обязательно освобождён по выходу из scopeА инстанс который живет в этой памяти должен быть деинициализирован обязательно. Опять же по правилам ООП. Поэтому придется по дереву удаляемых пройти все равно. И гораздо эффективней попутно и буфера в список неиспользуемых занести пока знаем какие, чтобы не сканировать постоянно всех живых.
А инстанс который живет в этой памяти должен быть деинициализирован обязательно
Совершенно не обязательно, если единственный используемый ресурс — это память.
И гораздо эффективней попутно и память удалить пока знаем какую, чтобы не сканировать постоянно всех живых.
Не факт. Удаление из глобальной кучи вотпрямщас дорогое + требуется межпоточная синхронизация.
Совершенно не обязательно, если единственный используемый ресурс — это память
А откуда вы знаете какой там ресурс под капотом и какая там вообще под ним глубина дерева композиции объектов и какие агрегации у этого поддерева нужно разорвать при деинициализации? В общем случае об этом знает только сам объект. Именно поэтому и требуется деинициализация всего удаляемого подерева.
Об этом говорит наличие интерфейса IDisposable и намерения программиста по явной очистке ресурсов.
Об этом говорит наличие интерфейса IDisposableТак он у всех абстрактных базовых типов должен быть. Потому как абстрактный предок не может знать что будет под капотом у потомков. А обрабатывается то оный потомок по ссылке на предка.
и намерения программиста по явной очистке ресурсов
20-ый год 21-го века. А все ручками делать. В том числе Dispose писать. Не я с такими глупостями еще в прошлом тысячелетии покончил. намучался достаточно на паскакале. Т.е. никакой разницы с полным отсутствием автоматики GC не дает кроме ненужного оверхеда.
Dispose ничего общего с GC в общем случае не имеет, и в большинстве не системных классах используется для иных целей.
Dispose используют для очистки ресурсов только когда надо освобождать неуправляему память, например при работе напрямую с DLL.
Но в реальности (продакшене) это используется как обычный метод который будет вызываться в using, с помощью него можно писать, например, структурные логи.
using(Log.Header())
using(Log.Body())
Для managed ресурсов явное написание Dispose вообще не имеет смысла.
Dispose используют для очистки ресурсов только когда надо освобождать неуправляему память, например при работе напрямую с DLL.
Но в реальности (продакшене) это используется как обычный метод который будет вызываться в using, с помощью него можно писать, например, структурные логи.
using(Log.Header())
using(Log.Body())
Для managed ресурсов явное написание Dispose вообще не имеет смысла.
Только оно очень редкое. Особенно с учетом того что вся мелочь композирована статически, a объекты которые живут на куче вообще по определению долгоживущие.
Удаление из глобальной кучи вотпрямщас дорогое + требуется межпоточная синхронизация.Но при этом эти затраты гарантированно единовременные и таких операций требуется на несколько порядков меньше. В отличии от GC, который дает огромный постоянный оверхед и остановки всех потоков, и при этом не обеспечивает корретного поведения объектов.
Про принцип суперпозиции который говорит о том что оптимальность элементов не гарантирует оптимальность комбинации? Вот современная автоматика и оптимизирует систему в целом, в отличии от GC в котором ускорение отдельных операций приводит к гигантскому оверхеду в целом.
GC не останавливает потоки. Он вообще может в фоне работать. Поэтому не приходится тратить ресурсы текущего потока на освобождение памяти.
Единственная возможная патологическая ситуация — когда GC не успевает за
GC не останавливает потоки. Он вообще может в фоне работатьВ фоне != параллельно. Ану ка прикиньте алгоритм сканирования трассы на рут без остановки потока аппаратный стек и содержимое регистров CPU которого и является оным рутом.
А теперь прикиньте алгоритм дефрагментации без остановки потоков которые имееют доступ к перемещаемым буферам, особенно при условии того что точно знать какой поток может иметь доступ к какому объекту GC не может. Прикинуть то можно, только вот синхронизация потребуется очень нетривиальная и на каждый перемещаемый буфер.
Поэтому не приходится тратить ресурсы текущего потока на освобождение памяти.У вас столько ядер что им заняться нечем? При этом бутылочное горлышко как сканера так и особенно дефрагментатора — скорость шины. Так что запускать его парллельно — это еще больший оверхед. Так что фоново это по сути сам отработает когда предвыделенный кусок памяти закончился.
При программировании многопоточных приложений на C++ я на практике сталкивался с ситуациями, когда подобное поведение оказывалось нежелательным,
А почему я с ним не сталкивался? Может потому что параллелить нужно или в режиме разделения ресурсов или в другом месте, иначе проблемы будут в любом случае?
С++ наиболее высокоуровневый язык на сегодняшний день.
Программисты на Haskell, Clojure или F# смотрят на этот комментарий с недоумением.
Самое странное, что никак не представлен гймдев, где плюсы до сих пор на коне (и не надо мне расказывать про Unity, там на шарпе только логика пишется, движок всё равно на плюсах, а самая частая жалоба на игры на этом движке — тормозит на топовых конфигурациях).
В самом началесрача дискуссии кратко упоминалось — если вам надо быстро разрабатывать — это к шарпу, если вам надо чтобы разработанное быстро работало — это к плюсам. На текущий момент единственный плюс у C++ — это предсказуемое время выполнения, что в геймдеве критично (бюджет времени 16 мс на кадр).
Подробней про это можно посмотреть в серии лекций томских Unigin-овцев: www.youtube.com/playlist?list=PLgeSUiT3pydG7KchiEhjYvwkORh7TSGNi
В самом начале
Подробней про это можно посмотреть в серии лекций томских Unigin-овцев: www.youtube.com/playlist?list=PLgeSUiT3pydG7KchiEhjYvwkORh7TSGNi
Есть подвижки по части переписывания критичной логики с плюсов на сабсет шарпа:
Погуглил, в основном народ не в восторге. Хотя направление (Job => IL => байт-код LLVM => оптимизации => машкод) интересное.
А на самом то деле если вам надо чтобы разработать быстрее чем на шарпе и чтобы работало быстро — это опять же к плюсам с соответсвующими фреймверками. А причина срача она в том что Майкрософт подобные фреймверки не осилил. Даже WinForms — результат совместного проекта с Борландом, релизить который Борланд отказался, по причине крайней убогости полученного гибрида по сравнению с нативным предком.
Меня всегда умиляет фраза «язык мультиплатформенный» от разработчиков, которые использую интерпретируемые языки. Как-будто эта мультиплатформенность родилась сама собой.
Больная мозоль.
На работе лежит проект, сделанный аж на Builder C++5. Много форм и элементов, СУБД,fastreport и пр.
Надо его переписать, но не могу сделать выбор. Кроссплатформенность не нужна. Важное — нужен мощный генератор отчетов.
Нынешняя громила Embarcadero Builder пугает. Смотрю в сторону Qt — очень радует он меня, и размер distroDLL в принципе адекватен.
А вот к шарпу отношусь напряженно, отчасти из-за кучи фреймворков и страха совместимости между ними. Мой бинарный код от BCB5 отлично работает на всех Windows и будет работать дальше. А шарп настораживает.
У кого-нибудь был похожий выбор? Спасибо.
На работе лежит проект, сделанный аж на Builder C++5. Много форм и элементов, СУБД,fastreport и пр.
Надо его переписать, но не могу сделать выбор. Кроссплатформенность не нужна. Важное — нужен мощный генератор отчетов.
Нынешняя громила Embarcadero Builder пугает. Смотрю в сторону Qt — очень радует он меня, и размер distroDLL в принципе адекватен.
А вот к шарпу отношусь напряженно, отчасти из-за кучи фреймворков и страха совместимости между ними. Мой бинарный код от BCB5 отлично работает на всех Windows и будет работать дальше. А шарп настораживает.
У кого-нибудь был похожий выбор? Спасибо.
Переходи на шарп, 12 лет назад плюнул на Борланд и не жалею.
FastReport прекрасно заменяется этим DevExpress XtraReports
FastReport прекрасно заменяется этим DevExpress XtraReports
У Microsoft с относительно недавних пор появилась такая штука как .Net-Standard. И как раз для того чтобы решать проблемы совместимости.
Если совсем грубо, то если вы пишите ваш код в библиотеке совместимой с определённой версией .Net-Standard, то он работает на любом фреймворке, который поддерживает эту версию.
Мне кажется что для C# гораздо лучше для сравнения и холиваров подходит Java. Эти два языка имеют похожие парадигмы и идеи и рыночные ниши в которых конкурируют. Это два детища microsoft и oracle которые были созданы в одинаковых условиях конкурентной борьбы.
Но С++ был создан с другими целями, гораздо раньше у него своё мировоззрение и идиомы. С++ не похож на эти два языка. Но на нём можно писать код мало отличимый (благодаря zero cost abstraction и богатому функционалу) от многих других языков.
Но С++ был создан с другими целями, гораздо раньше у него своё мировоззрение и идиомы. С++ не похож на эти два языка. Но на нём можно писать код мало отличимый (благодаря zero cost abstraction и богатому функционалу) от многих других языков.
Идеализм этот с некоторыми от C++, «убрать макросы», ну come on. Как я без макросов организую себе удобоваримые properties в классах, например? Пофиксите мне язык, добавьте адекватные class properties чтобы без этого вот бесконечного .set_value (a.get_value () + b.get_value()), добавьте named orderless function arguments, чтобы я мог тренировать свою память где-нибудь ещё кроме как привязки аргумента к его имени «на глазок», и проводить вечера с семьёй, а не с перетасовыванием аргументов при рефакторинге — вот тогда поговорим о удалении макросов. А пока я это всё только макросами и могу более-менее организовать, чтобы писать линейный код, а не продираться сквозь завалы тривиального синтаксиса.
Я однажды узнал перевода слова get с английского языка. Теперь применять префикс get в методах получения значений морально сложно.
Приведу некоторые почти очевидные примеры:
Во многих библиотеках (например Qt) трендово сейчас называть методы получения свойств так же как и свойство, что повышает читабельность программы особенно среди англоязычных программистов.
Приведу некоторые почти очевидные примеры:
man.get_married();
bank.get_money();Во многих библиотеках (например Qt) трендово сейчас называть методы получения свойств так же как и свойство, что повышает читабельность программы особенно среди англоязычных программистов.
Пример с get_married() просто ужасен.
Уже давно все нормальные люди для bool проперти используют is вместо get.
Что лучше, gameObject.GetDisabled() или gameObject.IsDisabled() ?
ИМХО, 2 вариант гораздо лучше читается.
Для bool проперти is перфикс — отличный выбор, никто же не спорит. Но ведь это может быть и не булевская переменная, а обьект — ребро социального графа.
Речь о get VS noget.
А get_married() лишь яркий пример который на слуху у многих людей, что бы понять почему get для пропертей плох.
Речь о get VS noget.
А get_married() лишь яркий пример который на слуху у многих людей, что бы понять почему get для пропертей плох.
Для устранения путаницы должно быть так, ИМХО:
man.get_married(woman) — женить man на woman.
man.is_married() — женат ли man?
man.is_married(woman) — женат ли man на этой woman?
man.get_wife() — получить информацию о той woman, на которой женат этот man.
но с полноценными пропертями это переписывается красивее…
man.GetMarried(woman) — жениться
man.Wife — возвращает жену или null
man.IsMarried — возвращает man.Wife != null
man.IsMarried(woman) — возвращаеет man.Wife == woman
Для многоженства надо писать вариант с man.Wives, с возвратом массива\списка\иного IEnumerable, ну и в прочем учесть
Вот я хотел это написать, но комментарий отредактировать не получилось.
Так-то стоит обоих наследовать от Person.
Не на partner, а на spouse тогда уж.
И, кстати, толерантность тут ни при чём — с симметричными отношениями попросту проще работать.
man.Wife — возвращает жену
Где-то задумался один Брэд Питт.
man.get_married(woman) — женить man на woman.
Главное не тащить это в публичный интерфейс!
man.IsMarriedTo(woman) же
> Во многих библиотеках (например Qt) трендово сейчас называть методы получения свойств так же как и свойство, что повышает читабельность программы особенно среди англоязычных программистов.
Yes. От безысходности. Но работал довольно давно с библиотекой, там .married() ещё возвращало ссылку на значение вместо поддержки тривиальных сеттеров, так что можно было .married() = false;. С тех пор косо посматриваю на безпрефиксные геттеры и сеттеры. Ну а проблем расширить C# при этом никогда не было: named parameters в C# 4, properties изначально, и т.д. и т.п. (Сам пишу 90% времени на С++).
Yes. От безысходности. Но работал довольно давно с библиотекой, там .married() ещё возвращало ссылку на значение вместо поддержки тривиальных сеттеров, так что можно было .married() = false;. С тех пор косо посматриваю на безпрефиксные геттеры и сеттеры. Ну а проблем расширить C# при этом никогда не было: named parameters в C# 4, properties изначально, и т.д. и т.п. (Сам пишу 90% времени на С++).
Да, надо геттеры делать константными, что также будет ожидаемо для пользователей API. Иначе возможны гораздо более странные примеры.
От безысходности.
А почему не просто от разумности? Какой-то идиот когда-то придумал писать get_xxx() вместо просто xxx() и все за ним повторяют. А эти просто не стали.
properties изначально
Только лучше ими по возможности не пользоваться. Так как properties имеют сильно расширенную семантику по сравнению с филдами и методами: property descriptors и всё что через них работает. Если я встречаю где-нибудь в десктопной программе property вместо метода, я вынужден искать, нет ли где на неё binding'а или сериализации или ещё чего-то такого.
Соглашусь! Реализация адекватных property-классов обёрток в C++ — то ещё развлечение. Обычно «узбагоиваемся» и делаем наподобие такого:
#include <iostream>
class C {
private:
struct { int field; } fields;
public:
int field() const { return fields.field; }
void field(int v) { fields.field = v; }
};
int main() {
C c;
c.field(12);
std::cout << c.field();
}добавьте named orderless function arguments
А ещё отдельный котёл в аду должен быть предусмотрен для того, кто решил, что возможность опускания имён параметров в объявлении функций — это нормально.
void some_function(int, int, int);А ещё отдельный котёл в аду должен быть предусмотрен для того, кто решил, что возможность опускания имён параметров в объявлении функций — это нормально.
А если это tag dispatch?
Там не принято именовать фейковые аргументы. Варнинги одна из причин.
Если это внутренний код библиотеки, не предназначенный для чтения её пользователем, то никаких проблем. Но когда такое пролазит в публичный интерфейс, то теряется самодокументированность кода.
Фича языка от этого никуда не денется.
Да, в C++ есть многое, что не нравится многим другим.
И ктото, возможно, считает также что авторы UB или aliasing`а или Elvis operator`а должны быть к том же котле.
Особенно есть множество фич которые можно использовать во вред или неправильно. Но это не повод обижать авторов какой то фичи, а повод задуматься о причине по которой она появилась в языке.
Так же все эти фичи делают C++ таким какой он есть, не похожем на все остальные.
Да, в C++ есть многое, что не нравится многим другим.
И ктото, возможно, считает также что авторы UB или aliasing`а или Elvis operator`а должны быть к том же котле.
Особенно есть множество фич которые можно использовать во вред или неправильно. Но это не повод обижать авторов какой то фичи, а повод задуматься о причине по которой она появилась в языке.
Так же все эти фичи делают C++ таким какой он есть, не похожем на все остальные.
Имена не видно в точке вызова функций
Это от IDE зависит. В случае с С# и VS имена аргументов как раз видно в точке вызова.
Имена не дают полной информации. int time — это что?
Они дают больше информации. Другое дело что имена надо тоже правильно давать.
Если вы вдруг поменяете API и порядок/семантику аргументов, то компилятор тоже не даст вам по рукам.
Поэтому когда аргументов много и/или есть относительно высокий шанс спутать их порядок, то рекомендуется использовать DTO. Это проблему целиком не решает, но обычно уменьшает вероятность что-то напутать.
А пуллреквесты на гитхабе (возможно, своём тырпрайзном) или фабрикаторе вы тоже в VS ревьювите? Или там, не знаю, git blame какой-нибудь.
Хороший вопрос. Никогда не обращал внимания есть там это или нет:)
Но даже если и нет во время ревью, то как минимум в разработке это есть и помогает.
И вы же не будете утверждать, что start_periodic_digging(int period_in_msecs, int start_time_since_1970, int length_in_km) лучше предыдущего варианта без имён переменных?
Это конечно достаточно субъективно и вопрос привычки. Но могу сказать с тех пор как мы среди всего прочего стали следить за более-менее "говорящими" именами методов, переменных и параметров, то лично мне работать стало гораздо удобнее.
Только имена вы даёте на порядок-другой чаще, чем создаёте новые типы, поэтому и глаз замыливается, и лениться более охота.
Тоже кстати вопрос привычки. Поначалу было сложно и часто приходилось размышлять над подходящим именем. Сейчас уже всё как-то на автомате происходит.
Но DTO — это тип, а значит, моё исходное утверждение в силе :)
Ок, тут не поспоришь, пункт за вами :)
Подставим вместо foo какой-нибудь operator -. Упс, кажется, все эти возражения уже не так хорошо смотрятся :-)
Сигнатура (int, int, int) вообще "не очень" по сути своей, там уже явно тянет отдельной структурой Params.
Генерить абстракцию на каждый чих — тоже не лучшая идея.
Зависит от конкретной ситуации и требований. С методом, допустим, принимающим восемь строк очень неудобно и ошибкоопасно работать — а это случай из реальной практики. Обертка всего этого в DTO убрала кучу «случайных» ошибок.
А мы и не говорим о функциях, принимающих восемь параметров. Разумный максимум — 3-4 параметра. Имеет ли смысл заворачивать их в DTO — большой вопрос хотя бы из соображений удобства вызова функций и эффективности (соглашения о вызовах, передача аргументов через регистры на x64 архитектуре).
3-4 однотипных — «ну неудобно». С т.з. производительности, конечно, нужно смотреть в каждом конкретном случае. В том же C++ влияние на производительность от «дополнительных DTO» — гораздо сильнее, чем в managed-языках, но ключевой момент именно в балансе «удобство\эффективность\производительность», в зависимости от конкретных целей и задач.
Вы сами ответили на свой вопрос: чтобы получить удобоваримые properties, они должны быть в языке, как они сделаны в C#. Макросы — это временная заглушка для разных проблем, которые нужно решать правильно, а не «как получилось».
Та properties есть везде кроме стандарта. А в стандарте их нет только потому что любой стандартизированный/нативный для ядра языка формат будет ущербный по сравнению с тем что можно запилить на шаблонах за несколько часов.
А зачем вообще нужны проперти в классах? Вроде существует рекомендация делать публичные поля в структурах под это дело
Дмитрий: Ну, zero cost abstraction — это ассемблер. Если мы хотим вообще zero cost abstraction, надо писать всё на ассемблере.
Ребят, после этой цитаты хоть кто-то серьёзно относится к этой дискуссии?
«Всем известно, что нет ничего глупее споров «какой язык лучше»»
@
«Давайте устроим спор какой язык лучше»
@
«Давайте устроим спор какой язык лучше»
Мне кажется, что сама попытка сравнить некорректная.
Шарпы — это язык общего назначения. С развитием Blazor и Core он позволяет писать на одном стеке хоть под браузер, хоть для сервера на Линукс. Это удобно тем, что позволяет использовать одинаковые библиотеки, шарить модели и логику и эффективнее использовать разработчиков между различными частями проектов. И хотя дотнет сделал гигантский шаг вперед в производительности с Core и аппаратными инструкциями, это все еще очень быстрая платформа общего назначения.
Плюсы — это язык специального назначения сейчас по факту. В основном он используется для задач близких к железу или требующих серьезных оптимизаций. Он быстрее, сложнее и дает больше контроля, но требует совершенного иного уровня подготовки и кругозора разраба.
Соответственно, никто не будет писать промышленный веб-портал helpdesk на плюсах, ибо затраты на разработку никогда не окупятся выигрышем в железе. И наоборот, никто (почти) не будет пытаться писать драйвера на C# cosmOS Поэтому что тут сравнивать, я не знаю.
П.С. Что касается обучения, то очевидно, текущий подход устарел. Нет никакого смысла учить людей пузырьковой сортировке потому что обычное программирование давно ушло от решения низкоуровневых задач к высокоуровневым. Я думаю 99% Дотнет разрабов понятия не имеют, как под капотом в Linq сортируются массивы, что не мешает им писать хороший и быстрый код. Алгоритмы сортировки и их реализация, тонкости размещения объектов в стэке нужны только компьютерным специальностям (а программирование у нас учат все технические, а не только программисты) и то, после того, как они научатся использовать стандартные фреймворки.
Я бы сейчас бы учил бы людей как раз на C#:
1) Основам синтаксиса
2) Правилам оформления кода
3) Программированию вида Asp.Net Core Blazor в самом простейшем виде
4) Умению находить и использовать готовые пакеты (а-ля выгрузку в эксель и логирование)
Такой курс позволил бы иметь готовые проекты, немного разобраться в экосистеме и не утонуть в магии указателей. Так как я преподавал даже не C++, а Дельфи, и люди уже не понимали что и как. И вот когда с простейшими вещами проблем не будет, вот тут уже можно рассказывать, а как оно на самом деле происходит.
Шарпы — это язык общего назначения. С развитием Blazor и Core он позволяет писать на одном стеке хоть под браузер, хоть для сервера на Линукс. Это удобно тем, что позволяет использовать одинаковые библиотеки, шарить модели и логику и эффективнее использовать разработчиков между различными частями проектов. И хотя дотнет сделал гигантский шаг вперед в производительности с Core и аппаратными инструкциями, это все еще очень быстрая платформа общего назначения.
Плюсы — это язык специального назначения сейчас по факту. В основном он используется для задач близких к железу или требующих серьезных оптимизаций. Он быстрее, сложнее и дает больше контроля, но требует совершенного иного уровня подготовки и кругозора разраба.
Соответственно, никто не будет писать промышленный веб-портал helpdesk на плюсах, ибо затраты на разработку никогда не окупятся выигрышем в железе. И наоборот, никто (почти) не будет пытаться писать драйвера на C# cosmOS Поэтому что тут сравнивать, я не знаю.
П.С. Что касается обучения, то очевидно, текущий подход устарел. Нет никакого смысла учить людей пузырьковой сортировке потому что обычное программирование давно ушло от решения низкоуровневых задач к высокоуровневым. Я думаю 99% Дотнет разрабов понятия не имеют, как под капотом в Linq сортируются массивы, что не мешает им писать хороший и быстрый код. Алгоритмы сортировки и их реализация, тонкости размещения объектов в стэке нужны только компьютерным специальностям (а программирование у нас учат все технические, а не только программисты) и то, после того, как они научатся использовать стандартные фреймворки.
Я бы сейчас бы учил бы людей как раз на C#:
1) Основам синтаксиса
2) Правилам оформления кода
3) Программированию вида Asp.Net Core Blazor в самом простейшем виде
4) Умению находить и использовать готовые пакеты (а-ля выгрузку в эксель и логирование)
Такой курс позволил бы иметь готовые проекты, немного разобраться в экосистеме и не утонуть в магии указателей. Так как я преподавал даже не C++, а Дельфи, и люди уже не понимали что и как. И вот когда с простейшими вещами проблем не будет, вот тут уже можно рассказывать, а как оно на самом деле происходит.
Вы ничего не перепутали? Язык с GC универсальным быть не может по определению. Соответсвенно шарп — это узконишевый язык, основное назначение которого — кастомизация кодом сборок компонентов WinForms/WPF. При этом шарп имеет принципиальные противопоказания к применению в подавляющем большинстве задач индустрии, особенно в наиболее актуальных на сегодняшний день — робототехнике и промавтоматике.
А вот плюсы — это таки универсальный язык по определению, и годен к применению в любой сфере.
А вот плюсы — это таки универсальный язык по определению, и годен к применению в любой сфере.
Подавляющее большинство программирования — это backend, frontend, всякий банковский софт и прочий кровавый энтерпрайз. А вот робототехника и промавтоматика — это нишевые области.
Да что вы. Реальный экономический выхлоп дают таки только робототехника промавтоматика и счет по наукам. Вспомогательным является учет, в т.ч. банковский. И даже при том что в этих сферах работает 10% от общего количества разрабов, это и есть 100% разрабов с профессиональным образованием, которые и решают 99% задач индустрии вообще. Все же остальные казуалочки и социалочки — это сфера личного потребления и соответсвенно не более 1% задач и потока финансов индустрии, а соответственно и натягивают туда неквалифицированных разрабов, пытаясь скомпенсировать качество количеством. Вот как раз для таких шарп и предназначен. И именно поэтому основан на яве, которой моск в американских школах насилуют всем поголовно, И Майкрософт прекрасно понимали в исходе абсурдность пытаться создать на этой ошибке природы каких либо профессиональных средств разработки. Но нужна был им как раз замена ворд, эксель и визуал бейсика, позиционируемого как средства для мелкой кастомизации готового софта и создания мелких утилит, производимых непрофессионалами.
Сфера личного потребления — это 1% потока финансов индустрии
Поскольку в развитых странах на сферу услуг приходится 70-80% всей экономики, было бы очень любопытно увидеть какие-нибудь источники, подтверждающие ваши слова о «1% потока финансов».
Ну в промавтоматике языки общего назначения используются редко. В основе там iso 61131.
А вот робототехника это эмбеддед со всем вытекающими на С/С++.
А вот робототехника это эмбеддед со всем вытекающими на С/С++.
Ваша реакция на C# неадекватна, при том, что совершенно точно вы не писали на нем годов с 2005х, т.к. ваши представления о производительности, сборщике мусора и прочем явно с тех пор.
Кроме того, ваше восприятие рынка также неадекватно. 95% софта — это как раз средства автоматизации управления предприятиями, банковский софт и прочие сайтики-визитки. Именно для этого и нужен C#. Я вот взял, и построил простенький сайт с нуля на Asp.Net Blazor за день. При этом у меня и с базой работа, и логирование, и бизнес-логика и UI. По факту — готовый проект. Жрет, если правильно работать с ORM порядка 100-120мб памяти с одновременной работой 30 пользователей. А если добавить кэширование, то web-api может десятки тысяч запросов в секунду держать.
А теперь, внимание вопрос. Сколько времени у вас займет написать такое на C++? Что бы и с базой работало, и чтобы логи были, чтобы шаблонизатор был для UI и чтобы перформанс был выше, чем на C#? Ну и чтобы это все можно было поддерживать и было читабельно. За неделю управитесь? Или вам месяц нужен?
Еще раз, платформа и язык общего назначения — это такая платформа, которая позволяет решать 90% задач дешево и эффективно. Я на ассемблере могу написать вообще все, но он никаким боком не будет общего назначения, так как сложно, дорого и долго.
Кроме того, ваше восприятие рынка также неадекватно. 95% софта — это как раз средства автоматизации управления предприятиями, банковский софт и прочие сайтики-визитки. Именно для этого и нужен C#. Я вот взял, и построил простенький сайт с нуля на Asp.Net Blazor за день. При этом у меня и с базой работа, и логирование, и бизнес-логика и UI. По факту — готовый проект. Жрет, если правильно работать с ORM порядка 100-120мб памяти с одновременной работой 30 пользователей. А если добавить кэширование, то web-api может десятки тысяч запросов в секунду держать.
А теперь, внимание вопрос. Сколько времени у вас займет написать такое на C++? Что бы и с базой работало, и чтобы логи были, чтобы шаблонизатор был для UI и чтобы перформанс был выше, чем на C#? Ну и чтобы это все можно было поддерживать и было читабельно. За неделю управитесь? Или вам месяц нужен?
Еще раз, платформа и язык общего назначения — это такая платформа, которая позволяет решать 90% задач дешево и эффективно. Я на ассемблере могу написать вообще все, но он никаким боком не будет общего назначения, так как сложно, дорого и долго.
Все так. Делфай, к слову, тоже получил нормальные Web библиотеки (UniGUI, TMS Web Core) — все быстро, удобно и просто — накидал формочки, воткнул коннекты к базе, и через день у тебя готовое веб приложение на 5-10 форм. Не нужно вникать в JS. Не нужно делать связку бэк <> фронт, все максимально само. Можно и какой-то ORM добавить — mORMot, например. Тогда и SQL нужен постольку.
Что бы и с базой работало,Для этого код писать не надо от слова совсем.
и чтобы логи были,
Вы считаете трудной задачей заменить cout на другое название а «Hello World» на другую строку? Все с вами ясно.
чтобы шаблонизатор был для UIПодробнее можете рассказать что вы под этим понимаете?
чтобы перформанс был выше, чем на C#
Знаете есть такое сравнение — тормозит как скайп. Или хотите сказать скайп не шарпом изуродовали?
За неделю управитесь? Или вам месяц нужен?
Вы главное не забывайте что C# builder aka WinForms это настолько жалкий обрубок Дельфы и С++ Builder что борланд который его делал просто отказался участвовать в релизе. Причем обрубок именно в продуктивности именно создания средств учета. Ну и еще один такой момент не путайте языки и фреймверки это две большие разницы. Да и вам же в первую очередь контраргумент. Потому что именно в плане фреймверка именно визуальной разработки именно средств учета/БД шарп и сливает по определению. При этом у шарпа он один. А у плюсов их много.
Знаете есть такое сравнение — тормозит как скайп. Или хотите сказать скайп не шарпом изуродовали?
Ядро Скайпа на С++, гуи старой версии на Delphi а новой версии на electron, так что да C# тут непричём
Для этого код писать не надо от слова совсем.
А как у вас C++ код будет читать записи с сервера БД? Ну я даже нашел ORM ODB, но синтаксис и объем мусорного кода там гигантский, а таких фишек как группировка и возврат анонимных типов такого небось еще 10 лет не будет.
Вы считаете трудной задачей заменить cout на другое название а «Hello World» на другую строку? Все с вами ясно.
Вы не поверите, но в нормальном мире логи желательно отправлять на отдельный сервер, обычно это MongoDB, ну и там опять-таки нужно уметь с этим работать. В богомерзком C# есть возможность простым измением конфига писать сразу в 20+ платформ serilog. А как у вас там в C++?
Подробнее можете рассказать что вы под этим понимаете?
Шаблонизатор это модуль, который на входе берет ваш шаблон с разметкой и кодом, а на выходе выдает метод, на вход которого подаются данные, например из таблички БД, а он генерит HTML код. Кстати, в богомерзком C# сейчас рассматривают возможность заменять HTML например на WPF, и внезапно, можно будет одну и ту же UI логику использовать и для веба, и для десктопа.
Знаете есть такое сравнение — тормозит как скайп. Или хотите сказать скайп не шарпом изуродовали?
Как вам уже сказали, скайп ни разу не был написан на C#. Снова два балла, пересдача.
Потому что именно в плане фреймверка именно визуальной разработки именно средств учета/БД шарп и сливает по определению. При этом у шарпа он один. А у плюсов их много.
У Шарпа есть вот просто для БД: EF, EF Core, NHibernate, Dapper, чистый ADO.Net в зависимости от того, что хочется/нужно. Что там есть у плюсов из ORM, чтобы хоть наполовину бы закрывало то, что умеет EF, я не знаю.
Короче поток бреда такой, что я даже не знаю, как это комментировать. Ясно видно, что гражданин крайне далек от разработки и его познания окончились видимо на C++ Builder в 2005 году, до релиза .Net 2.0
Кроме того, ваше восприятие рынка также неадекватно. 95% софта — это как раз средства автоматизации управления предприятиями, банковский софт и прочие сайтики-визитки
Оглянитесь вокруг. Наиболее распространенный софт это тот который управляет коммутацией фаз у вас в лампочке. Дальше по распространенности идет тот который управляет вашими холодильником микроволновкой, контроллером впрыскав автомобиле и т.д. Дальше тот который управляет изготовлением всего этого на станках. Потом тот при помощи которого все это проэктируют. Ну а потом тот на котором производят научные исследования для создания всего этого. И только уже потом идет учетный софт мизерная часть которого банковский. Если вы кроме сайтов-визиток ничего не видели это не значит что сайты визитки самые распространенные.
Кажется, Царя проапгрейдили до Царь++.
Да был (и в каком-то виде есть) такой персонаж на linux.org.ru. С характерным стилем и тезисами. А также клоны и подражатели. Один из основных тезисов (как он мне запомнился) такой: "всё можно и нужно писать на Си, а что нельзя писать на Си, то и не нужно".
Но он (как виртуальная мультиличность) не только и столько на абстрактные темы вещал, а в обсуждении конкретики участвовал, вещая дурь вперемешку с разумными и верными утверждениями, и с невероятным апломбом по типу "вы все ламерьё, вебнули, обезъяны, а я — Царь сишечки".
Вот пример: https://www.linux.org.ru/forum/development/15256164?cid=15260615
Да что вы. Реальный экономический выхлоп дают таки только робототехника промавтоматика и счет по наукам. Вспомогательным является учет, в т.ч. банковский. И даже при том что в этих сферах работает 10% от общего количества разрабов, это и есть 100% разрабов с профессиональным образованием, которые и решают 99% задач индустрии вообще. Все же остальные казуалочки и социалочки — это сфера личного потребления и соответсвенно не более 1% задач и потока финансов индустрии
Ну вот смотрите: я работаю на транспортный концерн. За то время что я на него работаю мы ввели в строй систему оптимизации маршрутов и загрузки грузовиков. По прикидкам концерна это минимум 4-5% сэкономленных километров. А местами и все 10%. Звучит может быть немного, но если взять тысячи грузовиков и миллионы(а то и миллиарды) километров, то получается совсем неплохой "экономический выхлоп".
Ещё мы перевели почти всю сопроводительную документацию с бумаги в дигиталку. А это тонны сэкономленной бумаги и огромное количество сэкономленных человекочасов. Тоже никто не жалуется.
И всё это на "казуальном сишарпе". Так что прежде чем подобные заявления делать было бы неплохо сначала хотя бы чуть-чуть проинформироваться.
И всё это на «казуальном сишарпе»Только вот весь остальной мир делает это на нативных языках. Потому что они позволяют иметь гораздо более продуктивные в этом плане фреймверки с гораздо более развитыми средствами визуальной разработки.
Если у вас есть статистика, то я с удовольствием на неё посмотрю. А так вы уж извините, но это для меня больше похоже на какие-то ваши личные фантазии.
П.С. И особо интересно мне было бы посмотреть на процент написанных иключительно на нативном языке "экосистем", включающих в себя в том числе и десктоп-приложения, B2B сервисы, веб и мобильные приложения.
Все очень просто. Ты разрабатываешь Великую Бухгалтерскую Программу.
При этом сидишь за компьютером, БИОС которого написан на Си, ОС на Си, все драйвера на С, IDE тоже возможно на Си. Итого статистика 1:10 =)
И стул, который пригорает, тоже спроектирован в написанном на С CAD'e )))
При этом сидишь за компьютером, БИОС которого написан на Си, ОС на Си, все драйвера на С, IDE тоже возможно на Си. Итого статистика 1:10 =)
И стул, который пригорает, тоже спроектирован в написанном на С CAD'e )))
И особо интересно мне было бы посмотреть на процент написанных иключительно на нативном языке «экосистем», включающих в себя в том числе и десктоп-приложения
Ну есть статистика по поддерживаемым лицензиям на средства разработки. Для Дельфы/билдера это 500k действующих лицензий. Т.е. практически весь сектор внутрикорпоративного софта крупных корпораций и его веб-мосты. Таких как Сименс, Самсунг и т.д.
И по продуктивности есть кое какая инфа. К примеру среднестатический клиент-банк для корпоративного клиента (это с сервером и рабочей группой на стороне клиента мультиподписями синхронизацией баз, процессингом, его изоляцией как внутренней так и внешней, завязкой на аккаунт-менеджеров, подсистемой администрирования ключей и т.д. мелочью) делается на дельфе или билдере двумя разрабами среднего пошиба месяца за два-три.
И по шарпу с жабой есть интересные наблюдения. Значит есть тут три индустриальных гиганта в городе. Два металлургических и один машиностроительный. Так вот пришли мы на практику в 98-ом на один из них у них там как раз новый отдел — новую ERP R3 внедряют. Там типа сверхпродуктивный язык кастомизации новейший ява. Ну договорились что друг другу не мешаем и разошлись (мне как бы на свой машиностроительный гигант бежать надо было к самому группа практикантов с технаря должна прийти была). Ну в общем к 2002-ому где то так внедрение полным ходом шло на всех трех гигантах. Потом там язык поменяли на новейший шарп и винформз все эти три отдела возрадовались наконец то мы ее докастамизируем (одним из этих отделов к тому времени уже мой одногрупник руководил так шо видел как они там типа рады были по самые немогу). Ну в общем суть в том что на металлургических гигантах ее до сих пор полным ходом внедряют. А машиностроительный 5 лет назад обанкротился и закрылся.
Ну есть статистика по поддерживаемым лицензиям на средства разработки
Посмотреть на неё можно где-то?
Для Дельфы/билдера это 500k действующих лицензий.
И что это должно доказывать? Особенно в контексте моего вопроса?
И по продуктивности есть кое какая инфа. К примеру среднестатический клиент-банк для корпоративного клиента (это с сервером и рабочей группой на стороне клиента мультиподписями синхронизацией баз и т.д.) делается на дельфе или билдере двумя разрабами среднего пошиба месяца за два.
А это то вообще причём? И если уж, то за какое время такое же делается "двумя разрабами среднего пошиба" на других языках? Ну для сравнения.
И если уж, то за какое время такое же делается «двумя разрабами среднего пошиба» на других языках?Это в первую очередь вопрос не языка. Это вопрос умения фреймверка работать с созданием системы учета по принципу zero code. Т.е. преимущественно визуальная разработка в первую очередь бизнес-логики работы с БД. Т.е. используется факт что оформление информационной постановки на компе по телодвижениям почти на 100% совпадает с реализацией. И вот ни ява ни шарп подобный принцип визуальной разработки бизнес-логики потянуть не смогли. Как Борланд не старались их этому обучить, даже в случае шарпа совместно с майкрософтом. GC мешает. Он лишний в ООП.
Это в первую очередь вопрос не языка.
Да неважно вопрос чего это в первую очередь. Приведите сравнение с альтернативными вариантами. Тогда это можно обсуждать.
П.С. Пока я если честно вижу кучу какой-то отсебятины и перепрыгивания с одного на другое. И слабо понимаю о чём это, зачем это и какое отношение это имеет к обсуждаемой теме.
Ну вот соседний с ними банк уже лет 10 все допиливает и допиливает свой клиент-банк на яве целыми двумя офисами в двух городах. Ну он правда на частного клиента ориентирован с одной стороны проще с другой вроде как объемней с третьей интеграцию с внутренними системами клиента и мультиподписи обеспечивать не надо, c четвертой интерфейс клиентский у них по определению веб а из html формат описания гуя никакой. Ну кое что более менее внятное оформилось. но как бы элементарных поисков нет хотя писал им на этот счет еще лет 5 назад (сам пользуюсь неудобно) сказали дада надо сделать. Ну как бы эту кухню я изнутри не видел. Но насколько понимаю срамо-агилом во всю воняет.
Ну вот соседний с ними банк уже лет 10 все допиливает и допиливает свой клиент-банк на яве целыми двумя офисами в двух городах.
И опять же: что это должно доказывать? И если я сейчас приведу пример какой-нибудь шарашкиной конторы где на С++ ничего толкового написать не могут, то это по вашему будет означать несостоятельность C++?
Хорошо. Давайте по другому. Потому что так можно все что угодно моя твоя не понимает. Надо или одной компании продукты сравнивать на обоих языках, причем одного направления. Но это бессмысленно. Потому что весовая категория разная. Единственное где так получается сравнить — это сама винформз с VCL. VCL практически монополист в своей нише. WinForms разработчик в релизе участвовать отказался. Релиз Delphi.NET тоже закончился эпическим фейлом. Настолько куцей и непродуктивной была по сравнению с нативной. Точно так же как и майкрософтовская С++.NET живет только потому что MS конкуренцию в нативном проиграл с треском а менеджед купил — т.е. понял что не его уровня задача и даже для себя не может сделать, а другого средства доступа к WinForms нет.
Или конкректно с графами и диаграмами показывать почему GC без ручного решения задачи управления взаимосвязями не способен обеспечить работу взаимосвязей по правилам ООП. Что и не позволяет вести на нем полноценную ООП разработку. А соответственно ни высокопродуктивных средствпреимущественно визуальной разработки бизнеслогики использовать не может, ни продуктивности разработки кода сравнимой с нативными языками, а особенно имеющими современные средства автоматики, не будет. Ей богу как будто на третьем курсе теорию графов не проходили и правила взаимосвязей в ООП — композиции и агрегации тоже никогда не слышали.
Или конкректно с графами и диаграмами показывать почему GC без ручного решения задачи управления взаимосвязями не способен обеспечить работу взаимосвязей по правилам ООП. Что и не позволяет вести на нем полноценную ООП разработку. А соответственно ни высокопродуктивных средствпреимущественно визуальной разработки бизнеслогики использовать не может, ни продуктивности разработки кода сравнимой с нативными языками, а особенно имеющими современные средства автоматики, не будет. Ей богу как будто на третьем курсе теорию графов не проходили и правила взаимосвязей в ООП — композиции и агрегации тоже никогда не слышали.
Единственное где так получается сравнить — это сама винформз с VCL.
И о чём нам именно это сравнение должно говорить? И если вы не можете нормально сравнивать и/или у вас нет адекватной информации, то зачем тогда ваши громкие заявления? И на чём они тогда вообще базируются?
Или конкректно с графами и диаграмами показывать почему GC без ручного решения задачи управления взаимосвязями не способен обеспечить работу взаимосвязей по правилам ООП.
Давайте, было бы интересно увидеть.
современные средства автоматики
Пелевин. Омон Ра.
Он произносил слово "автоматика" с такой чистой и мечтательной интонацией, что его лубянский кабинет, куда мы поднимались слушать лекции, на секунду словно превращался в резонатор гигантского рояля, но, хоть это слово всплывало в его речи довольно часто, никаких технических сведений он нам не сообщал, а рассказывал в основном житейские истории, или вспоминал, как партизанил во время войны в Белоруссии.
Ну считайте дважды два. В мире порядка 20 миллионов разрабов всего. из них с в/о по специальности порядка 2 миллионов. Ни в сектор корпоративного а тем более банковского учета, ни тем более в сектор автоматики без в/о не пустят. примерно 3/4 работают в сфере АСУТП, САПР и счета по наукам. и примерно оставшиеся пол миллиона в корпоративном учете. С учетом того что ни САПР на билдере не делают (ну там на вижак сели плотно еще в начале 90-х, вернее тогда он назывался MSC++), и в АСУТП если и пригоден фреймверк то очень ограниченно на выделенных терминалах. Ну в счете по наукам каую то часть лицензий юзают точно. Билдер в основном сюда позиционируется, в системы учета в основном дельфа. А остальные то где могут быть? А особенно если абсолютно точно известно что Борланд и потом Эмбаркадеро именно на крупные канторы ориентировано, а на мелочь им даже судя по их техническим решениям глубоко пофиг? Ну и продлевают эти лицензии как понимаете не для того чтобы они на полочках пылились.
Для Дельфы/билдера это 500k действующих лицензийБолее трех миллионов, если что.
Более трех миллионов, если что.
ну более трех миллионов то и прибрехать местами диллеры могли. или посчитать всех клиентов за все существование в том числе вышедших студенческих в те времена когда комьюнити-лицензии не было. А вот цифра более 500k. кототрую на эмбаркадере как то видел — ну это из серии точно не меньше. Хотя с Германии знакомые рассказывали — дельфа/билдер/плюсы/ада — другое не котируется в том числе в универах так и говорят — натив а то работу не найдете. У них там правда ситуация совсем не как у нас.
Ну вот что бы далеко не ходить:
www.embarcadero.com/ru/products/delphi/starter/free-download
www.embarcadero.com/ru/products/delphi/starter/free-download
Выбор более чем 3 миллионов разработчиков во всем мире
Хотя с Германии знакомые рассказывали — дельфа/билдер/плюсы/ада — другое не котируется в том числе в универах так и говорят — натив а то работу не найдете. У них там правда ситуация совсем не как у нас.
Вы знаете это очень интересно выглядит когда кто-то, со слов каких-то мифических знакомых, рассказывает людям живущим и работающим в Германии, что они оказывается работу не найдут...
И я вам ещё раз скажу: чушь вы полную несёте. В Германии сейчас нужны программисты практически на всех языках. И вот вам кстати для примера информация на тему самых востребованных программистов и языков:
https://entwickler.de/online/development/top-10-programmiersprachen-redmonk-tiobe-pypl-579886370.html
https://jaxenter.de/it-trends-deutschland-sprache-gehalt-tools-85752
https://t3n.de/news/programmierer-gesucht-developer-studie-programmiersprache-881255/
Надеюсь поймёте что там написано. В крайнем случае гугл-транслэйтор вам в помощь или друзей попросите перевести.
А при чем тут билдер к gcc? У нас же разговор пошел про высоко продуктивные фреймверки? Ну под плюсы их разных хватает. В том числе под стандартные плюсы. И все куда попродуктивней WinForms/WPF будут которыми шарп ограничен.
А это только про эмаркадеру. Ее фреймверк ее расширений требует. другие компиляторы с ним работать не будут. Хотя у самого него компилятор на основе __clang сделан.
Но тут сравнение с шарпом и винформзом очень показательное. Одного папши детки то.
А это только про эмаркадеру. Ее фреймверк ее расширений требует. другие компиляторы с ним работать не будут. Хотя у самого него компилятор на основе __clang сделан.
Но тут сравнение с шарпом и винформзом очень показательное. Одного папши детки то.
Очень странный спор, когда коснулись GPGPU даже не упомянули про OpenCL хотя он как раз кроссплатформенный, что может даже работать на CPU. Но вообще я все же за C# так как он покрывает очень много бизнес кейсов и гораздо удобен для них нежели С++. C# проще учить и на нем проще делать отладку. А во многих нишах, где требуется более низкоуровневое программирование, высокая производительность я бы использовал чистый Си или Rust. Таким образом я не вижу для каких задач С++ подходил бы лучше чем C#/Java, Си/Rust, TypeScript, python.
Таким образом я не вижу для каких задач С++ подходил бы лучше чем C#/Java, Си/Rust, TypeScript, python.
А если мыслить категориями не задач, а рыночными нишами?
Сколько на этой неделе можно нанять разработчиков на Rust?
Какой процент разработчиков на python готовы писать и отвечать за написанное в многопоточной среде?
Сколько можно найти C# девелоперов с многолетним опытом в эмбеддед и линукс?
Так или иначе рыночные ниши фрагментировались както, библиотеки в предметных областях написались в определенных исторических условиях, специалисты выучились и набрались опыта. Решать задачи нестандартными методами\языками\специалистами из других областей можно, но дорого.
"Что и требовалось доказать" — язык нужно выбирать под задачу. Подавляющее большинство задач "общего назначения" — лучше решаются на C#, чем на C++, т.к. C++ сейчас является всё-таки языком "местного назначения".
Он рвёт в клочья в определенном наборе задач, но слишком сильно удорожает разработку "in general".
P.S. Сам знаю оба, использую по уместности.
Он рвёт в клочья в определенном наборе задач, но слишком сильно удорожает разработку «in general».
Да дороже. Сейчас чаще получается рейты у плюсовиков выше, а доступность дешёвых ниже. Но ведь это не проблема языка, а резко возросший спрос рынка. Вот, например, в Киеве зашло около 10 крупных проектов, и спылесосили они всё что было доступно аж до уровня 4000usd по зарплате.
Понятное дело, что многие сферы, включая эмбеддед, перешли на более доступные альтернативы, и писать формочки/мобильные приложения/казуалки готовы на чем угодно только не С++. Шесть лет назад ситуация была сильно противоположная, думаю развитие языка дало сильный стимул рынку.
Он рвёт в клочья в определенном наборе задач, но слишком сильно удорожает разработку «in general»
При этом очень сильно снижает TOC.
Подавляющее большинство задач «общего назначения» лучше решаются на C#, чем на C++,— Ну к примеру ни одного САПР общего назначения на шарпе еще никто не видел. И ни одной СУБД общего назначения. И ни одного вебсервера общего назначения. И ни одной оси общего назначения. И не увидят никогда. Потому что если шарп таки довести до ума и сделать таки универсальным языком то получатся таки плюсы а не что то другое.
Вы так здорово скинули Си со счетов. Embeded лучше писать на Си, а прототипировать на python. Что то многопоточное очень удобно пишется на Go. Разработчики на Rust на рынке присутствуют в принципе. С++ хорошо подходит там, где много готового кода на С++ нет смысла переходить на что то еще. То есть С++ может в принципе неплохо справится со всем, но слишком немного задач, где бы он подходил лучше всего.
Не понятно почему Embedded лучше на C. C++ в чем — то уступает? Если это размер бинарника, то с отключенным rtti + exceptions отличия не должны быть существенно заметны для идентичного кода. В тоже время гораздо больше возможностей, огромная библиотека и выразительные конструкции которых нет в C. Яркий пример constexpr массивы которых порой очень не хватает и многие пишут кодогенераторы (частотные фильтры, флэш таблицы тригонометрии и прочее подобное).
Если это не совсем экстремальный эмбеддед с сотнями байт памяти, а что то уже за 5$ (cpu+ram), то там уже можно ставить boot to Qt и иметь вполне достойный инструментарий.
Не понятно почему многопоточное нельзя удобно писать на C++. Применяя правильные паттерны и абстракции я ни разу за 5 лет (Серверное ПО 100+ процессорных ядер) не столкнулся о проблемах о которых спрашивают на собеседованиях( deadlocks, race conditions, false sharing, memory barriers и пр). Более функционального и более удобного апи для векторизации и распараллеливания и многопоточности чем в с++ вообще мало где есть.
Опять же непонятно, почему прототипировать лучше на каком то языке, отличном от того, на котором будет разработка продукта. Поддерживать 2 и более кодовых базы в согласованном состоянии это невероятно сложно даже в рамках одного языка программирования. Даже если это 2к строк канонического+сайнтифик R\perl\python с 60% изменений, но которые дифф не может вообще никак сопоставить — это ад, и порой проще запортировать заново.
Если это не совсем экстремальный эмбеддед с сотнями байт памяти, а что то уже за 5$ (cpu+ram), то там уже можно ставить boot to Qt и иметь вполне достойный инструментарий.
Не понятно почему многопоточное нельзя удобно писать на C++. Применяя правильные паттерны и абстракции я ни разу за 5 лет (Серверное ПО 100+ процессорных ядер) не столкнулся о проблемах о которых спрашивают на собеседованиях( deadlocks, race conditions, false sharing, memory barriers и пр). Более функционального и более удобного апи для векторизации и распараллеливания и многопоточности чем в с++ вообще мало где есть.
Опять же непонятно, почему прототипировать лучше на каком то языке, отличном от того, на котором будет разработка продукта. Поддерживать 2 и более кодовых базы в согласованном состоянии это невероятно сложно даже в рамках одного языка программирования. Даже если это 2к строк канонического+сайнтифик R\perl\python с 60% изменений, но которые дифф не может вообще никак сопоставить — это ад, и порой проще запортировать заново.
Вот пример:
https://inobitec.com/products/dicomviewer/
Особенности: высокие требования к производительности, расчет как на CPU, так и на GPU с помощью OpenCL или CUDA, по-максимуму общая кодовая база как для разных десктопных платформ (Windows, Linux, MacOS X), так и мобильных (iOS, Android) — понятное дело, для мобильных в несколько облегчённом виде, но тем не менее. Сейчас это написано на C++ с использованием Qt. Как бы вы это писали на C# и с помощью чего?
Посыпаю голову пеплом, свою же область, на что учился, я и позабыл. Да, компьютерная графика всецело за С++. Хотя пока учился, то делал все из той же области на C# используя библиотечку OpenTK (OpenCL + OpenGL + OpenAL) кроссплатформенности тогда конечно же не было, сейчас вроде можно сделать и кроссплатворменно. Но С++ тут все же должен быть удобнее.
Я его не упомянаю потому что OpenCL существенно хуже CUDA по всем параметрам кроме проприетарности. Кода в 2 раза больше, инструменты отладки «как повезет» (CUDA Toolkit шикарный) и идея о том что один и тот же код можно писать и запускать и там и там — это идиллия, т.к. по факту все алгоритмы приходится все равно переписывать в стиле SIMT, а если нужно что-то дернуть из C++, никто не мешает пометить функцию как __device__ __host__.
Delphi/Lazarus в помощь: кроссплатформенность, быстрая сборка, второй работает на чем угодно вплоть до утюгов :) Интерефейсных компонент хватает, не нужно одним Qt ограничиваться (к слову — под него Lazarus) тоже собирает бинари. На распебери Лазарь не только собирает бинари но и среда работает.
А еще Лазарус обгоняет Питон!
Lazarus и Delphi это IDE. А язык называется Pascal. По возможностям он не отличается от C/C++, а по безопасности и удобству близок к C#. Производительность кода ограничена только качеством компилятора. Впрочем, можно прямо в коде использовать ассемблер, не полагаясь на компилятор.
Delphi — это и язык, и IDE.
Разница между Delphi и Pascal такая же, как между C++ и C.
Тогда почему у файлов Delphi расширение .pas? =)
DistortNeo прав, язык и самом деле называется Delphi. До определённой версии он назывался Object Pascal, но в Delphi 7 его переименовали в Delphi, так что с тех пор это действительно и IDE, и язык.
Формально — да. Хотя, разница между ObjectPascal и Delphi только в автоматическом разыменовывании типизированных указателей. То есть, можно не ставить @ и ^ во многих случаях.
В Lazarus и FreePascal это просто опция компилятора.
В Lazarus и FreePascal это просто опция компилятора.
Нет такого понятия как ObjectPascal. Есть Паскаль ISO/IEC 10206:1991 и есть недоразумение в виде Дельфи, которое меняется с каждой версией.
По безопасности и удобству он далеко взаду. А качество компилятора FPC описывается фразой «нативный неоптимизирующий компилятор»
Но в целом, надо было просто распознать сарказм в
По безопасности и удобству он далеко взаду. А качество компилятора FPC описывается фразой «нативный неоптимизирующий компилятор»
Но в целом, надо было просто распознать сарказм в
Из справки Delphi 7:
Delphi is a high-level, compiled, strongly typed language that supports structured and object-oriented design. Based on Object Pascal, its benefits include easy-to-read code, quick compilation, and the use of multiple unit files for modular programming.
Насчет ISO Pascal все понятно, это документированный стандарт, эталон. Как ANSI C.
Всякие Delphi, ObjectPascal, TurboPascal, VirtualPascal, FreePascal, PascalABC и прочие — диалекты, в которых что-то добавлено. Но в целом, ObjectPascal это ISO Pascal + OOP. Как C++, у которого тоже разные диалекты.
Delphi is a high-level, compiled, strongly typed language that supports structured and object-oriented design. Based on Object Pascal, its benefits include easy-to-read code, quick compilation, and the use of multiple unit files for modular programming.
Насчет ISO Pascal все понятно, это документированный стандарт, эталон. Как ANSI C.
Всякие Delphi, ObjectPascal, TurboPascal, VirtualPascal, FreePascal, PascalABC и прочие — диалекты, в которых что-то добавлено. Но в целом, ObjectPascal это ISO Pascal + OOP. Как C++, у которого тоже разные диалекты.
У Builder C++ расширение файлов .cpp, у Microsoft C++ расширение файлов тоже .cpp
Удачи с компиляцией Builder в MS Visual Studio
Удачи с компиляцией Builder в MS Visual Studio
C# писали в том числи люди из Borland-а.
Отсюда всеми любимые property в C#.
Правда некоторые любят заявлять что Borland мертв и там нет ничего полезного, забывая что много фишек C# это по сути Delphi/Builder
Отсюда всеми любимые property в C#.
Правда некоторые любят заявлять что Borland мертв и там нет ничего полезного, забывая что много фишек C# это по сути Delphi/Builder
Ну, зато виртуальная машина может, например, затюнить код для той или иной архитектуры.
очень странный аргумент. Мы можем скомпилировать плюсы в байткод вм и выполнять на целевой платформе. О состоятельности такого подхода можно судить в первую очередь по его популярности.
Когда-то разрабатывал только на С++ и был большим фанатом языка, писал для Embedded и библиотеки. Радовался уникальным пятиэтажным сочетаниям разноплановых языковых конструкций, а порой и макросов, которые позволяли мне получить гибкое решение для очевидных логических задач в стиле «вызови мне то, пока еще не знаю что». Каждый год чувствовал, что ну вот теперь-то я прокачался в языке — то OOP то templates, то Design Patterns, то S.O.L.I.D., то еще чего… Другие языки периодически посматривал, но как-то они не цепляли — ни Java, ни C# ни Python. А потом решил перейти на удаленную разработку, оказалось, что на С++ это сложно, начал учить web, и естественно javascript. А в javascript вдруг оказалось, что 90% всех моих логических задач решает то, что функция — это одновременно класс, объект, замыкание и экземпляр. То есть всего одна гибкая языковая конструкция решает все задачи. Добавьте к этому async/await для «многопоточности», для понимания которой кроме этих двух слов ничего не нужно. Добавьте typescript только, чтобы объявлять интерфейсы, которые так и так где-то все равно пришлось бы объявлять для документации, и которые при этом позволяют отлавливать ошибки рано, чем так гордится С++. И по сути, это все, что нужно держать в голове, чтобы писать на языке, решая конкретные бизнес задачи как full-stack разработчик, а не воображаемые проблемы в стиле «ой, у меня тут инкапсуляция нарушена, кто-то потом, используя мой код, сможет выстрелить себе в ногу».
Но что меня больше всего всегда выводило в С++, даже когда я только на нем и писал, это, разумеется стандартная библиотека. Написанная не для того, чтобы ее использовали. А как будто, чтобы показать всем: «Смотри, как я могу!»,- как ребенок в песочнице. Которая задала целый тренд мышлению С++ программистов совершенно не в том направлении, породив еще более форменное уродство под названием boost. И когда появился Qt — с человеческими интерфейсами (я, разумеется, не имею в виду UI, я имею в виду интерфейсы библиотеки), написанный для людей, он уже на этот тренд никак особо не повлиял.
Поэтому развивается С++ семимильными шагами или не развивается, мне как-то совершенно наплевать. Если придется возвращаться к программированию, где нужно думать не только об алгоритмической, но и других видах оптимизаций, я определенно начну учить Rust. Или тот же C#, если его допилили за эти годы. Но никак не в плюсы.
Но что меня больше всего всегда выводило в С++, даже когда я только на нем и писал, это, разумеется стандартная библиотека. Написанная не для того, чтобы ее использовали. А как будто, чтобы показать всем: «Смотри, как я могу!»,- как ребенок в песочнице. Которая задала целый тренд мышлению С++ программистов совершенно не в том направлении, породив еще более форменное уродство под названием boost. И когда появился Qt — с человеческими интерфейсами (я, разумеется, не имею в виду UI, я имею в виду интерфейсы библиотеки), написанный для людей, он уже на этот тренд никак особо не повлиял.
Поэтому развивается С++ семимильными шагами или не развивается, мне как-то совершенно наплевать. Если придется возвращаться к программированию, где нужно думать не только об алгоритмической, но и других видах оптимизаций, я определенно начну учить Rust. Или тот же C#, если его допилили за эти годы. Но никак не в плюсы.
нужно начать, а не плакать об упущенных возможностях…
тогда это,… кругозор появится
тогда это,… кругозор появится
А в javascript вдруг оказалось, что 90% всех моих логических задач решает то, что функция — это одновременно класс, объект, замыкание и экземпляр. То есть всего одна гибкая языковая конструкция решает все задачи.
Только вы забыли упомянуть цену этого.
Добавьте к этому async/await для «многопоточности», для понимания которой кроме этих двух слов ничего не нужно.
Ну еще бы, ведь к многопоточности это не имеет абсолютно никакого отношения. Расскажите мне, пожалуйста, как с помощью async/await распараллелить вычислительную задачу.
Только вы забыли упомянуть цену этого.
Да очень просто цена считается. Вот есть компания, ей нужно обеспечить бизнес процесс для сотрудников. Ее интерес — чтобы сотрудники имели заданный интерфейс взаимодействия друг с другом, чтобы работать эффективно, не тратить кучу времени на пересылку емейлов туда-сюда и иметь безопасный доступ к данным, ведь большая часть из них — еще и фрилансеры (переводчики, корректоры и т.п.). А еще хорошо бы знать, чем они там занимаются.
Для компании делается веб приложение. AWS бэкенд для него, при порядка 100 сотрудников в системе, обходится в 200$ в месяц, из них большинство уходит на базу данных. Ключевой для Вас момент — вычисления в Lambda на javascript — забирают 15$. Фронт энд запускается на любом обычном компьютере в браузере — это все что волнует компанию об его эффективности.
Разумеется, в такой ситуации самое дорогое для компании — это зарплата разработчика и скорость разработки. Поэтому на С++ такое никто не делает (хотя вроде ничего не мешало сделать в Lambda поддержку С++, это же чистые вычисления! Но нет же — с удивлением обнаруживаем там только Java, Go, PowerShell, Node.js, C#, Python и Ruby).
Ну еще бы, ведь к многопоточности это не имеет абсолютно никакого отношения. Расскажите мне, пожалуйста, как с помощью async/await распараллелить вычислительную задачу.
Вроде специально многопоточность в кавычки взял, нет, не помогло. Да, физически это к многопоточности не имеет ни малейшего отношения. А как часто Вам нужна именно физическая многопоточность? Чаще всего нужна многопоточность логическая — вот сейчас мне нужно делать А и Б одновременно, и чтобы ни одно из них не зависило от другого. async/await — это оно и есть. А вот как раз вычислительная задача с точки зрения конечного пользователя — это что-то неделимое, логически ему нужен просто конечный результат.
.Для компании делается веб приложение
Веб-приложениями мир не ограничивается. У вас, так сказать, та же болезнь, что и раньше, только наоборот — раньше вы считали, что на C++ нужно писать все, теперь вы считаете, что на нем не нужно писать ничего :) Вас просто кидает из крайности в крайность.
.Вроде специально многопоточность в кавычки взял, нет, не помогло.
Потому что async/await относятся к асинхронному выполнению, а не к многопоточности. Употребляйте термины правильно.
.А как часто Вам нужна именно физическая многопоточности?
Регулярно. Я-то не веб-приложения пишу. Каждой задаче — свой инструмент.
раньше вы считали, что на C++ нужно писать все, теперь вы считаете, что на нем не нужно писать ничего
Где я такое писал?
Я написал, что лично я постараюсь к С++ больше никогда не возвращаться. Как и к embedded. Хотя это мои личные пристрастия, я все равно подробно написал, почему для меня это так. Я совершенно четко понимаю, что в мире миллионы С++ разработчиков, триллионы legacy кода на С++, и ни сегодня ни завтра это никуда не денется. Так же как кучи процессоров и RTOS систем, для которых есть только С библиотеки, кучи графических и игровых движков и т.п. Но я считаю, что это потому, что так исторически сложилось, а не потому, что С++ лучше альтернатив. Если бы сейчас я выбирал язык под тот же круг задач, что я выполнял раньше (разработка управляющих программ для научных лазеров, например), я бы всеми силами постарался избежать использования С++, если это от меня зависит, и учил бы Rust. например.
Что в своем оригинальном сообщении я считаю реальностью, общей для всех — это полная ущербность стандартной библиотеки, которая сильно испортила общее направление развития языка. Я просто в принципе не вижу задач, для которых ее можно использовать (ну, разумеется, кроме поддержки legacy, где она уже используется). Если у вас есть нет сильного ограничения по ресурсам, и важно время разработки — Qt и подобное гораздо лучше. Если есть ограничения по ресурсам (например, embedded), то ее опять нельзя использовать, потому что исключения — это непозволительная роскошь. В итоге тысячи проектов, где люди пишут с нуля свои собственные контейнеры, функциональщину и прочее.
Позиции Qt как раз в embedded и сильны (в числе прочих). Он и на bare metal работает:
www.qt.io/qt-for-mcu
Как говорится, stop believing you should use the standard library for everything. Ей есть альтернативы, и слава богу, что C++ позволяет при необходимости «ужиматься» и не использовать тот функционал, который не нужен. Попробуйте в том же C# (раз уж статья о нем) обойтись без исключений или сборщика мусора — там это вообще не вариант, все это намертво вшито в язык так, что не отодрать даже с мясом. В C++ это решается просто заменой std на более подходящую для данного случая библиотеку и сборкой с -fno-exceptions.
www.qt.io/qt-for-mcu
Как говорится, stop believing you should use the standard library for everything. Ей есть альтернативы, и слава богу, что C++ позволяет при необходимости «ужиматься» и не использовать тот функционал, который не нужен. Попробуйте в том же C# (раз уж статья о нем) обойтись без исключений или сборщика мусора — там это вообще не вариант, все это намертво вшито в язык так, что не отодрать даже с мясом. В C++ это решается просто заменой std на более подходящую для данного случая библиотеку и сборкой с -fno-exceptions.
C++ — это как большая качественная головоломка. Людям с аналитическим складом с ней очень интересно. Но чтобы решить конкретную задачу, нужен эргономичный инструмент, а не головоломка. Если мне нужно строку разбить на подстроки, используя символ или строку как разделитель (что ну очень попсовая задача), я хочу написать str.split(delimiter), это абсолютно естественно. Но почему-то в С++ это не так. Достаточно вбить в гугл how to split a string in C++, чтобы осознать насколько далеко это не так. И мне совершенно непонятно, почему это не так. И на мой взгляд, этому нет никаких оправданий.
В Qt, который я главным образом и использую, это делается как раз естественно, через QString::split(), которых там куча вариантов на все случаи жизни :) В std — да, с конкретно этой операцией все печально. Но Qt — это тоже C++ :)
Сплит элементарно делается через std::find, я чуть ниже привёл пример. Вместо функтора можно использовать outiterator, будет похоже на Qt, но теряется гибкость и производительность в некоторых сценариях где создание временной строки не требуется.
Вот примерно такое велосипедописание arseniy_artmind и называет «люди пишут с нуля свои собственные...» whatever :) Люди либо везде таскают за собой собственную библиотечку из подобных «универсальных» велосипедов разной степени качества, либо просто занимаются переносом их из проекта в проект, и хорошо еще, если с помощью великой технологии copy&paste. Чем меньше тривиального кода типа этого нужно писать, тем меньше вероятность в нем ошибиться и тем лучше для всех.
я хочу написать str.split(delimiter), это абсолютно естественно.
Наблюдая за своими учениками, я в принципе понял почему C++ не любят те кто имеет опыт с других языков.
Типичный программист нажимая точечку в своей IDE ожидает выпадающего списка того, что можно сделать со строкой.
Что же он видит в С++? А ровным счетом ничего, со строкой ничего нельзя сделать, с вектором, листом… только положить элемент да и достать. Ни сплита, ни ввода вывода, ни поиска, ни конвертаций, ничего. Тут он делает умозаключение что библиотека в С++ нефункциональная и переключается на другой язык.
Но в С++ алгоритмы и контейнеры не связаны. В любой алгоритм можно подставить любую сущность, и мы имеем комбинаторный взрыв того, что мы можем сделать.
Например идиоматическая реализация split которой я учу:
template <typename Iter, typename Sep, typename F >
void split( Iter first, Iter last, const Sep& t, F f )
{
while ( true )
{
auto found = std::find( first, last, t );
f( first,found );
if ( found == end )
break;
first=++found;
}
}
Хороший студент её пишет без гугла за 5 минут, надо знать только что существует группа алгоритмов std::find. И в результате имеем функцию которая может посплитить что угодно что имеет итераторы (строки\контейнеры\стримы\корутины), а в качестве разделителя может быть как один элемент так и группа. А так как она принимает лямбду, то мы никак не ограничены тем, куда и как сериализовывать кусочки, а так же не создаём тысячи мелки объектов на куче. При небольшом (5%) изменении этой функции, мы можем получить вариант который будет векторизироваться или распараллеливаться. Или же можем получить сплит, работающий на этапе компиляции.
Всего лишь одна функция, но она показывает поистине впечатляющие возможности. 8 строк кода благодаря которым можно расплитить что угодно, и почти как угодно, и мы никак не ограничены типом результата. Поэтому мало знать С++, нужно понимать идеи которые стоят за этим языком.
Я ничего не имею против того, чтобы у студентов развивать абстрактное мышление, это хорошо.
Но давайте представим, как Вашу замечательную универсальную шаблонную функцию использовать на практике.
Немного утрируя, но допустим, пришел к Вам заказчик и говорит:
— А чем это, батенька, ты занимался неделю?
— (Гордо) Создал универсальную функцию разбивания всего на все с минимум оверхэда
— ?
— Ну в стандартной библиотеке нет такой функции. Кстати, вызывать ее достаточно легко: split(str.begin(), str.end(), sep, [&]([не прошло цензуру]) { [не прошло цензуру] })
— ***, мне нужно было разделить «Вася Пупкин» на имя и фамилию, чем ты занимался?!
Но давайте представим, как Вашу замечательную универсальную шаблонную функцию использовать на практике.
Немного утрируя, но допустим, пришел к Вам заказчик и говорит:
— А чем это, батенька, ты занимался неделю?
— (Гордо) Создал универсальную функцию разбивания всего на все с минимум оверхэда
— ?
— Ну в стандартной библиотеке нет такой функции. Кстати, вызывать ее достаточно легко: split(str.begin(), str.end(), sep, [&]([не прошло цензуру]) { [не прошло цензуру] })
— ***, мне нужно было разделить «Вася Пупкин» на имя и фамилию, чем ты занимался?!
Но ведь сейчас split() в многих языках
1) умеют не только строки а также другие контейнеры
2) и возвращают они итераторы
Т.е. на подобии ranges только ещё и в IDE методы выпадают.
Но в С++ алгоритмы и контейнеры не связаны. В любой алгоритм можно подставить любую сущность, и мы имеем комбинаторный взрыв того, что мы можем сделать.
Равно как и во всех других языках, имеющих шаблоны/дженерики. Просто в C++ это делается крайне неудобным образом из-за неудачного решения по представлению контейнера (вместо собственно контейнера передаются два итератора) и отсутствия методов-расширений (невозможен chaining).
А предложенный вами split плох тем, что содержит в себе сразу две функциональности: разделяет коллекцию и выполняет над ней действие f. К тому же, он императивен и требует написания кучи кода вокруг него. А ещё непонятно, чем может являться F. Концепт, что ли, добавьте.
Ведь гораздо удобнее видеть в таком виде:
obj.split(arg).for_each(f);На худой конец:
for_each(split(obj, arg), f);Не надо путать С++ и stl. Не нравится то что предоставляет stl — ничто не мешает сделать свои контейнеры со своими принципами передачи диапазонов. В этом и есть фишка плюсов — в вынесении всего этого хозяйства в библиотечные средства, позволяющие дополнять/заменять их по своему усмотрению.
А вот на шарпе такую манипуляцию произвести будет очень проблемно, если вообще возможно. И как подсказывает опыт древних без плюсов она все равно не обойдется.
А вот на шарпе такую манипуляцию произвести будет очень проблемно, если вообще возможно. И как подсказывает опыт древних без плюсов она все равно не обойдется.
Не надо путать С++ и stl. Не нравится то что предоставляет stl — ничто не мешает сделать свои контейнеры со своими принципами передачи диапазонов
Ну да, стандартный аргумент в пользу C++. И вместо того, чтобы сразу приступать к решению задачи, мы сначала потратим кучу времени на велосипедостроительство.
В этом и есть фишка плюсов — в вынесении всего этого хозяйства в библиотечные средства, позволяющие дополнять/заменять их по своему усмотрению.
Ну да. А потом окажется, что в большом проекте каждый модуль зависит от своей библиотеки. И будем видеть мешанину из QString, std::string, char*, std::wstring и т.д.
А вот на шарпе такую манипуляцию произвести будет очень проблемно, если вообще возможно. И как подсказывает опыт древних без плюсов она все равно не обойдется.
На шарпе это попросту не нужно. Зачем?
На шарпе это попросту не нужно. Зачем?
Шарп не используют для решения задач где это нужно. Точнее так будет. А нужно это везде что хотя бы чуть серьезнее хеллоувердов магазина виндоуз.
Ну да. А потом окажется, что в большом проекте каждый модуль зависит от своей библиотеки. И будем видеть мешанину из QString, std::string, char*, std::wstring и т.д.
А нефиг разрабатывать по принципу натянем побольше говна и палок с гитхаба. Это не разработка а вредительство. Тогда и проблем таких не возникает. А типов строк и т.д. в большом проекте будет в любом случае несколько. Потому что где то удобней/оптимальней их иметь с одной внутренней структурой/семантикой где с совсем другой.
И вместо того, чтобы сразу приступать к решению задачи, мы сначала потратим кучу времени на велосипедостроительство.
Нет потратим немного времени на создание сверхвысокоуровневых абстракций значительно ускоряющих разработку.
Ну да, стандартный аргумент в пользу C++.
С++ — универсальный язык в отличии от шарпа. А это означает что пригоден в любых направлениях разработки. И вот что что, а такая с одной стороны простая, а с другой стороны задачезависимая штука как контейнеры и смартпоинтеры для оных разных направлений должны жить по асболютно противоположным реалиям. Сам же лисапет под названием stl предназначена по большому счету для облегчения студентам перехода с явы, которой школьникам в америках моск насилуют поголовно, и больше ни для чего. Хотя бы потому что любая стандартная библиотека может быть годной для мифического «наиболее частого случая» только за счет того что лучшая вообще ни для какого случая, а для многих случаев принципиально не годна.
Узконишевему шарпу, оказавшемуся непригодным даже для создания на нем профессионального средства визуальной разработки даже совместными усилиями двух мировых лидеров в этом вопросе, естественно это ни к чему.
Есть мнение, что компьютер должен помогать человеку, а не человек компьютеру.
Нет ничего сложного привязать функции к типу, например, по типу первого параметра. Компилятору без разницы, что там — str.split() или split(str), машинный код будет одинаков. А человеку удобнее и понятнее str.split().
Нет ничего сложного привязать функции к типу, например, по типу первого параметра. Компилятору без разницы, что там — str.split() или split(str), машинный код будет одинаков. А человеку удобнее и понятнее str.split().
Компилятору без разницы, что там — str.split() или split(str), машинный код будет одинаков. А человеку удобнее и понятнее str.split()
А где проходит граница что помещать в класс, а что не помещать?
Весь STL был основан на принципах SR и DI, ещё до того как эти принципы были сформулированы.
Если поместить в std::string порождающие паттерны как типичный split, то дело на этом не закончится. Будут те кто недоволен отсутсвием членов класса: toLower() toUpper() toUtf() toAnsi() toLatin() readFromFile() bitBlt() getKerningsPairs() regExSearch() find() boyer_moore_find() replace(). А так же будут недовольные тем, что split`а нет во всех остальных контейнерах и писать обобщённый код — стало невозможно.
В C# для этого были придуманы методы-расширения.
В C++ же предлагался uniform function call, но из-за того, что он приводит к проблемам, связанным с пространством имён, оно так и висит пропозалом.
Причем в C# расширения пишут обычно для дженериков, поэтому не нужно городить огород для всех контейнеров.
И внезапно, мы сможем искать минимум для любых типов, которые IQueryable
public static TResult Min<TSource, TResult>(this IQueryable<TSource> source, Expression<Func<TSource, TResult>> selector);И внезапно, мы сможем искать минимум для любых типов, которые IQueryable
Да, основной мотиваций UFC в с++ Саттер как раз называет автодополнение в IDE (discoverability), о котором я писал.
Но если его примут, все алгоритмы всё еще принимают итератор первым элементом, или executionPolicy. Поэтому, без STL 2.0, выгода сомнительна иначе будет ещё одна тысяча новых перегрузок.
В тоже время концепты потенциально обещают discoverability, тк уже есть какой никакой но критерий для фильтрации аргументов, и увода внимания с UFC на задний план.
Я думаю, UFC имеет шанс только после reflection, тк Саттер все свои маркетинговые силы бросил в этом направлении.
Но если его примут, все алгоритмы всё еще принимают итератор первым элементом, или executionPolicy. Поэтому, без STL 2.0, выгода сомнительна иначе будет ещё одна тысяча новых перегрузок.
В тоже время концепты потенциально обещают discoverability, тк уже есть какой никакой но критерий для фильтрации аргументов, и увода внимания с UFC на задний план.
Я думаю, UFC имеет шанс только после reflection, тк Саттер все свои маркетинговые силы бросил в этом направлении.
to serbod, второй like.
Расскажите мне, пожалуйста, как с помощью async/await распараллелить вычислительную задачу.Никак. Оно предназначено для распараллеливания одной вычислительной задачи и нескольких операций ввода вывода.
Ну еще бы, ведь к многопоточности это не имеет абсолютно никакого отношения.Имеет и еще какое. Даже если вызывающий async операции код не создает потоки. Операции ввода-вывода обслуживаются потоками ядра, с которыми точно так же необходима синхронизация и т.д. Ну и вообще начните с определения потока. Поток это асинхронный контекст выполнения. Так что любая асинхронность по определению многопоточность, независимо от того как потоки переключаются, какие средства управления потоками имеются в распоряжении, и какие именно задачи выполняет каждый из асинхронных контекстов.
Неохота разбирать все по каждой фразе, но вобщем — дискуссия несостоятельна. В том смысле, что у каждого инструмента есть своя ниша, и есть своя устоявшаяся практика. Аргументы насчет быстрого развития C# и медленного C++, это как раз больше аргументы в пользу C++, т.к. быстрое развитие обесценивает знания и опыт, и инструменты постоянно находятся в лучшем случае в руках «экспериментаторов». Т.е. мало кто знает, как лучше, и как надо — а делают так, абы работало. На выработку правильных подходов уходят годы, и когда инструменты меняются, это все идет коту под хвост. Кому нужно такое развитие, если от этого страдает качество?
Ну и пара слов насчет UI — прекрасно он делается и на C++, спасибо Qt. Тем кто скажет, что Qml это не плюсы, я отвечу, что и XAML как бы не C#. И даже UI на основе QWidgets гораздо ближе к XAML, чем WinForms.
А самый фундаментальный недостаток C# — это то, что им по прежнему рулит Microsoft, что бы там ни говорили про .NET Foundation и прочие игры в open source. А Microsoft давно потеряла доверие, вспомним что было с Windows Phone, с Silverlight, с .NET Compact / Micro Framework — где это все? Это корпорация, где шла война кланов, и где победил Azure. Вот и все, что нужно знать про эту (гнилую) контору.
Ну и пара слов насчет UI — прекрасно он делается и на C++, спасибо Qt. Тем кто скажет, что Qml это не плюсы, я отвечу, что и XAML как бы не C#. И даже UI на основе QWidgets гораздо ближе к XAML, чем WinForms.
А самый фундаментальный недостаток C# — это то, что им по прежнему рулит Microsoft, что бы там ни говорили про .NET Foundation и прочие игры в open source. А Microsoft давно потеряла доверие, вспомним что было с Windows Phone, с Silverlight, с .NET Compact / Micro Framework — где это все? Это корпорация, где шла война кланов, и где победил Azure. Вот и все, что нужно знать про эту (гнилую) контору.
Опишу свою историю: есть «железный» коммерческий продукт, управляется по юсб. Нужно написать юзер-френдли софт под вин и мак. Сначала выбор пал на C#, были долгие мучения заставить работать его под МакОС с Моно… Возможности Моно в плане GUI очень скудные. Работает очень криво. Баги под маком от OpenDialog'а и дальше… Юзерам объяснить зачем приложению в 30 Мб, скачивать и устанавливать Моно на 1Гб тоже тяжело… То, что в статье пишут про 150Мб — не верно (ну или не совсем верно). Был выбор или Qt или, о, Боже, С++ Builder. Остановились на Билдере… На его фреймворке FMX. Такое ощущение, что делфи там же, где и 20 лет назад, и на тех же костылях. IDE глючная, С++ портирован с Делфи -( компиляторы под вин32, вин64 и мак ос разные, поддерживающие разные стандарты С++. Это всё боль разработчика. Но! Один код под винду и мак. очень гибкие механизмы по работе GUI. Идея FMX оч правильная, но хотелось бы, чтобы ее реализовали в MS, а не в Embarcadero. Я понимаю, что рынок десктопных приложений очень мал уже. И вся ориентация на веб. Но когда пишут, что C# кроссплатформенный, это сильное преувеличение… Может какой-то бек-энд сервер на нем и можно сделать, но с десктопом еще не скоро… Моно жалок. Как по мне, C# очень привлекателен для разработчиков, согласен, но нужна реальная кроссплатформенность в нынешних реалиях. Поэтому и приходится быть на С++ и выбирать между Juce, QT, и FMX от Embarcadero.
Все зависит от сложности UI, может Avalonia на .Net Core вам бы подошла.
И нет, то что выше писали, это не Mono. Выше писали про .Net Core именно. И вы даже можете не ставить отдельно пакет, все можно включить в саму программу (но не надо так делать)
И нет, то что выше писали, это не Mono. Выше писали про .Net Core именно. И вы даже можете не ставить отдельно пакет, все можно включить в саму программу (но не надо так делать)
Советовать использовать бета-версии в продакшн????
NET Core 3 вышла позавчера, а Авалония до сих пор 0.8
NET Core 3 вышла позавчера, а Авалония до сих пор 0.8
1) бетта снята, почитайте
2) она 8, 9я вот вот готова, а после будет 0.10, что вам дает нумерация?
3) у kekekeks в его статьях достаточно примеров удачных приложений
2) она 8, 9я вот вот готова, а после будет 0.10, что вам дает нумерация?
3) у kekekeks в его статьях достаточно примеров удачных приложений
Я умею читать.
Состоялся очередной бета-релиз AvaloniaUI 0.8.
На гитхабе последний 0.8.2 bugfix release
Состоялся очередной бета-релиз AvaloniaUI 0.8.
На гитхабе последний 0.8.2 bugfix release
0.8 ретроспективно назначили стабильным релизом, ввиду, как бы это сказать, стабильности и готовности к использованию на десктопах. Уже после публикации на хабре.
Версионирование пока так и будет в стиле 0.123.1 по требованиям SevVer, поскольку бинарной обратной совместимости между версиями в ближайшее время не планируется. Ну или перейдём на браузерную модель версионирования с новым мажорным релизом каждые несколько месяцев.
Сейчас, интерфейс приложения, выглядит полностью стилизован: от кнопок, менюшек, списков, ползунков, графиков… И само приятно, что абсолютно одинаково, что под win, что под mac.
exmp.1
exmpl.2
exmpl.3
Моно же был абсолютно сырой, ну от банальных вещей типа мультивыбора файлов в openDialog, прорисовывалось в нем что-то криво. И до проблем с обычными контролами. Вообщем, всё что касалось взаимодействия с юзером вне винды, оставляло ощущения гуляния по минному полю. В одном из продуктов было реализована простенькая утилитка к одному из продуктов, на Моно: там просто пара кнопок и пара listbox… В итоге отказались от саппорта под мак.
Раньше, иногда, фыркали на IDE Visual Studio, но после перехода на Embarcadero — пришло понимание, что MS это просто идеально -) Но идея с их (Embarcadero ) фреймворком FMX очень не плохая (разработчик россиянин Brovin Yaroslav). Жаль, что реализована не в MS, а в Embarcadero. Есть боль при разработке, но для юзеров все гладко. При Моно было наоборот. Я бы с удовольствием вернулся в MS среду, с нормальной кроссплатформенной поддержкой в плане GUI.
Есть еще фреймворки JUCE и Qt. Но там свои приколы. У JUCE лицензии не нравятся…
exmp.1
exmpl.2
exmpl.3
Моно же был абсолютно сырой, ну от банальных вещей типа мультивыбора файлов в openDialog, прорисовывалось в нем что-то криво. И до проблем с обычными контролами. Вообщем, всё что касалось взаимодействия с юзером вне винды, оставляло ощущения гуляния по минному полю. В одном из продуктов было реализована простенькая утилитка к одному из продуктов, на Моно: там просто пара кнопок и пара listbox… В итоге отказались от саппорта под мак.
Раньше, иногда, фыркали на IDE Visual Studio, но после перехода на Embarcadero — пришло понимание, что MS это просто идеально -) Но идея с их (Embarcadero ) фреймворком FMX очень не плохая (разработчик россиянин Brovin Yaroslav). Жаль, что реализована не в MS, а в Embarcadero. Есть боль при разработке, но для юзеров все гладко. При Моно было наоборот. Я бы с удовольствием вернулся в MS среду, с нормальной кроссплатформенной поддержкой в плане GUI.
Есть еще фреймворки JUCE и Qt. Но там свои приколы. У JUCE лицензии не нравятся…
Идея FMX оч правильная, но хотелось бы, чтобы ее реализовали в MS, а не в Embarcadero
Хотелось чтобы ее реализовал Борланд. Но так понимаю идея не сбыточная. А MS в этом плане это направление всухую слил еще в 95-ом. Вплоть до того что куцый обрубок Билдера который называется WinForms делал для MS именно Борланд.
Такое ощущение, что делфи там же, где и 20 лет назадА куда она может двинуться? Автоматика управления жизненным циклом плюсового разлива как не вписалась в паскалевский синтаксис так сейчас не вписывается. Потому и остается общение с VCL на «С c классами» примерным аналогом которого является паскаль/дельфа а не так как это принято в плюсах. В общем пока дельфу не похоронят окончательно и VCL/FMX не перепишут полностью на плюсах нового взлета там не будет. А с учетом того что в своей нише крупного корпоративного софта, которому свистоперделки не просто не нужны, а принципиально противопоказаны, оно еще в 90-х за счет принципа zero-code, реализованного для систем учета практически на 100%, вытеснило практически все остальное и свои позиции сдавать не собирается, то делать это никто не спешит.
Раньше, иногда, фыркали на IDE Visual Studio
Ну еще бы. Вместе с C# Builder Майкрософту досталась и все борландовское наследие по IDE невизувльной разработки. И развить они его развили норм. По удобству вижак почти ничем не уступает IDE Borland C++ 1.0, и при этом имеет все новшества типа проверки синтаксиса на лету и т.п. Ну хотябы потому что для внутреннего использования у MS вопрос невизуальной разработки api и т.д. основной. А Embarcadero средства работы с кодом не развивало по ходу от слова совсем, потому как основная концепция в основной нише таки zero code и средства редактирования кода носят вспомогательный характер.
Раньше, иногда, фыркали на IDE Visual Studio, но после перехода на Embarcadero — пришло понимание, что MS это просто идеально -)
Ну основная претензия к вижаку до 19-го — компилятор крешится просто задолбал. С 19-го багло такое что ужас. Вплоть до вылета экскепшинов при попытке закрытия вкладки с кодом и зависаний при переключении дебаг/релиз. Компилятор как крашился так и крашится. Единственное что догадались добавить вывод сообщения на какой именно строке кода. До этого приходилось код комемнтить построчно чтобы это найти.
Embarcadero себе таких багов в релизе не позволяло никогда. Не говоря уже про Борланд.
Был выбор или Qt или, о, Боже, С++ Builder.Ну Qt это такая штука которая впитала в себя абсолютно все недостатки как VCL и MFC так и stl, не поимев при этом абсолютно никаких преимуществ.
Суть статьи С++ vc C#… Я просто поднял вопрос реальной кроссплатформенности в рамках десктопных приложений. С# на данный момент не имеет нормального решения для создания таких приложений: все или в вечной бете, или в очень сыром состоянии, или под виндовс. С++ имеет больше вариантов реализаций. С# приятней для разработчика. На мой взгляд, у C# на первом месте забота о комфортности разработчика, а на втором месте результат работы разработчика. Еще момент, С# полностью декомпилируется — по сути, весь ваш код это opensource. Многих это не устраивает. С++ тоже декомпилится, но до «готового» кода пилить и пилить.
С/С++ это дефакто стандарт для embedded. И лучшей альтернативы нет. ИМНО и не нужно -) Потому, что там где вы работаете с железом вы, скорее всего не будете писать int, а будете писать UInt32 или Int32, если хотите контролировать происходящее.
С/С++ это дефакто стандарт для embedded. И лучшей альтернативы нет. ИМНО и не нужно -) Потому, что там где вы работаете с железом вы, скорее всего не будете писать int, а будете писать UInt32 или Int32, если хотите контролировать происходящее.
Потому, что там где вы работаете с железом вы, скорее всего не будете писать int, а будете писать UInt32 или Int32, если хотите контролировать происходящее.
То есть, как будто в C# нет UInt32, а int в C# означает что угодно, а не Int32.
А вот я такой иду смотреть C++, хочу научиться, и вижу в официальном референсе
int32_t
int_fast32_t
int_least32_t
И я такой, WTF?
Вы вытащили это с контекста… Речь шла о embedded. И там преимущественно, даже не С++, а С99. И про int переживают с самой статье, а не я. Я сделал упоминание, в рамках того, что там, где нужно, переменные, нужного типа, применяются вполне осознанно.
Безспорно, существует много легаси кода. И есть проблемы с ним. Но стоит ли винить С/С++ за то, что он был основным языком, и практически все с чем и на чем мы работает было написано на нем. Язык продолжает развиваться, и да, легаси его ограничивает. Стоит ли это упрека? Да, порог вхождения в С/С++ выше, чем в С#.
C/C++ это более низкоуровневые языки, C# более высокоуровневый. С++ обвешанный фреймворками — может то что и С#. С# не может «залезть глубже» по своей сути…
Безспорно, существует много легаси кода. И есть проблемы с ним. Но стоит ли винить С/С++ за то, что он был основным языком, и практически все с чем и на чем мы работает было написано на нем. Язык продолжает развиваться, и да, легаси его ограничивает. Стоит ли это упрека? Да, порог вхождения в С/С++ выше, чем в С#.
C/C++ это более низкоуровневые языки, C# более высокоуровневый. С++ обвешанный фреймворками — может то что и С#. С# не может «залезть глубже» по своей сути…
На C# вполне можно пилить автоматизацию под железо, особенно если это железо подключено через последовательный порт :) И это будет вполне себе embedded, по определению. Четырех-ядерного Intel Core на это вполне хватает)
Управление по протоколу можно писать на чем хочешь… Особенно если это UART. Это не тот embed, о котором я говорю. Embedded это когда вы управляете процессами в реальном времени, когда вы считаете операции за такт процессора, когда вы экономите память, когда математика подводится под архитектуру, когда вы реально можете видеть, чем inline отличается от обычной ф-ции. и т.д.
Ну так и автоматизация через UART, тоже вполне себе происходит в реальном времени. Например дозатор чего-нибудь — получаем параметр, смотрим уже хватит или еще подождать, когда хватит посылаем команду железу что-то выполнить. При этом можно отправлять данные куда-то на сервер, и показывать красиво в UI. И такое ПО, по определению, тоже будет являться встраиваемым. Требования к нему просто, менее жесткие. Особенно если железо — штучный товар. Я уже молчу про софт для банкоматов и кассовых терминалов — там C# аж бегом можно применять.
"… посылаем команду железу что-то выполнить..." Вот железо, которое будет что-то реально выполнять- это и есть уровень С/С++. А послать команду этому железу что-то выполнить можно и на HTML.
И если эту команду захочется послать не с консоли, а с ГУЯ, и не только с винды, то С# и тут не оч подходит — С# вин ориентирован, вся его кроссплатформенность сводится к «консольному»/серверному back-end«у. В лучшем случае, сейчас, его хватит на легкий конфигуратор — галочки расставить. Но для этого есть 1001 альтернативный способ… Плюс, повторюсь, его код полностью открыт. Это все-равно, что управлять банкоматом на каком-то bat»нике.
C# приятен в работе, все за тебя написано, удобно… Но и плата за это соответствующая.
И если эту команду захочется послать не с консоли, а с ГУЯ, и не только с винды, то С# и тут не оч подходит — С# вин ориентирован, вся его кроссплатформенность сводится к «консольному»/серверному back-end«у. В лучшем случае, сейчас, его хватит на легкий конфигуратор — галочки расставить. Но для этого есть 1001 альтернативный способ… Плюс, повторюсь, его код полностью открыт. Это все-равно, что управлять банкоматом на каком-то bat»нике.
C# приятен в работе, все за тебя написано, удобно… Но и плата за это соответствующая.
Да нормально C# подходит. Железо готовое — модули от ICP-DAS, управляются командами по RS-485. На C# пишется логика всего процесса. И т.к. это специальное ПО под специальный комп, на котором больше не будет (не должно) ничего работать, то вполне можно поставить туда любую винду и наваять хоть на C# 2.0 нормальное приложение, которое легко дебажить и поддерживать. И которое будет работать годами (при соответствующей настройке винды). Я этим как бы занимался, несколько лет.
Я этим как-бы занимался тоже… Сименсовые контроллеры… точно так же управляются по RS485… Вся производственная линия, и очистные сооружения управляются софтом написанным на С#. Такая связка почти производственный стандарт сейчас — дешево и сердито, низкий порог вовлечения сторонних программеров, которым дается более-менее адекватное ТЗ, и они не понимая сути, делают просто удаленное управление по сценариям, со сбором статистики. Но если, поставить задачу сделать тоже самое нод линукс\мак\винду. И чтобы вашим софтом пользовалось более 5 обученных человек… Чтобы софт выглядел дружественно, симпатично и одинаково под всеми ОС. Чтобы у вас был один код на все ОС. То С# вам не помощник… Что-то, как-то, и через /*№" может и создадите. Но это будет костыль на костыле. Поэтому я тут не сказки теоретизирую…
Ну так о чем мы спорим тогда. Если добавляются требования Мак, Линукс, установка на пользовательские компы, то это уже не embedded тогда, и выбор инструмента должен учитывать эти требования. И в таком случае, очевидный (для меня) выбор инструмента — Qt. Я даже больше скажу — если бы Qt в том виде как он есть сейчас, появился на 15 лет раньше, то и C# мог бы умереть, не родившись.
Я вообще не спорю… Это просто мое мнение из моего скромного опыта. Просто по статье получается. С++ весь такой отживший, сложный, медленно развивающийся, бюрократичный. А C# весь такой современный, передовой, кроссплатформенный, удобный. ИМНО истина где-то посередине… Плюс повторюсь — можно смело считать, что С# приложение поставляется с исходным кодом сразу… Кому-то (мне) это не нравится, кто-то от этого в восторге…
которым дается более-менее адекватное ТЗ, и они не понимая сути, делают просто удаленное управление по сценариям, со сбором статистики.
Это диверсия называется
дешево и сердито, низкий порог вовлечения сторонних программеров,Ндя. В америках конторы которые автоматизацией и прочим хайтечем занимаются выпускников вузов раскупают еще на последнем курсе. И з/п дают на время стажировки такую «от» что в энтерпрайзе это глобально «до» а в гугле 2/3 этого глобально «до». Догадаетесь почему?
А тут типа порог вхождения стипа нижают. А потом сказки рассказывают на всех углах что типа пожары в пожары в торговых центрах и т.д. де агенты ФБР устраивают.
Я обсуждал вполне нишевый сегмент… Как это обычно происходит у нас (не америка): есть инженер-программист, который программирует промышленные контроллеры (те же сименсы и т.п) он по сути главный, всю логику, автоматику он реализует «железно»… Далее привлекается программист, который пишет приложение, которое отображает, как правило, визуально состояние системы, ведет и сохраняет логи, в самом крайнем случае обеспечивает сценарную логику. Если возникает некая ошибка — сигнализирует оператору. По сути все приложение — это парсер с таймером. Студенты последних курсов — как раз очень подходят: дешево и сердито… С# для таких задач — просто идеальное решение. Все сливки получает инженер — рутину за немного денег делает программист. Все счастливы, все заняты. Инженер со своим С++, и программист с С# -)) Така я вот диверсия -)))
Если возникает некая ошибка — сигнализирует оператору.
Если бы не вот это это было бы вполне допустимо.
А так это диверсия чистой воды.
Я обсуждал вполне нишевый сегмент… Как это обычно происходит у нас (не америка):
Да хоть Африка. Главная причина всех багов, в том числе таких которые приводят к серьезным авариям — недопонимане задачи. И никакие средства разработки эту болезнь не лечат в принципе. Только досканальное исследование предметной области и анализ задачи. Т.е. сам подход с использованием студентов вслепую — это еще гораздо большая диверсия чем шарп туда пихать.
можно поставить туда любую виндуэто не ембеддед никоим образом
"Реальное время" и "сборщик мусора" — несовместимые понятия.
Точно так же несовместимы "реальное время" и "ОС общего назначения".
именно это я и имел ввиду, когда писал, что С/С++ сможет, а C# по своей природе не способен, на определенные вещи.
Реальное время, скажем так, может иметь разную степень «реальности». А процессы, которыми управляет ПО на C#, могут иметь определенную цикличность. Тогда в удобные моменты, достаточно просто вручную запускать сборку мусора, что с достаточно высокой надежностью гарантирует от возникновения проблем на критичных участках. Плюс, дополнительно можно отслеживать метрики по управляемым ресурсам (например памяти) и заранее принимать меры при достижении опасных уровней. Но обычно, на C# пишут то, что такого контроля не требует, а (теоритически возможные) задержки в 10-20 мс на процесс особо не повлияют. По шине RS-485 скажем, интервал опроса обычно десятки миллисекунд, за это время GC успеет 100 раз отработать.
Реальное время, скажем так, может иметь разную степень «реальности».это просто необразованность. нет понимания основ
ну или так сказать, имеет некоторую «степень образованности» =)
Подсказка. «Реальное время» не связано с быстродействием.
Да знаю я, с чем оно связано. Хорошо настроенная WinXP без всяких излишеств, не предподносит никаких сюрпризов по времени реакции. Там где тех.процесс допускает задержки до десятков мс, нет никаких причин не применять десктопные решения вроде Windows и C#, для создания встраиваемого ПО. Вас кстати не смущает, что MS выпускала и до сих пор выпускает специальные редакции Windows, называемые Embedded? Все отличие которых от десктопных, составляет 15 лет гарантированной поддержки и чуть ли не пофайловая конфигурация образа. И Embedded на самом деле, это не про размер, а про назначение, ПО и системы.
Какой плавный съезд с real-time sys на embedded xp =)
нет никаких причин не применять десктопные решения вроде Windows и C#, для создания встраиваемого ПО.
Как это нет? А как же предупреждение Майкрософта о том что не предназначено для управления оборудованием в реальном времени? Или лицензионное соглашение оно там так чтоб галочку нажать?
Ну и еще такой вопрос — а если оно взорвется или задавит вы в курсе что и тот кто такое решение принял и тот кто его на работу нанял будут лес валить очень долго.
А можно ссылку на лицензию которую вы имеете ввиду и цитату конкретно этого места? А то что-то не могу в актуальной embedded лицензии такого найти.
А можно ссылку на лицензию которую вы имеете ввиду и цитату конкретно этого места?
Да пожалуйста:
16. RESTRICTED USE. The Microsoft software was designed for systems that do not require fail-safe performance. You may not use the Microsoft software in any device or system in which a malfunction of the software would result in foreseeable risk of injury or death to any person. This includes operation of nuclear facilities, aircraft navigation or communication systems and air traffic control.
Хотя по большому счету достаточно отсутствия всякого присутсвия сертификата на применение в системах реального времени.
Здесь нет ни слова про системы реального времени. Только про отказоустойчивые. А это совсем разные вещи.
В системе реального времени — не вложилась в лимит времени это отказ системы.
Но не всегда отказ системы — это что-то страшное. Например, запись компакт-дисков — тоже как бы задача реального времени. Но цена отказа тут — всего лишь запоротая болванка (и то если у нас не RW-диск).
Но не всегда отказ системы — это что-то страшное
You may not use the Microsoft software in any device or system in which a malfunction of the software would result in foreseeable risk of injury or death to any person.
В любой системе промавтоматики управляющей оборудованием такой риск всегда есть. А написанно именно так потому что существуют системы и не реалтаймовые и не управляющие оборудованием где такой риск тоже всегда есть.
В любой системе промавтоматики управляющей оборудованием такой риск всегда есть.
Насколько я знаю, в промавтоматике приняты аппаратные цепи безопасности (там, где это возможно). При выходе из строя управляющего компьютера оборудование просто останавливается.
Да, это убытки. Но риска для здоровья нет.
У вас дыра в логике. Не каждая система реального времени должна быть отказоустойчивой. И не каждая отказоустойчивая система должна бытъ системой реального времени.
У вас дыра в логике.
То у вас дыра в логике. Потому что реалтамовость — одно из требований по отказоустойчивости к системе по своей сути. Т.е. недопустимость отсутсвия реакции в заданный лимит времени.
Потому что реалтамовость — одно из требований по отказоустойчивости к системе по своей сути.
С каких это пор?
У меня может быть например отказоустойчивая система, вся задача которой это сохранять логи событий. При этом она совсем не обязательно должна делать это в реальном времени и вполне достаточно если все логи будут просто сохранены на момент выключения системы.
У меня может быть например отказоустойчивая система, вся задача которой это сохранять логи событий
А какие у вас в другой системе требования по устойчивости к отказам никакого отношения не имеет к требованиям отказоустойчивости в системах управления оборудованием.
и вполне достаточно если все логи будут просто сохранены на момент выключения системы.
The Microsoft software was designed for systems that do not require fail-safe performance
Т.е. нет абсолютно никакой гарантии что система обеспечит сохранение ваших логов. К примеру банально не закрешится на самом интересном месте.
И что? Вы вообще понимаете что вы уже пошли по второму кругу? Никто не спорит что Microsoft embedded не годится для отказоустойчивых вещей. Но отказоустойчивые системы это не тоже самое что системы реального времени.
И есть системы реального времени, которые не должны быть отказоустойчивыми. А вы утверждали что Microsoft embedded не годится именно для систем реального времени. Где вы это вычитали?
Где вы это вычитали?
А где вы вычитали что она может годится? Для реалтаймовых систем нужно как раз пригодность к реалтайму доказывать а не наоборот. Нигде нет никаких заявлений от производителя о том что она пригодна к реалтайму и нет никаких сертификатов подтверждающих такую пригоднось. Идите матчасть подучите.
Вы уже сами не помните что писали в треде? Мне то ничего вычитывать и не надо. Потому что в отличие от вас я не утвеждал что:
А как же предупреждение Майкрософта о том что не предназначено для управления оборудованием в реальном времени? Или лицензионное соглашение оно там так чтоб галочку нажать?
Так где вы в лицензионном соглашении прочитали предупреждение Microsoft о том, что их embedded не предназначен для управления оборудованием в реальном времени?
По большому счету там где не написано о том что он для этого специально предназначен. А для особо одаренных еще специальное предупреждление о недопустимости использования в системах чей отказ может вызвать аварию. Такой риск в любой системе управления промышшленным оборудованием всегда есть
Еще раз — сходите в универ подучите матчасть.
Еще раз — сходите в универ подучите матчасть.
Во первых это уже ничто иное как банальная отмазка. Вы ошиблись и теперь зачем то юлите вместо того чтобы просто признать что были неправы.
А во вторых это на мой взгляд полная чушь и я ещё не видел таких лицензионных соглашений где бы были перечисленны по пунктам абсолютно все ситуации где лицензируемую вещь можно применять.
Майкрософт и так ни за что не несет ответственности, так что их предупреждения до одного места. А насчет взорвется или задавит, это ваши собственные фантазии. Требования определяют инструмент, и с этим никто не спорит. Требования просто разные бывают, как и сумма, которую за это готовы заплатить.
Майкрософт и так ни за что не несет ответственности, так что их предупреждения до одного места
там прямо написано: вам не разрешается использова програмное обеспечение Майкрасофт в устройстве или системе чей отказ может привести к ранению или смерти людей. Включая ядерные установки, навигацию самолетов, системы связи, управление воздушным движением.
То что то не перечислено не означает что оно разрешено.
Требования просто разные бывают, как и сумма, которую за это готовы заплатить
В для начала в законах и нормативных актах проконсультируйтесь. А то у нас на заводах не то что системы индикации сбоев, компы которые за калибрацией весов наблюдают на сертифицированных к реалтайму осях. Потому что подсудное дело в систему промышленной автоматизации несертефецированный софт пихать или неквалифицированных спецов не то что в разработке, даже в техническом обслуживании задействовать.
Да и не путайте FA и Embedded когда будете нормативные акты смотреть. Это две огромные разницы.
В FA могут начальника отдела лет на 5 упечь к примеру за то что некоторый тип датчика смещен на пол метра. это при том что длина линии автоматизации 250 метров и никакой аварии не было.
А Embedded в лампочке фазы коммутирует. Или в микроволновке светодиодиками моргает. Хотя конечно и не только это делает. Но его смысл девайс встроенный в устройство и выполняющий в большинстве случае преимущественно информационные задачи а не задачи управления.
для начала в законах и нормативных актах проконсультируйтесь.В РФ нет там ничего подобного. и не надо так возбуждаться
А в станциях визуализации всех мировых вендоров сплошь и рядом стоит Windows — CE в панелях оператора, а SCADA — на обычных версиях
В мобиле под капотом ведра тожже линукс. И ракеты в космос на линуксе летают. Только это разные линуксы с разными ядрами.
Опять же разницу видите между визуализацией и управлением? У любой системы управления есть некритичная по времени реакции часть. И ее в принципе можно делать нереалтаймовыми методами но при условии что она выполняется на отдельном от реалтаймовой вычислителе. При этом отсутсвие требований к реалтайму у этих частей необходимо доказывать в рамках конкретно взятой системы. Требования же по остальной надежности это никак не снимает.
Опять же разницу видите между визуализацией и управлением? У любой системы управления есть некритичная по времени реакции часть. И ее в принципе можно делать нереалтаймовыми методами но при условии что она выполняется на отдельном от реалтаймовой вычислителе. При этом отсутсвие требований к реалтайму у этих частей необходимо доказывать в рамках конкретно взятой системы. Требования же по остальной надежности это никак не снимает.
еще раз, для особо одаренных — требований в нормативке _нет_
а буйные фантазии основанием не являются. приплетать ведра, ракеты, линукс, рт итп не надо
я давно в этой области работаю
а буйные фантазии основанием не являются. приплетать ведра, ракеты, линукс, рт итп не надо
я давно в этой области работаю
еще раз, для особо одаренных — требований в нормативке _нет_О каком тогда реалтамовом управлении оборудованием вообще идет речь? Из того что вы в нереалтаймовой встраиваемой системе где то используете что то, абсолютно не вытекает то что оно годно к использованию в реалтайме на основании того что типа тоже встраиваемый.
Там где тех.процесс допускает задержки до десятков мс, нет никаких причин не применять десктопные решения вроде Windows и C#, для создания встраиваемого ПО.
Знаете я вот в свое время на одном прокатном стане работал. Так там в системе самый маленький лимит времени отработки был 50мс. И вы туда винду с шарпом хотите поставить? Вы когда нибудь видели как 100-тонный валок перебитый пополам летит по линии прокатки?
А полетит ежедневно. Потому что кроме времени отклика важен еще приоритет обработки сигналов а винде они в кучу свалены вместо обработчиков прерываний заглушки которые сваливают было прерывание в очередь без приоритетов и когда оно там отработает и в каком порядке вообще неизвестно. Немчура кстати предлагала на винде решение. Только со своим кернелом который это обеспечивает. Этот настолько реалтаймовый что часть тамогавков на нем летала. И стоил он 50 килобаксов копия. Только вот крайняя версия для которой его делали была хрюшка. А дальше сказали все не можем. Догадайтесь причина какая? Банально в ней .NET из коробки присутсвует. Все непригодна. Наверное там в Сименсе вооще дураки работают по вашему?
Дотнет из коробки, прямо вот сразу готовый к использованию, появился ЕМНИП только в Win8. И это всегда была проблема дотнета, отсутствие его рантайма у большинства юзеров. Винда, а именно WinXP, если правильно сконфигурирована, вполне надежная и предсказуемая система (в частности, если отключено все лишнее и не абсолютно необходимое, в т.ч. сеть, звук, проводник и т.д.). Простые вещи на ней можно делать (напимер дозатор песка или цемента). Тот кейс, что вы приводите, требует многоуровневой распределенной системы управления, и на каждом уровне будут свои решения (начиная с датчиков и автоматики на уровне железа, до контроллеров сбора данных и операторских пультов, заканчивая SCADA системой которая все это объединяет). Понятно что одним компом с виндой и поделкой на шарпе тут не обойтись.
В Vista. А в сервере в 2003-ем
Простые вещи на ней можно делать (напимер дозатор песка или цемента).Майкрасофт так не считает.
Тот кейс, что вы приводите, требует многоуровневой распределенной системы управления,
Реально там хватает двух УВМ с 800Khz тактовой и 768Кб тактовой каждый производства конца 70-х. Да и форточки местные тоже тянут. Терминалы операторов и графические мониторы отображающие схему. А винду туда пускать нелязя без замены кернела железо какой бы мощности ни было.
По шине RS-485 скажем, интервал опроса обычно десятки миллисекунд, за это время GC успеет 100 раз отработать.Я вот не далее года назад наблюдал картинку маслом. Там конечно не с автоматикой слава богу связано было. А с сервами которые друг друга тестировали раз в 6 часов. И при этом тесте лимит времени на счет тестовых данных и отклик был 2 секунды. И все норм укладываются там в милисикунды. месяц-два — начинают ложится. Верне не ложится а не проходить тест. Что оказалось под счет тест нужен был непрерывный буфер не очень большой метров десять. И вот как раз по приходу задачи он начинал GC-шить по всей видимости свап потому что занимало это от 20 до 45 секунд. Конечно линукс и ява это как бы не винда и шарп. Но как бы не стоит надеяться на то что GC управится в какой то лимит времени. Этот лимит может оказаться непредсказуемо и абсолютно неожиданно гораздо гораздо больше.
Плюс, дополнительно можно отслеживать метрики по управляемым ресурсам (например памяти) и заранее принимать меры при достижении опасных уровней.
Есть только один способ гарантировать наличие нужной памяти — иметь ее распределенной на старте системы.
Ну Qt это такая штука которая впитала в себя абсолютно все недостатки как VCL и MFC так и stl, не поимев при этом абсолютно никаких преимуществ.
Оборжаться просто))) Интересно, за что же его все любят? И где были бы плюсы сейчас, если бы не Qt?
Оборжаться просто))) Интересно, за что же его все любят?А все это кто?
И где были бы плюсы сейчас, если бы не Qt?Ну живут же крупные конторы без Qt. Сименс к примеру или Дассо. И еще куча мировых лидеров по производству софта. Вы ее вообще где то в том что не раздается бесплатно с гитхаба видели?
Практически весь совт для комп графики написан на Qt (maya, katana, nuke, hudini и тд) даже в стандартах VFX прописано какую Qt нужно брать vfxplatform.com
maya, katana, nuke, hudini и тдНу первый вопрос который решается при разработке таких систем — алгоритмическая генерация элементов гуя (формы ввода параметров команд/модификаторов и прочей инспекции объектов, тулбаров, менюх и т.д.). и основным моментом здесь является наличие рефлекшин инфы, а библиотека самих конторловлишь бы какая нибудь была, хоть голый винапи это неважно. Т.е… взяли для гуя первое стороннее что под руку попало где есть генератор рефлкшин инфы, который у любой более-менее серьезной конторы занимающейся средствами моделирования давно свой. Этим по всей видимости доля Qt даже в гуе исчерпывается. Геометрический же движок и движок визуализации явно разрабатывали в совсем другой IDE. потому что в плане разработки и отладки кода в Qt вообще средневековье.
даже в стандартах VFX прописано какую Qt нужно брать vfxplatform.com
А что у линуксоидов есть какие то варианты окромя того чтобы кактус грызть?
Ну первый вопрос который решается при разработке таких систем — алгоритмическая генерация элементов гуя
Нет, и этот вопрос никогда не вызвал каких либо проблем, и уж точно никогда не являлся первым вопросом. (это вообще тупо, первым делом решать как писать гуи, а не как правильно составить архитектуру)
И кстати во всех перечисленных мной программах рефлекшен не используется, используются либо специальные атрибуты которые описывают данные, либо декларативная разметка, либо гуи составляется на С++ или на питоне напрямую. И причём тут Qt creator? Qt можно использовать и без Qt creator, собственно практически никто Qt creator и не использует, используют только библиотеки Qt, пишется обычный cmake и спокойно собирается например студией.
А что у линуксоидов есть какие то варианты окромя того чтобы кактус грызть?
А причём тут линукс? Все эти программы также спокойно работают под виндой, а Qt в достаточной мере обеспечивает возможность создания сложных гуи решений, с хорошей производительностью и мультиплатформенностью, и при этом имеет легко читаемый код. За это Qt и любят.
а Qt в достаточной мере обеспечивает возможность создания сложных гуи решенийВот в том то и дело что абсолютно недостаточную. Начнем с того что для компонентов модель акторов реализована только частично. Дальше можно не продолжать. Никаких широких возможностей не будет в принципе.
Нет, и этот вопрос никогда не вызвал каких либо проблем, и уж точно никогда не являлся первым вопросом.
Вопрос винспекции объектов вобще не завист от архитектуры. Его задача по большому счету уметь редактировать объекты любой архитектуры. И такой подход как раз и является наиболее здравым в плане архитектуры, потому что позволяет полностью отделить сущности предметной области от средств их инспекции.
Вот в том то и дело что абсолютно недостаточную. Начнем с того что для компонентов модель акторов реализована только частично. Дальше можно не продолжать. Никаких широких возможностей не будет в принципе.
Вы чушь какую-то несёте, может приведёте пример чего нельзя добиться на Qt?
Вопрос винспекции объектов вобще не завист от архитектуры. Его задача по большому счету уметь редактировать объекты любой архитектуры.
wat!? Это бред какой-то, такое ощущение что вы нахватались слов и пытаетесь их составить в какое-то осмысленное предложение, но у вас вместо этого получается какой-то бред.
Qt можно использовать и без Qt creator, собственно практически никто Qt creator и не использует, используют только библиотеки Qt, пишется обычный cmake и спокойно собирается например студией.
Ну это уровень средств разработки начала 90-х имеющий слишком низкую продуктивность. Причем падение продуктивности прямо пропорционально росту навороченности библиотеки.
Все эти программы также спокойно работают под виндой,
а при чем вообще винда до VFX, которая ставит своей задачей унификацию графических средств под линуху?
Ну это уровень средств разработки начала 90-х имеющий слишком низкую продуктивность. Причем падение продуктивности прямо пропорционально росту навороченности библиотеки.
эм… нет уровень разработки 90-х это формошлёпство в дельфях, которые засоряют код компонентами, для судента удобно, для работы нет.
а при чем вообще винда до VFX, которая ставит своей задачей унификацию графических средств под линуху?
Да при том что эти средства без проблем работают и на других платформах. Что доказывает состоятельность Qt.
Вот лично у меня, когда я писал CRM (Qt) на CLion продуктивность была намного выше, чем в QtCreator. Там же обычный CMake — его понимает любая среда.
Геометрический же движок и движок визуализации явно разрабатывали в совсем другой IDE
а вы сами то работали с графикой в Qt? Далеко не каждый фреймворк позволяет декларативно накинуть слой с шейдером прямо в нём, да и scenegraph штука классная. Как минимум, она поддерживает не только directx.
А IDE ортогональна и компилятору, и отладчику, и используемым фреймворкам…
Далеко не каждый фреймворк позволяет декларативно накинуть слой с шейдером прямо в нём, да и scenegraph штука класснаяКраем глаза смотрел как это в FMX сделано. Для графики начального уровня типа визуализации расчетов по наукам и т.д. красава. Для чего то более продвинутого не то пальто. В Qt лучше не будет т.к. что то более продвинутое уже очень сильно задачезависимо.
ортогональна и компиляторуДык потому и использовали другой IDE что у Qt ни того не другого нет а в плане разработки кода средневековье.
Как минимум, она поддерживает не только directx.Ну тоже мне достоинство или сложность нашли. Адаптер API это как раз самая простая часть. В та же FMX еще и сама выбирает что из них и какой версии пользовать.
C++ против C#