Совсем подробный — это TR18015 — 202 страницы с разбором эффективности (скорость, потребление RAM, ROM, скорость компиляции, затраты на разработку и поиск ошибок) C++. В том числе там идет сравнение с C. Дается разбор действий компилятора, необходимых для реализации той или иной фичи, а также даютя реальные замеры производительности 6ти разных компиляторов. Кроме того даются рекомендации по организации интерфейса к железу.
Меня же хватит только на несколько экранов текста.
#include из STL и написав объектный модуль с иерархией и наследованием объектов событий (был такой протокол), мы поимели увеличение прошивки ровно в два раза с 0,7 МБ до почти 1.4 МБ.
Поэтому я не призывал везде использовать STL. Там есть сложные объекты и есть совсем простые. Сложные безусловно надо мерять и хорошо думать, прежде чем использовать. Но такая элементарщина, как std::min, которая встречается довольно часто, точно не повредит.
Что за такая нелюбовь с Си, что прямо так и тянет потратиться там, где дорог каждый байтик.
Ну что вы, я люблю C. Но вместо структуры и двух функций init и destroy я предпочту класс. Это полный аналог и даст такой же ассемблерный код (это я проверял), зато компилятор сам расставит вызовы деструктора.
В C++ много вещей, которые стоят ровно столько же, сколько их аналоги на C, только предоставляют больше проверок корректности кода. А если я могу сделать что-то простыми способами на C, то с какой стати я буду делать это сложно на C++?
Полагаю, что всё это будет во первых безумно кушать и без того миниатюрной оперативной памяти
Вы думаете, а я мерял. И серьезные люди из ISO в 2006 году меряли и пришли к выводам, что причин C++ коду потреблять больше памяти или работать медленее, чем C код, нет. Исследование проводилось как раз на тему применимости C++ для встраиваемых систем.
Что позволяет достаточно легко дизассемблировать программу и посмотреть сбойный кусок, как такое обстоит с с++?
Точно также. Структуры C++ совершенно аналогичны структурам данных, которые пишут C программисты руками. При нормально знании языка я без труда понимаю, во что он превращается. Правила не сложные.
Я не имел в виду прямое использвоание IPMI, я понимаю, что это технология из другого мира. Я имел в виду саму идею. На марсоходе наверняка не один управляющий компьютер, а несколько, должно быть дублирование. Перепрошивают их наверняка не все сразу, а по одному.
Научить эти компьютеры перепрошивать друг друга — не большая добавка в коде и железе.
На серверах есть такая штука, как IPMI, особенно интересно работает в варианте от supermicro, когда через неет можно смотреть на экран сервера, работать с мышью и клавиатурой и вставлять в виртуальный DVD-rom образы дисков. Все это удаленно по сети и сервер видит все эти виртуальные йстройства как родные. В том числе можно заходить в BIOS и грузиться с виртуального диска.
Тут то же самое, всегда останется низкоуровневый компонент, позволяющий перенастроить программное обеспечение в случае любой программной ошибки.
Тогда он находится в неадекватном состоянии и его все равно не надо допускать до критически важной системы. Пусть успокоится и принимает решения на холодную голову.
Нет, так нельзя. Интерфейс у всех контейнеров одинаковый (вернее определено несколько концепций интерфейсов контейнеров) и это позволяет stl алгоритмам работать с любыми контейнерами. Удалив size вы нарушите эту концепцию.
> Никто и не будет читать, кроме тех, кто разрабатывал непосредственно сам велосипед. Ведь команда пишет велосипед только для себя.
Значит у вас незаменимая команда.
> Да, причём значительно быстрее в отдельных местах.
А можно какой-нибудь пример, когда алгоритм из stl работает значительно медленее рукописного аналога? За исключением случая, когда вместо циклического буфера используется deque.
Действительно, для atomic гарантируется, что все потоки увидят изменения в одной последовательности. Но в результате на ровном месте получаем дорогие операции.
Повышение опыта и скиллов — это хорошо. Но библиотеками тоже надо уметь пользоваться, причем пользоваться правильно и знать их тонкости. И это тоже надо практиковать.
Но надёжность… Обоснуйте, за счет чего ваш велосипед будет надежнее, чем вылизанный за годы код стандартной библиотеки. Которую, кстати, пишут одни из наиболее квалифицированных разработчиков. А другие высококвалифицированные разработчики перепроверяют перед использованием в важных проектах.
А вы уверены, что изменения size_ и is_size_true_ будут видны в том же порядке, что вы написали.
Компилятор имеет право кэшировать переменные на регистрах и записывать их в память в любом порядке. Если не ошибаюсь, в данном случае, компилятор имеет право переставить инструкции местами т.к. наблюдаемое поведение не изменится. Процессор может сохранить переменные в память в любом порядке (для x86 это возможно, если они попадут в разные кэшлайны). Процессор может переставить инструкции местами. Поэтому size() перестанет быть thread safe.
Ошибкой не было бы, так как внешне объект остается константным, семантика выдержана, но такой хак того не стоит. В том числе потому, что size() перестанет быть thread safe даже при условии вызова только константных методов.
Зато возникают куда более худшие проблемы:
Плохая или очень специфичная реализация. Чтобы сделать на уровне stl надо потрать очень много времени.
Большие временные затраты. Намного большие, чем прочитать документацию на stl.
Трудная поддержка. Чтобы поддерживать ваш код надо прочитать вашу документацию. А stl сторонний разработчик уже знает.
Проблемы взаимодействия со сторонними библиотеками. Им нужны стандартные контейнеры или хотя бы стандартные интерфейсы.
Меня же хватит только на несколько экранов текста.
Поэтому я не призывал везде использовать STL. Там есть сложные объекты и есть совсем простые. Сложные безусловно надо мерять и хорошо думать, прежде чем использовать. Но такая элементарщина, как std::min, которая встречается довольно часто, точно не повредит.
Ну что вы, я люблю C. Но вместо структуры и двух функций init и destroy я предпочту класс. Это полный аналог и даст такой же ассемблерный код (это я проверял), зато компилятор сам расставит вызовы деструктора.
В C++ много вещей, которые стоят ровно столько же, сколько их аналоги на C, только предоставляют больше проверок корректности кода. А если я могу сделать что-то простыми способами на C, то с какой стати я буду делать это сложно на C++?
Вы думаете, а я мерял. И серьезные люди из ISO в 2006 году меряли и пришли к выводам, что причин C++ коду потреблять больше памяти или работать медленее, чем C код, нет. Исследование проводилось как раз на тему применимости C++ для встраиваемых систем.
Точно также. Структуры C++ совершенно аналогичны структурам данных, которые пишут C программисты руками. При нормально знании языка я без труда понимаю, во что он превращается. Правила не сложные.
Использование чисто виртуальных методов — 20 байт флеша и 2 байта оперативки вне зависимости от количества. И то, если такие методы есть в программе.
Статические переменные с инициализацией в рантайме — их вообще лучше не использовать. Поэтому оверхэда нет.
placement new — это inline функции, которые будут убраны компилятором, оверхэда нет.
прочие new, delete — не мерял, но дадут оверхэд в десяток байт, если их использовать.
Так что я наоборот уложился в 20 байт флеша, а остальное оставил на полезные задачи.
В таком случае, если верить FAQ avrlibc дополнительный код не нужен: «Constructors and destructors are supported though, including global ones.»
Научить эти компьютеры перепрошивать друг друга — не большая добавка в коде и железе.
Тут то же самое, всегда останется низкоуровневый компонент, позволяющий перенастроить программное обеспечение в случае любой программной ошибки.
Значит у вас незаменимая команда.
> Да, причём значительно быстрее в отдельных местах.
А можно какой-нибудь пример, когда алгоритм из stl работает значительно медленее рукописного аналога? За исключением случая, когда вместо циклического буфера используется deque.
Но надёжность… Обоснуйте, за счет чего ваш велосипед будет надежнее, чем вылизанный за годы код стандартной библиотеки. Которую, кстати, пишут одни из наиболее квалифицированных разработчиков. А другие высококвалифицированные разработчики перепроверяют перед использованием в важных проектах.
Компилятор имеет право кэшировать переменные на регистрах и записывать их в память в любом порядке. Если не ошибаюсь, в данном случае, компилятор имеет право переставить инструкции местами т.к. наблюдаемое поведение не изменится. Процессор может сохранить переменные в память в любом порядке (для x86 это возможно, если они попадут в разные кэшлайны). Процессор может переставить инструкции местами. Поэтому size() перестанет быть thread safe.
Плохая или очень специфичная реализация. Чтобы сделать на уровне stl надо потрать очень много времени.
Большие временные затраты. Намного большие, чем прочитать документацию на stl.
Трудная поддержка. Чтобы поддерживать ваш код надо прочитать вашу документацию. А stl сторонний разработчик уже знает.
Проблемы взаимодействия со сторонними библиотеками. Им нужны стандартные контейнеры или хотя бы стандартные интерфейсы.