std

Интересно было бы глянуть

Какой год производства?

Пропустишь одно слово, так как думаешь что все всё понимают и получаешь. Ну мы же ведем разговор о EMBEDDED разработке. Embedded это еще hard realtime, часто ассемблер, прямая работа с железом и оригинальные решения, платы, разводка, сигналы, схемки, электронные компоненты, алгоритмы, методика отладки и тестирования. Методика построения проектов электроники, программных проектов. Документация, в конце концов. А Мейерсу и Голубу в обед двадцать лет. Примерно тогда я их и скурил. Интересны гуры именно Embedded разработки, то бишь еще и электроника, а не очередное программирование. Теплится надежда что есть тот заветный фолиант, который прочтешь - и сразу станешь магом. (шучу конечно, но это именно та причина, по которой я спросил что за книжка) Что за камень-то был, имя! 😃 В противовес задвину байку из примерно 2000 года и вышедшей тогда в 1998 свеженькой VS6. По аналогии с микроконтроллерными циклами или даже с x86 асмом я писал DSP обработку в духе: mov reg_address, address mov reg_counter, count loop: do with [reg_address] whatever... ; Что-то делаем с данными по адресу.. inc reg_address ; Инкремент адреса dec reg_counter ; Декремент счетчика jnz loop .... И удивился, когда циклы в C++ STL показали более быструю работу. WTF?!? WTF?! Фича оказалась в том, что STL использует для проверок циклов сравнение указателей, т.е. обходится без счетчиков.

Спасибо. Мне не этот вопрос интересен, есть интерес почитать волшебные книги реальных гуру. Я уже размечтался. 😃 От себя скажу, схема с выставлением булевого или битового флага в прерывании (флаг что прерывание произошло) связана не только с "минимизацией времени обработки прерывания". Этот архитектурный паттерн для меня обладает иной ценностью. Прерывания представляют собой полноценный параллельный поток выполнения. И если внутри прерывания отрабатывают какие-то алгоритмы зависимые по данным с основным потоком, придется вводить примитивы синхронизации. С возможностью ошибки. Рабочий алгоритм программы разбавится еще и вызовами синхронизации, блокировками, итд. Паттерн с выставлением из прерывания флажка и анализа флажка в заданном нами месте позволяет "обработать" прерывание именно тогда когда мы желаем, в заданной очередности, избегая синхронизации. Для wfi есть. В большинстве реализаций это вход в режим энергосбережения с возможной приостановкой сигналов синхронизации и проч. Соответственно, прерывание придет и понадобится время раскочегариться.

Не припомните, что за книга/книги?

Компилятор может вывести и применить девиртуализацию только двумя способами. 1. Виртуальный метод или весь класс помечен final. 2. Класс определен в анонимном пространстве имен и не имеет производных классов в единице трансляции.

См к примеру файл: C:\Users\User\STM32Cube\Repository\STM32Cube_FW_F1_V1.8.3\Drivers\CMSIS\Device\ST\STM32F1xx\Source\Templates\gcc\startup_stm32f103x6.s (или другие файлы по этому пути, например startup_stm32f103xb.s) (подправьте в пути имя пользователя под себя и требуемую версию пакета) В стартапах для GCC STM'мная недокументированная "фича" прописана, в стартапах для других тулчейнов нет. ST видимо забыли задокументировать. На форумах ST это обсуждалось, включая недоумение почему нигде не описано. Строка поиска Google: site:st.com 0x1E0 startup_stm32f103x6.s

Таки я не прав. В 23 удалили сбор мусора =))) А это всё же концепция. По факту его никто не поддерживал (т.е. его и не было).

Здравствуйте, kan35. Выше все чудесно написали, но мне показалось что до конца именно вашу странность не объяснили. Я думаю что ваша странность объясняется так. Скорее всего, вы конвертировали в short не из явного signed char, а из char. Во многих компиляторах существует опция знака char по умолчанию, знаковый или беззнаковый. Либо у вас была другая целевая машина, потому что знак char может еще зависеть от целевой платформы. В итоге у вас был в одном случае по умолчанию unsigned char, а в другом случае signed char. Вот и получались разные результаты. В вопросе знака char до определенной даты имелись расхождения. Так, старый K&R (по книжке) char беззнаковый, первые стандарты в этом вопросе ничего не утверждали, стандарт 99 сообщает же только: Для GCC знак задается -funsigned-char или -fsigned-char для MSVC (cl.exe) опция /J делает char unsigned.

