Comments 74
Си, конечно, мощный язык, но С++ гораздо более дружелюбен и удобен. А Visual Studio C++, по факту, очень хорошая среда разработки.
Я с Си всерьез столкнулся при попытке внедрить код FFPlay.c в своей проект «МедиаТекст» (он не опубликован, но скриншот можно посмотреть в http://scholium.webservis.ru/Pics/MediaText.png ). Но, чтобы добиться этого пришлось сильно напрячься. Вообще, перенос Си-проектов в С++ – удовольствие ещё то!
Ну, разные языки под разные задачи. ИМХО если требуется что-то низкоуровневое, то я бы предпочел чистый C, а не C++, из-за читаемости и "отлаживаемости". Если требуется что-то более масштабное, гибкое и быстрое, то я бы взял C#. Все эти пляски со стандартами, перегрузками, sfinae и другая шаблонная магия — напрочь отбили желание как-то продолжать его использовать.
Думаю, что лучше сравнивать собственные конкретные проекты. Для работы с пользовательским интерфейсом очень удобен C++ / WTL. Кстати, последний мой проект, в этой связке, это обучающая программа «L'école» ( https://habr.com/ru/articles/848836/ ).
Не нашел по ссылкам исходники к программе, чтобы как-то посмотреть на удобство работы в коде. Для работы с пользовательским интерфейсом отлично подходит связка C# и AvaloniaUI.
Не нашел по ссылкам исходники к программе, чтобы как-то посмотреть на удобство работы в коде.
Вы можете показать мне скриншоты своей программы на Си либо С#. Мне этого будет вполне достаточно, чтобы сделать вывод: стоит с этим заморачиваться либо нет.
А свои исходники я опубликую, когда оптимизирую код. Пока он мне самому не нравится, а вам, уверен, тем более. Там, сейчас, более актуальна концепция построения обучающих уроков, о чем, я надеюсь, поговорить позже.
Для работы с пользовательским интерфейсом отлично подходит связка C# и AvaloniaUI.
«Лучше один раз потрогать, чем сто раз увидеть» или что-то в этом роде… :) . Конкретно, меня интересуют опенсорсные исходники типа «ТоталКоммандер».
ТоталКоммандер вообще на Delphi, насколько я помню, также как и классический Skype
А идея оценивать удобство ЯП по скриншотам GUI звучит так, что вы знаете толк в извращениях. Тем более, что судя по вашим скриншотам, вы совсем какой-то древний UI-фреймворк используете. Даже 20 лет назад такой интерфейс выглядел устаревшим как какая-то программа времён Windows 95.
ТоталКоммандер вообще на Delphi, насколько я помню, также как и классический Skype
Делфи мне не интересен, хотя, в свое время, я программировал на полных исходниках ObjectProfessional, который тоже на Паскале.
Меня интересует не именно TotalCommander, а приложения такого типа, но на С++. Например, опенсорсный файл-менеджер «Explorer++» (Exe-шник: https://download.explorerplusplus.com/dev/latest/explorerpp_x64.zip и Sources: https://github.com/derceg/explorerplusplus/tree/master ). Этот проект вполне устраивает меня, для моих целей.
А идея оценивать удобство ЯП по скриншотам GUI звучит так, что вы знаете толк в извращениях.
Не удобства ЯП, а его возможности. Вот если мне, например, не нравиться вести учет в веб-формах, то пусть они будут написаны, хотя на супер-пупер движке (вроде управляемых форм 1С8х). Достаточно, одного взгляда на скриншот, чтобы сделать вывод – это не моё!
Тем более, что судя по вашим скриншотам, вы совсем какой-то древний UI-фреймворк используете. Даже 20 лет назад такой интерфейс выглядел устаревшим как какая-то программа времён Windows 95.
Хорошо, покажите мне современный интерфейс, для задач моего типа, вроде «МедиаТекста» (ссылка на скриншот, здесь, в моем первом комментарии), либо обучающей программе «L'école». Только, не надо мне онлайновых программ, пусть они хоть сто раз будут современными. Только, оффлайн для десктопа, желательно, под «Форточки».
Здесь уместно спросить: «Вам шашечки или ехать?». Я предпочитаю «ехать». Удобство моего интерфейса меня устраивает, было бы что-то лучшее, не писал бы своих программ, а взял бы готовые.
Судя по скриншоту вам зайдет Tk, который поддерживается, пожалуй, всеми возможными языками уже.
Только, оффлайн для десктопа, желательно, под «Форточки».
Под «Форточки» вам .NET как эталон интерфейсов надо рассматривать, вот обзор UI-фреймворков под него: https://www.youtube.com/watch?v=ze8o-Qa3v7Y
Здесь уместно спросить: «Вам шашечки или ехать?». Я предпочитаю «ехать».
Это ложная дихотомия. Использовать современный UI-фреймворк ничуть не сложнее, чем UI-фреймворк старый как дерьмо мамонта. Наоборот, современные ещё и поудобнее будут.
Под «Форточки» вам .NET как эталон интерфейсов надо рассматривать, вот обзор UI-фреймворков под него: https://www.youtube.com/watch?v=ze8o-Qa3v7Y
Вы это серьезно? Мне приходилось, по работе, иметь дело с программами, разработанными на .NET. Ну, это же чудовищные монстры, для рафинированных садо-мазо. Уж, используйте его, как-то, без меня…
Это ложная дихотомия. Использовать современный UI-фреймворк ничуть не сложнее, чем UI-фреймворк старый как дерьмо мамонта. Наоборот, современные ещё и поудобнее будут.
Ага, Qt, например или, там U++ либо wxWidgets. Работал с ними, но для моих пет-проектов они чересчур избыточны, тем более, что всех задач интерфейса не решают. Например, хороших форм списков (в терминологии 1С), с группами, нет нигде. Хотя, ListCtrl, в MFC, поддерживает категории и группы, но как-то «через одно пикантное, не побоимся этого слова, импозантное место». Вот, разработаны, при царе Горохе, нормальные справочники в 1С77, с поддержкой групп и всё. Что-то более современного, с тех пор, не появилось. Еще худо-бедно присутствует иерархия в справочниках 1С81 и 1С82, но в 1С83, с их уклоном на управляемые формы, все стало только хуже. Лучшие из табличных контролов, представлены в Qt, но, во-первых, без групп (из «коробки»), а во-вторых, Qt – слишком громоздок. Тридцать лет прошло, но эталоном иерархических справочников остается только морально устаревшая «семерка», хотя как быстрой «рабочей лошадке» (когда надо разработать уникальную учетную систему еще вчера) конкурентов ей нет до сих пор.
Вы это серьезно?
Да, серьёзно. Интерфейсы под Windows определяет Microsoft. Чтобы они выглядели нативно, будьте любезны следовать их рекомендациям.
А что вы чудовищного нашли в .NET программах непонятно. Речь идёт об обычных простеньких десктопных приложениях. Там .NET очевидно лучший выбор под Windows. Кажется, вы явно переоцениваете на порядок сложность ваших пет-проектов, раз считаете что C++ там жизненно необходим.
P.S. Почитайте книгу "Психбольница в руках пациентов". Там как раз подробно разбирается ситуация, когда программисты делают интерфейсы для себя, а не для пользователей.
Интерфейсы под Windows определяет Microsoft.
Ну, да. WTL, например. Чем он вам так не нравится? Потому, что «древний»? Зато простой, для пет-проектов, само то!
Чтобы они выглядели нативно, будьте любезны следовать их рекомендациям.
Для WTL, я и следую рекомендациям. Или M$ уже ввела запрет на использование своих продуктов, условно говоря, раннее 2020-года?
А что вы чудовищного нашли в .NET программах непонятно.
Ну, я же говорил, вынужден был иметь дело, на работе, с коммерческими .NET программами. Это и были «монстры», при том, что пользовательский интерфейс там был ужасный. Я бы переписал функционал тех программ на 1С77, только там были «раненые на голову» системы шифрования / дешифрования никому не нужной информации. При этом экспорт / импорт, нужной нам информации, штатными средствами не предусматривался. Приходилось, чуть ли не хакерским методами экспортировать туда наши данные, поскольку вводить их в тех программах было попросту невыносимо. А когда избавились от этой обязаловки, был хороший повод отметить «это дело».
Речь идёт об обычных простеньких десктопных приложениях.
А кому они нужны, если они ничего не умею делать?
Там .NET очевидно лучший выбор под Windows.
Мне, совершенно не очевидно! А, очевидно, С++/ WTL.
Кажется, вы явно переоцениваете на порядок сложность ваших пет-проектов, раз считаете что C++ там жизненно необходим.
Ну, я бы понял разговор, если бы были представлены аналоги моих программ «МедиаТекст» и «Леколь» в других системах разработки. Вся дискуссия идет «вообще», а не «конкретно». А это, никому, ничего не доказывает. Каждый, в любом случае, останется при своем мнении.
Там как раз подробно разбирается ситуация, когда программисты делают интерфейсы для себя, а не для пользователей.
Ну, и в чем проблема? Я лично, ничего не имею против любого творчества. Если мне что-то не нравится, то, просто не использую это, без желания «перевоспитать» кого-либо. Другое дело, когда принуждают заниматься нелюбимым делом. Скажем, работать с «дурацкой» программой. Тогда стараюсь найти какой-то приемлемый для себя выход. И, чаще всего, нахожу.
Ну, у вас свой путь - хобби-программирование.
В коммерческой разработке свои правила. Там не прокатит применять интерфейсы 30-летней давности. Разве что это заказная разработка для какой-то мелкой конторы, где вы демпингом контракт заполучили и им теперь сложно отказаться.
Ну, у вас свой путь - хобби-программирование. В коммерческой разработке свои правила.
Я ведь не претендую на свой «Устав» в коммерческой разработке. Просто, то «коммерческое», с чем приходилось сталкиваться на основной работе, мягко говоря, не очень. Сейчас основная тенденция это веб-программирование, работа с онлайн-формами обмена данными и т.п. По удобству пользования все это не ахти. Производственный учет, в предприятиях, переводят на управляемые формы «восьмерки».
Для меня это все скучно и не интересно. Потому и пошел по пути собственных пет-проектов. Удивляет только менторский тон собеседников. Мол, программирую «неправильно», Надо применять Qt, Net. TK и далее перечисляют всё, что нравится («вообще», а не «конкретно», т.е., без показа собственных наработок) участникам дискуссий. Не понимая, что человек просто решает задачу, которая у него возникла. Как решил, показал свой проект. Не нравится, не пользуйтесь, какие проблемы? Нет, надо «поучить демократии» или чему там еще?
Там не прокатит применять интерфейсы 30-летней давности. Разве что это заказная разработка для какой-то мелкой конторы, где вы демпингом контракт заполучили и им теперь сложно отказаться.
Я использую, в основном, C++ / WTL. C++ более чем 30-летней давности. Отменяем его? WTL первой версии уже лет двадцать, а последняя, десятая версия, обновлена в 2020 году. Тоже – слишком старая? А у капиталистов новое, не всегда лучше, но, как правило, сложнее и дороже. Так стоит ли заморачиваться возрастом фрейморка, если он реально позволяет решать задачи? И не за счет пользователей, которым снижают удобство работы ради Интернет-мобильности приложений для них.
Поэтому, если меня попросят назвать самую лучшую современную программу для пользователя, допустим, ведущего учет на предприятии, то я даже не знаю, что сказать. ERP на 1С83? – Эта система хороша для фирмы «1С» (приносит им максимальную прибыль), но, «так себе» для рядового пользователя. Что еще? А ничего! Учет в облаке – того же порядка.
Хорошо. Какие можно назвать современные продукты от российских программистских команд, которыми бы хотелось пользоваться простым смертным? Что-то я, «с разбегу», не могу назвать ни одной. Может быть, вы подскажите? Я не имею в виду игры.

Вот можете скачать потрогать и код тоже посмотреть:
https://github.com/libreoffice
интересно узнать ваши впечатления, если вы действительно ищете примеры пользовательского интерфейса в исходниках.
Вот можете скачать потрогать и код тоже посмотреть: https://github.com/libreoffice интересно узнать ваши впечатления, если вы действительно ищете примеры пользовательского интерфейса в исходниках.
Ну, с такими ссылками я и сам имею дело по многу раз в день. Это «вообще», а я предпочитаю говорить о «конкретном».
Вот я дал выше ссылки на «Explorer++» :
Exe – https://download.explorerplusplus.com/dev/latest/explorerpp_x64.zip
Code – https://github.com/derceg/explorerplusplus/tree/master .
Запускаем программу и сразу понятно, о чем речь. После этого, при наличии интереса, скачиваем исходники.
Это «вообще», а я предпочитаю говорить о «конкретном».
из конкретного есть WPF (над DirectX-м там все просто и понятно как по мне), не пробовали? Там даже исходники есть в открытом доступе, как ни странно. Видимо они потому и в открытом доступе, потому что джентельменов "чужие" технологии не интересуют, они изобретают свои с приставкой нано.
из конкретного есть WPF (над DirectX-м там все просто и понятно как по мне), не пробовали?
Я не понимаю вашей логики. Вам хочется, чтобы я для решения своей задачи применил технологию, которая интересна вам? Но, ведь задача уже решена, зачем мне ее решать повторно? Чтобы вам было бы приятней пользоваться этой программой? Но, не уверен, что вы будете пользоваться моей программой, в любом случае.
джентельменов "чужие" технологии не интересуют, они изобретают свои с приставкой нано.
«Жентельменов»,, как и «Мадамов», «чужие» технологии интересуют. У меня там из своего только весьма специфические алгоритмы, для которых нет фрейморков. А так, WTL – фрейморк от M$, кроме того применен опенсорс по работе с графикой, звуком и перегрузкой видов в SDI-окне. Кроме того, использован опенсорсный движок SQLite. Без них бы, я эту программу не потянул бы.
Конечно, есть и другие технологии, с помощью которых можно решить эту задачу. Но нет смысла применять их все сразу. Если вы считаете, что технология А эффективней технологии Б, то обосновывайте свой вывод, желательно на примерах, а не голословно.
Ладно, вот уже много лет меня интересует контрол, типа, «справочник» в 1С77, который поддерживает группы. Можете предложить опенсорный проект по использованию аналогичного контрола? Например, как в ТоталКомандере используется отображение папок и файлов. Мне нужно тоже самое, но для базы данных, например, SQLite.
Если вы не подскажите мне ответ, то придется изобретать собственный велосипед, с «приставкой нано». Чтобы потом, вы опять сказали, ну, вот, снова не применил существующие технологии.
Кстати, без групп, можно использовать (на С++ / WTL) исходники контрола «WTLGridCtrl». Это лучшее, что я знаю, для WTL.
Вам хочется, чтобы я для решения своей задачи применил технологию, которая интересна вам
да нет, я не конкретно про вашу задачу писал, а как бы в общем, если уже работает проект и, видимо, достаточно большой его конечно не перепишешь вдруг.
меня интересует контрол, типа, «справочник» в 1С77, который поддерживает группы. Можете предложить опенсорный проект по использованию аналогичного контрола?
так вам не использование контрола надо искать, мне кажется, а "Проект контрола" - библиотеку с контролом какой вам нужен или хотя бы такой чтобы его не сложно было доработать до вида который вам нужен, наверно можно кстати и WPF-ные контролы посмотреть, их насколько я знаю из С++ можно вызывать, но с этим наверно сложно разбираться, это какая-то отдельная супер технология в которую вдруг не влезешь конечно, мне бы самому наверно месяц-два понадобился чтобы что-то изобразить в этом направлении работающее. Наверно самое сложное с визуальными компонентами это их согласование с текущим рабочим енвайроментом (с действующи набором библиотек). Ну и разработка контролов это отдельная тема от их использования.
если спуститься по ниже на WinApi будет разработка почти как в SDL любой версии, в ВинАпи в части отрисовки окна, кистей, отрисовке текстур через GDI(на сколько помню есть еще помню есть конкретно свои методы по загрузке текстур и дескрипторов текстур), RichText и прочее, сами удивитесь будет даже проще чем даже если и намерено рисовать в граффике в DirectX любой версии, я про десктопные приложения аля Нотпад и прочее
да нет, я не конкретно про вашу задачу писал, а как бы в общем, если уже работает проект и, видимо, достаточно большой его конечно не перепишешь вдруг.
На самом деле переписать проект не проблема, главное, чтобы был смысл. Так, я уже думаю над второй версией «МедиаТекста», поскольку, при работе с ним, столкнулся с необходимостью его улучшения.
Поэтому, я был бы не прочь узнать, что именно хотят другие, в части программного интерфейса. Однако понять претензии довольно сложно. Похоже на анекдот:
«На митинге Партии Женщин:
– Кто мы?
– Женщины!
– Чего мы хотим?
– Не знаем!
– Когда мы этого хотим?
– Прямо сейчас! И много!!!»
Мы ведь говорим на разных языках. То, что для меня означает «вообще», для вас означает «конкретно». И тому подобное.
кстати и WPF-ные контролы посмотреть
Да, нет там ничего! Например, в https://github.com/Kinnara/ModernWpf - обычные списки, без групп. А сам интерфейс «плоский», который мне не нравится. Причем, главное, это проект на C#, что вне моих интересов. Я предпочитаю оставаться на С++.
Наверно самое сложное с визуальными компонентами это их согласование с текущим рабочим енвайроментом (с действующи набором библиотек). Ну и разработка контролов это отдельная тема от их использования.
Да, нет особого смысла впихивать чужеродные контролы в свой проект. Лучше уже разрабатывать контролы самому. В моем случае, есть подходящий прототип WTLGridCtrl, о котором я уже упоминал. А группы ему можно будет уже нарисовать самому. Кстати, все контролы это именно умение рисовать их на экране компьютера. Поэтому, надо хорошо осваивать работу с графикой, вроде GDIplus и ему подобным, скажем, с опенсорсной библиотекой «ImageStone».
Для примера, смотрите скриншот моих редактируемых ячеек ( http://scholium.webservis.ru/Pics/CellsEdit.png ), которые я успешно рисую в своей демонстрационной программе (там можно редактировать любую ячейку, перемещая фокус ввода).
Кстати, все контролы это именно умение рисовать их на экране компьютера.
я бы даже сказал управлять рисованием на экране или даже программировать рисование. И я согласен что:
Поэтому, надо хорошо осваивать работу с графикой, вроде GDIplus и ему подобным, скажем, с опенсорсной библиотекой «ImageStone».
наверно хороший пример, с которым я не очнь знаком. Для меня WPF является такой своего рода опенсорсной библиотекой. Но в основе любой такой графической библиотеки лежит определенная концепция-идея, которую требуется время понять осознать, в этом сложность если мы имеем и занимаемся в какой то выбранной (задданной проектом) системе даже просто для сравнения попробовать что-то другое очень непросто затратно. Согласен!
Пользовательский интерфейс я сейчас делаю исключительно в браузере, и более никак. Практика показала, что этот способ наиболее переносим.
... только необходимо изучить язык разметки html, изучить стили css, ну и javascript. Учитывая их "совершенно не строгую типизацию" переменных, разработка интерфейса скатывается в "добавил свойство в css, перегрузил страницу в браузере, с удивлением обнаружил, что свойство не применимо в текущем контексте". Лыко и мочало начинай с начала. Но наше "наиболее" перевешивает все.
Есть куча языков, компилируемых в js. Тот же TypeScript например. Хотя я предпочитаю scala.js. Пожалуйста тебе и строгая типизация и ещё куча вкусных плюшек. На js пробовал писать лет 12 назад. Более 2К строк не выдержал. Хорошо добрые люди подсказали мне про TypeScript который тогда только-только появился.
ИМХО если требуется что-то низкоуровневое, то я бы предпочел чистый C, а не C++, из-за читаемости и "отлаживаемости".
Можно всегда на С++ в Си-стайл писать, используя только подмножество языка. Но у Си конечное есть своя ниша - старые/актуальные и новые проекты, типа Linux/DPDK/SPDK/кодеки/либы и т.д. Ну и конечно C ABI.
Тут дело в том, что на C++ можно писать сильно по-разному. Кто-то плотно сидит на boost, у кого-то свое понимание использования шаблонов, бывает магия перегрузок и так далее. А бывает, как Вы сказали, и в стиле Си с классами. И загвоздка может заключаться в том, что в разных проектах C++ может использоваться кардинально разный подход и области языка. В случае Си или C# я не видел подобного, обычно все довольно похоже и целостно (за исключением добавления странного на мой взгляд сахара в C# в последние года). Это исключительно моё наблюдение, не претендую на объективность. Отдельно добавлю, что я с удовольствием смотрел лекции Константина Владимирова по C++, но это скорее академический интерес, мне немного возвращает воспоминания из юношества, когда я изучал плюсы и сделав тогда невероятно хитрый шаблон который разворачивался из одной строчки во что-то безумное — был невероятно горд собой и получал от этого удовольствие, но вот в работу я бы такой код не добавлял =)
Писать можно, но нет, не пишут сильно по разному, все пишут примерно одинаково, есть "талантливые" ребята которые могут в шаблонную магию высокого порядка, но таким говоришь не пиши так и они не пишут. В среднем народ пишет на с++ как на си с классами и немного простых шаблонов + стандартная библиотека, типа возврата optional, если подразумевается что значения может не быть. 9 из 10 программистов в шаблоны толком не умеет. А насчет плотно сидит на boost, что в вашем понимание плотно сидеть? boost достаточно разношерстная и огромная библиотека, ее части можно использовать независимо от друга, но не в этом суть, разработка проекта ведется командой, команда должна обсуждать какие библиотеки использовать и брать в проект, в крайнем случае это может сказать лид, это юзаем, это не юзаем, но для этого у лида должен было очень сильный авторитет в команде, иначе будет разброд и шатание, плюс саботаж решений. я предпочитал советоваться с командой, точнее спрашивать у них и провоцировать их самих прийти к решению, если команда в целом подобрана правильно и сработавшаяся то мнение как правило единогласное. А тем кто приходит на проект, ну сорян, есть проект, есть зависимости, что бы хорошо ориентироваться в проекте придется подразобраться с зависимостями то же. Но как правило большой проблемы нет, есть 20-30 распространённых либ, их примерно все и используют. Так на вскидку, для сети curl, для работы с сжатием zlib, картинки imageio, физика libbullet, бд libpq или sqlite, и так далее... или у вас Qt и там все и так есть на все случаи жизни и можно ни о чем не думать.
В среднем народ пишет на с++ как на си с классами и немного простых шаблонов + стандартная библиотека
Так а зачем городить сложности на ровном месте?
Впрочем, писать на плюсах, как на сишке (с сырыми указателями и прочими штуками) не очень хорошо. На плюсах надо писать как на плюсах. Но и наворачивать тоже ни к чему. Я, например, редко использую исключения и шаблоны - только там, где без них реально будет сложнее и очень многословнее.
Мне не нравится как сделаны исключения в с++, их не использую и всем советую делать так же. Только из конструктора нельзя вернуть ошибку, но здесь проблема решается просто, раздели инициализацию и конструирование объекта и возвращай ошибку другими способами.
Зачем городить сложности, так и я говорю что их не городят. А пишут на с++ примерно как на яве или сишарпе. Сырые указатели заворачиваются в unique_ptr. Сложно так сказать сразу, как-то выработался за время работы некий джентельменский набор хорошего тона что стоит использовать что нет. На си нет такой хорошей стандартной библиотеки, потоков, да много чего нет, filesystem, thread и прочего и прочего. А самое важное что на си нет многих библиотек, сам язык не так важен, наверно многие библиотеки имеют си интерфейс, например curl но использовать чистый курл - да застрелиться можно, cpr значительно удобнее. Си библиотеки можно в с++ обратно сложно. С++ силен огромный количеством библиотек в первую очередь, меня всегда удивляют рассуждения на тему вот тут функцию вызвать удобнее, а тут массив перебрать, да вообще все равно как оно там и какой в языке синтаксический сахар. На С++ я могу решать любую прикладную задачу и скорее всего там будет лучшая на свете библиотека для этого. В других языках будет в лучшем случае порт си/с++ библиотеки в их язык через обертки. Но некоторые библиотеки я не представляю как портировать boost::graph или CGALL, особенно в последней просто тысячи человек работы закопаны, конечно она не всегда нужна или даже правильнее сказать очень редко и мало кому нужна, но если вам понадобится то где это взять? Вообще перечислять библиотеки можно часами, так на вскидку Bullet, OpenCV, OpenImageIo, Imgui, libpq, libnoise, box2d, spirv-tools, taskflow, sqlite и я еще не достал ультимативное оружие в виде Qt.
Почему-то все думают что с++ такие отмороженные и вообще не хотят даже смотреть в сторону других языков, да почему не хотим, я лично прикручивал python, lua, chaiscript к разным проектам на с++, все хорошо там где оно уместно, просто я реально не понимаю зачем мне идти и разбираться в концепции AndroidSDK, если я могу взять и сделать приложение на с++, прикрутить к нему imgui и программировать себе дальше ровно так же как до этого делал на десктопе все кнопочки, менюшечки и прочее, ну или Qt достать и делать все то же самое. Это же справедливо и под iOS. Про десктоп вообще молчу, с 2017 года наверно даже стало как-то некультурно обсуждать будет ли кроссплатформенная поддержка или нет, просто сразу думаешь о том что приложение будут собирать на вин, мак, линуксе.
Просто два слова которые уложат на лопатки любые попытки заменить с++. ffmpg и gstreamer. Все нет аналогов. В лучшем случае порты. И не будет никогда. Никто не напишет на java аналог gstreamer. Надо для этого еще одну планету иметь с 8 млрд населением.
два слова которые уложат на лопатки любые попытки заменить с++. ffmpg и gstreamer
Но они же на Си?
Никто не напишет на java аналог gstreamer.
Разработчики gstreamer усиленно переходят на раст. Ядро фреймворка, может быть, ещё долго будет сишным, но плагины на расте пишут.
Это не правильно и многие не согласятся, но я воспринимаю Си/С++ как один язык. Почему так? Ответ простой, могу ли я взять Си библиотеку и просто ее использовать в своем коде - ответ могу. То есть мне не нужно думать о биндингах, обертках и каких-то еще вещах.
>>силенно переходят на раст
Много кто переходит на Раст, разработчики ядра линукса то же, посмотрим что из этого будет. Вы же знаете С++ крайне ленивые жопы и жутко консервативные, что бы просто посмотреть и почитать какую-то новую технологию ей нужно дать настояться и пройти бета тест временем, если через 3-5-7 лет она не заглохнет, а популярность будет расти(ха-ха, забавная игра слов, "популярность раста будет расти") , будет все больше статей, и ключевые слова все чаще попадаться на глаза, то можно и обратить внимание. Может конечно это только я такая ленивая жопа и за всю Одессу говорить не стоит, но я правда не вижу пока смысла тратить время на Раст. Так пропустил C#, Go, NodeJS и еще что-то. Эти языки заняли какую-то нишу и прекрасно живут в ней, беда в том что мы с ними идем параллельными курсами, геймдев все так же живет на с++, все так же есть огромное количество движков и библиотек на с++ которые позволяют решать задачи не хуже чем на Юнити, а местами даже лучше. Все так же есть огромный спрос на с++ программиста в геймдеве. Поэтому вопрос, зачем тратить силы и время на какую-то параллельную технологию, если даже в мире С++ каждый день появляется столько всего нового и полезного что и его не всегда успеваешь посмотреть. Появляются из ниоткуда новые фичи языка, новые библиотеки, старые обрастаю все более крутыми функциями, еще вчера я писал в вижуал студии под вин на ДХ9, а сегодня появился, андроид, ios, кроссплатформенная разработка, cmake, webasm, оказывается можно взять ImGui и забабахать на нем крутое веб приложение, какие-то библиотеки для бэкенда на с++ вроде того же userver о котором только сегодня услышал, открываешь его а там все так непонятно и ново, модно, современно. Так что Раст это здорово и хорошо, если взлетит - пощупаем, если не взлетит, то оттуда в с++ 25, 27, 30 идей надергают и будет счастье, а мне бы пока не отстать от мира С++.
Ответ простой, могу ли я взять Си библиотеку и просто ее использовать в своем коде - ответ могу
Во-первых, это должно работать и в обратную сторону, чтобы считать их одним языком. Во-вторых, этак в родственники Си можно записать кучу языков, нативно поддерживающих сишные хедеры, например, Zig.
Много кто переходит ..., а мне бы пока не отстать от мира С++.
Не вижу, как эта простыня связана с утверждением "ffmpg и gstreamer. Все нет аналогов. В лучшем случае порты. И не будет никогда."
если нет интереса писать свои реализации физики и посмею сказать на библиотеки окон запустить окно иксами извините или ВинАпи, и в альтернативу воспользоваться 1 библиотекой для текстур и 1 библиотекой для музыки, то вполне норм, если брать по минимуму то матешу, окно, и часть физики вполне вроде можно осилить, даже учитывая что есть мастодонты Анриал и Юнити (единственное препятствие может быть если нужен Андроид), насчет имгуй я пока не понял почему его все хвалят вы же можете сделать двух матричную отрисовку и гуй рисовать решив еще вопрос со шрифтами (ну разве что сложность может быть с реализацией BVH - но вроде можно натаскаться поняв суть зачем он - отсюда баундинг боксы(причем они просто симулируются для расчета) и рейкасты)
Из предисловия к одной популярной книге по C++ :
С++ — это на самом деле не столько язык, сколько инструмент для создания ваших собственных языков.
Разве что запрещением тех или иных возможностей в вашей кодовой базе. Ну как где-то запрещены исключения, где-то запрещено шаблонное метапрограммирование, где-то ещё что запрещено.
Создавать языки метапрограммированием в C++ тяжело: адекватной макросистемы нет, шаблонное метапрограммирование — ад. В языке ML-семейства (в хаскеле, например) куда проще что автору библиотеки с eDSL'ем, что её пользователю. Лисперы тоже много чего хорошего расскажут про их стиль метапрограммирования.
Создавать языки «классически», где вы пишете парсеры-компиляторы-интерпретаторы, на C++ тоже тяжело хотя бы просто потому, что на том же хаскеле комбинаторные парсеры пишутся за время, сравнимое со временем однократной компиляциии проекта, использующего тот же boost.spirit.
Я бы сказал, что основная ниша плюсов — развитие и взаимодействие с уже написанным кодом на плюсах. Так как его много, плюсы никуда не денутся. Но начинать новый чистый проект в 2025-м на плюсах я не вижу смысла (если это, конечно, не какая-нибудь эмбеддщина, где компиляторов других языков нет).
Правда, к C почти всё это тоже относится.
Я эту цитату про "собственные языки" менее буквально понимаю, в том примерно смысле как было выше написано что "на C++ можно писать сильно по-разному" , то есть для конкретного проекта вы создаете какие-то свои локальные мини-идиомы.
А с практической точки зрения я с Вами вынужден согласиться, я люблю C++, но теперь это только как хобби...
Я бы сказал, что С++ допускает большую свободу в определении своего стиля программирования. Но не создания языка.
Я больше всё-таки про низкоуровневый код. Если Си становится тесным, то вполне можно перейти на С++, потихоньку добавляя разные возможности. Есть свои нюансы, но в принципе возможно. И тут большой плюс у C++ - какая-никакая но совместимость.
А в остальном согласен, С++ за время существования, такое легаси накопил, что очень сложно читать код реальных проектов, там разброс от фабрик-фабрик, до шаблоны-шаблонами погоняют. а ещё функциональщина. И это не говоря о библиотеках.
На Си тоже есть мастера жанра, которые изобретают ручное ООП, ещё и с макросами, но лично для меня классический процедурный код понятнее. Например, Linux-ядро - тупое как пробка.
мы несколько драйверов написали на С++17. Это просто небо и земля по сравнению с чистым Си. Деструкторы, шаблоны, лямбды. Я вообще не представляю зачем писать на С в 2025 году хоть где-то.
А есть ли возможность посмотреть на код где-то? Или может быть у Вас есть ссылка на нечто похожее, которое отражает суть вышесказанного "небо и земля"?
Согласен, лучше писать на C++ и при необходимости делать обёртку на C для FFI.
Вот не знаю... Чистый Си очень прост. И глядя на код довольно легко понять, во что примерно он будет развернут. Глядя на код С++, этого понять уже нельзя. В приложениях реального времени (а мне раньше часто приходилось этим заниматься) это очень важное качество. Я честно говоря вообще не понимаю, зачем С++ до сих пор развивают и принимают новые стандарты. Он уже стал совершенно необозрим, и напоминает скорее собрание собрание заплаток и костылей. А для более абстрактного и высокоуровневого программирования сейчас есть языки куда более приятные чем С++. По-моему зафиксировать его на текущем стандарте и забыть.
Чистый Си очень прост. И глядя на код довольно легко понять, во что примерно он будет развернут.
Ну, это как писать :)
Особенно, с учётом возможностей препроцессора. Реально, на практике астречается много "заумно эффективного" кода, особенно, в программировании микроконтроллеров
Не, ну тут как бы без вопросов. Говнокод можно написать на любом языке, тут нет ничего удивительного. Просто по-моему на С++ сделать это значительно легче, чем на чистом С. Разумеется я про задачи реального времени, где очень важно иметь представление, во что код будет развернут. Если оно будет ходить на столе у бухгалтера, там разницы особой нет. Лишь бы работало. Но для этого ни С не нужен, ни С++.
Чистый Си очень прост. И глядя на код довольно легко понять, во что примерно он будет развернут. Глядя на код С++, этого понять уже нельзя.
Ну, это ни о чём не говорит. Вот беру я код FFPlay,c, размером около 150 КБ. И что я там вижу? Вроде, достаточно простой алгоритм использования различных функций и структур (порой чрезмерно сложных, вроде OptionDef options[]). Но, во-первых, никто не отменял зависимости, а они, для консольного видео-плейера, достаточно сложны. А, во-вторых, мне не нужны консольные программы, я больше ориентируюсь на оконные приложения. Поэтому, чтобы интегрировать видео в отдельное окно, мне приходится делать достаточно много телодвижений.
Что касается «кода С++». Да, любой объемный проект, достаточно сложен для восприятия. И подчас, чтобы просто скомпилировать его, надо иметь чуть ли не «семь пядей во лбу», особенно, если система сборки не связана с Visual Studio C++ и, тем более, с «Windows». Но, здесь я использую метод «пересборки» проекта. Т.е., делаю пустой проект и начинаю туда последовательно копировать код, из оригинального проекта, в порядке его выполнения. Это, конечно, долго. Но, я руководствуюсь такой установкой. Допустим мне надо написать подобную программу с нуля. Вот, у меня есть рядом аналогичный проект, как прототип. Ведь, все же легче программировать по прототипу, даже со всеми его «бзиками», чем, полностью, с нуля. При достаточной настойчивости, иногда, получается, что очень радует.
Далее, если собственный проект, на С++, полностью оригинальный, то он вполне понятный, поскольку, реализуется постепенно по нужному сценарию. Здесь, естественно, имеет смысл использовать паттерны «идеального программирования». На эту тему много всякой разной литературы и вопрос еще не закрыт. Для себя я придерживаюсь такой тактики:
Использую шаблоны WTL, на мой взгляд, идеального фреймворка, для моих целей.
Применяю метод «итерационного программирования». Т.е., нулевой проект это пустой шаблон приложения, например, сгенерированный мастером WTL и «причесанный» на собственный вкус. В первой итерации добавляется небольшой код, с описанием, в сопровождающем его, doc-файле. Во второй итерации проекта добавляется еще один кусок кода, делающий какую-то минимально самодостаточную работу и т.д. и т.п. Не могу сказать, что это идеальный подход, но, я постоянно думаю, над его совершенствованием. Например, выношу общую часть всех итераций в отдельный каталог.
Я честно говоря вообще не понимаю, зачем С++ до сих пор развивают и принимают новые стандарты. Он уже стал совершенно необозрим, и напоминает скорее собрание собрание заплаток и костылей.
Новые стандарты, как и новые версии Виндоуз, я, лично, просто не использую. Просто, нет потребности. Однако, сулить нужно / не нужно, не берусь. «Им» из «погреба» виднее. Пока, мне более, чем достаточно VS C++ 2013 и 2017. Что-то есть ценное, в плане создания проектов из «чистого» кода в VS-2019, который я использовал только затем, чтобы создать проектные файлы, в которых уже понижал версию «Студии» до 2013-й или даже до 2010-й. Ограничением здесь являются только новые фичи языка, которые встречаются в опенсорных проектах. Всегда стараюсь, по мере возможности, от них избавиться
можно посмотреть в http://scholium.webservis.ru/Pics/MediaText.png
Ого, чистый незамутнённый http в 2025 году
Странно, что в выжимке "что обязательно нужно знать" ни слова не сказано про Undefined Behavior.
А это именно то, что нужно любому разработчику на сях и плюсах знать с первых дней. Потому что доходит до откровенно смешного, я не раз сталкивался, что люди, которые пишут код на C много лет (!), не до конца понимают, что же такое undefined behavior и чем оно может грозить - и продолжают распространять всякие заблуждения, что "это только про ошибки работы с памятью", и "если на моей платформе и моем компиляторе оно работает, то значит так можно, все нормально"...
Странно, что в выжимке "что обязательно нужно знать" ни слова не сказано про Undefined Behavior.
В статье есть раздел (прямо в оглавлении указан под №14 из 15):
14. Переносимость, неопределенное поведение и безопасность доступа к памяти
А в каком языке нет проблем с библиотеками и зависимостямм? Например на питоне могут не менее интересные чудеса. Как то натыкался на случай, когда питоновский скрипт требовал библиотеку определенной версии, а автор библиотеки эту версию удалил из общего доступа.
Уверен и на шарпе что то похожее может происходить
На питоне всё-таки есть собственный менеджер пакетов pip, что гораздо удобнее нежели скачивание пакетов вручную или добавление скачивания через сценарии. Просто две команды: pip freeze > requirements.txt
и pip install -r requirements.txt
В питоне есть несколько вариантов. Либо попытаться вручную решить конфликт версий путём доработки модуля(если не бинарник). Или найти на PyPI аналог.
С Питоном не смешивайте, там свой мир. Я наткнулся на багу в opensource библиотеке, которая мешала. Поправить то можно, но софт должен идти на конкретном дистрибутиве конкретной версии, и там пакет библиотеки уже не обновится. Что делать? Всю библиотеку с собой тащить?
Нет, гружу как есть и после загрузки подменяю в загруженном коде один метод на свой, поправленный.
Как такую проблему решают в С++?
Обычно тянут свой подправленный вариант в виде динамической библиотеки, под windows такая практика повсеместна, под linux для closed-source плюс-минус тоже.
Хотя в целом, ничего не мешает поставить хук на таком методе и выполнить свой вариант, но конечно же это удовольствие совершенно не из легких. Но так можно решить проблему в любом нативном коде, не только C++.
А вообще если это действительно баг - отправлять PR конечно же.
Когда впервые начал изучать, то взял с++. Но по истечении времени решил, что более правильно будет начать с си. Во-первых он проще, а во вторых очень полезно наработать чтение си, т.к. много всякого опенсорса есть на нём. Первой моей целью разбор CPython. Но это вкусовщина.
помимо gnu ld, есть еще gold и mold, сейчас переписываю 3D(DSA OpenGL 4.6 core) на С без использования библиотек (использую только такие библиотеки как X11,GLX, Glew, assimp, stb) и столкнулся, что ld действительно медленный, но в целом и так нормально покачто (компил без стандарта - мне нравится как работает, структурный стиль очень удобный), без симейка в вскод с простым скриптом сказка просто, после этих всяких перелинковок Симейка, программа на С немного по другому работает, еще заметил окно быстрее открывается - практически мгновенно
Из IDE можно еще вспомнить Code::Blocks: выполняется в системе наитивно и нетребовательна к ресурсам, в отличии от перечисленных в статье.
Одно из преимуществ всего этого — частичная сборка: если вы сохраняете объектные файлы после компиляции чего-либо, вам нужно перекомпилировать объектные файлы только для тех C-файлов, которые вы обновляете.
Это если вы не изменяете общие .h файлы, включаемые в исходники и желательно вручную указываете что компилировать. На С\С++ приходится для микроконтролеров и сильно раздражает, когда меняя один .h файл включаемый тоьлко в один из .С файлов, чертова автоматическая сборка иногда начинает полную перекомпиляцию вообще всего.
Язык C небезопасен с точки зрения доступа к памяти, плюс вам придется самостоятельно управлять ею
что это вообще значит? Если процесс начнет ломиться куда не положено, то получит SEGFAULT. Или например после fork()
процесс-потомок не получит доступ на запись к памяти родителя без дополнительных усилий. Это безопасность или нет? А как насчет присутствующих в gcc и clang аттрибутов cleanup
, constructor
, destructor
- это случайно не полные аналоги init
и defer
из golang?
Когда вы работаете с кодом, который должен обезопасить или обработать ненадежные входные данные
то есть в других языках входные данные всегда надежные, ничего обрабатывать не надо? Дальше не читал, прокрутил вниз.
Мы все в курсе, что язык C — появился раньше сред, требующих работы с зависимостями и библиотеками.
я в курсе, что например в cmake есть FetchContent
, позволяющий скачивать что угодно откуда угодно. А ламер, наливший кучу воды в этой статье - видимо нет. Хотел написать "наливший кучу воды при помощи нейронок", но даже ChatGPT в ответе на вопрос про управление зависимостями в проектах на Си упоминает conan с vcpkg...
Хотел написать "наливший кучу воды при помощи нейронок"
И затем это полито каким-то адским брейнфакингпромптом:
Например, если я хочу использовать библиотеку криптовалют, то я могу установить libopenssl
Оригинал:
For instance, if I want to use the cryptology library, then I can pull install libopenssl
Если процесс начнет ломиться куда не положено, то получит SEGFAULT.
Это и есть "небезопасная работа с памятью". Если указать выходящий за пределы массива индекс в С - будет segfault, всё упадет, мир взорвется. В более безопасных языках есть сначала compile-time check , потом runtime check, после которого будет либо ошибка, либо исключение, а не краш.
В более безопасных языках есть сначала compile-time check
int main(int argc, char *argv[]) {
int a[5];
a[6] = 1;
}
$ clang t.c
t.c:3:3: warning: array index 6 is past the end of the array (that has type 'int[5]') [-Warray-bounds]
3 | a[6] = 1;
это компайл-тайм чек?
потом runtime check
тебе кто-то запрещает делать рантайм проверки в Си, бездарь?
после которого будет либо ошибка, либо исключение, а не краш.
ты несешь бессмысленную чушь. Рассказать, к чему приводит необработанное исключение, или сам догадаешься?
это компайл-тайм чек?
Это хрупкая эвристика, которая тривиально ломается:
void set(int *arr, int pos, int val)
{
arr[pos] = val;
}
int main()
{
int a[5];
set(a, 6, 1);
}
$ clang++ -Wall -Wextra test.cpp
$
тебе кто-то запрещает делать рантайм проверки в Си, бездарь?
Бездарям из кучи опенсорс-проектов, в которых потом находятся CVE, что-то мешает.
Рассказать, к чему приводит необработанное исключение, или сам догадаешься?
Откуда подмена тезиса про «необработанное» взялась?
Давно такого не Хабре не видел, жаль кармы на минусы не хватает.
Если указать выходящий за пределы массива индекс в С - будет segfault, всё упадет, мир взорвется.
Это лучший случай. Худший случай — это если оно пройдётся по памяти вашего же процесса, и просто тихо испортит данные.
А есть ли такая статься по JS?)
Набор инструментов, необходимых для создания языка C, обычно называют toolchain.
Ужасно звучит
Под виндой с удовольствием использовал https://ru.m.wikipedia.org/wiki/LCC
Хорошая обзорная статья. Я бы еще добавил в часть с библиотеками пару слов про возможность явной и неявной линковки (через dllexport/dllimport) и DEF файлы. В моей практике довольно часто используются.
Собрал в одном большом гайде всё, что хотел бы знать, когда изучал язык C