[adnega 11]

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

При этом время работы будет не const.

[svss 0]

А что, C-и жестко риалтаймный?

Как C-и так и Java нужно приучать к риалтайму. Делать профайлинги, проектировать HAL и проч.

 

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

 

Две копейки в тему:

на многоядерной машине актуальность рассуждения о реальном времени исчезает насовсем.

Да, сделать без системной (и языковой) поддержки непросто.

Однако тренд - туда: делать много ядер хороших и разных. Одни тянут операц. систему и файловую систему, другие - коммуникации и безопасность, а оставшиеся - задачи реального времени, изложенные на любом языке.

[DASM 0]

А мне все равно неясна желательность С++ в приложениях малого среднего размера. Нужна инкапсуляция ? static в С никто не отменял (не тот, что модификатор хранения, а тот, что спецификатор области видимости). Виртуальные ф-ции и наследование - нет проблем http://habrahabr.ru/post/138684/

Ну да, операторы не перегрузишь, - но имхо польза этого сомнительна, в Яве это вообще убрали. Ну, а главное, красивые программы для эмбеддед - лично мне доводилось видеть только на С. На С++ 90 % используют 10 % особенностей языка, а так - в основном фишки вроде "объявляю переменную где хочу, более продвинутые promotion rules, ну и подобные , малозначимые вещи. Что-то серьезное, с полиморфной обработкой данных, общепринятыми паттернами, использованием STL итп в МИКРОконтроллерах - ну не видел. Ну не спорю, может мало видел. Зато качественного С кода - много. Статистика однако, пусть и личная. А обработку исключений в MCU много кто использует ? Не все даже знакомы с try - catch , а вы ++ говорите.

 

Две копейки в тему:

на многоядерной машине актуальность рассуждения о реальном времени исчезает насовсем.

Да, сделать без системной (и языковой) поддержки непросто.

Однако тренд - туда: делать много ядер хороших и разных. Одни тянут операц. систему и файловую систему, другие - коммуникации и безопасность, а оставшиеся - задачи реального времени, изложенные на любом языке.

Вообще не вижу связи.

 

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

При этом время работы будет не const.

А гда вы вообще реализации с кучей видели (в смысле с дин. выделением памяти в ней) ? Вот рекурсивные они обычно, это да..

[AlexMad 0]

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

Простите за оффтоп, а почему все еще говорят на древних языках? Врачи латынь почему-то не отвергают. Может это потому, что язык самодостаточен для задачи?

Мое мнение, что чистый Си проживет еще очень долго.

[DASM 0]

О чем и речь.

[AlexandrY 3]

Что-то серьезное, с полиморфной обработкой данных, общепринятыми паттернами, использованием STL итп в МИКРОконтроллерах - ну не видел

 

Вот прямо сейчас у меня в проекте на Kinetis MK70 используется Flash File System на NAND с выравниванием износа и прочими фичами.

Вся написана на C++. Там по полной используются классы, всякие виртуальные методы, итераторы, переопределения операторов, STL и проч.

До этого как то портировал Windows CE на iMX, там тоже файловые системы только на C++ были.

А все это довольно слабые uКонтроллеры.

 

Эт так для сведения.

 

Терпеть не могу когда в одном проекте мешаются несколько языков.

[DASM 0]

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

[adnega 11]

А гда вы вообще реализации с кучей видели (в смысле с дин. выделением памяти в ней) ? Вот рекурсивные они обычно, это да..

Тут меня прошу простить - ибо я не компитент.

Есть мнение

Все stdio функции из NewLib используют хитрую буферизацию и динамически распределяют память для своих внутренних нужд. А значит им нужна куча и не маленькая

Сейчас на форуме ведется много споров, о том как делать исходники лучше в плане совместимости и соответствию стандарту.

Мне казалось, что newlib для МК будет самым совместимым и стандартным решением.

Конечно же реализации printf для вывода строк и целых чисел не обязана быть сложной и требовать много ресурсов - этим и объясняется большое количество безкучевых решений.

 

Но на самом деле я ничего не утверждал, а лишь предположил ответ на #27

А что, C-и жестко риалтаймный? Особенно его функции printf, scanf и т.д.?

[svss 0]

А мне все равно неясна желательность С++ в приложениях малого среднего размера

Опустим малый размер из рассуждения.

В прочих случаях красота=надёжность кода экономят время. Не железякино время, а время от нашей жизни.

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

[AlexandrY 3]

Но на самом деле я ничего не утверждал, а лишь предположил ответ на #27

 

printf обладает некой детерминированностью только на простейших реализациях от Microchip-а.

А, например, в RealView от ARM совсем другая песня.

 

А вообще имелся в виду и heap который printf использует, и то что он выходит на потоки STD IN/OUT/ERR которые платформенно зависимые, и то что время выполнения может быть детерминировано но все равно не известно и нужен по любому профайлинг. А также то, что время выполнения зависит от аргументов.

Ну короче, printf никак не риалтайм функция.

 

 

В прочих случаях красота=надёжность кода экономят время. Не железякино время, а время от нашей жизни.

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

 