Ничто не мешает. Никаких базовых классов вы не обязаны создавать. Наследование не обязательно. Классы не обязательны. В ООП парадигме можно писать на ассемблере или Си. Поёрничаю: почему бы CComPort-у не содержаться в вашем классе качестве композита, в виде агрегата, быть миксином или вообще никак не содержаться, вызывая его функции или например не вызывая функции, а подписаться на него, получая сообщения или периодически проверяя сообщения где-нибудь в общей очереди? Вообще, не кажется ли что совсем наоборот, это CComPort зависит от CUart? 🙂 Читая "будет класс", "класс-наследник", "переопределяет", становится понятно что у вас сложился образ "ООП" обязательно подразумевает наследование. Это не так. Я предлагаю вам начать с людей которые это создали и изучить что же они имели в виду, их цели и как они их добивались. Если открыть страницу OOP и почитать, то становится понятно, что OOP оформился в языке SIMULA и это произошло задолго до C++ и даже до C (1957-1962). Еще полезно изучить что есть SIMULA и для чего создавалось (там немного лукваят хотя бы потому что спонсировали эти исследования и вообще проект компьютера министерство обороны). Вот документ Some features of the SIMULA 67 language. в нем я бы обратил внимание на: Ибо это и есть самая суть. Все остальное уже рюшечки. Some features of the SIMULA 67 Languge (1968_0007).pdf

Все верно. Объекты и классы должны быть максимально изолированы (это называется не иметь зависимостей, dependency-free). Каждый финальный рабочий объект должен представлять собой не имеющую зависимостей "изолированную" программу-объект полноценно выполняющую строго отведенные ей обязанности. Взял объект, может быть параметризовал, сконфигурировал впрыснул зависимости — и он завёлся, начал выполнять работу. Больше ничего и не надо. Это в идеале. К этому надо стремиться. См. принципы SOLID Потому давно замечено, что написанная таким образом программа приобретает целый ряд очень ценных свойств и качеств. Одно из них — само-замкнутость, целостность, устойчивость, отсутствие хрупкости, тестируемость. Насчет "Объекты между собой должны взаимодействовать, как ни крути" Если CUart (или его наследник) будет дергать методы CScreen - всё, конец. Класс-иерархия превращается в кашу взаимо-зависимостей. Потому что потом невозможно будет изъять из программы CUart и его периспользовать. CUart намертво будет переплетен с CScreen. А должно быть написано так, что в любой момент можно изъять CUart и использоавть его в другом проекте или в другой части проекта (а иногда - прямо в программе заменить его другим классом, этому способствует паттерн "Фабрика"). * - я не могу здесь распылиться на агрегирование, композицию и наследование, иначе пост превратится в стену текста. Зависимости при композиции не избежать в принципе и вообще всё в конечном итоге не так просто и баинарно, есть зависимости разного рода, дальние и ближние итд. Данный "общий" код будет "сверху", вынесен из CUart и из CScreen, содержась в некоем CDisplayManager, который в свою очередь содержит лишь экземпляры (или указатели) на CUart и CScreen. Это-то и будет тот, кто дергает выставленные методы объектов "из космоса" (о чем мы говорили выше). Однако, за все надо платить. И это тоже не бесплатно, это несет проблему. Проблемой здесь становится высокое "размытие" программы по классам и методам. Это анти-паттерн, который можно привнести в свои же собственные программы. Тогда вместо "цельности", "разумности" где каждый объект выполняет свое предназначение начнется иное - начнется ад из десятков классов с тонкой кодовой "кашицей" размытой между ними. Возникает "Yo-Yo problem", когда чтобы понять или редактировать программу приходится метаться между десятками файлов и вкладок или бегать вверх-вниз по файлу. Вдобавок, писать код подобным образом муторно. Лениво ваять дополнительные "клеевые" glue-объекты и классы (и интерфейсы). Всевозможные "CManager"-ы начинают возникать в неудержимом количестве. Но в конечном итоге платой будут определенные свойства программы. Надо соблюдать здравый смысл. Если у себя проект небольшой, ни к чему такой пуризм. Лучше повыкусывать потом код, чем обезуметь и самому же себе создать декомпозицию из 20 классов на 70.

