caxapa.ru :: Какие преимущества имеет применение C++ перед C99 в области embedded-программирования? Для проектов размера ~40тыс. строк. Т.е. например, более явное деление на функциональные модули с более чётко выраженными интерфейсами. Меньшее количество

fk0^{легенда} (02.08.2012 14:51, просмотров: 47750) MBedder

Какие преимущества имеет применение C++ перед C99 в области embedded-программирования? Для проектов размера ~40тыс. строк. Т.е. например, более явное деление на функциональные модули с более чётко выраженными интерфейсами. Меньшее количество ошибок при операциях с указателями (и арифметика, и cast). Готовые контейнеры и надёжные/отлаженные алгоритмы работы с ними (из STL). Более читаемый код (syntactic sugar). Более строгая типизация -- меньше ошибок. Автоматическая (нельзя забыть) инициализация (вызов конструкторов) и деструкторов. Что-то ещё? Недостатки: больший объём кода (~20% как пишут, особенно исключения и RTTI), больший объём ОЗУ (связано в основном со сменой стиля программирования). Существенно большая нагрузка на динамически выделяемую память (при использовании STL, например). Bloatware при безумном использовании шаблонов. Можно ли вообще скорость разработки ПО разменять на ресурс CPU (мегагерцы и килобайты)? При использовании других, более высокоуровневых ЯВУ и на ПК очень даже можно. А в embedded?

[ZX]

Ответить

