one_eight_seven

Придерживаешься правил и всё нормально.

Вложенность блоков обуславливается одинаковым количеством ведущих пробелов, а не фигурным скобками и не begin/end'ами

Да, инструмент хороший. Не нравится только, что он позволяет код писать через жёппу. То, что у Synopsys/Cadence выявляется на этапе сборки, в Questa вылезает только в рантайме. С другой стороны, у Cadence просто отрватительное решение по рандомизации. Притом, сломали они его в 2019. До этого Xcelium был неплох. А вот VCS прекрасен до сих пор.

https://google.gik-team.com/?q=linenoise

И что делать среди запойных специалисту, который выбил себе приемлемые условия? И вообще зачем их выбивать, если в других местах их предлагают сразу - непонятно. За что ещё надо будет постоянно бороться?

Можно и вообще без файлов. Просто в командной строке. Но с файлами быстрее и удобнее

Для вашего удобства это. Компилятору вообще дела нет до расширения файлов. Это, чтобы вы могли для себя быстро определить, где у вас объявления сущностей, а где их реализация. Ну и заодно, как бонус - редакторы, IDEшки могут по расширениям определить тип файла, и синтаксис подсветить, или проиндексировать их поудобнее. Но это не обязательно.

Нет. const-метод вполне может изменять следующие типы данных: mutable поля класса любые данные, к которым класс имеет неконстнантный доступ. т.е. которые для класса не являются константой: те, к которым он имеет доступ по указателям и ссылкам (технически, метод не меняет поле класса, оно остаётся неизменным, но данные, доступные по этим полям - изменяемы) данные, передаваемые в const-метод по указателю или ссылке в качестве аргументов через указатели или ссылки, возвращаемые функциями напрямую доступные через namespace или класс - такие, как статические члены.

Присоединяюсь к @esaulenka, а какое у вас понимание? Насколько я могу объяснить, модификатор const, применительно к методу класса, влияет не на метод класса, а на указатель this. Т.е. если у нас class C, то this в данном случае будет типа C const *, в то время как для неконстантного метода он будет C *. А статические методы не имеют указателя this в принципе.

Вы связь с сутью разговора потеряли. Перечитайте и прийдите в себя.

Нет. Это значит доступно и исполняется. Недоступно - это если оно BusFault или HardFault вызовет.

Наоборот, очень часто доступно. Встречал два поведения: 1) Всегда читаются нули 2) одни и те же адреса используются в качестве интерфейса TX FIFO (при записи в эти адреса) и RX FIFO (при чтении по этим же адресам) В большинстве случаев лучше считать, что ОЗУ вообще не существует. Есть процессор (с его системой команд, регистрами общего назначения, SFR, прерываниями) и память. Просто память. Если нужно эту память как-то делить, это уже какая-то экзотика. Вы запретите запись через MPU? Нет, вы не запретите, запись исполнится процессором, но, в зависимости от настроек MPU (которая - периферия отображённая в память, т.е. с точки зрения процессора - опять же просто область памяти), результат этой записи может быть разным. И обработка таких событий опять же ограничивается обращениями в память и прерываниями.

Ну, кому развлекуха, кому - рутина. И уж с матлабом-то эту систему построить и отладить - как два байта переслать.

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

P.S. Подумал ещё, и стал ещё сильнее согласен с тем, что на этапе компиляции такое проверять правильно. Добавил: -Wwrite-strings И получил: $ gcc -Wall -Wextra -pedantic -Wwrite-strings tst.c tst.c: In function ‘main’: tst.c:9:16: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 9 | char * p = "inmutable"; | ^~~~~~~~~~~ $