С/С++, Почему до сих пор все сидят на древних языках вроде С и С++ Опции

[juvf]

Очередной хлоливар С/С++ vs Java/C# возник в месте обсуждения РТОС для мк. Я его переместил сюда.

Вброс

Читаю все это и волосы дыбом. Тем более что и работаю с этим. Почему программист должен думать об освобождении памяти? Почему многопоточность не поддерживается средствами языка? Почему до сих пор все сидят на древних языках вроде С и С++ (он недалеко ушел от С, пусть и поддерживает ООП, но все равно с ним обрушить любую систему на ура можно. Есть ли нормальные реализации Явы или С шарп для контроллеров? Иначе это хождение по граблям будет вечным. 15 лет в теме и все одно и тоже. И памяти то уже достаточно для Явы например, и все равно. От слов «указатель» и «приведение типов» тошнит уже в век, когда объемы флеш и озу - ничто, а время на выпуск - все, это анахронизм какой то

Читаю все это и волосы дыбом.

я когда вижу код на Perl - волосы дыбом, это не значит что Perl гавно.

Почему многопоточность не поддерживается средствами языка?

а почему в языке должна быть многопоточность? Язык - это всего лишь язык. А всё остальное - это библиотеки, фрэймворки. Нужна многопоточность - подключай boost, Qt, *RTOS.... или сам суперлупом обеспечивай. Такто можно заявит: Почему сигналы-слоты не обеспечивает язык? Почему extFat не обеспечивает язык? Почему KDE не обеспечивает язык?

Есть ли нормальные реализации Явы или С шарп для контроллеров?

нету. не нормальных, не ненормальных.
какая к чёрту жава на мк? Даже эти ваши линуксы пишут на си по сей день. не на жаве, и тем более не на с#. и жава.... для неё нужна жавамашина. какую жава машину вы запехнёте в мк с 1кБ ОЗУ? Всё это удел высокоуровнего программирования, окошки, форточки... даже для ПК драйвера пишут на Си/С++. Не разу не слышал чтобы кто-то написал низкоуровневый драйвер для ПК на жаве.
А по поводу с# на мк- вообще смешно.... ибо c# не не язык программирования, а "язык программирования виндоус". Вы бы ещё спросили "А есть нормальные реализации языка 1С для мк?". ))
см вики

C# — объектно-ориентированный язык программирования. Разработан в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework....

Это нужно в мк с 256 байтами ОЗУ (да хоть и с 64 кБ ОЗУ) запихать .NET? А также для неё поставить Windows8.... c мэтро

С++ (он недалеко ушел от С, пусть и поддерживает ООП, но все равно с ним обрушить любую систему на ура можно.

Дак на ура и жавой рушатся приложения только так.

Посмотрите примеры программ на Java - там нет этого дебилизма. С++ позволит даже такое *(int *)0x40001234 = 0; На Яве вам никто не позволит пользоваться указателями, оных и нету, и никто не позволит приводить типы с уменьшением точности. С++ - это очень старый язык, он неплох для своих лет, но уже 2014 на дворе. Тот же ассемблер завуалированный.

А как в яве запись в регистр микросхемы? например в общем адресном пространстве 0x40001234 - адрес регситра RxDATA, а 0x40001236 - адрес регистра TxDATA. Как на Jave происходит обращение к этим регистрам?

С++ - это очень старый язык, он неплох для своих лет, но уже 2014 на дворе.

старый не знаяит плохой. Русский ещё старее, а на дворе 2014...
ДВС - ему больше 100 лет. а на дворе 2014. Но пока человечество не придумало лучше двигатель.

[halfdoom]

Сугубо практический взгляд со стороны. Этим летом мы сдавали с подрядчиком контроллер техпроцесса (все x86+Linux, порядка 10 отдельных контроллеров). Наши ребята писали все на чистом C++ с Qt (лицензия на последний принадлежит заказчику) - это 7 контроллеров. Подрядчик писал на Java (остальные контроллеры). До выезда на объект было написано множество тестэ-кейсов, вопросы взаимодействия были более или менее отлажены.

Запуск линии прошел на ура, а проблемы начались на 3й день работы. После разбора полета выяснилось, что контроллеры на Java не успевали отрабатывать все события, причем простой перезапуск системы полностью восстанавливал работоспособность. Их ребята выяснили, что 2ГБ на процесс им мало. Причем ничего навороченного там нет, математика на уровне 3го курса. Одноплатные компьютеры у заказчика специфические, поэтому нарастить память возможности нет. В итоге, что-то они там крутили в параметрах Java-машины и все пришло в норму. Это стоило нам лишней недели командировки, но теперь мы единственный исполнитель на следующую линию, что можно отнести к несомненным плюсам Java технологий.

С другой стороны, у меня есть возможность оценивать работу программистов пишущих на C++/Qt и FreePascal/Lazarus. UI последние однозначно пишут быстрее, но кривость LCL периодически вылазит на кросс-платформенных приложениях. Так-же, подключение сторонних C/C++ библиотек на Паскале не так прозрачно как на C++. Совершенно отвратительно выглядят интерфейсы к C++ библиотекам, а некоторые части сильно завязанные на шаблоны вообще невозможно использовать. И о шаблонах - сам я в них не большой специалист, и иногда вообще не могу понять код изобилующий ключевым словом template... Но это уже моя проблема, т.к. все компилируется и работает .

Думаю, что C++ рано списывать со счетов, а скорость разработки и качество кода однозначно зависит от программистов и их непосредственного руководителя (который у нас тоже программист).

[Xenia]

Сугубо практический взгляд со стороны. Этим летом мы сдавали с подрядчиком контроллер техпроцесса (все x86+Linux, порядка 10 отдельных контроллеров). Наши ребята писали все на чистом C++ с Qt (лицензия на последний принадлежит заказчику) - это 7 контроллеров. Подрядчик писал на Java (остальные контроллеры). До выезда на объект было написано множество тестэ-кейсов, вопросы взаимодействия были более или менее отлажены.

В тех случаях, когда на контроллере операционка стоит, то это уже "взрослый" контроллер, которому C++ не будет в тягость. А уж про Qt и вопрос не стоит - без C++ там никак нельзя. Да и вообще, если есть 1 МБ памяти, то отказываться от C++ просто глупо.

Я же избегаю (как выразилась ранеее) С++ на МК гарвардской архитектуры с объемом flash до 128 КБ (AVR почти все такие). В последнем случае "повторяемость" не достигает такого уровня, на котором деление классы и объекты давало бы ощутимую выгоду. В самом деле, нужно ли заводить класс, если его будет использовать только один единственный объект?

Но и в тех же случаях, когда "повторяемость" имеет место, организовать универсальный класс бывает слишком сложно. Скажем у МК есть 6 штук UART'ов (на разных портах), обмен с которыми организован одинаково. Казалось бы, такой обмен можно описать в виде класса, а затем на его основе создать объекты для каждого порта. Но не тут-то было! Процедуры прерывания у каждого порта свои, и далеко не очевидно, как сделать так, чтобы объект для данного порта вписался в нужные адреса. И это на фоне того, что начинающие вообще не могут организовать процедуру прерывания, как функцию члена класса.

В том же случае, когда препоны такого рода все-таки удалось успешно преодолеть, оказывается, что время было потрачено на борьбу с языком C++, чтобы уломать его сделать очевидные вещи через ухо.

[juvf]

Скажем у МК есть 6 штук UART'ов (на разных портах), обмен с которыми организован одинаково. Казалось бы, такой обмен можно описать в виде класса, а затем на его основе создать объекты для каждого порта. Но не тут-то было! Процедуры прерывания у каждого порта свои, и далеко не очевидно, как сделать так, чтобы объект для данного порта вписался в нужные адреса. И это на фоне того, что начинающие вообще не могут организовать процедуру прерывания, как функцию члена класса.

Именно так и делаю. Процедуру прерывания не обязательно делать членом класса. Более того, была плата с разными интерфейсами (UART, CAN, SPI....), это не помешало сделать классы/объекты.

Если возникает проблема, которую среди всего форума решили только два человека, то этот факт уже настораживает. Настораживает тем, что некое средство требует для своего использования определенных сверхспособностей, отсутствующих у большинства.

это вообще не проблема, и не нужно ни каких сверхспособностей.

Если 5-ый этаж проблема, чем 1-ый не устраивает? Если есть причины не использовать классы и шаблоны, почему нужно переходить на СИ? Чем с++ без ООП не устраивает?