- Хочу вопрос автору топика задать. На ваш взгляд, имеет ли смысл использование нескольких задач и средств межзадачного взаимодействия при грамотном использовании С++? - VVB(06.08.2012 07:49)
  - Не зависит от языка. Имеет, на мой взгляд, но только разделение на небольшое число относительно независимых задач. Или когда действительно нужно вытеснение. То же что делают во многих современных RTOS (по отдельной задаче на каждый мигающий fk0(709 знак., 06.08.2012 10:42)
    - WaitForMultipleEvents есть в CTL. единственный недостаток всех этих таск-шедулеров - это расход стека. всё остальное перечисленное (сложные механизмы синхронизации, ошибки в них) - бред. я уже настолько привык к многозадачке, что не представляю Mahagam(35 знак., 06.08.2012 11:54)
      - Если взять не CTL, а FreeRTOS, например. Как сделать WaitForMultiple... ? Или, иными словами говоря, как обеспечить реакцию на _множество_ событий в пределах одной "задачи"? - fk0(06.08.2012 11:59)
        
        править саму фриртос. но IMHO, место фриртосины - в мусорке. от неё только одна польза, она портирована на всё что исполняет код. и этим не грех попользоваться. - Mahagam(06.08.2012 12:55)
        
        В TNKernel глянте реализацию event - AVF(06.08.2012 12:21)
    - C++ применительно к RTOS смущает вопрос компоновки. - да нормально стыкуются, если про extern "C" не забывать. - =AlexD=(06.08.2012 11:25)
- Преимущества как всегда. Ты будешь писать на си то что можно написать на шелле? Дальше начинаются ограничения. Если не брать предельных задач как линукс кернел то скорость разработки важнее. Производительность железа растёт ещё быстрее. - ЯВУ(04.08.2012 01:42, )
- Одно из важнейших преимуществ Си++ состоит в том, что он не засирает глобальное пространство имён так сильно как Си. - =AlexD=(03.08.2012 13:15)
  - Засирание глобального пространства имен на С предотвращается волшебным словом static и структурным подходом. Может, лень-матушка мешает? ;) - Vladimir Ljaschko(03.08.2012 15:08)
    - дефайнам, которые заменяют константы в Сях похер на статик, кроме того есть мнение, что одинаковые статик имена в разных модулях - мина замедленного действия - =AlexD=(03.08.2012 20:33 - 20:36)
      - ??? #undef решает все проблемы и делает дифайн ручным и ласковым. Гадит только в свой лоток. - Юра(04.08.2012 13:10, )
        
        Насколько я помню, MISRA запрещает #undef, значит есть там что-то, люди думали. - Vladimir Ljaschko(04.08.2012 15:11)
        
        MISRA не есть истина в последней инстанции. Пробовал соблюдать - обплевался. Нуевонафик. - SciFi(04.08.2012 17:44)
        
        Неправда, никакого запрета нет. Насколько я помню,, обязательносте требование (О) - макросы не должны определяться (#define) или уничтожаться (#undef) только внутри блока. Остальное - опции. - Юра(04.08.2012 17:05, )
        
        Увы, следующим пунктом в версии 2004 идет "17.6 #undef shall not be used - Required". - Vladimir Ljaschko(04.08.2012 17:31 - 17:35)
        
        Вот она, наша MISRA. Юра(52 знак., 04.08.2012 17:53, )
        
        -> - =AlexD=(04.08.2012 14:46, ссылка)
        
        --> Юра(28 знак., 04.08.2012 14:55, )
      - Ну по хорошему внутренние дефайны библиотек не должны попадать в хедеры для подключения библиотеки. Что касается второго, то в чем мина? Компилятор/ линкер глюкнет? Или программист ? - Vladimir Ljaschko(04.08.2012 04:46)
        
        лана, нет проблемы, так нет проблемы, мне нахрен не нужно кого-то переубеждать - =AlexD=(04.08.2012 07:44)
        
        Вот тока спокока:) Поздняк в отказ идти - колись, чего бояцца! - Vladimir Ljaschko(04.08.2012 07:58)
        
        Присоединяюсь к вопросу. Тоже хотел узнать про мину, забылось как то в процессе чтения топика... - Dir(04.08.2012 11:10 - 11:15)
        
        Да ничего сверхестественного, окромя того, что статик - это гвоздями прибитый код в единице компиляции (файле) и как только появится желание распилить модуль на файлы, так сразу ваш статик идёт в жопу. Со всеми последствиями. - =AlexD=(04.08.2012 12:31)
        
        А... Ну это не страшно. Статик можно и в подпрограмме назначить. Я уж забеспокоился о реальных минах :) - Dir(04.08.2012 12:38)
        
        И не надо рассказывать как это обойти, я сам знаю несколько способов. Всё правильно, вы все умные. - =AlexD=(04.08.2012 12:37)
    - +1. Нехватка имён - признак того, что пора что-то менять в консерватории. - SciFi(03.08.2012 15:16)
      - При подключении библиотечного хедера периферии VisualDSP у меня сломалась большая отлаженая либа из-за пересечений их дефайнов с моими константами. Предлагаете что-то править в консерватории AD? В хедерах и либах современных процев овер 100500 =AlexD=(97 знак., 03.08.2012 20:18)
        
        Если говнолиба содержит 100500 имён без нормальных префиксов, то можно только посочувствовать. Пейсатели такого говнокода должны были озаботиться данной проблемой. Или нет? - SciFi(03.08.2012 22:48)
        
        Префикс -- это такая уродливая форма имитации namespaces. - fk0(04.08.2012 12:10)
        
        Угу.. особенно, если все в конторе пишут префиксы к каждой(!) функции и к каждой(!) переменной в виде: IvanovIvanIvanichIsOtdelaRasrabotkiStekaProtocolovTcpIp..MySocket().. :) - quark(04.08.2012 12:29 - 12:36)
        
        да-да, пэшыте пысьма - =AlexD=(04.08.2012 07:34, ссылка)
        
        В сторонней либе править в консерватории, конечно, не стоит. А вот свою приспособить всяческими #ifdef и т.п. не так и сложно. Dir(137 знак., 03.08.2012 21:15)
        
        Препроцессором очень многое можно приспособить, только скользкий и не самый правильный путь. Должно решатся средствами языка. Увы, С в этом плане архаичен. sbb(81 знак., 05.08.2012 01:01)
  - +1. И еще передача по ссылке, только из-за этого и прочих приятных мелочей, склоняюсь к использованию С++ даже в небольших embedded проектах. sbb(1097 знак., 03.08.2012 14:46)