Время экономят хорошая память и наработанные рефлексы.

Красота тратит наше время, ибо оно тратится на созерцание.

[dxp 65]

Давно уже не вступаю в дискуссии по поводу языков программирования, т.к. тема неблагодарная и флеймоопасная. Но всё же внесу свой пятачок.

 

А мне все равно неясна желательность С++ в приложениях малого среднего размера.

Где утверждается желательность? На чём нравится, на том и пишите. Язык во много определяет процесс мышления и комфортно думать на том языке, который ближе/нравится. Если вам удобнее думать в пространстве средств языка С, ради бога; мне удобнее думать в пространстве средств языка С++ (в одном и том же контексте, естественно).

 

Нужна инкапсуляция ? static в С никто не отменял (не тот, что модификатор хранения, а тот, что спецификатор области видимости).

Вы сами-то пробовали такую "инкапсуляцию"? Я пробовал (ещё во времена, когда с плюсами на embedded было скудно). Фигня это, а не инкапсуляция. К тому же, и даже важнее, имхо, не столько инкапсуляция, сколько абстракция, которая позволяет уйти на более высокий уровень при проектировании.

 

Виртуальные ф-ции и наследование - нет проблем http://habrahabr.ru/post/138684/

Да всё можно, даже на асме люди писали объектно-ориентированные программы. Но зачем этот "закат солнца вручную", если есть штатное средство, которое применять только религия не позволяет (или отсутствие соответствующих скиллов)?

 

Ну да, операторы не перегрузишь, - но имхо польза этого сомнительна, в Яве это вообще убрали. Ну, а главное, красивые программы для эмбеддед - лично мне доводилось видеть только на С. На С++ 90 % используют 10 % особенностей языка, а так - в основном фишки вроде "объявляю переменную где хочу, более продвинутые promotion rules, ну и подобные , малозначимые вещи. Что-то серьезное, с полиморфной обработкой данных, общепринятыми паттернами, использованием STL итп в МИКРОконтроллерах - ну не видел. Ну не спорю, может мало видел. Зато качественного С кода - много. Статистика однако, пусть и личная.

Статистику нужно наводить относительную - какой процент программ, а по абсолютным значениям судить бессмысленно, ясно, что на С программ на порядок-два больше, как и программистов. И уж красота программы на С - это само по себе достаточно странное - какая там может быть глубокая красота программы, написанной на портабельном макроассемблере, которым по сути является С, поддерживающим одну-единственную парадигму программирования - процедурную. Вот вся эта красота процедурная и есть. Уровень описания очень низкий, никуда особо не разбежишься. Да, код получается эффективный (компактный, быстрый), но это благодаря близости к железу. Вот и вся красота. К слову, на С++ при должном умении код получается не уступающим по эффективности С (а кое-где и превосходящим), только вот умение оное приобрести не так просто. Что касается красоты, так и тут пространства больше. На этом форуме neiver приводил собственную либу управления пинами AVR, основанную на списках типов (добро пожаловать к тов. Александреску :)). Вот это действительно красота (для тех, кто понимает), хотя практическое применение именно в этом контексте лично для меня сомнительно.

 

А обработку исключений в MCU много кто использует ? Не все даже знакомы с try - catch , а вы ++ говорите.

Использование механизма исключений на малых процах, работающих в реальном времени, указывает на неадекватность понимания средств языка С++, их возможностей и целевых потребностей. Это скорее пример того, как не надо использовать плюсы в ембеддед.

[juvf 17]

А мне все равно неясна желательность С++ в приложениях малого среднего размера.

А мне не ясно нежелание писать на с++ в приложениях малого среднего размера...... Хотя наверно ясна... это консервативность... т.е. если прогер в си как рыба в воде, а в с++ его в ступор вводит символы ::, то конечно ТОЛЬКО СИ. Но если ты знаешь с++ или ты не знаешь ни си, ни с++, то однозначно учи и пользуй с++. Пример: маленькая программа, холоворд на с++

int main()
{
printf("hello world!");
}

Чем не нравится эта с++ программа? Чем она хужа аналога на си? Ничем! Если кто-то нелюбит ООП в с++ для эмбэддэд, считает что не нужны try - catch в эмбэддэд, а STL на аттини - это оверинженеринг - не пользуйте эти плюшки. Пишите весь код в си стиле но на с++. Зачем нужен си? Несегодя-завтра у вас в эмбеддэд будет linux или windowsXP, и этот эмбэддед будет мало чем отличатся от настольного ПК, и вам потребуется try/catch - пожалуста, пользуйте. Будет эмбэддед на ATtiny с компилятом с++, в котором даже не реализованы new и delete - пишите всё на томже с++. Зачем учить новый язык? везде нужно использовать с++.

 

Конечно при написании рпограммы на с++ нужно адекватно оценивать возможности эмбэдэда и потребность в тех или иных плюшка. Там где достаточно массива интов, не нужно использовать std::list<MyClass>, где MyClass содержит в привате инт, и в паблике кучу методов для чтения/модификации этого инта.

[AlexandrY 3]