(Я уже когда написал подумал "сейчас программисты накидают". Потому что крайне любят цепляться за соринку в глазу 🙂 неточности, оставляя порой самое важное за бортом). Да, спасибо. Я конечно же имел в виду не было отмены важных концепций. Я бы отметил auto_ptr, который удален в C++17. Но это не значит что удалили концепцию смартпоинтеров.

Это связано с типичными архитектурными особенностями программ написанных в процедурном стиле и в ООП стиле. 1. В процедурном стиле все вызовы иерархичны (и чаще всего при правильном построении локальны). Функция дергает другие функции. Или эту функцию выше кто-то дергает. Program Flow и что самое главное - логика программы легко восстанавливается. 2. А в ООП программы и пишутся обычно как симуляторы дискретного времени (как это и было в основополагающей Simula). Есть "мир" или "набор" объектов (классов если быть более точным). У объектов выставлены наружу методы. А кто там дёргает за эти методы - неизвестно. Кто-то дергает... Извне.. Из космоса-пространства. Так написаны большинство больших ООП проектов и поначалу меня это сильно смущало, до сих пор привыкнуть не могу. Особо ярко это выражено в Java и в особо больших проектах, редактор Eclipse например. Любой public-метод кандидат. Еще одной особенностью как ООП так и C++ программ является очень частая передача управления по указателю, которая если используются "виртуальные методы" происходит за кулисами всегда и неявно. И наконец скрытое неявное преобразование типов. Итогом всего этого часто является то, что хотя и известно что метод вызывается, но найти откуда он зовется чисто по коду программы невозможно. Только запускать и ставить breakpoint.

Со всем выше согласен. У всех разный опыт и разное понимание и даже использование языка. Что же касается именно применения ООП, опишу случай, который у меня был в жизни. Году в 2004 у меня был срочный и неприятный проект. Пришлось как бы "спасать" своего партнера, который взял очень важный проект, но почти что завалил его, отдав парню работавшему ранее на PHP и не имевшему даже представления о байтах. Время было потеряно. Проект этот представлял собой просмотрщик масок микросхем (он открывал Calma GDSII файлы) в 3D виде. При этом верхние слои представлявшие собой как правило токопроводящие дорожки должны были в простейшем случае как бы "осыпаться" вниз на нижние, изображая посредством OpenGL как в кремнии созданы структуры. Это "осыпание" пришлось сделать логическими операциями над сложными многоугольными полигонами масок. Но дело вот в чем. Алгоритм, который производил действия над слоями и составляющими их частями был настолько сложен, что я смог выразить его только в качестве C++ объектов над которыми осуществляли действия операторы. Написать и отладить алгоритм не-объектно, чисто в процедурной парадигме оказалось выше моих сил. А объектно, переопределив операторы комбинирования (or xor and not) удалось его наконец запрограммировать, потому что конечные выражения резко упростились и стали представлять собой своеобразный метаязык. Отдельной сложностью там являлось управление памятью - вследствие операций над полигонами объекты самостоятельно множились или сокращались/удалялись. Мне помогли такие вышестоящие абстракции как контейнеры и shared pointer'ы (тогда они не были в стандартных библиотеках). Такой вот опыт, когда возможности C++ позволили реализовать проект вообще как таковой. Я конечно понимаю возможный скепсис, когда читаешь такое. Казалось бы, любая C++ программа изоморфна C-программе. Но дело-то в том что возможности человека не бесконечны. Я не говорю что C++ это прям-прям панацея и золотая пуля. Например несколько прошивок приборов я намеренно написал на чистом Си (однако же, с усложнением назрела необходимость переписать на C++). Возможностей настрелять себе в ногу в C++ гораздо больше чем в Си. C++ всего лишь инструмент облегчающий определенные вещи, часто он делает структуру и код понятными, убирая шум низкого уровня и оставляя application level.

Вот книга "Дизайн и Эволюция C++" авторством Страуструпа. 1994 год. Ее хоть и знают, но редко упоминают. Чтение позволяет постичь почему были выбраны те или иные решения. Дизайн и Эволюция C++.djvu