Да. А если не подключать тариф, то через полгода-год начинают списывать по 500..800 рублей в месяц ("за сохранение номера"). Это все три основных оператора так делают и это всегда было в договорах Таким образом они борются с забытыми и заброшенными симками, чтобы не копились.
Именно так оно и работает. Современные мощные ноуты часто (почти всегда) имеют родную зарядку на 200...260 ватт, но умеют и по Tyoe-C питаться, в этом случае потребление ограничивается на уровне 100..120 ватт (например видеокарта не поднимает частоту более 80%).
Правильное IDE и синтаксический анализатор нужно использовать. А через grep искать это лютая дикость и боль. Попробуйте поискать в исходниках стандартных библиотек и каких-нибудь библиотек от STM. Оно вам сотню вхождений может выдать.
Например портирование/кастомизирование FreeRTOS под свою платформу. Или портирование/доработка stdlib. Например переопределние 64-битной арифметики в stdlib позволяет сэкономить от 10 до 30 килобайт FLASH и при этом дать 30% прирост производительности, что может быть критично для многие проектов. А правильный тюнинг сохранения контекста DSP в многозадачных средах позволяет сократить накладные расходны на переключение задач в разы, и при этом практически везде сохранение контекста сделано неоптимально (или даже неправильно). А ещё можно (и часто нужно) патчить макросы сборки библиотек ST (так как там куча недоработок и ошибок). Только там мегпбайт макросов легко может вывалиться.
Если у вас даже 128к ROM, то сложная прошивка в исходных текстах будет весить мегабайты. И есть проект живет долго и эволюционирует, то в какой момент оказывается, что он может собираться тремя разными компиляторами, с четырьмя вариантами libstdc, тремя вариантами OS, и на пяти разных микроконтроллерах, двух разных семейств.
Успехов в отладке действительно многоплатформенных приложений таким путём. У меня в одном из приложений этот сгенерированный header был полтора мегабайта весом. Тайные знания в том, что именно, что переключает и от чего зависит. Без исходников все эти макросы - просто мешанина кода. Генерация всю информацию о происхождении макросов убирает.
Всё верно, но кроме вот таких глобальных переключений в серьёзный embedded проектах есть ещё куча копиляторо0заивисмых настроек, библиотеко-зависимых (мы можем собираться с различными libc/libc++ библиотеками), toolchain-зависмых (привет всем этим китайским колхозным системам сборки), ОС-зависимых, и ещё чёрте-от-чего-зависмых настроек. Выносить всё это в глобальные макросы не нужно, так как на практике это очень редко меняется (только при портировании на новую платформу/окружение). А ещё если из одного дерева исходников собираются сильно разные вещи, то возникает здоровое желание переключать глобальные настройки удобным образом в исходниках, чтобы это было лучше видно в системе контроля версий. Поэтому в нормальных проектах делают три уровня абстракций: - высокоуровневые макросы, задаваемые через настройки компилятора; - высокоуровневые макросы и настройки в заголовках, которые переключают какие-то совершенно глобальные вещи, которые нужно править или менять только при портировании на новое железно или окружение или при создании каких-то новых программ на основе того же дерева исходников; - низкоуровневые макросы, которые завязаны на предыдущие два уровня и проверяют/определяют/настраивают кучу макросов, которые в дальнейшем уже непосредственно влияют на условную компиляцию в файлах исходный текстов кода.
Именно так построены все серьёзные проекты от самого GCC/CLANG, до всех портов libc, и ядра Linux. И задать всё через макросы, определяемые ключами компилятора, просто не возможно: будет куча мусора и тайных знаний при совершенно шаманской финальной структуре макросов.
Извините, но это лютейший бред. Конфигурация настраивается в хедерах, а переключается настройками компилятора (объявлением макросов). Сугубо потому, что хедеры уже могут изменять структуру C-файлов, вплоть до отключения/подключения целых наборов файлов.
Таки раньше электронные тормоза могли подключаться только по независимой шине с односторонними шлюзами (которые физически ничего не могли передавать на эту шину). Как сейчас не знаю
Их отлично сдают в аренду, но там проблема в дровах для виртуализации. Профессиональные серии можно делить не несколько независмых видеокарт, лего пробрасывать в контейнеры и прочие фишки.
Да. А если не подключать тариф, то через полгода-год начинают списывать по 500..800 рублей в месяц ("за сохранение номера"). Это все три основных оператора так делают и это всегда было в договорах Таким образом они борются с забытыми и заброшенными симками, чтобы не копились.
Справедливости ради, большая часть пакетов и программ в любом случае являются "неизвестными".
Если из-за износа, то они в режим read only переходят. А если в иной мир, то это отказ какой-то или брак, а не износ памяти.
Где символы по восемь вариантов кодирования имеют, а качественная нормализация это очень дорогой процесс?
Именно так оно и работает. Современные мощные ноуты часто (почти всегда) имеют родную зарядку на 200...260 ватт, но умеют и по Tyoe-C питаться, в этом случае потребление ограничивается на уровне 100..120 ватт (например видеокарта не поднимает частоту более 80%).
Это разделитель полезной нагрузки с пиропатронами. Это не зубья, это отверстия были, но вокруг выгорел защитный кожух.
Это официльно. А неофициально лётчиков учили аж до 40.
Германия готовила танкистов и лётчиков в СССР с дополнительным дообучением. Именно для того, чтобы скрыть их истинное число.
Слив из исходников под Linux.
Правильное IDE и синтаксический анализатор нужно использовать. А через grep искать это лютая дикость и боль. Попробуйте поискать в исходниках стандартных библиотек и каких-нибудь библиотек от STM. Оно вам сотню вхождений может выдать.
Например портирование/кастомизирование FreeRTOS под свою платформу. Или портирование/доработка stdlib. Например переопределние 64-битной арифметики в stdlib позволяет сэкономить от 10 до 30 килобайт FLASH и при этом дать 30% прирост производительности, что может быть критично для многие проектов. А правильный тюнинг сохранения контекста DSP в многозадачных средах позволяет сократить накладные расходны на переключение задач в разы, и при этом практически везде сохранение контекста сделано неоптимально (или даже неправильно).
А ещё можно (и часто нужно) патчить макросы сборки библиотек ST (так как там куча недоработок и ошибок). Только там мегпбайт макросов легко может вывалиться.
Если у вас даже 128к ROM, то сложная прошивка в исходных текстах будет весить мегабайты. И есть проект живет долго и эволюционирует, то в какой момент оказывается, что он может собираться тремя разными компиляторами, с четырьмя вариантами libstdc, тремя вариантами OS, и на пяти разных микроконтроллерах, двух разных семейств.
Успехов в отладке действительно многоплатформенных приложений таким путём. У меня в одном из приложений этот сгенерированный header был полтора мегабайта весом.
Тайные знания в том, что именно, что переключает и от чего зависит. Без исходников все эти макросы - просто мешанина кода. Генерация всю информацию о происхождении макросов убирает.
Всё верно, но кроме вот таких глобальных переключений в серьёзный embedded проектах есть ещё куча копиляторо0заивисмых настроек, библиотеко-зависимых (мы можем собираться с различными libc/libc++ библиотеками), toolchain-зависмых (привет всем этим китайским колхозным системам сборки), ОС-зависимых, и ещё чёрте-от-чего-зависмых настроек. Выносить всё это в глобальные макросы не нужно, так как на практике это очень редко меняется (только при портировании на новую платформу/окружение). А ещё если из одного дерева исходников собираются сильно разные вещи, то возникает здоровое желание переключать глобальные настройки удобным образом в исходниках, чтобы это было лучше видно в системе контроля версий.
Поэтому в нормальных проектах делают три уровня абстракций:
- высокоуровневые макросы, задаваемые через настройки компилятора;
- высокоуровневые макросы и настройки в заголовках, которые переключают какие-то совершенно глобальные вещи, которые нужно править или менять только при портировании на новое железно или окружение или при создании каких-то новых программ на основе того же дерева исходников;
- низкоуровневые макросы, которые завязаны на предыдущие два уровня и проверяют/определяют/настраивают кучу макросов, которые в дальнейшем уже непосредственно влияют на условную компиляцию в файлах исходный текстов кода.
Именно так построены все серьёзные проекты от самого GCC/CLANG, до всех портов libc, и ядра Linux.
И задать всё через макросы, определяемые ключами компилятора, просто не возможно: будет куча мусора и тайных знаний при совершенно шаманской финальной структуре макросов.
А как вы условную сборку своим массивов структур сделаете?
Извините, но это лютейший бред. Конфигурация настраивается в хедерах, а переключается настройками компилятора (объявлением макросов). Сугубо потому, что хедеры уже могут изменять структуру C-файлов, вплоть до отключения/подключения целых наборов файлов.
Проблема не в софте. Софт продавцы поставят. А вот как физически они оплату от ВТБ получат, с которым даже китайцы дел иметь не хотят?
На теслах переключатель передач, это второстепенное устройство, не влияющее примерно ни на что.
Таки раньше электронные тормоза могли подключаться только по независимой шине с односторонними шлюзами (которые физически ничего не могли передавать на эту шину). Как сейчас не знаю
Их отлично сдают в аренду, но там проблема в дровах для виртуализации. Профессиональные серии можно делить не несколько независмых видеокарт, лего пробрасывать в контейнеры и прочие фишки.