Добрый день, %username%! Так уж получилось, что за годы разработки на дотнете мои познания C/C++ упали ниже плинтуса, что аж стыдно. И посему, хочется пообщаться с гуру гиками, которые умеют, знают и любят разрабатывать внутреннее по для микроконтроллеров. Т.е., хочется сделать тему для обсуждения и вопросов практики разработки, а точнее, как в просто народе, бест практиз И надеюсь, что на основе ответов на ниже перечисленные вопросы можно потом создать короткий FAQ для разработки. И вот вопросы: 1. Используете ли вы ООП в своих проектах? И если да, то насколько сильно? 2. Используете ли вы template функции? Классы? Если нет, то почему? 3. Используете ли вы friend функции? Классы? Если нет, то почему? 4. Используете ли вы структуры? 5. Контейнеры, на примере Vector, List etc., используете? Если да, то своя реализация либо используете ли вы стороннюю библиотеку? Если нет, то почему? 6. Какой, приблизительно (именно приблизительно), размер у ваших проектов, в кб? Можно в процентах, у меня к примеру при пользовании пару классов уже 16% отжирается на Adruino Uno. 7. При каком размере, в процентном соотношении, стоит паниковать и начать рефакторить код на предмет поиска жирных мест? 8. Самая распространенная проблема, с который вы сталкивались при разработки на C++, с использованием классов? 9. Самая распространенная проблема, с который вы сталкивались при разработки на C, без использования классов? 10. При написании на C разбиваете ли вы свой код на разные файлы, т.е. хидеры (*.h) и си файлы (*.c)? 11. Используете ли вы дебаггер? И если да, то как и помогает ли вам?
Для всех ответивших - большое человеческое спасибо! Особенно интересны ваши ответы на template, friend, struct, vector вопросы.
Имеется в виду программирование для МК или вообще? ОК, будем считать, что не для МК, если оное специально не указано. 1. Используете ли вы ООП в своих проектах? И если да, то насколько сильно? Да, потому что это элементарно удобно. 2. Используете ли вы template функции? Классы? Если нет, то почему? Ограниченно, т.к. они сильно усложняют код. При компиляции иногда возникают такие ошибки, которые вообще непонятно где и как исправлять. 3. Используете ли вы friend функции? Классы? Если нет, то почему? Да, когда есть группа классов внутри одного модуля. Использовать для внутреннего интерконнекта внешний интерфейс при этом - чистый оверхед. 4. Используете ли вы структуры? Да, группировка переменных без создания полноценного класса тоже периодически нужна. 5. Контейнеры, на примере Vector, List etc., используете? Если да, то своя реализация либо используете ли вы стороннюю библиотеку? Если нет, то почему? Если код идет на экспорт, тогда STL, а если для внутреннего пользования, то чаще своя реализация. Интерфейс у STL писали марсиане, пользоваться можно, но неудобно. Кармак вон тоже весь STL переписал с человеческим лицом =) 6. Какой, приблизительно (именно приблизительно), размер у ваших проектов, в кб? Можно в процентах, у меня к примеру при пользовании пару классов уже 16% отжирается на Adruino Uno. В конечном продукте контроллер подбирается под размер проекта, а так никогда на это особо не смотрю - хватает флэша и ладно. Ну и да, пред началом проекта нужно продумать задачи и выбрать хотя бы подходящее семейство контроллеров. 7. При каком размере, в процентном соотношении, стоит паниковать и начать рефакторить код на предмет поиска жирных мест? Очевидно, когда он перестает влезать в контроллер. Но лучше сразу нормально писать. 8. Самая распространенная проблема, с который вы сталкивались при разработки на C++, с использованием классов? 9. Самая распространенная проблема, с который вы сталкивались при разработки на C, без использования классов? Не помню, все одинаково. 10. При написании на C разбиваете ли вы свой код на разные файлы, т.е. хидеры (*.h) и си файлы (*.c)? Да, обязательно (если там не единственный main.c). Но придерживаюсь принципа: один заголовок - одна реализация. 11. Используете ли вы дебаггер? И если да, то как и помогает ли вам? Для МК - пока нет. Atmel Studio не использую, а другой инструментарий не настраивал. А на ПК, конечно, использую, valgrind тоже очень сильно выручает.
Добрый день. Спасибо за ответы. Как я понял, что вы ответили в разрезе общей практики C/C++, исходя из ответа про дебаггер. Все эти вопросы у меня возникли при изучении, что да как делают с микроконтроллерами. И исходя из этого я удивился, что ООП не сильно распространено, так же, как и контейнеры и темплейты. Вот и подумал, что использовать такие вещи в данном случае, при разработки для микроконтроллеров, не бест практиз. И вот к примеру, про контейнеры вопрос у меня появился после прочтения этой темы - container for Objects like c++ vector?. Согласен полностью по поводу STL. Я помню то время, когда еще не перешел на дотнет, парился ночами перед монитором. Тогда еще MFC была флагманом у MS. А на никсах тогда мне не удалось поработать Вопрос еще, а всяческие системы тестирования, аля юнит тесты и прочее вы используете? Если да, то подскажите как грамотно использовать, какие библиотеки пользовать?
И да, еще я понял при серче, что пользоваться мультифредингом не стоит и в большинстве случаях можно обходиться одним потоком. Хотя с этим можно поспорить.
Системы тестирования - это слишком серьезно для моих проектов, хотя кое-где было бы неплохо их прикрутить. Наколеночные тесты пишу иногда, если очевидно, что регрессии есть и будут, а так обычно просто некогда их писать. Навороченные языковые фичи раздувают код, стек, шапку, а на МК памяти и так немного. Поэтому все на ручном управлении, все по байтам-по битам разложено и учтено. Это вот Wiring тут вносит некоторый разлад, отучая от экономии ресурсов
А, ок. Хороший ответ. Конечно перегнул палку с понятием "система тестирования", но подумал, что может есть что, только я об этом не знаю. Я ж все же новичок В общем, как я понял исходя из беседы при разработки на мк нужно просто соблюдать золотую середину, т.е. не перебздеть использования фичами языка и использовать в меру и только, когда это оправдано. Просто, ну очень не хотелось отказываться от ООП. Уж привык сильно. Спасибо еще раз!
Еще вопрос новичка. Предположим, у меня есть граф объектов и мне нужно его сериализовать и передать, допустим, веб сервису, который десереализует его обратно в граф объектов, далее его схоронит граф в бэдэ, и через некоторое время, веб сервис должен отдать мк тоже граф объектов и мк должен десериализовать его в свой граф объектов. %) Так, вот, самый лучший вариант это использовать XML формат при передаче туда-обратно-и-опять-туда. Но я не нашел никакой понравившейся мне реализации этого требования. Собирать XML посредством обычного string мне кажется не очень грамотным, не уверен из-за не знания, что кодировка будет верна и т.д. А уж обратно, на мк, XML перегнать обратно в объекты пока понятия не имею как. Может кто подскажет мне, как грамотно сделать такую вещицу? Т.е. весь вопрос заключается, как грамотно сериазовать и десериализовывать объекты в XML на МК? Заранее спасибо!
Зачем так сложно? XML хорош когда памяти навалом. А так лучше или велосипед или хотя бы JSON. Ну а граф передать проще в виде двух массивов (вершин и ребер). Можно перед заливкой на МК заранее сконвертировать его во внутреннее представление МК и передать в HEX как образ памяти.
По поводу XML. XML — это overkill для МК, как собственно и для десктопа во многих случаях. Когда важна компактность, стоит обратить внимание на Google Protobuf. Чумовой адаптивный стандарт, в котором даже int занимает 1, 2 или 4 байта в зависимости от собственного значения: 100 влезает в 1 байт, а вот 300 уже в 2