А мне не ясно нежелание писать на с++ в приложениях малого среднего размера...... Хотя наверно ясна... это консервативность...

 

Почитаете первые же ссылки по психологии программистов и поймете свои заблуждения.

Например "Психбольница в руках пациентов" Алана Купера. (глава 7)

 

Вылечится можно только если взяться за веь проект разработки встраиваемой системы.

От идеи до конструкции, от схемы и разводки платы, до разработки чертежа корпуса, маркетингового продвижения и тех. поддержки.

 

Вот тогда поймете чего действительно стоят 'плюшки' на C++.

[ASN 0]

juvf

IMHO, ответ на вопрос "Почему до сих пор "сидят" на С/С++? " очень прост.

Потому, что в embedded большинство задач (и следовательно программистов) решают достаточно тривиальные задачи.

Для таких задач язык С прост и понятен. А также удобен и достаточен.

При переходе к более сложным задача используют С++. Это даже не язык - это целая вселенная! Средств языка хватает чтобы работать и на низком уровне аппаратных регистров и на уровне очень мощных абстракций ООП.

Мощь С++ заключается именно в его демократичности: изучить и практически использовать его можно буквально за 1 день. Другое дело, что года за три можно освоить его в той мере, что начинаешь понимать его красоту и изящество. Его реальную мощь. (Это пример из жизни когда в одном проекте работали и простые кодеры и ПРОГРАММИСТЫ. И все на С++).

Только в embedded-задачах мощи то и особенно развернутся и негде.

К моему глубокому сожалению, большинство тех, кто использует С++ (по моему опыту) слабо понимают силу инструмента, который они используют.

Поэтому и плодятся всякие Java, C# и прочие "серебряные пули". Эдакие "эрзац С++" для ленивых.

Только в реальной жизни чудес не бывает - за всё надо платить: памятью, быстродействием, энергопотреблением.

Пока цена ресурсов ниже цены труда программиста - это приемлемо. И оправдано.

 

[Xenia 45]

Среди программистов тоже есть свои созидатели и потребители :). И хотя, строго говоря, созидают и потребляют те и другие, но в количественном отношении разница между ними все же есть.

 

Проведу аналогию с архитектурой, чтобы стало яснее, что я имею в виду. Один человек (архитектор) точно знает, какой дом он хочет построить. Можно сказать, что план этого дома сложился у него в голове раньше, чем в чертежах. А потому его цель - не просто хороший дом, а именно тот, который полностью отвечает его идее. Еще ближе аналогия с художником, который желает нарисовать на холсте именно то и именно так, как он задумал, а не просто скопировать чужую картину. Вот это то, что я называю созидательным направлением.

 

Противоположное ему, потребительское направление, состоит в том, что человеку нужен удобный дом для проживания в нем или (пере)продажи. Здесь его интересует дом лишь в функциональном отношении, а к тому, как он построен, интереса не проявляет. Либо проявляет лишь в той плоскости, во сколько это ему обойдется. Здесь он стремится лишь минимизировать свои издержки на пути получения продукта, удовлетворяющего его пользовательские потребности или потребности заказчика. А по поводу того, как устроен этот продукт в мелочах желает знать как можно меньше, чтобы не утруждать себе "моск".

 

Так вот C/С++ это язык для тех, кто точно знает, как то или иное должно быть устроено (для "архитекторов"), и нуждаются в таком языке, который был бы способен выразить все нюансы идеи. В тех же случаях, когда язык этого в полной мере не позволяет, такой программист вынужден непроизводительно тратить свое время и силы на борьбу с языком, изобретая способы, как бы ему заставить язык сделать код именно таким, каким он его задумал, а не таким, каким он получается по умолчанию. Языки слишком высокого уровня такого программиста зачастую раздражают, т.к. он не хочет пользоваться кодом, который "написали индусы или финские студенты" :).

 

Напротив, программисты-потребители обычно избегают вникать в то, как работают те или иные функции, а уж тем более заниматься по этой части оптимизацией. Мол, занимает данная функция столько-то килобайт в памяти и требует столько-то времени на свое выполнение – то так тому и быть. В крайнем случае, они станут искать аналогичную функцию в библиотеках других производителей, но никогда даже не подумают о том, чтобы написать такую функцию самим. Свою работу такие программисты рассматривают в плоскости того, как "подружить" одни части чужого кода с другими, настолько же чужими. И даже по вопросам на форуме, таких за версту видно.

 

Понятно, что черезчур "процедурные" языки последних напрягают, поскольку требуют от них определенной детализации задачи. А данная категория программистов от детализации шарахается, т.к. сами они весьма смутно представляют себе, как их программа должна работать на нижнем уровне. Или даже более того – представляют себе только то, что им желательно получить в результате, но не то, как это надо делать. В этом смысле они похожи на ... строителей коммунизма :), которые в подробностях представляют, какая при этом коммунизме должна быть житуха, но совершенно не представляют, как его надо строить.

 

Вот для последних и создают языки типа Python :), которые предоставляют широкий спектр готовых функций в обмен на сокрытие всего того, что связано с их работой.