- ИМХО в embedded нет потребности в ООП - не нужно создавать много сущностей в одной программе. Даже динамического выделения памяти не нужно - хватает статических структур и функций работающих с ними. - zeleny(03.08.2012 10:57)
  - Просто вы тут о разном говорите. Вот у меня шеф, ежели чего, выеживается: "да я , писал на асскмблере для AVR...". При этом не понимая, что нормальную прогу на асме нужно снабжать комментариями через строчку, иначе кроме него , никто в этой херне _basile(707 знак., 03.08.2012 23:08)
    - Я вас умоляю. Говнокоду никакие каменты не помогут. А годный программер способен написать код, не нуждающийся в каментах, и на Си, и на Си++. - SciFi(03.08.2012 23:11)
      - каменты должны описывать не "что и как тут делается", а "накуа оно тут надо". без таких комментариев никакой самодокументированный код не поможет понять, что тут вот мы багофичу проца обходим, тут вот глюк сторонней железки, а тут вот этот битик Mahagam(54 знак., 04.08.2012 02:32)
        
        +1 ...Именно - "накуа оно тут надо" - и само такое не задокументируется - Apтём(04.08.2012 03:21)
      - Не могу с вами согласиться. Программу, в которой отсутствуют комментарии, можно просто выбросить, независимо от Bill(221 знак., 03.08.2012 23:25, ссылка)
        
        Смотрю исходники линукс... Его выбросить весь ? - 3m(04.08.2012 19:30)
        
        Вот я и раскрыл тебя, наглый тролль. И это программу выбросить? -> SciFi(152 знак., 04.08.2012 00:00, ссылка)
        
        Self-documenting? Какой программой лучше пользоваться чтобы доку получить? Что посоветуете? - Apтём(04.08.2012 00:31)
        
        Doxygen - zeleny(06.08.2012 12:32)
        
        Здесь (по ссылке)можно посмотреть. - Bill(06.08.2012 10:06, ссылка)
        
        Опыт и здравый смысл. Ищите у дистрибьютеров по месту прописки. - SciFi(04.08.2012 00:33)
        
        у дистрибьютеров? Оно не open source? B даже не freeware? - Apтём(04.08.2012 00:40)
  - А что ты будешь делать, если обнаружишь, что тебе нужны две идентичные статические структуры и идентичные до констант функции работы с ними? Копипастить? Макросы писать? В С++ вопрос элементарно решается шаблоном. - =AlexD=(03.08.2012 11:06 - 11:14)
    - а что memcpy/memmove уже запрещены ? - zeleny(03.08.2012 11:08)
      - При чём здесь инициализация? Перечитай вопрос. - =AlexD=(03.08.2012 11:14)
        
        Если все идентично - то хватит одной функции, принимающей указатель на структуру. Может я не врубился в вопрос - поясните в чем там проблема... - zeleny(03.08.2012 11:18)
        
        Ладно, пусть будет так. Если ты используешь указатель на структуру, то уже фактически врукопашную реализуешь класс. :-) =AlexD=(167 знак., 03.08.2012 11:26)
        
        "не всегда указатель на структуру допустимо с точки зрения быстродействия" - уже интересно :) С++ "позволяет" процессору при обращении к памяти не указывать адрес ? - Юрий_СВ(03.08.2012 12:38)
        
        Вы понимаете разницу между членами класса и статическими членами класса? - =AlexD=(03.08.2012 12:51 - 13:16)
        
        Сверху написано "статические структуры", а не "статические члены". Статические члены можно вынести из класса - с быстродействием будет, как минимум, не хуже. - Юрий_СВ(03.08.2012 13:23)
        
        И в чём же разница? И зачем выносить? - =AlexD=(03.08.2012 13:37)
        
        Разница такая : Юрий_СВ(275 знак., 03.08.2012 14:29)
        
        За деревьями не видишь леса, а ведь я спрашиваю не просто так, а в связи с твоим вопросом ->. Для функций-членов разница между статическими и нестатическими членами ровно на отсутствие указателя this. =AlexD=(423 знак., 03.08.2012 14:56, ссылка)
        
        Заинлайнить и все будет. Кстати, где гарантия, что компилятор С++ не работает через указатель. - Vladimir Ljaschko(03.08.2012 11:35)
        
        здрасьте... там все через указатели (this неявно задействован всюду), плюс дополнительный слой трансляции для виртуальных методов... - zeleny(03.08.2012 12:22)
        
        Кого заинлайнить? Православный тру Си не поддерживает инлайны ;-)) - =AlexD=(03.08.2012 11:51)
        
        Хотя должен сказать, что если брать конкретно С99, то с ним всё гораздо легче. Но многие ли компиляторы поддерживают его в полном объёме? - =AlexD=(03.08.2012 11:55)
        
        Ксенин компилятор поддерживает, а лучшего нам и не надо :) - Vladimir Ljaschko(03.08.2012 11:58)
