STL во встроенной среде

Question

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

Мой вопрос заключается в том, каковы причины этого популистского (по крайней мере, так выглядят многие из меня), который называет STL , а не для встроенной среды?

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

Редактировать: поэтому здесь я буду складывать баллы по мере поступления ответов:
1. Проблемы с переносимостью
2. справиться с огромным распределением dymanice контейнерами STL
3. STL трудно отлаживать
4. Глубокие вызовы функций в STL приводят к низкой производительности компиляторов, слабых с встраиванием (мощность функторов бесполезна!)

Answer 1

STL имеет довольно много проблем (как описано здесь EASTL ), во встроенной системе или в мелкомасштабной системе, основная проблема, как правило, заключается в том, как он управляет (своей) памятью,хорошим примером этого является PSP порт Aquaria .

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

Наконец, boost основывается на шаблонах, поэтому, если вы посмотрите на размер сгенерированного кода шаблона, он 'будет страдать так же, как и STL.

Редактирование / обновление:

Чтобы прояснить мое последнее утверждение (которое только что ссылалось на повышение VS STL).В C вы можете (ab) использовать один и тот же код для выполнения одной и той же работы в разных структурах, использующих один и тот же заголовок (или макет), но с шаблонами каждый тип может получить свою собственную копию (я никогда не проверял, если какие-либо компиляторыдостаточно умен, чтобы сделать это, если «оптимизация по размеру» увеличена), даже если он точно такой же (на уровне машины / сборки), как тот, который только что был сгенерирован.Преимущество boost заключается в том, что он намного чище и в него помещается гораздо больше вещей, но это может привести к длительному времени компиляции из-за большого количества (иногда огромных) заголовков.STL выигрывает, потому что вы можете передавать свой проект и не требовать загрузки / сопровождения надстройки.

Answer 2

Это зависит от того, что вы подразумеваете под встраиваемым. В системах Atmel8 очень мало оперативной памяти. Так мало, что у тебя не может быть разумного мальлока. В этом случае вы хотите очень явно управлять памятью, возможно, со статическими массивами нужного вам типа. Если у вас есть это, вам в основном не нужно большинство STL.

В системах вооружений у вас много баранов. Используйте STL!

Answer 3

Существует некоторая логика в том, что шаблоны приводят к большему коду.Основная идея довольно проста: каждый экземпляр шаблона создает по существу отдельный код.Это было особенно проблематично с ранними компиляторами - поскольку шаблоны (обычно) должны быть помещены в заголовки, все функции в шаблоне inline.Это означает, что если у вас есть (например) vector<int>, созданный в 10 различных файлах, у вас (теоретически) будет 10 отдельных копий каждой используемой вами функции-члена, по одной для каждого файла, в котором вы ее используете.

Любойсравнительно недавний компилятор (скажем, менее 10 лет) будет иметь некоторую логику в компоновщике, чтобы объединить их вместе, поэтому создание экземпляра vector<int> для 10 файлов приведет к тому, что только одна копия каждой функции-члена, которую вы использовали, попадет в финалисполняемый файл.Что бы там ни было, однако, как только стало «известно», что шаблоны производят раздутый код, многие люди больше не смотрели, чтобы узнать, остался ли он верным.

Еще один момент (который остается верным) заключается в том, чтоШаблоны могут облегчить создание довольно сложного кода.Если вы пишете что-то самостоятельно в C, у вас, как правило, есть сильная мотивация использовать самый простой алгоритм, набор и т. Д., Которые могут выполнить эту работу - достаточно мотивированную, чтобы вы могли проверить детали, например, максимальное число.предметов, с которыми вы можете столкнуться, чтобы увидеть, можете ли вы сойти с рук с чем-то действительно простым.Шаблон может сделать использование коллекции общего назначения настолько простым, что вам не придется проверять подобные вещи, поэтому (например) вы получите весь код для построения и поддержания сбалансированного дерева, даже если вы толькохранение, скажем, не более 10 элементов, поэтому простой массив с линейным поиском сэкономит память и, как правило, будет работать быстрее.

Answer 4

Я наткнулся на эту презентацию: Стандартный C ++ для программирования встраиваемых систем

основная сложность с шаблонами связана с компилятором, чем с системой времени выполнения, и именно в этом проблема- поскольку мы не знаем наверняка, какую часть оптимизации может выполнить компилятор.Фактически код C ++, основанный на STL, должен быть более компактным и быстрым, чем код C ++, не использующий шаблоны и даже код C!

Answer 5

Я был во встроенном проекте, который использовал C ++ и STL в очень ограниченной системе (память в долях мегабайта, ARMv4 на низкой скорости).По большей части STL был великолепен, но были части, которые нам пришлось пропустить (например, для std :: map требовалось 2-4k кода на экземпляр [что является большим числом по сравнению с размером нашего ПЗУ), и у нас былонаша собственная нестандартная замена для std :: bitset [это может быть ~ 1k ROM]).Но std :: vector и std :: list были очень полезны, так как использовали boost :: intrusive_ptr для подсчета ссылок (shared_ptr был слишком большим, около 40 байт оперативной памяти на объект!).

Единственный недостатокиспользование STL означает, что у вас нет исправления ошибок, когда исключения отключены (что они были для нас, поскольку исключения и RTTI были недешевы для нашего компилятора).Например, если выделение памяти где-то в коде в этой строке не удалось (std :: map object):

my_map[5] = 66;

, вы бы этого не увидели, а код просто молча продолжал бы двигаться вперед;Скорее всего, объект находится в поврежденном состоянии, но вы не потерпите крах намного позже.

При этом мы добились большого успеха с C ++ и STL.Как сказал другой автор, попробуйте на вашей системе и определите, какие части STL работают.В качестве примечания, есть хороший технический отчет о производительности C ++ в целом, который хорошо читается: http://www.open -std.org / jtc1 / sc22 / wg21 / docs / TR18015.pdf

Answer 6

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

Большинство руководств по системам, критичным для безопасности, просто запрещают использование динамического выделения памяти. Разработать программу гораздо проще и безопаснее, если вам не нужно беспокоиться о сбое вызова malloc / new. А для долго работающих систем, где может произойти фрагментация кучи, вы не можете легко доказать, что выделение памяти не даст сбой, даже на чипе / системе с большим объемом памяти (особенно, когда устройство должно работать годами без перезапуска).

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

То, что я сделал в более крупных проектах, - это изоляция функций реального времени и критических функций от остальных. Некритические вещи могут быть написаны с использованием стандартных инструментов, таких как STL. Это нормально, пока ОС не мешает критически важным частям. И если я не могу гарантировать, что таких взаимодействий нет, тогда вообще не пользуйтесь инструментами.

Answer 7

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

Answer 8

Зависит от характера встроенной системы.

Такая система может иметь несколько килобайт оперативной памяти (или меньше) или много мегабайт или даже гигабайт. Так что ограничения памяти могут быть или не быть проблемой.

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

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

Answer 9

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

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

Answer 10

У меня не было недостатков в использовании STL во встроенных системах, и я планирую использовать его в своем текущем проекте. Повысьте также.