Проблема в том, что билдер мог создавать только 32-ух битные приложения под макос. Мак Ос перевели на 64 бит. И 32-ух битные приложения перестали работать в новых версиях ОС. Для делфи сделали поддержку 64 бит, а для Билдера нет - и тянули полтора года с этим. Теперь Эпл выпустили АРМ М1. Делфи сделали поддержку, а Билдер все в том же состоянии. И это вот за последние 3 года -) Когда мы выбирали Билдер - он был на равне с Делфи. Но в процессе его задвинули на не приоритетное направлние - и по сути не развивают, или развивают по остаточному принципу. Эпл тут не причем. Эмбаркадеро - козлы. Согласитесь сделать сборку под 64-бит в 2019-2021 году для С++ компилятора не сверх задача! Тоже самое у них было с 64 бит для Андроида.
Почему изначально выбрал не правильнео средсьво? Они везде декларировали кросс-платформеноость среди разработки, как Делфи так и С++. Но когда дошло дело до обновлений, то С++ они перестали обновлять, а обновляли только Делфи! Причем полтора года не могли признаться что все-таки С++ они притормозили. А пользователи приложения нам полтора года саппорт выносили поддержкой мак 64 бит. А мы ничего не могли сделать....
И на счет совсем другие инструменты? Это что, например? Чтобы один и тот же код работал по разными ОС, и выглядел одинаково. JUCE и Qt только приходят на ум. JUCE не подошел бы по возможности с GUI. У Qt - свои тараканы....
У всех своя правда... Стоит и стояла задача сделать десктопное приложение под винду и мак... Так как весь код на C++ - выбор пал на билдер и мульиплатформенный FireMonkey. Главный фокус был в том, что один и тот же код работает как под виндой так и под маком, и выглядят приложения одинаково. Но Емберкадеро убило поддержку макОс в билдере, со времен перехода на 64бит. Причем не могло в этом признаться полтора года, кормя завтраками и след. релизом. И до сих пор ее не сделало. Нам пришлось переписать весь код на Делфи, а непереводимое засунуть в DLL. После этого я прсто люто ненавижу Емберкадеро. К сожалению я не знаю годной альтернативы, для приложений под вин+мак. Есть фреймворки типа JUCE для С++, но они проигрывают по удобству разработки Делфи....
Я обсуждал вполне нишевый сегмент… Как это обычно происходит у нас (не америка): есть инженер-программист, который программирует промышленные контроллеры (те же сименсы и т.п) он по сути главный, всю логику, автоматику он реализует «железно»… Далее привлекается программист, который пишет приложение, которое отображает, как правило, визуально состояние системы, ведет и сохраняет логи, в самом крайнем случае обеспечивает сценарную логику. Если возникает некая ошибка — сигнализирует оператору. По сути все приложение — это парсер с таймером. Студенты последних курсов — как раз очень подходят: дешево и сердито… С# для таких задач — просто идеальное решение. Все сливки получает инженер — рутину за немного денег делает программист. Все счастливы, все заняты. Инженер со своим С++, и программист с С# -)) Така я вот диверсия -)))
Я вообще не спорю… Это просто мое мнение из моего скромного опыта. Просто по статье получается. С++ весь такой отживший, сложный, медленно развивающийся, бюрократичный. А C# весь такой современный, передовой, кроссплатформенный, удобный. ИМНО истина где-то посередине… Плюс повторюсь — можно смело считать, что С# приложение поставляется с исходным кодом сразу… Кому-то (мне) это не нравится, кто-то от этого в восторге…
Я этим как-бы занимался тоже… Сименсовые контроллеры… точно так же управляются по RS485… Вся производственная линия, и очистные сооружения управляются софтом написанным на С#. Такая связка почти производственный стандарт сейчас — дешево и сердито, низкий порог вовлечения сторонних программеров, которым дается более-менее адекватное ТЗ, и они не понимая сути, делают просто удаленное управление по сценариям, со сбором статистики. Но если, поставить задачу сделать тоже самое нод линукс\мак\винду. И чтобы вашим софтом пользовалось более 5 обученных человек… Чтобы софт выглядел дружественно, симпатично и одинаково под всеми ОС. Чтобы у вас был один код на все ОС. То С# вам не помощник… Что-то, как-то, и через /*№" может и создадите. Но это будет костыль на костыле. Поэтому я тут не сказки теоретизирую…
"… посылаем команду железу что-то выполнить..." Вот железо, которое будет что-то реально выполнять- это и есть уровень С/С++. А послать команду этому железу что-то выполнить можно и на HTML.
И если эту команду захочется послать не с консоли, а с ГУЯ, и не только с винды, то С# и тут не оч подходит — С# вин ориентирован, вся его кроссплатформенность сводится к «консольному»/серверному back-end«у. В лучшем случае, сейчас, его хватит на легкий конфигуратор — галочки расставить. Но для этого есть 1001 альтернативный способ… Плюс, повторюсь, его код полностью открыт. Это все-равно, что управлять банкоматом на каком-то bat»нике.
C# приятен в работе, все за тебя написано, удобно… Но и плата за это соответствующая.
Управление по протоколу можно писать на чем хочешь… Особенно если это UART. Это не тот embed, о котором я говорю. Embedded это когда вы управляете процессами в реальном времени, когда вы считаете операции за такт процессора, когда вы экономите память, когда математика подводится под архитектуру, когда вы реально можете видеть, чем inline отличается от обычной ф-ции. и т.д.
Вы вытащили это с контекста… Речь шла о embedded. И там преимущественно, даже не С++, а С99. И про int переживают с самой статье, а не я. Я сделал упоминание, в рамках того, что там, где нужно, переменные, нужного типа, применяются вполне осознанно.
Безспорно, существует много легаси кода. И есть проблемы с ним. Но стоит ли винить С/С++ за то, что он был основным языком, и практически все с чем и на чем мы работает было написано на нем. Язык продолжает развиваться, и да, легаси его ограничивает. Стоит ли это упрека? Да, порог вхождения в С/С++ выше, чем в С#.
C/C++ это более низкоуровневые языки, C# более высокоуровневый. С++ обвешанный фреймворками — может то что и С#. С# не может «залезть глубже» по своей сути…
Суть статьи С++ vc C#… Я просто поднял вопрос реальной кроссплатформенности в рамках десктопных приложений. С# на данный момент не имеет нормального решения для создания таких приложений: все или в вечной бете, или в очень сыром состоянии, или под виндовс. С++ имеет больше вариантов реализаций. С# приятней для разработчика. На мой взгляд, у C# на первом месте забота о комфортности разработчика, а на втором месте результат работы разработчика. Еще момент, С# полностью декомпилируется — по сути, весь ваш код это opensource. Многих это не устраивает. С++ тоже декомпилится, но до «готового» кода пилить и пилить.
С/С++ это дефакто стандарт для embedded. И лучшей альтернативы нет. ИМНО и не нужно -) Потому, что там где вы работаете с железом вы, скорее всего не будете писать int, а будете писать UInt32 или Int32, если хотите контролировать происходящее.
Сейчас, интерфейс приложения, выглядит полностью стилизован: от кнопок, менюшек, списков, ползунков, графиков… И само приятно, что абсолютно одинаково, что под 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 лицензии не нравятся…
Опишу свою историю: есть «железный» коммерческий продукт, управляется по юсб. Нужно написать юзер-френдли софт под вин и мак. Сначала выбор пал на C#, были долгие мучения заставить работать его под МакОС с Моно… Возможности Моно в плане GUI очень скудные. Работает очень криво. Баги под маком от OpenDialog'а и дальше… Юзерам объяснить зачем приложению в 30 Мб, скачивать и устанавливать Моно на 1Гб тоже тяжело… То, что в статье пишут про 150Мб — не верно (ну или не совсем верно). Был выбор или Qt или, о, Боже, С++ Builder. Остановились на Билдере… На его фреймворке FMX. Такое ощущение, что делфи там же, где и 20 лет назад, и на тех же костылях. IDE глючная, С++ портирован с Делфи -( компиляторы под вин32, вин64 и мак ос разные, поддерживающие разные стандарты С++. Это всё боль разработчика. Но! Один код под винду и мак. очень гибкие механизмы по работе GUI. Идея FMX оч правильная, но хотелось бы, чтобы ее реализовали в MS, а не в Embarcadero. Я понимаю, что рынок десктопных приложений очень мал уже. И вся ориентация на веб. Но когда пишут, что C# кроссплатформенный, это сильное преувеличение… Может какой-то бек-энд сервер на нем и можно сделать, но с десктопом еще не скоро… Моно жалок. Как по мне, C# очень привлекателен для разработчиков, согласен, но нужна реальная кроссплатформенность в нынешних реалиях. Поэтому и приходится быть на С++ и выбирать между Juce, QT, и FMX от Embarcadero.
Проблема в том, что билдер мог создавать только 32-ух битные приложения под макос. Мак Ос перевели на 64 бит. И 32-ух битные приложения перестали работать в новых версиях ОС. Для делфи сделали поддержку 64 бит, а для Билдера нет - и тянули полтора года с этим. Теперь Эпл выпустили АРМ М1. Делфи сделали поддержку, а Билдер все в том же состоянии. И это вот за последние 3 года -) Когда мы выбирали Билдер - он был на равне с Делфи. Но в процессе его задвинули на не приоритетное направлние - и по сути не развивают, или развивают по остаточному принципу. Эпл тут не причем. Эмбаркадеро - козлы. Согласитесь сделать сборку под 64-бит в 2019-2021 году для С++ компилятора не сверх задача! Тоже самое у них было с 64 бит для Андроида.
Почему изначально выбрал не правильнео средсьво? Они везде декларировали кросс-платформеноость среди разработки, как Делфи так и С++. Но когда дошло дело до обновлений, то С++ они перестали обновлять, а обновляли только Делфи! Причем полтора года не могли признаться что все-таки С++ они притормозили. А пользователи приложения нам полтора года саппорт выносили поддержкой мак 64 бит. А мы ничего не могли сделать....
И на счет совсем другие инструменты? Это что, например? Чтобы один и тот же код работал по разными ОС, и выглядел одинаково. JUCE и Qt только приходят на ум. JUCE не подошел бы по возможности с GUI. У Qt - свои тараканы....
У всех своя правда... Стоит и стояла задача сделать десктопное приложение под винду и мак... Так как весь код на C++ - выбор пал на билдер и мульиплатформенный FireMonkey. Главный фокус был в том, что один и тот же код работает как под виндой так и под маком, и выглядят приложения одинаково. Но Емберкадеро убило поддержку макОс в билдере, со времен перехода на 64бит. Причем не могло в этом признаться полтора года, кормя завтраками и след. релизом. И до сих пор ее не сделало. Нам пришлось переписать весь код на Делфи, а непереводимое засунуть в DLL. После этого я прсто люто ненавижу Емберкадеро. К сожалению я не знаю годной альтернативы, для приложений под вин+мак. Есть фреймворки типа JUCE для С++, но они проигрывают по удобству разработки Делфи....
И если эту команду захочется послать не с консоли, а с ГУЯ, и не только с винды, то С# и тут не оч подходит — С# вин ориентирован, вся его кроссплатформенность сводится к «консольному»/серверному back-end«у. В лучшем случае, сейчас, его хватит на легкий конфигуратор — галочки расставить. Но для этого есть 1001 альтернативный способ… Плюс, повторюсь, его код полностью открыт. Это все-равно, что управлять банкоматом на каком-то bat»нике.
C# приятен в работе, все за тебя написано, удобно… Но и плата за это соответствующая.
Безспорно, существует много легаси кода. И есть проблемы с ним. Но стоит ли винить С/С++ за то, что он был основным языком, и практически все с чем и на чем мы работает было написано на нем. Язык продолжает развиваться, и да, легаси его ограничивает. Стоит ли это упрека? Да, порог вхождения в С/С++ выше, чем в С#.
C/C++ это более низкоуровневые языки, C# более высокоуровневый. С++ обвешанный фреймворками — может то что и С#. С# не может «залезть глубже» по своей сути…
С/С++ это дефакто стандарт для embedded. И лучшей альтернативы нет. ИМНО и не нужно -) Потому, что там где вы работаете с железом вы, скорее всего не будете писать int, а будете писать UInt32 или Int32, если хотите контролировать происходящее.
exmp.1
exmpl.2
exmpl.3
Моно же был абсолютно сырой, ну от банальных вещей типа мультивыбора файлов в openDialog, прорисовывалось в нем что-то криво. И до проблем с обычными контролами. Вообщем, всё что касалось взаимодействия с юзером вне винды, оставляло ощущения гуляния по минному полю. В одном из продуктов было реализована простенькая утилитка к одному из продуктов, на Моно: там просто пара кнопок и пара listbox… В итоге отказались от саппорта под мак.
Раньше, иногда, фыркали на IDE Visual Studio, но после перехода на Embarcadero — пришло понимание, что MS это просто идеально -) Но идея с их (Embarcadero ) фреймворком FMX очень не плохая (разработчик россиянин Brovin Yaroslav). Жаль, что реализована не в MS, а в Embarcadero. Есть боль при разработке, но для юзеров все гладко. При Моно было наоборот. Я бы с удовольствием вернулся в MS среду, с нормальной кроссплатформенной поддержкой в плане GUI.
Есть еще фреймворки JUCE и Qt. Но там свои приколы. У JUCE лицензии не нравятся…