- Маленький вопрос: сядете ли вы в самолет, зная, Bill(58 знак., 03.08.2012 10:19)
- Embedded приложения сильно разные. VVB(694 знак., 03.08.2012 07:38 - 07:49)
  - "ЯВУ созданы для облегчения жизни программистов" - вас неверное информировали -> SciFi(341 знак., 03.08.2012 10:11, ссылка)
    - Блин, перевод какой-то дебильный оказался (с фактическими ошибками). Лучше читать на языке оригинала -> - SciFi(03.08.2012 14:55, ссылка)
      - Отец, да ведь там английский надо знать, а еще и думать. Проще пургу нести на форуме. - blackbit(04.08.2012 22:50)
    - Даже и не знаю что думать. Похоже на стёб, но как-то всё слишком серьёзно. - VVB(03.08.2012 10:59)
      - Дык это старая шутка. Только вот звучит ну очень правдоподобно :-) - SciFi(03.08.2012 10:59)
        
        Есть (была) еще подобная шутка для чего разрабатывался язык С. Мол сделали все не так, как надо, чтобы диверсию против СССР устроить (подобную ЕС ЭВМ). Вот только не могу отыскать в Интернете текст. - Dir(03.08.2012 11:47)
        
        Во-во! Только не нужно мне лишнего приписывать. Типа у психиатра провериться. У меня стойкое убеждение, что есть более совершенные языки программирования. - mazur(04.08.2012 17:08)
        
        Это из разряда 'не читал, но осуждаю'. Не интересно. - SciFi(04.08.2012 17:51)
    - "сейчас большинство людей уже уяснили для себя, что C++ - это пустая трата времени"! Я в большинстве :) - Vladimir Ljaschko(03.08.2012 10:38)
  - Мне показалось, что Вы несколько смешиваете RTOS и язык. Это разные сущности. С++ никак нельзя противопоставить RTOS. Сложный проект на любом языке без OS - нечто странное. - Evgeny_CD(03.08.2012 08:54)
    - Вот изучу С++, тогда и поспорим. На сегодня моё ощущение, что Вы идеалист. - VVB(03.08.2012 10:57)
- кое-что обсуждалось уже 2 года назад -> - Snaky(03.08.2012 07:38, ссылка)
  - Все правильно. Зачем снова это обсуждать? Все равно Bill(42 знак., 03.08.2012 08:44)
    - смотря какая цель обсуждения - если кого-то переубедить, то может смысла и правда нет (тут всей толпой одного мазура с асма на си не можем перетянуть). а если чтобы узнать другие точки зрения чтобы посмотреть на вопрос под новым углом, пошатать Snaky(72 знак., 03.08.2012 08:53 - 08:57)
      - Ну, разве что так. Только, опять же, я думаю, что Bill(146 знак., 03.08.2012 09:01)
        
        самому себе не всегда просто в силу субъективности мышления -> - Snaky(03.08.2012 09:05, ссылка)
        
        Ну, да. Когда человек прочитал одну единственную книгу или Bill(204 знак., 03.08.2012 09:14)
    - Ассемблер против С уже не обсуждается, нужно же чем-то заняться :) - Vladimir Ljaschko(03.08.2012 08:48)
      - А вообще, все эти "войны" бесконечны. Всегда находится кто-то новый, на которого снисходит откровение, и Bill(26 знак., 03.08.2012 09:07)
