поэтому 6 битный Packed ASCII вполне себе удовлетворял этому требованию
Нет, не удовлетворял и не мог удовлетворять в принципе. Сколько раз ещё повторить про CHAR_BIT и его минимальный размер? И я привёл ссылку из C++98. Слишком старо? Боитесь несовместимых изменений? Вот C++17:
21.3.5 Header synopsis
The header defines all macros the same as the C standard library header <limits.h>.
— Никуда декларация совместимости с Си не делась. Даже более того, добавили:
See also: ISO C 5.2.4.2.1
— Прямая отсылка в стандарт Си. И я этот раздел даже цитировал в предыдущем сообщении!
Поэтому логично сказать, что sizeof возвращает размер в символах, а не в байтах, так как обычно под байтом в программировании (а не стандартом С++) подразумевается 8 бит, а символ может быть практически любого размера.
Сочувствую тем, кто считает байт 8-битным, а ещё больше их окружению: они опасны в своём заблуждении.
Байт — это упорядоченный набор бит, минимально адресуемая ячейка. Без какого либо ассоциированного типа! А char — это символ (а по совместительству ещё и целое число). И по обоим стандартам символ занимает одну ячейку хранения, строго. Причём строго то только по историческим причинам: «нет языка кроме английского».
Не нахожу логики в измерениях места, занимаемыми объектами, ничего общего не имеющего с символами в символах.
Да и чему эта демагогия? Вы утверждали
И кстати sizeof возращает размер не в байтах
Что я опроверг цитатами из стандартов: и для Си, и для Си++. Стандарты чётко определяют, что в байтах. И ничего придумывать больше не надо.
Specializations of the standard library template std::numeric_limits (21.3) shall specify the maximum and minimum values of each arithmetic type for an implementation.
Единственно, что сказано, что максимальное и минимальное значение должно быть определено в стандартной библиотеке под конкретную реализацию.
Что ж вы снова не дочитали секцию 21.3, отсылку к которой приводит ваша же цитата? И там не только для целых, но для типов с плавающей запятой, вот прямо в самом конце:
The header defines all macros the same as the C standard library header <float. h>.
See also: ISO C 5.2.4.2.2
И я этот раздел, опять же, даже цитировал в предыдущем сообщении!
Ещё раз: Си++ родился как надстройка над Си (изначально это был препроцессор), но со временем из-за разногласий групп стандартизации, языки разошлись немного. Тем не менее, Си++ поддерживает бинарную совместимость с Си: вот в виде этих вот отсылок к лимитам базовых типов и via extern "C". Без этого Си++ не смог бы использовать огромный корпус уже написанного кода на Си.
например — posit, bfloat16 или minifloat.
Типы есть, но если они не влезают в минимальные указанные стандартом границы, то они не могут быть соответствующим типом в стандартном Си. Вот хоть ты тресни, но не влезут 16 и 24 битные float в необходимый минимум.
Стандарт и на Си то огромен, а на Си++ в три раза больше — читать не перечитать, а уж освоить все тонкости — это ещё труднее. Вот это то и есть главная проблема этих языков.
P.S. Даже Markdown парсер на Хабре устал и сломался .)
Для char — сказано напрямую, для остальных типов вычисляется по лимитам значений. Из разделов 3.5 и 3.6 следует, что биты у нас только и исключительно двоичные.
Не верите, что C++ наследует значительный корпус C?
C++98 18.2.2 C Library
The contents are the same as the Standard C library header <limits.h>.
Неожиданно. В стандарте не просто повторили пределы из стандарта Си, дак ещё и сказали, что они точно такие же, как в Си (логично, это обещает бинарную совместимость).
Вы неправы.
char — это модель байта в данной системе. Чисто теоретически на 4-битной машине или 7-битной байт может быть и 4 бита и 7 бит
Не может, CHAR_BIT по стандарту не меньше 8 бит. И это зафиксировано в первом стандарте C89, никуда не делось и в последующих и перекочевало в С++.
И кстати sizeof возращает размер не в байтах, в традиционном представлении, а в количестве char.
Неправда, sizeof возвращает размер в байтах:
C99 3.6 byte — addressable unit of data storage large enough to hold any member of the basic character set of the execution environment
C99 3.7.1 single-byte character — bit representation that fits in a byte
C99 6.5.3.4 The sizeof operator — The sizeof operator yields the size (in bytes) of its operand...
— и в Си
C++98: 1.7 The C++ memory model
The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set and is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Every byte has a unique address.
5.3.3 Sizeof
The sizeof operator yields the number of bytes in the object representation of its operand.
— и в Си с двумя плюсами.
то sizeof(char) == 1
А это я написал в комментарии, на который вы отвечаете.
А вот для float и double — тут вообще ничего не определено.
Как же не определено:
C99 5.2.4.2.2 Characteristics of floating types <float.h>
The values given in the following list shall be replaced by constant expressions with implementation-defined values that are greater or equal in magnitude (absolute value) to those shown, with the same sign:
FLT_DIG 6
DBL_DIG 10
LDBL_DIG 10
— Да, не говорят, в каком точно формате должно храниться, но что мантисса для float должна вмещать не менее 6 десятичных цифр — говорят. Там же сказано, что десятичная экспонента должна вмещать значения от -37 до +37.
При двоичном представлении для мантиссы из 6 десятичных цифр нужно как минимум 20 бит, для 10 — 34; для экспоненты — 8 бит. Плюс бит на знак. Итого минимум 29 бит на float при двоичном представлении, 43 для double и long double. При BCD формате требования будут выше.
Так что да, не 32 и 64, но и вполне определена минимальная точность. Это я спутал с другой частью:
C99 Annex F (normative) IEC 60559 floating-point arithmetic
— Вот тут уже полное соответствие IEEE 754, IEEE 854. Будем теперь знать, что это не требование...
Поэтому в микроконтроллерах float может и 24 бита — PIC16 и PIC18 компиляторы не дадут соврать. А double поголовно 32 бита по умолчанию на том же IAR компиляторе под все 8 битные и 16 битные микроконтроллеры.
И, как видно по цитатам из стандарта, это не Си. И если вы вынуждены разрабатывать под такую платформу, то в первую очередь нужно выяснить отличия от стандартного Си. (Для PIC16, вот, я вижу с ходу AN575 «IEEE 754 Compliant Floating Point Routines», где «Routines for the PIC16/17 families are provided in a modified IEEE 754 32-bit format together with versions in 24-bit reduced format.»)
При переносе кода с одного микроконтроллера на другой, особенно, если структурки переносятся — такая ерунда иногда приключается, если всех этих тонкостей не знать и использовать базовые типы без указания размера грубо говоря запрещено.
Ну дак нужно для начала первые главы стандарта прочитать, чтобы понимать, на каком языке писать. А потом «особенности» целевой платформы изучить. (Для платформ с кривым компилятором все эти char/short/int/long заменяются sed'ом на специфические типы в одну команду. Но м)
Поэтому это хорошее правило от МИСРЫ и полезное, оно не просто так было сделано.
Ограниченно полезное. Оно помогает разработчикам, которые неспособны прочитать документацию на инструмент, которым работают. Ну, если пытаться масштабировать разработку человеко-часами и для ускорения разработки нанимать больше народа… тогда да, это полезное правило, чтобы не угробить весь проект.
Ну а если у нас не сырые джуниоры, то это плохое правило, ломающее переносимость кода, написанного на Си. На настоящем Си.
MISRA a top coding standard for embedded industries, including automotive
Не нужно натагивать правила из embedded (даже его части) на весь остальной мир. Ну а правила, диктующие, что при ложном срабатывании нужно переделывать корректный код, чтобы удовлетворить кривой чекер...
Да, там есть интересные правила, из которых есть что позаимствовать (но, опять же, в зависимости от целевой области — разные множества).
И еще одно удобство, что если ваша система не поддерживает int32_t или int8_t, например, то как миниму код не должен скомпилироваться.
Отличное удобство. Для проекта на несколько файлов — может быть. А для проекта на 30К файлов это так себе. Гораздо удобнее, когда всё это хозяйство просто компилируется на новой платформе стандартным Си и работает.
А так вы взяли int, предполагаю, что он у вас 32 бит, но на одной машине он 16 бит,
Вот только не надо снова мне приписывать ваших ошибок. Я уже на это отвечал.
Дополнение: Про то, что в int влезет как минимум 16 бит я не забуду никогда (слишком много раз перечитывал стандарт, видимо), да и опыт немалый был работы на Си на 8-ми и 16-битных платформах. А вот про то, что на POSIX платформе в int влезет 32 — постоянно забываю (благо один POSIX.1 больше C99 в двадцать раз).
P.S. Если мы говорим Си без дополнения, то с 90-го года подразумеваем ISO/IEC 9899. Если мы говорим Си++, то с 98-го года подразумеваем ISO/IEC 14882. О странных отклонениях я ничего в комментариях выше не писал.
Дополнение: всё вышесказанное не значит, что не нужно использовать фиксированные типы никогда — если мы принимаем некоторые ограничения на целевую платформу, то они вполне себе удобны.
Так, я для криптографии (внутри, но не на уровне API) их использую и необходимость переноса на гипотетическую 36-битную платформу потребует дополнительной работы пересмотреть код, но пока этого не случилось, можно упростить себе жизнь.
К таким ограниченным платформам относится часто и системное программирование уровня ядра ОС: если в ОС принято использовать u8, u16, u32, u64, то нужно их и использовать (но только для того, для чего они предназначены).
Т.е. в случае если вы просто int указали и используете его для всего диапазона значений для 32 битного int
То вы совершили ошибку, очевидно же. Не нужно так делать. (Если мы про Си, а не про POSIX.) У стандартных типов есть минимальные размеры:
char — 8 бит;
short — 16 бит;
int — 16 бит;
long — 32 бита;
long long — 64 бита;
float — 32 бита;
double — 64 бита;
long double — 64 бита.
и граничные значения:
signed char — от -127 до +127;
short — от -16383 до +16383;
и т.д.
Заметьте, что не -128 и не -16384, так знак может быть представлен разными способами.
Ну тогда надо явно указать int_least32_t — теперь везде будет 32 бита или больше.
Если это вам нужно, то да. В текущих реалиях единственная причина использовать least типы как раз в использовании int_least32_t вместо long, чтобы на 64-bit SysV ABI сэкономить место. (И тут нужно ещё подумать, а нужно ли экономить.)
int_least8_t и int_fast8_t
Вот в случае ARM до StrongARM одним из способов для int_least16_t и int_fast16_t будет выделение для них 16 и 32-битных ячеек: в первом случае медленно побайтово загружаем/сохраняем и собираем/разделяем сдвигами и экономим память, во втором просто используем машинное слово и ценой памяти получаем быстрые операции.
Ну и дополнение: всё ещё зависит от целевой платформы, для которой пишется код. Это может быть C89 (да, не все компиляторы до сих пор умеют C99), C99, C11 (C++98, C++03, C++11, C++14, C++17 — что там ещё есть?). А может быть POSIX, который не поддерживает 16-битные платформы в принципе — для него ограничения на обсуждаемые типы такое же, как в Си, за исключением, что int не меньше 32 бит. (То есть UNIX V7 на PDP11 и XENIX на 286 никогда не сделать POSIX системами, не сломав ABI.)
P.S. Всё вышесказанное относится к значащим битам, ещё могут быть неиспользуемые для вычислений, в которых можно хранить дополнительную информацию, но это уже сильно платформенно-зависимо.
P.P.S. В общем, не имеет смысла использовать int_least8_t — он не может быть меньше char никогда (sizeof char = 1, по определению), и вместо него всегда использовать signed char (char может быть как signed, так и unsigned по умолчанию — артефакт долгого развития языка до стандартизации). Аналогично с 16-битными типами: все эти least-типы для 8 и 16 просто для унификации существуют. А fast 8 и 16 практически всегда можно заменить на int в современных реалиях.
This rule helps to clarify the size of the storage,
Именно, что «helps». Разве оно там требование? При этом требования к памяти прекрасно рассчитываются для конкретной платформы и с обычными char, short, int, long… Вообще, многие требования и рекомендации MISRA, мягко говоря, весьма спорны.
but does not guarantee portability
Именно. Очень всё весело становится, когда на целевой платформе не оказывается int8_t, int16_t, int32_t, int64_t — все эти типы необязательны по стандарту (в C точно, для C++ нужно уточнить).
На каком-нибудь современном DSP запросто могут быть 32-битные char, short и int и никаких int8_t и int16_t. Да даже ARM до StrongARM не умел загружать/сохранять 16-битные значения (но можно было эмулировать с помощью сдвигов и побайтовых load/store).
Тип int такой не просто так — именно это позволило UNIX спокойно работать на 16, 18, 32 и 36-битных машинах уже на заре своего становления.
(NOTE: 9, 12, 18, 36-битные слова занимают цело число 8-ричных разрядов.)
Так как это счетчик, то скорее всего тип должен size_t.
В общем случае — да, но в конкретном случае 2¹⁵ — 1 на 16-битной машине может быть недостижимо большим, как и 2³¹ — 1 на 32-битной и даже на 64-битной. Всё зависит от предметной области. (Например, размер квадратной матрицы, хранящей 4-байтные значения.) Так что попытка ругать разработчика приведёт только к справедливому отторжению такого инструмента статического анализа.
Итого: нет, наоборот, не стоит использовать типы фиксированной размерности без крайней необходимости. Для индексации потенциально «бесконечных» множеств — size_t, для расчётов ≥ int, для хранения ≥ char (если char как целое, то обязательно с указанием signed/unsigned).
Не стоит преобразовывать явно возвращаемое значение malloc — это Си, а не Си++, и здесь void * приводится к любому указателю: void * для этого и придуман.
Не стоит в данной конструкции использовать sizeof(int), конструкция sizeof(*ptr_one) уменьшает число точек отказа при поддержке кода.
Например, при смене типа переменной (int * на long * — как вариант), если выполнить пункты выше — вся конструкция останется валидной. (А лучше, если здесь будет указатель на структурный объект.)
Если оставить как есть, то рано или поздно кто-нибудь да забудет исправить размер выделяемой памяти, а явное преобразование типа запретит умному компилятору выдать предупреждение об этом (так как явное преобразование — это «делай как я сказал» в Си).
Хорошее замечание: простой алгоритм не работает даже для английского. И особенно для английского. Есть же ещё и одинарные кавычки и футы и они тоже должны заменяться. (Минуты и секунды сюда же.)
В качестве быстрого решения могу предложить только двойную замену: символ «"» непосредственно после целого числа заменять на double prime, а потом на двойную кавычку. Отмена (undo, backspace) отменяет последнюю автозамену. Аналогично для одинарной кавычки.
Что-то большее только с более глубоким анализом контекста.
Проблема в том, что когда рассуждает рынок, меньшинство неизбежно оказывается вышвырнуто на обочину.
Ну, тут только два варианта: либо привыкать, либо изготавливать самому для себя, ли по заказу. С соответствующей ценой.
У меня, например, обратная проблема — мне этот блок мешает:
я бы давно купил себе новый ThinkPad 15", если бы на нём не появился ненужный (и сильно мешающий) numpad. Даже два купил бы уже за эти годы, но Lenovo не хочет моих денег.
И вообще уже склоняюсь к заказному ноутбуку (как минимум, ранее, были такие сервисы).
Не хочется в один прекрасный день обнаружить, что рынок решил полностью избавиться от цифровых блоков, а что десятку гиков он необходим, никого не волнует.
Мой опыт общения с людьми из нетехнической сферы даёт основания утверждать, что цифровые блоки будут жить и далее: как минимум, бухгалтера их очень любят и без них страдают.
Буду вам благодарен, если подскажите, как, например, назначить клавише с цифрой 1 (рис. выше) сочетание клавиш «Ctrl+Shift+Space» (используется в Word)
Под MS Windows — не подскажу, под X11 — возможно помогут xmodmap или xkb, хотя я не уверен, что они справятся с такой специфической задачей. Вам нужно устанавливать глобальную «горячую клавишу» (это Win32 API умеет), а потом генерировать fake keyboard event. Второе можно реализовать ища окно с фокусом ввода и посылая сообщение ему.
UPD: Вон, вам уже подсказали — autohotkey.
Увы, я не программист и мой возраст не позволяет надеяться на то, что я им стану.
Не думаю, что это настолько сложно. Вот, я нашёл, что это такое и заглянул в AutoHotkey Beginner Tutorial и вашу задачу должен выполнять следующий скрипт:
1::
Send, ^+{Space}
return
Сохраняем в файле test.ahk, двойной клик на нём и должно работать. Но проверить мне не на чем, за сим оставляю эту задачу вам, ли другим помощникам.
Если MS Word не отключает автозамену при выборе стиля «Preformatted», то это основание для оформления ошибки, так как автозамена часть форматирования. Если такого стиля нет в стандартном наборе стилей — это другое основание для оформления feature request.
По-моему, в современном мире процессор текстов должен уметь оформлять тексты программ наиболее распространённых языков программирования. Если MS Word этого ещё не умеет — печально.
В общем, плохая автозамена в MS Word (если она такова) — это проблема плохой реализации в MS Word, а не проблема изначального тезиса.
P.S. У MS Word и его клонов есть гораздо более серьёзная ошибка: панель выбора лигатуры, размера и начертания на месте панели выбора стиля параграфа. В результате имеем отвратительное оформление документов.
Вы почему-то уцепились за один конкретный пример, хотя я их привёл несколько.
Я всего лишь поправил один из примеров и никак не спорил с прочим текстом. Да не вижу смысла спорить: я такими комбинациями/приложениями не пользуюсь, у меня таких проблем нет.
Вы почему-то уцепились
Нет уж, это вы уцепились и решили заменить пример на другой, который меня никак не касается и не особо интересен. Я лишь дополнил, что это не проблемы наличия или отсутствия цифрового блока клавиатуры. Так что пример некорректный.
Ну а лично моё мнение по вопросу статьи описано чуть выше в другом комментарии:
Ну а по теме статьи, делаем три варианта: с numpad, без него и отдельный numpad — и все довольны (и рынок рассудит).
Разные. Текст в моём понимании, если нет дополнений, это текст на естественном человеческом языке. Ну а для текстов программ, как и многие, использую разговорное «код». По мне, текст программ по структуре гораздо ближе к математическим формулам (если не совпадает с ними), а набор формул мне трудно называть текстом (как, полагаю, и многим).
Так что да, у нас проблема разных диалектов русского языка.
P.S. А для кода многие пользуются другим типом автозамены — автоформатированием согласно выбранному стилю. (Здесь лично я использую только автоотступы с нужным заполнением, в зависимости от проекта.)
Ну, лично мне никто пока не мешает их отобрать и использовать так, как я хочу. Или, если нужна совместимость, использовать комбинации.
Впрочем, лично я давно этими клавишами практически не пользуюсь (лишь изредка, запуская MC): Compose решает большинство моих проблем ввода. (Поверхностный поиск обнаружил WinCompose — может, будет полезно Windows-пользователям.)
Ну а для функциональных действий есть xbindkeys, если мало функциональности, предоставляемой DE (Desktop Environment).
Современные редакторы достаточно умны, чтобы различать режимы ввода. Для тех, кому не нравится, конечно, нужно предоставить возможность отключения автозамены. Но для большинства пользователей она всё же полезна: больно смотреть на текст с дефисом на месте тире, а большинство пользователей никогда не запомнят разницы, увы — это для них лишняя информация. То же самое с кавычками.
Если автозамена слишком часто ошибается — это плохая автозамена и она не нужна. Если в подавляющем числе случаев она справляется — она полезна.
отключаю всю автозамену во всяких Punto Switcher’ах
Эм, а как можно отключить автозамену в этом странном искажителе ввода, если вся его суть и есть в автозамене? (Может, конечно, что-то изменилось за более, чем полтора десятка лет, когда я его в первый и последний раз пробовал, поматерился и убил.)
А это уже, очевидно, проблема этого почтового клиента. (Можете им feature request написать.)
А также это проблема ОС, не предоставившей отдельных кодов для zoom in и zoom out и комбинаций для их генерации. Вот в расширении для X11 от XFree86 они есть:
#define XF86XK_ZoomIn 0x1008FF8B /* zoom in view, map, etc. */
#define XF86XK_ZoomOut 0x1008FF8C /* zoom out view, map, etc. */
— Расширение прошлого века, если не ошибаюсь. Ну и в X.Org, референсной реализации X11, они есть.
чтобы на клавах было несколько программируемых на любую функцию кнопок
Неожиданно, но они там есть: называются функциональными. Именно для того, что вы хотите они и предназначались. Ныне многие порываются их удалить, сатрапы! А вот то, что ваша ОС не предоставляет такого механизма — это другой вопрос. (А может и предоставляет, но мы об этом просто не знаем.)
Ещё совсем недавно и с вводом русского языка вообще были проблемы во многих приложениях, о чём вы? Вся локализация достигается большой болью. Думаете почему буква «ё» редко применяется в печати (кроме детских изданий)? А всё просто: в наборной кассе (импортируемой из Франции) не хватило места — букв в русском в те времена было больше, чем во французском. Ну а что должно быть «е» или «ё» грамотному человеку в большинстве случаев понятно даже без контекста. Так и повелось. (Ну а само рождение буквы «ё» — это отдельная история.)
удобнее использовать пару кодов 147–148 с альтом чем запоминать нижную начальную как альт плюс 132
Я, вот, даже не сразу понял, что вы про мучения ввода символов по их кодам, хотя пользовался когда-то давно ещё в DOS и ранних Windows этим костылём и, более того, на эту тему отвечал тут несколько минут назад.
Для меня боль — это жизнь без Compose, где все эти символы вводить можно гораздо проще и без увода рук с основного положения. (А ещё можно самому настроить комбинации: если хочется — вставлять целые фразы, целые предложения парой нажатий клавиш.)
Ну а кавычки, тире… человек вообще не должен думать об этом, это дело для автозамены: вполне логично в режиме набора текстов «"» на левой границе слова заменять на правильную левую кавычку для текущего языка, а на правой границе слова — на правую; можно учитывать вложенность кавычек; дефис, отделённый пробелами заменять на тире. И так далее. Насколько я помню, в MS Word это было ещё в прошлом веке и, если не понравилась автозамена, то Ctrl-Z.
Нет, не удовлетворял и не мог удовлетворять в принципе. Сколько раз ещё повторить про CHAR_BIT и его минимальный размер? И я привёл ссылку из C++98. Слишком старо? Боитесь несовместимых изменений? Вот C++17:
Это голословное утверждение.
А вы не думайте, а проверте, если не верите:
Для char — сказано напрямую, для остальных типов вычисляется по лимитам значений. Из разделов 3.5 и 3.6 следует, что биты у нас только и исключительно двоичные.
Не верите, что C++ наследует значительный корпус C?
Неожиданно. В стандарте не просто повторили пределы из стандарта Си, дак ещё и сказали, что они точно такие же, как в Си (логично, это обещает бинарную совместимость).
Вы неправы.
Не может, CHAR_BIT по стандарту не меньше 8 бит. И это зафиксировано в первом стандарте C89, никуда не делось и в последующих и перекочевало в С++.
Неправда, sizeof возвращает размер в байтах:
— и в Си
— и в Си с двумя плюсами.
А это я написал в комментарии, на который вы отвечаете.
Как же не определено:
— Да, не говорят, в каком точно формате должно храниться, но что мантисса для float должна вмещать не менее 6 десятичных цифр — говорят. Там же сказано, что десятичная экспонента должна вмещать значения от -37 до +37.
При двоичном представлении для мантиссы из 6 десятичных цифр нужно как минимум 20 бит, для 10 — 34; для экспоненты — 8 бит. Плюс бит на знак. Итого минимум 29 бит на float при двоичном представлении, 43 для double и long double. При BCD формате требования будут выше.
Так что да, не 32 и 64, но и вполне определена минимальная точность. Это я спутал с другой частью:
— Вот тут уже полное соответствие IEEE 754, IEEE 854. Будем теперь знать, что это не требование...
И, как видно по цитатам из стандарта, это не Си. И если вы вынуждены разрабатывать под такую платформу, то в первую очередь нужно выяснить отличия от стандартного Си. (Для PIC16, вот, я вижу с ходу AN575 «IEEE 754 Compliant Floating Point Routines», где «Routines for the PIC16/17 families are provided in a modified IEEE 754 32-bit format together with versions in 24-bit reduced format.»)
Ну дак нужно для начала первые главы стандарта прочитать, чтобы понимать, на каком языке писать. А потом «особенности» целевой платформы изучить. (Для платформ с кривым компилятором все эти char/short/int/long заменяются sed'ом на специфические типы в одну команду. Но м)
Ограниченно полезное. Оно помогает разработчикам, которые неспособны прочитать документацию на инструмент, которым работают. Ну, если пытаться масштабировать разработку человеко-часами и для ускорения разработки нанимать больше народа… тогда да, это полезное правило, чтобы не угробить весь проект.
Ну а если у нас не сырые джуниоры, то это плохое правило, ломающее переносимость кода, написанного на Си. На настоящем Си.
Не нужно натагивать правила из embedded (даже его части) на весь остальной мир. Ну а правила, диктующие, что при ложном срабатывании нужно переделывать корректный код, чтобы удовлетворить кривой чекер...
Да, там есть интересные правила, из которых есть что позаимствовать (но, опять же, в зависимости от целевой области — разные множества).
Отличное удобство. Для проекта на несколько файлов — может быть. А для проекта на 30К файлов это так себе. Гораздо удобнее, когда всё это хозяйство просто компилируется на новой платформе стандартным Си и работает.
Вот только не надо снова мне приписывать ваших ошибок. Я уже на это отвечал.
Дополнение: Про то, что в int влезет как минимум 16 бит я не забуду никогда (слишком много раз перечитывал стандарт, видимо), да и опыт немалый был работы на Си на 8-ми и 16-битных платформах. А вот про то, что на POSIX платформе в int влезет 32 — постоянно забываю (благо один POSIX.1 больше C99 в двадцать раз).
P.S. Если мы говорим Си без дополнения, то с 90-го года подразумеваем ISO/IEC 9899. Если мы говорим Си++, то с 98-го года подразумеваем ISO/IEC 14882. О странных отклонениях я ничего в комментариях выше не писал.
Дополнение: всё вышесказанное не значит, что не нужно использовать фиксированные типы никогда — если мы принимаем некоторые ограничения на целевую платформу, то они вполне себе удобны.
Так, я для криптографии (внутри, но не на уровне API) их использую и необходимость переноса на гипотетическую 36-битную платформу потребует дополнительной работы пересмотреть код, но пока этого не случилось, можно упростить себе жизнь.
К таким ограниченным платформам относится часто и системное программирование уровня ядра ОС: если в ОС принято использовать u8, u16, u32, u64, то нужно их и использовать (но только для того, для чего они предназначены).
То вы совершили ошибку, очевидно же. Не нужно так делать. (Если мы про Си, а не про POSIX.) У стандартных типов есть минимальные размеры:
и граничные значения:
Заметьте, что не -128 и не -16384, так знак может быть представлен разными способами.
Если это вам нужно, то да. В текущих реалиях единственная причина использовать least типы как раз в использовании int_least32_t вместо long, чтобы на 64-bit SysV ABI сэкономить место. (И тут нужно ещё подумать, а нужно ли экономить.)
Вот в случае ARM до StrongARM одним из способов для int_least16_t и int_fast16_t будет выделение для них 16 и 32-битных ячеек: в первом случае медленно побайтово загружаем/сохраняем и собираем/разделяем сдвигами и экономим память, во втором просто используем машинное слово и ценой памяти получаем быстрые операции.
Ну и дополнение: всё ещё зависит от целевой платформы, для которой пишется код. Это может быть C89 (да, не все компиляторы до сих пор умеют C99), C99, C11 (C++98, C++03, C++11, C++14, C++17 — что там ещё есть?). А может быть POSIX, который не поддерживает 16-битные платформы в принципе — для него ограничения на обсуждаемые типы такое же, как в Си, за исключением, что int не меньше 32 бит. (То есть UNIX V7 на PDP11 и XENIX на 286 никогда не сделать POSIX системами, не сломав ABI.)
P.S. Всё вышесказанное относится к значащим битам, ещё могут быть неиспользуемые для вычислений, в которых можно хранить дополнительную информацию, но это уже сильно платформенно-зависимо.
P.P.S. В общем, не имеет смысла использовать int_least8_t — он не может быть меньше char никогда (sizeof char = 1, по определению), и вместо него всегда использовать signed char (char может быть как signed, так и unsigned по умолчанию — артефакт долгого развития языка до стандартизации). Аналогично с 16-битными типами: все эти least-типы для 8 и 16 просто для унификации существуют. А fast 8 и 16 практически всегда можно заменить на int в современных реалиях.
Именно, что «helps». Разве оно там требование? При этом требования к памяти прекрасно рассчитываются для конкретной платформы и с обычными char, short, int, long… Вообще, многие требования и рекомендации MISRA, мягко говоря, весьма спорны.
Именно. Очень всё весело становится, когда на целевой платформе не оказывается int8_t, int16_t, int32_t, int64_t — все эти типы необязательны по стандарту (в C точно, для C++ нужно уточнить).
На каком-нибудь современном DSP запросто могут быть 32-битные char, short и int и никаких int8_t и int16_t. Да даже ARM до StrongARM не умел загружать/сохранять 16-битные значения (но можно было эмулировать с помощью сдвигов и побайтовых load/store).
Тип int такой не просто так — именно это позволило UNIX спокойно работать на 16, 18, 32 и 36-битных машинах уже на заре своего становления.
(NOTE: 9, 12, 18, 36-битные слова занимают цело число 8-ричных разрядов.)
В общем случае — да, но в конкретном случае 2¹⁵ — 1 на 16-битной машине может быть недостижимо большим, как и 2³¹ — 1 на 32-битной и даже на 64-битной. Всё зависит от предметной области. (Например, размер квадратной матрицы, хранящей 4-байтные значения.) Так что попытка ругать разработчика приведёт только к справедливому отторжению такого инструмента статического анализа.
Итого: нет, наоборот, не стоит использовать типы фиксированной размерности без крайней необходимости. Для индексации потенциально «бесконечных» множеств — size_t, для расчётов ≥ int, для хранения ≥ char (если char как целое, то обязательно с указанием signed/unsigned).
Порядок поменяли из-за конфликта в грамматике: выражение n=-1 парсилось и как
и как
(пробелы в те далёкие времена не очень жаловали).
Например, при смене типа переменной (int * на long * — как вариант), если выполнить пункты выше — вся конструкция останется валидной. (А лучше, если здесь будет указатель на структурный объект.)
Если оставить как есть, то рано или поздно кто-нибудь да забудет исправить размер выделяемой памяти, а явное преобразование типа запретит умному компилятору выдать предупреждение об этом (так как явное преобразование — это «делай как я сказал» в Си).
Я тоже использую r01 и больше десяти лет. А вы не заметили, что ru-center несколько лет как съел r01? См. https://r01.ru/about/
Хорошее замечание: простой алгоритм не работает даже для английского. И особенно для английского. Есть же ещё и одинарные кавычки и футы и они тоже должны заменяться. (Минуты и секунды сюда же.)
В качестве быстрого решения могу предложить только двойную замену: символ «"» непосредственно после целого числа заменять на double prime, а потом на двойную кавычку. Отмена (undo, backspace) отменяет последнюю автозамену. Аналогично для одинарной кавычки.
Что-то большее только с более глубоким анализом контекста.
Ну, тут только два варианта: либо привыкать, либо изготавливать самому для себя, ли по заказу. С соответствующей ценой.
У меня, например, обратная проблема — мне этот блок мешает:
И вообще уже склоняюсь к заказному ноутбуку (как минимум, ранее, были такие сервисы).
Мой опыт общения с людьми из нетехнической сферы даёт основания утверждать, что цифровые блоки будут жить и далее: как минимум, бухгалтера их очень любят и без них страдают.
Под MS Windows — не подскажу, под X11 — возможно помогут xmodmap или xkb, хотя я не уверен, что они справятся с такой специфической задачей. Вам нужно устанавливать глобальную «горячую клавишу» (это Win32 API умеет), а потом генерировать fake keyboard event. Второе можно реализовать ища окно с фокусом ввода и посылая сообщение ему.
UPD: Вон, вам уже подсказали — autohotkey.
Не думаю, что это настолько сложно. Вот, я нашёл, что это такое и заглянул в AutoHotkey Beginner Tutorial и вашу задачу должен выполнять следующий скрипт:
Сохраняем в файле test.ahk, двойной клик на нём и должно работать. Но проверить мне не на чем, за сим оставляю эту задачу вам, ли другим помощникам.
Если MS Word не отключает автозамену при выборе стиля «Preformatted», то это основание для оформления ошибки, так как автозамена часть форматирования. Если такого стиля нет в стандартном наборе стилей — это другое основание для оформления feature request.
По-моему, в современном мире процессор текстов должен уметь оформлять тексты программ наиболее распространённых языков программирования. Если MS Word этого ещё не умеет — печально.
В общем, плохая автозамена в MS Word (если она такова) — это проблема плохой реализации в MS Word, а не проблема изначального тезиса.
P.S. У MS Word и его клонов есть гораздо более серьёзная ошибка: панель выбора лигатуры, размера и начертания на месте панели выбора стиля параграфа. В результате имеем отвратительное оформление документов.
Я всего лишь поправил один из примеров и никак не спорил с прочим текстом. Да не вижу смысла спорить: я такими комбинациями/приложениями не пользуюсь, у меня таких проблем нет.
Нет уж, это вы уцепились и решили заменить пример на другой, который меня никак не касается и не особо интересен. Я лишь дополнил, что это не проблемы наличия или отсутствия цифрового блока клавиатуры. Так что пример некорректный.
Ну а лично моё мнение по вопросу статьи описано чуть выше в другом комментарии:
Разные. Текст в моём понимании, если нет дополнений, это текст на естественном человеческом языке. Ну а для текстов программ, как и многие, использую разговорное «код». По мне, текст программ по структуре гораздо ближе к математическим формулам (если не совпадает с ними), а набор формул мне трудно называть текстом (как, полагаю, и многим).
Так что да, у нас проблема разных диалектов русского языка.
P.S. А для кода многие пользуются другим типом автозамены — автоформатированием согласно выбранному стилю. (Здесь лично я использую только автоотступы с нужным заполнением, в зависимости от проекта.)
Ну, лично мне никто пока не мешает их отобрать и использовать так, как я хочу. Или, если нужна совместимость, использовать комбинации.
Впрочем, лично я давно этими клавишами практически не пользуюсь (лишь изредка, запуская MC): Compose решает большинство моих проблем ввода. (Поверхностный поиск обнаружил WinCompose — может, будет полезно Windows-пользователям.)
Ну а для функциональных действий есть xbindkeys, если мало функциональности, предоставляемой DE (Desktop Environment).
Гм, я же написал:
Современные редакторы достаточно умны, чтобы различать режимы ввода. Для тех, кому не нравится, конечно, нужно предоставить возможность отключения автозамены. Но для большинства пользователей она всё же полезна: больно смотреть на текст с дефисом на месте тире, а большинство пользователей никогда не запомнят разницы, увы — это для них лишняя информация. То же самое с кавычками.
Если автозамена слишком часто ошибается — это плохая автозамена и она не нужна. Если в подавляющем числе случаев она справляется — она полезна.
Эм, а как можно отключить автозамену в этом странном искажителе ввода, если вся его суть и есть в автозамене? (Может, конечно, что-то изменилось за более, чем полтора десятка лет, когда я его в первый и последний раз пробовал, поматерился и убил.)
А это уже, очевидно, проблема этого почтового клиента. (Можете им feature request написать.)
А также это проблема ОС, не предоставившей отдельных кодов для zoom in и zoom out и комбинаций для их генерации. Вот в расширении для X11 от XFree86 они есть:
— Расширение прошлого века, если не ошибаюсь. Ну и в X.Org, референсной реализации X11, они есть.
Неожиданно, но они там есть: называются функциональными. Именно для того, что вы хотите они и предназначались. Ныне многие порываются их удалить, сатрапы! А вот то, что ваша ОС не предоставляет такого механизма — это другой вопрос. (А может и предоставляет, но мы об этом просто не знаем.)
Ещё совсем недавно и с вводом русского языка вообще были проблемы во многих приложениях, о чём вы? Вся локализация достигается большой болью. Думаете почему буква «ё» редко применяется в печати (кроме детских изданий)? А всё просто: в наборной кассе (импортируемой из Франции) не хватило места — букв в русском в те времена было больше, чем во французском. Ну а что должно быть «е» или «ё» грамотному человеку в большинстве случаев понятно даже без контекста. Так и повелось. (Ну а само рождение буквы «ё» — это отдельная история.)
Я, вот, даже не сразу понял, что вы про мучения ввода символов по их кодам, хотя пользовался когда-то давно ещё в DOS и ранних Windows этим костылём и, более того, на эту тему отвечал тут несколько минут назад.
Для меня боль — это жизнь без Compose, где все эти символы вводить можно гораздо проще и без увода рук с основного положения. (А ещё можно самому настроить комбинации: если хочется — вставлять целые фразы, целые предложения парой нажатий клавиш.)
Ну а кавычки, тире… человек вообще не должен думать об этом, это дело для автозамены: вполне логично в режиме набора текстов «"» на левой границе слова заменять на правильную левую кавычку для текущего языка, а на правой границе слова — на правую; можно учитывать вложенность кавычек; дефис, отделённый пробелами заменять на тире. И так далее. Насколько я помню, в MS Word это было ещё в прошлом веке и, если не понравилась автозамена, то Ctrl-Z.