Самое любопытное. На работе был "неубиваемый" Panasonic CF-"не помню точно индекс". Так он быстро сломался, не смотря на заявленную прочность. Вопрос везения...
У меня самый неубиваемый ноутбук был Acer Aspire 5520. Но это скорее исключение. Повезло с экземпляром. Даже АКБ не в 0 умерла, а поддерживала к концу использования около 40 минут работы.
Как новая версия для baremetal? Раньше тоже использовал этот экспериментальный плагин, но начиная с какого-то версии стал "отпадать" отладчик,. Но это было терпимо до момента, когда консольное приложение с ncurses стало невозможно отлаживать в версиях 9 и 10. Пришлось искать альтернативу.
Про это я знаю. С этого начиналась ветка. Про то что при объявлении литерала как неизменного массива на стекле будет всегда происходить копирование - не задумывался. Теперь буду это учитывать.
Много статей читал, какие эффективные сейчас компиляторы. Думал, что если строковой литерал не меняется в функции, то будет исключено лишнее копирование. Заблуждался. Буду знать, и сам за счёт ключевых слов заботиться о исключении копирования, где это не требуется.
В принципе всё логично. Если мы хотим при каждом вызове функции иметь её первоначальное состояние, по придётся каждый раз копировать. Хоть из секции данных, хоть инструкциями кода. Избежать копирования невозможно.
Если строка увеличивается, то она переезжает в секцию инициализированных данных, но используются инструкции копирования (clang вызывает memcpy, а gcc использует команды копирования с префиксом rep).
Модификатор static независимо от длины строки использует секцию инициализированных данных и прямое обращение без копирования.
Задумался, возможно стоит для строковых литералов, инициализируемых внутри функции всегда использовать static...
Извините, но как оно попадёт в стек как не из области инициализированных данных секции .data ?
Я обязательно проверю это. Моё предположение, что в стеке функции будет указатель на начало массива, инициализированный числом из секции .data. Не думаю что будет копирование данных.
В языке Си изначально не было специального типа bool. Программист в праве выбрать любой тип в зависимости от архитектуры, скорости/компактности хранения данных.
Вы правы. Как раз const char *str позволит выловить ошибку на этапе компиляции, а не выполнения. Хотя скорее всего будет предупреждение, что char *str писать можно, но не нужно.
Массив символов скорее всего будет не в стеке, а в области инициализированных данных. А указатель на массив может быть как глобальной переменной. Так и в стеке локальной области видимости.
Справедливости ради, в той же ОС "Linux" константы (например, строковые литералы) размещаются в защищенных от записи страницах памяти. Обращение к ним может привести к ошибкам сегментации. Как я понимаю, это позволяет при запуске нескольких экземпляров одного процесса использовать общие данные без риска их повреждения.
Интерфейс 485 вполне не плох. Протоколов по нему огромное количество. Ваш протокол - не плохая задумка. К сожалению, куча производителей лепят что хотят. Встречал такие варианты, когда не было контрольной суммы и не использовались даже биты четности (приходилось данные прогонять через медианный фильтр для исключения некорректных данных, вызванных помехами).
Создавал свой протокол, который мог пройти через трансформаторную развязку. Приходилось подмешивать дополнительные биты, что бы искусственно создать "перемену" (но умудрились в эти избыточные биты фактически поместить аналог контрольной суммы). Позже перешли на оптику.
Качество реализации 485 тоже разное. Для проверки используем мощный пускатель, плохой (крайне шумный) частотник и сломанную пьезозажигалку (бьём по контактам). Бывает именитые фирмы не выдерживают проверок, а "самоделки" отделываются испугом (отбрасывают сбойный пакет).
Самое любопытное. На работе был "неубиваемый" Panasonic CF-"не помню точно индекс". Так он быстро сломался, не смотря на заявленную прочность. Вопрос везения...
У меня самый неубиваемый ноутбук был Acer Aspire 5520. Но это скорее исключение. Повезло с экземпляром. Даже АКБ не в 0 умерла, а поддерживала к концу использования около 40 минут работы.
Как новая версия для baremetal? Раньше тоже использовал этот экспериментальный плагин, но начиная с какого-то версии стал "отпадать" отладчик,. Но это было терпимо до момента, когда консольное приложение с ncurses стало невозможно отлаживать в версиях 9 и 10. Пришлось искать альтернативу.
Если эта модель снабжена микрофоном, то она запишет свою работу.
Вы правы, если речь о C++. Там тип bool так сказать, с рождения.
Но в Си (без плюсов) тип _Bool появился как дополнительный в стандаре C99.
И он является расширением, доступным при подключении
<stdbool.h>.Понял. Я был не прав. Для меня программирование это хобби. Будет стимул изучить эту тему. Даже не буду задавать вопросы про технические подробности.
Вы правы.
Но, в Вашей крайней статье на этом сайте приведён код:
int hash = calc_hash((unsigned char*)argv[1]);if(hash != 152) {char failure[] = "Password is wrong\n";write(1, failure, sizeof(failure));return 1;}char success[] = "Password is right!\n"; write(1, success, sizeof(success));И в коде строковые константные литералы в виде массивов.
Про это я знаю. С этого начиналась ветка. Про то что при объявлении литерала как неизменного массива на стекле будет всегда происходить копирование - не задумывался. Теперь буду это учитывать.
Много статей читал, какие эффективные сейчас компиляторы. Думал, что если строковой литерал не меняется в функции, то будет исключено лишнее копирование. Заблуждался. Буду знать, и сам за счёт ключевых слов заботиться о исключении копирования, где это не требуется.
В принципе всё логично. Если мы хотим при каждом вызове функции иметь её первоначальное состояние, по придётся каждый раз копировать. Хоть из секции данных, хоть инструкциями кода. Избежать копирования невозможно.
Интересная ситуация получается.
Для коротких строк стек заполняется инструкциями.
Если строка увеличивается, то она переезжает в секцию инициализированных данных, но используются инструкции копирования (clang вызывает memcpy, а gcc использует команды копирования с префиксом rep).
Модификатор static независимо от длины строки использует секцию инициализированных данных и прямое обращение без копирования.
Задумался, возможно стоит для строковых литералов, инициализируемых внутри функции всегда использовать static...
И ещё добавлю. Для малых масивов идёт заполнение стека прямо из кода, но для длинной строки (набил пару сотен символов) - вызывается memcpy.
Тоже посмотрел. Идёт копирование. Причём в секции кода.
Извините, но как оно попадёт в стек как не из области инициализированных данных секции .data ?
Я обязательно проверю это. Моё предположение, что в стеке функции будет указатель на начало массива, инициализированный числом из секции .data. Не думаю что будет копирование данных.
В языке Си изначально не было специального типа bool. Программист в праве выбрать любой тип в зависимости от архитектуры, скорости/компактности хранения данных.
Вы правы. Как раз
const char *str позволит выловить ошибку на этапе компиляции, а не выполнения. Хотя скорее всего будет предупреждение, что char *str писать можно, но не нужно.Массив символов скорее всего будет не в стеке, а в области инициализированных данных. А указатель на массив может быть как глобальной переменной. Так и в стеке локальной области видимости.
Справедливости ради, в той же ОС "Linux" константы (например, строковые литералы) размещаются в защищенных от записи страницах памяти. Обращение к ним может привести к ошибкам сегментации. Как я понимаю, это позволяет при запуске нескольких экземпляров одного процесса использовать общие данные без риска их повреждения.
Интерфейс 485 вполне не плох. Протоколов по нему огромное количество. Ваш протокол - не плохая задумка. К сожалению, куча производителей лепят что хотят. Встречал такие варианты, когда не было контрольной суммы и не использовались даже биты четности (приходилось данные прогонять через медианный фильтр для исключения некорректных данных, вызванных помехами).
Создавал свой протокол, который мог пройти через трансформаторную развязку. Приходилось подмешивать дополнительные биты, что бы искусственно создать "перемену" (но умудрились в эти избыточные биты фактически поместить аналог контрольной суммы). Позже перешли на оптику.
Качество реализации 485 тоже разное. Для проверки используем мощный пускатель, плохой (крайне шумный) частотник и сломанную пьезозажигалку (бьём по контактам). Бывает именитые фирмы не выдерживают проверок, а "самоделки" отделываются испугом (отбрасывают сбойный пакет).
Легко, если калькулятор с поддержкой мат. анализа (типа maple, maxima). Но если таким уметь пользоваться, то это только плюс.