- Важно еще то, как именно Вы хотите использовать ++. Evgeny_CD(742 знак., 03.08.2012 00:40)
- Никаких не имеет. Вообще вопрос непонятен. Проект можно писать модулями на разных языках. HAL на C или даже ASM, более высокие уровни на C++. Тут более важен тот факт, что для написания HAL нужно уметь работать с документацией и rezident(53 знак., 02.08.2012 19:24)
  - На PC можно. На ARM (STM32, например) выбор ЯВУ не велик как-то... не? HAL занимает менее 10% от всего остального, остальное чистое программирование без железа. Разве что ОС нет, файловой системы и т.п. - fk0(02.08.2012 20:25)
    - А вот в курятниках HAL (Hot Air Leveling?) занимает до 70% программы. Но я все равно хочу перейти на C++, так как там порядка больше. - Лeoнид Ивaнoвич(02.08.2012 23:36)
      - Порядок он в головах.Оттуда перетекает в документацию.А на чем писать зависит от задачи. - PlainUser(03.08.2012 07:16)
      - HAL=Hardware abstraction layer. Hot Air Leveling - это кто? - Apтём(03.08.2012 00:25)
        
        Печатные платы никогда не заказывали? - SciFi(03.08.2012 00:28, ссылка)
        
        HAL - прошлый век :> в век SMD - моветон :> - Snaky(03.08.2012 04:15)
        
        Для ручной пайки - самое то. - Лeoнид Ивaнoвич(03.08.2012 09:31)
        
        ручная и на золоте хорошо идет если оно не лежало долго на открытом воздухе, а вот выравнивать TQFP100 на плате с HAL это мучение - Snaky(03.08.2012 09:37)
        
        А разве золото не дороже? - Лeoнид Ивaнoвич(03.08.2012 13:42)
        
        дороже, но не сильно. HAL опаснее и сложнее для производителя плат и от него отхотят потихоньку. - Snaky(03.08.2012 14:04)
      - при этом м8 может стать тесновата - koyodza(02.08.2012 23:42)
        
        Я про STM32. - Лeoнид Ивaнoвич(03.08.2012 09:30)
        
        "не верю" ;=) - koyodza(03.08.2012 10:53)
        
        Пока это только мечта, а в мечту верить надо. - Лeoнид Ивaнoвич(03.08.2012 13:41)
        
        ну хоть так, уже хорошо - koyodza(03.08.2012 15:35)
        
        Не теснее чем для Си. - =AlexD=(03.08.2012 07:01)
        
        Если не тянуть туда STL, RTTI и прочее, то с чего тесновата станет? - Apтём(03.08.2012 00:21)
    - Чистое программирование без железа как раз можно на PC писать/отлаживать. У меня был такой опыт. Я скидывал с устройства экспериментальные данные и передавал их коллеге, а он на ПК алгоритм обработки на базе этих данных отлаживал. После rezident(84 знак., 02.08.2012 20:34)
      - Обычно это называют "синтетический порт" - Evgeny_CD(02.08.2012 22:55)
  - HAL на С++ пишется и юзается гораздо проще, элегантнее и удобнее. - =AlexD=(02.08.2012 19:47)
    - Я не против, хоть на BASIC :) В любом случае для написания HAL нужно знание "железа". Этот тот уровень, который "платформеннозависим". "Старые наработки" для другого железа, которыми, например, Mahagam недавно бравировал, тут слабо помогут. - rezident(02.08.2012 20:29 - 20:36)
      - Охоспидя, умение прочитать названия регистров и назначения битов делают кого-то неимоверно крутым ембеддером? Я тя умоляю. - =AlexD=(03.08.2012 06:58)
        
        Умение в нужное время выставить нужный бит делают крутым.Круче ничего нет. - PlainUser(03.08.2012 07:19)
      - я под наработками понимал что-то не сильно зависимое от платформы. то, что легко и быстро можно портировать дальше. а так начало любого проекта на новой железке - колупание с даташитом, вылизывание железного кода, и потом уже льётся бизнес-логика. - Mahagam(03.08.2012 00:21)
  - когда речь идёт о 40 тыс. строк взаимодействие с оборудованием составляет не более 10%, иначе это просто говнокод - koyodza(02.08.2012 19:31)
    - Да хоть 1%. Если HAL не работает как надо, то всё устройство глючит и виснет. - rezident(02.08.2012 19:38)
      - само собой, но как уже отметили выше, проект может быть неоднородным, и эта часть может быть выполнена хоть на ассемблере, если в том есть необходимость, но это будет 1% от всего проекта - koyodza(02.08.2012 20:14)
