Мне, разумеется, кажется, что я вполне понимаю :) Если вам не трудно, поясните, в чем именно я не прав?
В пункте 6.2.1 Scopes of identifiers читаем "An identifier can denote an object; a function; a tag or a member of a structure, union, or enumeration; a typedef name; a label name; a macro name; or a macro parameter."
Т.е. идентификатор — это в т.ч. имя переменной. У вас __config — это имя переменной.
Весь пункт 7.1.3 описывает зарезервированные идентификаторы; идентификаторы, которые начинаются с двух подчеркиваний — зарезервированы всегда (это я уже цитировал), т.е. в любых областях видимости.
Использование зарезервированных идентификаторов в контекстах, в которых они зарезервированы — UB. Т.е. использовать два подчеркивания в начале идентификаторов нельзя вообще, в любых контекстах.
Зачем читать всю главу 7 (которая описывает стандартную библиотеку), я не очень понимаю, это вроде к делу не относится.
Я честное слово не понимаю, в чем я не прав, объясните, пожалуйста!
Каким образом это приводит к неопределенному поведению, что-то вы ахинею говорите. Несколько раз перечитал спойлер, так и не понял о чем вы.
Это цитата из стандарта С99. "Все идентификаторы, которые начинаются с подчеркивания и заглавной буквы или двух подчеркиваний являются зарезервированными" — т.е. их нельзя объявлять, они зарезервированы для использования компилятором или стандартной библиотекой.
Там же, далее "If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined." — т.е. использование таких идентификаторов приводит к неопределенному поведению (пардон, сразу не процитировал этот кусок).
Не по теме, но замечу, что идентификаторы, которые начинаются с двух подчеркиваний, зарезервированы и не должны использоваться в пользовательском коде, это UB.
Spoiler header
C99 7.1.3 Reserved identifiers: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use."
Еще можно поискать отладочные платы с нужным контроллером, или делать микроплаты-переходники, чтобы запаивать несовместимые по пинам чипы (скажем, F4 даже на чип-дипе еще есть по цене всего в 1к за штуку).
В качестве альтернативы отмечу, что у Альтиума с некоторых пор есть какая-никакая интеграция с git'ом — например, диффы таки можно посмотреть:
Spoiler header
Но насколько я понимаю, мерджи делать будет почти невозможно, поэтому на мой взгляд вместо гита лучше подойдет (о боги!) SVN, поскольку в нем можно делать глобальный лок на редактирование.
Так это норма. Деление на ноль — это неопределенное поведение, оно не обязано порождать какие-то ошибки.
В embedded достаточно часто получается просто ноль и все :)
Да, ассерты в SPL и HAL — достаточно полезная штука; хотя примерно половину можно было бы убрать, если вместо uint16_t параметры у функций были бы enum class (я понимаю, что они не могут, но помечтать-то можно).
А вот у LL ассертов на порядок меньше, это немного напрягает.
А, вы про кейл. Просто я сразу вспомнил про:
gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
github.com/google/sanitizers/wiki/AddressSanitizer
А разве эти опции работают для таргета arm-none-eabi?
Выявление багов при помощи надежного тестирования, очистки и фаззинга критически важно для повышения качества и корректности любых программ, в том числе, написанных на Rust.
Забавно, что fuzzing остался фаззингом, а вот address sanitizer превратился в "очистку".
Людей можно понять, в плюсах и функции «сами собой вызываются». Причем ведь накалываешься на мелочах — упустил буквально один символ при наборе, и если бы у тебя не был удален конструктор копирования, то ты бы не увидел ошибку, и возможно нескоро узнал бы, что делаешь что-то не то.
Да я их прекрасно понимаю, че уж. С по крайней мере можно целиком в голове удержать, а С++ уже кажется нельзя :)
Хм, а я ни разу. А что с санитайзерами кстати, почему нет?
А вы про какую ситуацию? Просто какой-нибудь парсер со сложным автоматом на кучу потоков не заменишь. Или вы про другое?
Парсер не особо, но просто какую-то логику "событийную" типа "послать такой запрос — подождать ответ (или таймаут) — послать следующий — подождать" — иногда очень хочется.
Да, и оно ведь во многом растет от библиотеки шаблонов. Так что тут так — и этим своим не станешь, и эти врагами объявятся)))
На мой взгляд, оно растет чаще просто от незнания; многие думают, что в С++ память как-то "сама по себе тратится" и не пытаются вникать дальше, просто сходу отметают.
Требования совместимости. Впрочем, выход за границы массива — вещь нечастая. А при наличии foreach… Который еще и оптимизируется лучше.
Имхо норм указатель и размер, я даже в шарпе этого не стесняюсь при работе со строками (иначе получается нечитаемая хтонь), просто дело же не только в этом, спан типа вообще лучше.
foreach по указателю как раз не сделать, например.
Я лично регулярно за границы вылезал, прям фобия развилась. Особенно учитывая, что никаких санитайзеров-то нема, можно ведь вылезти и не заметить вообще.
Вы Аду не пробовали? Тут параллельно идет обсуждение. Там все есть, и все красиво. :)
Слышать — слышал, пробовать — не пробовал. В бывшем СНГ вроде на ней вакансий около нуля, так что… В Rust лично у меня веры больше.
Ммм, вы находите? Вроде норм… Но вообще, как по мне — уж лучше в потоки, я к асинхронщине в принципе отношусь с сомнением.
Можно и потоки, лишь бы не городить полотнища свитчей для конечных автоматов. С другой стороны, зато все просто и понятно :)
Да, но не использовать контейнеры — это же почти идиоматическое преступление, могут и к высшей мере приговорить в интернетах!!!111
В embedded — скорее наоборот, насколько я могу судить; многие придерживаются мнения, что С++ в принципе — это недопустимо.
Впрочем это может быть интересной концепцией — запретить вообще пространство имен STL. Только сишные либы (выпилив и из них динамику) и сам стандарт языка. То есть все эти вот извращения вокруг STL это примерно как мамкино веганство («курицы глупые, их можно есть»), а вот такой подход — чистое, настоящее веганство.
Но в std есть куча полезных вещей, которые с контейнерами не связаны — скажем, std:nth_element или std::atomic; контейнеры в отдельный неймспейс не выделили.
Можно, конечно, просто несколько контейнерных хедеров "запретить", но зачем — если запретить динамическую аллокацию, то с ними все равно линковаться не будет.
А, ну вы про РТТИ еще вспомнили, точно. Главное же кучу задать нулевой!
Просто именно куча опцией-то как раз не выключается, по крайней мере в Кейле для этого прагму надо писать, в gcc или ставить нулевой размер кучи или какой-то костыль делать типа --wrap=malloc. Мб в IAR опция, не знаю.
М, да, кстати, спан бывает полезен, впрочем я и к нему с сомнением отношусь.
Меня лично спан (как и все остальные контейнеры STL) огорчает в основном тем, что он не проверяет выход за границы в операторе [] — а легко везде заменить [] на at — не особо получается.
Но спан все равно лучше, чем отдельно указатель и размер.
Мне, разумеется, кажется, что я вполне понимаю :) Если вам не трудно, поясните, в чем именно я не прав?
В пункте 6.2.1 Scopes of identifiers читаем "An identifier can denote an object; a function; a tag or a member of a structure, union, or enumeration; a typedef name; a label name; a macro name; or a macro parameter."
Т.е. идентификатор — это в т.ч. имя переменной. У вас
__config— это имя переменной.Весь пункт 7.1.3 описывает зарезервированные идентификаторы; идентификаторы, которые начинаются с двух подчеркиваний — зарезервированы всегда (это я уже цитировал), т.е. в любых областях видимости.
Использование зарезервированных идентификаторов в контекстах, в которых они зарезервированы — UB. Т.е. использовать два подчеркивания в начале идентификаторов нельзя вообще, в любых контекстах.
Зачем читать всю главу 7 (которая описывает стандартную библиотеку), я не очень понимаю, это вроде к делу не относится.
Я честное слово не понимаю, в чем я не прав, объясните, пожалуйста!
Это цитата из стандарта С99. "Все идентификаторы, которые начинаются с подчеркивания и заглавной буквы или двух подчеркиваний являются зарезервированными" — т.е. их нельзя объявлять, они зарезервированы для использования компилятором или стандартной библиотекой.
Там же, далее "If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined." — т.е. использование таких идентификаторов приводит к неопределенному поведению (пардон, сразу не процитировал этот кусок).
Не по теме, но замечу, что идентификаторы, которые начинаются с двух подчеркиваний, зарезервированы и не должны использоваться в пользовательском коде, это UB.
C99 7.1.3 Reserved identifiers: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use."
Воо, вот это я понимаю, богоугодная фигня!
Так непонятно, с чего счет начинается :)
Может тогда уж сразу
for i in 0..daysбез всякой iota?АО ПКК "Миландр" wants to know your location :)
Еще можно поискать отладочные платы с нужным контроллером, или делать микроплаты-переходники, чтобы запаивать несовместимые по пинам чипы (скажем, F4 даже на чип-дипе еще есть по цене всего в 1к за штуку).
Но вообще можно только посочувствовать...
Сделать список из чисел от 1 до 189 и итерироваться по нему b раз, начиная с позиции а :)
(типа сложение по аксиомам Пеано)
У gcc есть -Wsign-compare
В качестве альтернативы отмечу, что у Альтиума с некоторых пор есть какая-никакая интеграция с git'ом — например, диффы таки можно посмотреть:
Но насколько я понимаю, мерджи делать будет почти невозможно, поэтому на мой взгляд вместо гита лучше подойдет (о боги!) SVN, поскольку в нем можно делать глобальный лок на редактирование.
Так это норма. Деление на ноль — это неопределенное поведение, оно не обязано порождать какие-то ошибки.
В embedded достаточно часто получается просто ноль и все :)
Да, ассерты в SPL и HAL — достаточно полезная штука; хотя примерно половину можно было бы убрать, если вместо uint16_t параметры у функций были бы
enum class(я понимаю, что они не могут, но помечтать-то можно).А вот у LL ассертов на порядок меньше, это немного напрягает.
В последний раз я давненько проверял, конечно. Надо будет перепроверить, но чет я сомневаюсь.
А разве эти опции работают для таргета arm-none-eabi?
Забавно, что fuzzing остался фаззингом, а вот address sanitizer превратился в "очистку".
"C++ is not hard, it's just expert-friendly" :)
Да я их прекрасно понимаю, че уж. С по крайней мере можно целиком в голове удержать, а С++ уже кажется нельзя :)
Почему — не знаю, просто нету их и все.
Ну, точнее, у Кейла они в альфе сейчас https://www.keil.com/support/man/docs/armclang_ref/armclang_ref_lnk1549304794624.htm, про другие тулчейны не в курсе
Переопределить глобальные операторы new и delete?
Парсер не особо, но просто какую-то логику "событийную" типа "послать такой запрос — подождать ответ (или таймаут) — послать следующий — подождать" — иногда очень хочется.
На мой взгляд, оно растет чаще просто от незнания; многие думают, что в С++ память как-то "сама по себе тратится" и не пытаются вникать дальше, просто сходу отметают.
foreach по указателю как раз не сделать, например.
Я лично регулярно за границы вылезал, прям фобия развилась. Особенно учитывая, что никаких санитайзеров-то нема, можно ведь вылезти и не заметить вообще.
Слышать — слышал, пробовать — не пробовал. В бывшем СНГ вроде на ней вакансий около нуля, так что… В Rust лично у меня веры больше.
Можно и потоки, лишь бы не городить полотнища свитчей для конечных автоматов. С другой стороны, зато все просто и понятно :)
В embedded — скорее наоборот, насколько я могу судить; многие придерживаются мнения, что С++ в принципе — это недопустимо.
Но в std есть куча полезных вещей, которые с контейнерами не связаны — скажем,
std:nth_elementилиstd::atomic; контейнеры в отдельный неймспейс не выделили.Можно, конечно, просто несколько контейнерных хедеров "запретить", но зачем — если запретить динамическую аллокацию, то с ними все равно линковаться не будет.
Просто именно куча опцией-то как раз не выключается, по крайней мере в Кейле для этого прагму надо писать, в gcc или ставить нулевой размер кучи или какой-то костыль делать типа
--wrap=malloc. Мб в IAR опция, не знаю.Меня лично спан (как и все остальные контейнеры STL) огорчает в основном тем, что он не проверяет выход за границы в операторе [] — а легко везде заменить [] на at — не особо получается.
Но спан все равно лучше, чем отдельно указатель и размер.