- для 40к строк, имхо, можно и не заморачиваться с С++. но есть хорошие программеры, которым проще на С++ писать. опять же RTTI, динамик касты и пр. эксепшены могут жрать и память и иногда производительность. STL ну тут как говорится - либо шашечки, ыыыы(365 знак., 02.08.2012 16:01, )
  - чтоб не расплываться мыслею - мое мнение по таким вопросам всегда одинаковое: зависит от хуманских ресорсов. если команда умеет писать на С++ - то пусть пишет. на С у них получится хуже. ну и личное, холиварное мнение - из двух одинаковых команд, ыыыы(186 знак., 02.08.2012 16:09, )
    - если студенты сразу начинают на С++ то обычно на нем они и заканчивают, а вопрос "какое напряжение на ножке" такого программера приводит в полный ступор - koyodza(02.08.2012 16:17)
      - Тут вы не правы. Нынешние студенты (даже младших курсов) просто удивительно хорошо подкованы в С++. Шаблоны, STL... короче полный комплект инструментов С++. Речь, конечно, не о двоечниках. Dir(179 знак., 02.08.2012 17:41)
        
        я не говорю, что студенты не шарят в С++, я говорю что обученные изначально на С++ в основной массе не шарят в микроконтроллерах в частности и электронике в целом koyodza(194 знак., 02.08.2012 17:51)
        
        И это совершенно логично - "взрослый" программист получает намного больше. - Vladimir Ljaschko(02.08.2012 17:55)
        
        что понимается под словом "взрослый"? - koyodza(02.08.2012 18:03)
        
        С точки зрения программиста -- не марающийся об эти ваши микроконтроллеры. С точки зрения работодателя -- мальчик до 27, с мамой, папой и квартиркой... - fk0(02.08.2012 18:56)
      - Что-то Вы не стой ноги встали. Причинно-следственная связь нарушена. Говнокодерство и говноэмбеддерство инвариантны к языкам и платформам. - Evgeny_CD(02.08.2012 16:36)
        
        а вот нифига, связь есть. Речь не о применении языков или платформ в принципе, а в порядке обучения. Исключения бывают, но они только подтверждают правило - koyodza(02.08.2012 16:50 - 16:52)
        
        А где было сказано, что надо брать первокурсников и сразу заставлять их изучать boost? - Evgeny_CD(02.08.2012 16:54)
        
        К большому сожалению boost к микроконтроллерам практически не применим :-((( - =AlexD=(02.08.2012 19:33)
        
        ну почему же :) Вот это -> тоже микроконтролер :) - Evgeny_CD(02.08.2012 22:53, ссылка)
        
        Проблема не в крутизне процессора, а в том, что значительная часть буста завязана на ОСи и их либы, и прикручивание и портирование на специфичный компилятор становится отдельной работой эпического масштаба. К примеру BuilderC++ в состоянии собрать =AlexD=(332 знак., 03.08.2012 07:09)
        
        Тут я умолкаю в силу отсутствия знаний. Замечу лишь, что по boost удивительно мало книг, и еще реже они встречаются среди warez-книг. - Evgeny_CD(03.08.2012 09:03)
        
        там - koyodza(02.08.2012 16:58, ссылка)
    - Ключевое слово - "в пределе". Пока предела ждать будешь, или осёл сдохнет, или падишах. - SciFi(02.08.2012 16:14)
- C# есть и для MicroFramework. Так что можно и в embedded. Вообще список вопросов сильно неполон. Evgeny_CD(556 знак., 02.08.2012 15:05)
  - Целевая платформа single chip (почти) и уж точно без параллельных шин. Т.е. до мегабайта FLASH, например, и от силы пара сотен КБайт SRAM. Ещё serial FLASH порядка 8МБайт. Критерий оптимизации -- уменьшение времени разработки ПО. 40к кода уже есть fk0(419 знак., 02.08.2012 15:42)

Средства и методы разработки