Скрытые возможности C

Было бы здорово, если бы вы / кто-то отредактировали «вопрос», чтобы указать на выбор лучшие скрытые функции, например, в версиях этого вопроса для C# и Perl.

Я не думаю, что это портативный. Он будет работать на x86, но как насчет других платформ?

Понятия не имею - вы должны задать вопрос по этому поводу

Это хороший метод, и он специфичен для X86 (хотя, вероятно, есть аналогичные методы на других платформах). Однако это не функция C. Это зависит от нестандартных расширений C или вызовов библиотеки.

В GCC есть __builtin_trap и для MSVC __debugbreak, которые будут работать на любой поддерживаемой архитектуре.

Но на самом деле, как часто вам нужно компилировать свой код с помощью другого компилятора?

@Joe D, если это кроссплатформенный проект, такой как Windows / OSX / Linux, возможно, немного, а также есть разные арки, такие как x86 vs x86_64 и т. д.

@JoeD Если только вы не участвуете в очень ограниченном проекте, который счастлив выйти замуж за одного поставщика компилятора, очень. Возможно, вы захотите избежать фактической смены компиляторов, но вы хотите, чтобы эта опция оставалась открытой. Однако со встроенными системами у вас не всегда есть выбор. АГС, АСС.

Я этого не понимаю. Я добавил ссылку, она отображается в превью, но не в финальном посте ...

Это неправильная функция strcpy - эта реализация предполагает, что «to» - это регистр с отображением в память.

@ComSubVie: вы создали ссылку, но еще не создали ее. К ответу нужно добавить что-то вроде этого: «[статья в Википедии] [1] на устройстве Даффа». Лично мне не нравится нотация Markdown для ссылок, я обычно использую теги привязки HTML напрямую.

@ComSubVie, любой, кто использует Устройство Даффа, является скрипачом, который видел Устройство Даффа и думал, что их код будет выглядеть 1337, если они будут использовать Устройство Даффа. (1.) Устройство Даффа не предлагает никакого увеличения производительности на современных процессорах, потому что современные процессоры имеют нулевые накладные расходы зацикливания. Другими словами, это устаревший фрагмент кода. (2.) Даже если ваш процессор не поддерживает цикл с нулевыми накладными расходами, он, вероятно, будет иметь что-то вроде SSE / altivec / vector-processing, что заставит ваше Устройство Даффа посрамить при использовании memcpy (). (3.) Я упоминал еще о том, что выполнение memcpy () duff's бесполезно?

@ComSubVie, познакомься с моим кулаком смерти (en.wikipedia.org/wiki/…)

Это ... УЖАСНО. зачем кому-то делать это с плохим беззащитным кодом?

@Trevor: значит, только скриптовые дети программируют 8051 и микроконтроллеры PIC, верно?

@Trevor Boyd Smith: Хотя устройство Даффа кажется устаревшим, это все еще историческое любопытство, которое подтверждает ответ ComSubVie. Во всяком случае, цитирую Википедию: «Когда многочисленные экземпляры устройства Даффа были удалены с сервера XFree86 в версии 4.0, производительность значительно улучшилась». ...

В Symbian мы однажды оценили различные циклы для быстрого кодирования пикселей; устройство даффа на ассемблере было самым быстрым. Так что сегодня он по-прежнему актуален для основных ядер ARM на ваших смартфонах.

@Trevor: Хотя устройство Даффа может быть устаревшим (это не так), его концепция (разворачивание цикла) - нет.

#pragma Идентификаторы яда GCC Эта директива запрещает использование идентификаторов в программе. Отравленные идентификаторы не могут быть # ifdef'd или # undef'd, и попытка использовать их для чего-либо приведет к ошибке. Идентификаторы - это список, разделенный пробелами.

C поддерживает цепочку, поэтому вы можете сделать a ^ = b ^ = a ^ = b;

Строго говоря, пример состояния - это галочка препроцессора, а не языка C - можно использовать первый без второго.

OJ: на самом деле то, что вы предлагаете, - это неопределенное поведение из-за правил точки последовательности. Он может работать на большинстве компиляторов, но не является правильным или переносимым.

Использование обмена XOR, как правило, плохая идея, в основном потому, что он работает только для целых чисел, а сглаживание может оказаться большой проблемой. Я почти уверен, что большинство компиляторов оптимизируют его, когда возникает проблема с памятью.

Своп Xor может быть менее эффективным в случае бесплатной регистрации. Любой достойный оптимизатор сделает временную переменную регистром. В зависимости от реализации (и необходимости поддержки параллелизма) своп может фактически использовать реальную память вместо регистра (что будет таким же).

пожалуйста, никогда не делайте этого: en.wikipedia.org/wiki/…

Зачем тебе это делать? кроме как вызвать множество серьезных предупреждений статического анализа. Используйте оператор switch case, заключенный в цикл while.

@OJ: Нет, это неопределенное поведение.

Замена XOR не выполняется, если 'a' является псевдонимом 'b'

OJ: Раньше я делал это с GCC ... пока я не попытался скомпилировать небольшой пример для MIPS и потерял много времени на отладку, потому что он компилировался как-то иначе. Как здесь сказали: не определено.

Чтобы решить большинство из них, сделайте эти предположения зависимыми от характеристик вашей платформы и опишите каждую платформу в своем собственном заголовке. Выполнение ордера - исключение - никогда не полагайтесь на это; С другой стороны, каждая платформа требует надежного решения.

@Blaisorblade, еще лучше, используйте утверждения времени компиляции, чтобы задокументировать свои предположения таким образом, чтобы компиляция завершилась ошибкой на платформе, где они нарушены.

Я думаю, что следует комбинировать оба, чтобы ваш код работал на нескольких платформах (это было первоначальное намерение), и если макросы функций установлены неправильно, утверждения времени компиляции поймают это. Я не уверен, можно ли, скажем, предположить, что ABI функции можно проверить как утверждения времени компиляции, но это должно быть возможно для большинства других (действительных) (кроме порядка выполнения ;-)).

Функциональные проверки ABI должны выполняться с помощью набора тестов.

Еще лучше ... char c = 2 ["Привет"]; (c == 'l' после этого).

Не так уж и странно, если учесть, что v [index] == * (v + index) и index [v] == * (index + v)

Пожалуйста, скажите мне, что вы на самом деле не используете это «все время», как задается вопрос!

Эту возможность обычно называют «составными литералами». Анонимные (или безымянные) структуры обозначают вложенные структуры, у которых нет имен членов.

согласно моему GCC, «ISO C90 запрещает составные литералы».

«ISO C99 поддерживает составные литералы». «В качестве расширения GCC поддерживает составные литералы в режиме C89 и в C++» (dixit info gcc). Кроме того, «Как расширение GNU, GCC позволяет инициализировать объекты со статической продолжительностью хранения с помощью составных литералов (что невозможно в ISO C99, потому что инициализатор не является константой)».

Но если бы они указали поведение при переполнении, это сделало бы его очень медленным на архитектурах, где это не было нормальным поведением. Очень низкие накладные расходы времени выполнения всегда были целью разработки C, и это означало, что многие подобные вещи не определены.

Мне очень хорошо известно, что переполнение Почему - это UB. Это по-прежнему является ошибкой, потому что в стандарте должны быть по крайней мере предусмотрены библиотечные процедуры, которые могут проверять арифметическое переполнение (всех основных операций), не вызывая UB.

@zvrba, «библиотечные подпрограммы, которые могут проверять арифметическое переполнение (всех основных операций)», если бы вы добавили это, вы бы значительно снизили производительность для любых целочисленных арифметических операций. ===== Пример из практики Matlab специально ДОБАВЛЯЕТ функцию управления поведением целочисленного переполнения для переноса или насыщения. И он также выдает исключение всякий раз, когда происходит переполнение ==> Производительность целочисленных операций Matlab: ОЧЕНЬ МЕДЛЕННО. Мой собственный вывод: я думаю, что Matlab - убедительный пример, показывающий, почему вам не нужна проверка переполнения целых чисел.

@zvrba, на мой взгляд, C был разработан ПРЕДПОЛАГАЯ, что всякий раз, когда вы выполняете целочисленную арифметику, вы, программист, проводите строгий анализ, чтобы УБЕДИТЬСЯ, что у вас есть ограниченный-вход-ограниченный-выход (причудливый способ сказать "убедитесь, что ваш ввод и вывод остаются в пределах диапазона ") !! Если вы не проводите такой тщательный анализ, тогда виноват не язык, а программист.

Я сказал, что в стандарте должна быть предусмотрена поддержка библиотека для проверки арифметического переполнения. Каким образом библиотечная процедура может снизить производительность, если вы никогда ее не используете?

Большой минус в том, что GCC не имеет флага для перехвата целочисленных значений со знаком и выдачи исключения времени выполнения. Хотя существуют флаги x86 для обнаружения таких случаев, GCC их не использует. Наличие такого флага позволило бы приложениям, не критичным к производительности (особенно устаревшим), пользоваться преимуществами безопасности с минимальным обзором и рефакторингом кода или без него.

Ничего из этого вовсе не «скрыто». Стандартная библиотека, например, хорошо разрекламирована; если люди предпочитают не читать документацию, они дураки. Указатели на функции просто «продвинутые», они никоим образом не скрыты - с ними связано большинство текстов на языке.

Скрытность относительна, документация относительно абсолютна.

зачем нужна замена strtok?

Комбинация структур и объединений еще более интересна - во встроенных системах или низкоуровневом коде драйвера. Например, когда вам нравится анализировать регистры SD-карты, вы можете прочитать его с помощью union (1) и прочитать с помощью union (2), который представляет собой структуру битовых полей.

Битовые поля не переносимы - компилятор может свободно выбирать, будут ли в вашем примере для ног выделяться 3 старших бита или 3 младших бита.

Битовые поля - это пример того, где стандарт дает реализациям настолько большую свободу в том, как они реализованы, что на практике они почти бесполезны. Если вам важно, сколько бит занимает значение и как оно хранится, лучше использовать битовые маски.

Битовые поля действительно переносимы, если вы относитесь к ним как к элементам структуры, а не «частям целых чисел». Во встроенной системе с ограниченной памятью важен размер, а не местоположение, поскольку каждый бит драгоценен ... но большинство современных кодировщиков слишком молоды, чтобы помнить об этом. :-)

Ура для битовых полей! Я использую их все время.

@Adam: местоположение может иметь значение во встроенной системе (или где-либо еще), если вы зависите от положения битового поля в его байте. Использование масок устраняет двусмысленность. Аналогично для профсоюзов.

@ComSubVie: с этой точки зрения ничего не переносимо :)

Да, я действительно использовал это для задания, которое у меня было в прошлом году на уроке CS. Мы реализовали алгоритм LZW для работы с определенным ограничением памяти. Единственным вариантом было указать количество битов, которое будет использоваться для каждого поля в структуре, поскольку по умолчанию каждое поле было слишком большим.

Я почти уверен, что это не переносная конструкция. Результат создания многосимвольной константы определяется реализацией.

удалите запятую после "WAIT" на случай, если кто-то попытается это сделать.

@ blak3r - спасибо! это напоминает мне еще об одной скрытой особенности. см. здесь: stackoverflow.com/questions/132241/hidden-features-of-c/…

Проблема в том, что их нельзя сравнивать с реальными строками, поскольку в зависимости от порядка байтов они могут храниться в памяти как «STOP» или «POTS».

Он не предназначен для сравнения с настоящими струнами. Дело в том, что вы можете присвоить перечислениям уникальные значения, которые легко читать в дампе памяти.

Запятая была преднамеренной и синтаксически верной.

@Ferruccio - я считаю, что запятая действительна в C99, но не в C89. Это означает, что GCC, вероятно, проглотит его, но некоторые старые компиляторы (или более старые версии GCC) нет.

Комментарии "непереносимых" полностью упускают из виду суть. Это все равно, что критиковать программу за использование INT_MAX только потому, что INT_MAX "непереносимый" :) Эта функция настолько портативна, насколько это необходимо. Константа с несколькими символами - чрезвычайно полезная функция, которая обеспечивает удобочитаемый способ создания уникальных целочисленных идентификаторов.

@Chris Lutz - Я почти уверен, что конечная запятая идет обратно к K&R. Это описано во втором издании (1988 г.).

@Ferruccio: Вы, должно быть, думаете о конечной запятой в списках агрегированных инициализаторов. Что касается конечной запятой в объявлениях перечислений - это недавнее добавление, C99.

Вы забыли HANG или BSOD :-)

Почему бы просто не использовать макросы с определенными числовыми флагами?

@Vince: Макросы, даже для констант, загрязняют пространство имен программы. Аналогичным образом, почему бы не использовать сборку вместо C? ;)

Я тестировал и, по крайней мере, с gcc (пробовал на PowerPC и x86) многобайтовые символы не зависят от порядка байтов. Кто-то пробовал с другим компилятором или проверял стандарт ISO? Приведенный выше ответ кажется неправильным относительно порядка байтов.

Первое слишком просто. Я думаю, вы имели в виду someNybble ["0123456789abcdef"]. Второй не компилируется, пока вы не добавите *.

Я думаю, что первый правильный как есть: он преобразует целое число someNybble в диапазоне 0-15 в его шестнадцатеричный эквивалент.

Обе формы правильны для 1-го, но показанная на самом деле не сложная, просто необычная для восприятия, но очевидная для понимания.

Разве вместо этого вы не получаете предупреждение о недоступности кода? Почему бы просто не закомментировать «данные» - это также удалит предупреждение о неиспользуемых параметрах.

Нет, я не понял этого в последний раз, когда проверял это, но на самом деле я не использую этот трюк, я предпочитаю использовать неиспользуемый атрибут. Удаление данных не всегда возможно, если вы придерживаетесь подписи, например, потому, что пишете обратные вызовы.

Нет, подпись не меняется. Вы просто делаете это: void callback (const char msg, void * / data * /) Или это: void callback (const char * msg, void *)

С помощью gcc вы можете добавить неиспользуемый атрибут к параметрам: void callback (const char * msg, void * data __attribute __ ((unused)))

В отличие от использования непереносимого синтаксиса атрибут. Вы можете просто указать: (void) data; в функции. Я обычно ставлю его сразу после любых местных (так как они должны быть первыми в c89). Я также стараюсь создать такой макрос: #define UNUSED (x) (void) x, чтобы я мог просто написать: UNUSED (data).

Вы можете использовать '(void) data' где угодно до 'return'. (кажется, Эван это уже сказал)

@Greg Whitfield void callback (const char * msg, void *) {...} здесь не компилируется @all Я знаю, что есть много способов подавить подобные предупреждения

@quinmars - Какой компилятор вы используете? То, что я сказал вам, является стандартным C. Какую ошибку вы получаете?

Я использую gcc, я повторил попытку с g ++, и там действительно работает. Так что, похоже, это особенность C++.

Разве вы не можете просто использовать # неиспользуемые данные?

Уловка классная ... :) Особенно с определенными вами макросами. :)

Синтаксис, который gcc поддерживает в течение долгого времени, не совпадает со стандартным синтаксисом C99.

Будет ли это работать правильно, если размер байта / символа на целевой платформе не равен 8 битам? Знаю, такие случаи редки, но все же ... :)

Я думаю, что это C99 или около того. Я не нашел портативного способа гарантировать, что они будут поблизости.

Они являются необязательной частью C99, но я не знаю поставщиков компиляторов, которые бы это не реализовали.

stdint.h не является обязательным в C99, но, очевидно, следование стандарту C99 для некоторых поставщиков (кашель Microsoft).

Microsoft Visual C++ также не следует стандарту Ada95. Это не компилятор C99. Это компилятор C++ 97. (Он не всегда соответствует этому стандарту, но несправедливо жаловаться на то, что это не то, на что он не претендует)

@Pete, если хочешь быть аналом: (1) Эта ветка не имеет ничего общего ни с каким продуктом Microsoft. (2) Эта ветка никогда не имела ничего общего с C++. (3) Не существует C++ 97.

Взгляните на azillionmonkeys.com/qed/pstdint.h - почти переносимый stdint.h

@gnud: спасибо за подсказку, но меня беспокоит то, что в этом нет необходимости - большинство компиляторов реализуют стандартные определения типов. Единственный компилятор, который я когда-либо использовал, который не использовал, была старая версия GCC, адаптированная для разработки встроенных VxWorks (старый, например, GCC 2.7).

@Ben Collins: Он указывает, что он почти реализует C++ 98, но не соответствует некоторым требованиям. Кроме того, MSVC не поддерживает C99, особенно stdint.h, который является королевским PITA.

@Anacrolix: Да. Я понял, на что он указывал. Вы, кажется, упускаете мою мысль: это ни к чему. Независимо от того, "поддерживает ли конкретный компилятор C99", на самом деле не имеет никакого отношения к тому, следует ли вам использовать стандартные целочисленные определения типов. Они переносимы и их легко определить, даже если ваш компилятор отстой. Если вам нужно указать определенную целочисленную ширину, тогда следует использовать стандартные определения типов всегда, всегда, независимо от того, откуда берутся определения.

Спасибо большое! Он получает резервную копию, когда я использую заголовки Windows, и вы получаете typedef unsigned long ULONG. Серьезно? Или введите typedef float FLOAT.

Насколько мне известно, в Visual Studio 2010 теперь есть stdint.h из-за высокого спроса на эту особенность C99. Это была королевская PITA, которой не было раньше.

За 20 лет C я такого НИКОГДА не видел!

В C++ его даже можно перегрузить.

может! = должен, конечно. Опасность с перегрузкой заключается в том, что встроенная функция уже применяется ко всему, включая void, поэтому никогда не потерпит неудачу при компиляции из-за отсутствия доступной перегрузки. То есть, дает программисту большую веревку.

Int внутри цикла не будет работать с C: это улучшение C++. Является ли "," той же операцией, что и для (i = 0, j = 10; i <j; j--, i ++)?

Это подпадает под «обычное использование, от которого я бы не рекомендовал». Псевдонимы типов и оптимизация не ладят. Вместо этого используйте объединения для ясности как для читателя, так и для компилятора.

Если быть точным, «не ладите» означает, что «этот код на самом деле может быть неправильно скомпилирован», потому что это неопределенное поведение в C.

Это не соответствует стандарту; В C99 есть «гибкие элементы массива», которые достигают того же результата и соответствуют требованиям. (Удалите 1 из объявления, чтобы использовать гибкий элемент массива.)

ссылка больше не работает, на самом деле кажется, что сам сайт не работает. Можете дать еще одну ссылку?

@thequark: Любая статья об "уязвимостях строки формата" будет содержать некоторую информацию .. (например, crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf) .. Однако из-за характера поля сами сайты безопасности немного нестабильны, и трудно найти настоящие академические статьи by (с реализацией).

Более того, компилятор C лучше вас знает, какие переменные больше всего выиграют от нахождения в регистре. Большинство современных компиляторов достаточно умны, чтобы полностью игнорировать ключевое слово register, но если бы они действительно обратили на него внимание, это, вероятно, замедлило бы ваш код.

Я почти уверен, что некоторые компиляторы не позволяют вам принимать адрес переменной, объявленной с помощью register. Так что это полезно для того, чтобы ваши намерения были ясны.

На самом деле, когда вы проверяете это в очень конкретном сценарии с оптимизацией кода и, возможно, смешанной сборкой, это ключевое слово действительно имеет свои достоинства и может значительно увеличить скорость. Конечно, это крайние случаи (один мой пост на EE показывает, как и когда это полезно, но это было давно).

Учитывая комбинацию микроконтроллера и чтения вывода сборки, это все равно может быть полезно в каком-то странном случае.

Обнуляет ли он и весь массив?

Однако он не обнуляет отступы, если они есть.

@drhorrible: вы можете сделать int array [50] = {0}; Например. Но только при декларации (думаю.)

Разве это не делает что-то неопределенное, если структура содержит нецелочисленные типы (например, числа с плавающей запятой и двойные)?

@simonn, нет, он не выполняет неопределенное поведение, если структура содержит нецелочисленные типы. memset с 0 в памяти float / double будет по-прежнему равным нулю, когда вы интерпретируете float / double (float / double специально созданы таким образом).

@Trevor Я думал, что эффект, который это оказывает на числа с плавающей запятой, - это «все нулевые байты», что во всех разумных случаях даст вам значение с плавающей запятой, равное 0,0, но это все еще определяется реализацией.

@Andrew: memset / calloc выполняет «все нулевые байты» (т.е. физические нули), что действительно не определено для всех типов. { 0 } гарантированно инициализирует все с соответствующими нулевыми значениями логичный. Например, гарантируется, что указатели получат свои правильные нулевые значения, даже если нулевым значением на данной платформе является 0xBAADFOOD.

@AndreyT: Не могли бы вы подробнее рассказать о различиях между логическими и физическими нулями?

@nvl: вы получаете физический ноль, когда вы просто принудительно устанавливаете всю память, занятую объектом, в состояние «все биты-ноль». Это то, что делает memset (с 0 в качестве второго аргумента). Вы получаете нулевое значение логичный, когда инициализируете / назначаете 0 (или { 0 }) объекту в исходном коде. Эти два вида нулей не обязательно дают одинаковый результат. Как в примере с указателем. Когда вы выполняете memset для указателя, вы получаете указатель 0x0000. Но когда вы назначаете 0 указателю, вы получаете значение нулевого указателя, который на физическом уровне может быть 0xBAADF00D или чем-то еще.

Другими словами, значение физический является явным битовым шаблоном, который хранится в памяти. Значение Логический - это то, как этот битовый шаблон интерпретируется на программном уровне.

@AndreyT Я понимаю, что такое физический ноль. Но не может полностью переварить эти логические нули. Любая другая структура данных, кроме указателя, которая имеет разные логические / физические представления?

@nvl: Ну, на практике разница часто носит чисто концептуальный характер. Но теоретически он может быть практически у любого типа. Например, double. Обычно это реализовано в соответствии со стандартом IEEE-754, в котором логический ноль и физический ноль совпадают. Но язык не требует IEEE-754. Таким образом, может случиться так, что когда вы сделаете double d = 0; (логический ноль), физически некоторые биты в памяти, занятой d, не будут равны нулю.

То же самое со значениями bool для другого примера. Если вы используете bool b = false; (или, что то же самое, bool b = 0;), это не обязательно означает, что в физической памяти b будет обнулен (хотя на практике это обычно так).

Понятно. Спасибо. Теперь я вспоминаю представление с плавающей запятой. Имеет смысл.

@AndreyT: Отличные комментарии. +1

Конечно, такой способ обхода больших структур влияет на производительность; это часто бывает полезно (и это действительно то, что многие люди не осознают, что вы можете это сделать), но вам нужно подумать, лучше ли передавать указатели.

Конечно, есть мощь. Компилятор также вполне может обнаружить использование и оптимизировать его.

Будьте осторожны, если какие-либо элементы являются указателями, так как вы будете копировать сами указатели, а не их содержимое. Конечно, то же самое верно и в случае использования memcpy ().

Компилятор не может оптимизировать это преобразование по значению, передаваемому по ссылке, если он не может выполнять глобальную оптимизацию.

Вероятно, стоит отметить, что в C++ стандарт специально позволяет оптимизировать копию (стандарт должен позволять компиляторам реализовать его, потому что это означает, что конструктор копирования, который может иметь побочные эффекты, не может быть вызван), и поскольку большинство компиляторов C++ также являются компиляторами C, есть большая вероятность, что ваш компилятор выполняет эту оптимизацию.

Я исправил последний вызов «конструктора», он вызывал Point (0, 0), что, конечно же, неправильно, point_new () - это то, что нужно. Ой.

Инициализация структуры C99 предназначена для оптимизации, в то время как этот код полагается на тот факт, что компилятор МОЖЕТ встроить функцию И МОЖЕТ отбросить копию.

У вас есть дополнительная буква R в VA_ARGS.

Это также важно в среде с несколькими разработчиками, где, например, Эрик добавляет «baz», а затем Джордж добавляет «бум». Если Эрик решит вытащить свой код для следующей сборки проекта, он все равно будет компилироваться с изменениями Джорджа. Очень важно для управления исходным кодом нескольких ветвей и перекрывающихся графиков разработки.

Перечисления могут быть C99. Инициализаторы массивов и конечная запятая - K&R.

Простые перечисления были в c89, AFAIK. По крайней мере, они существуют уже много лет.

Вы уверены, что это портативный? Я думал, что стандарты C не дают никаких гарантий относительно выравнивания структуры, кроме того, что первый элемент находится со смещением 0. Между элементами могут быть промежутки. Т.е. sizeof (Point) не обязательно будет sizeof (float) * 3.

@jmtd, Верно. На практике его вполне достаточно «портативного», чтобы доставить вам неприятности. Смещение любого члена, кроме первого, является поведением, определяемым реализацией, и не обязательно должно иметь такую ​​же эффективную упаковку, как массив этого типа. На практике вполне вероятно, что он имеет ту же упаковку, что и массив, поэтому этот код будет работать до тех пор, пока он не будет перенесен на платформу следующий, где он загадочным образом выйдет из строя. То же самое произошло с обычной реализацией MD5 при переносе на 64-битную версию: она скомпилировалась и запустилась, но получила другой ответ.

В C99 правильный способ объявить это: char b[];, который имеет то преимущество, что вам не нужно вычитать 1*sizeof b[0] из размера вашей структуры.

Разве доступ к b [] не превышает объявленного размера undefined, независимо от того, существует ли для него выделенное пространство? Я бы подумал, что было бы чище использовать char b [MAX_ARRAY_SIZE], а затем вычесть MAX_ARRAY_SIZE из распределения. Еще лучше было бы, если бы массивы нулевого размера были разрешены в первую очередь, и компиляторы должны были бы рассматривать их как указатель на место начала массива, но без ограничения размера.

пожалуйста, не нравится ... например, в противном случае правильный код if (something) mmaloc(); else otherthing; не будет компилироваться, если _DEBUG определен.

вам нужна запятая в макросах malloc, а не точка с запятой (по причинам, описанным @fortran). Однако это игнорирует возвращаемое значение (но опять же, я не уверен, почему эти макросы желательны).

О боже! все они вносят свой вклад в stackoverflow, извините (я здесь новичок и не заметил, что есть раздел скрытых функций) ... В любом случае, он может работать как справочник и краткое руководство по этим темам.

в том же семействе есть также offsetof (), ну, это макрос, но все равно приятно.

А если хотите: #define countof(array) (sizeof (array) / sizeof (array[0]));)

@ Томас Сенарт. У вас есть ссылка на это? Я полностью согласен с тем, что вы не можете использовать fflush (stdin) для очистки буфера, который работает только в Windows c компилятор, но не работает в gcc.

Вместо того, чтобы использовать шестнадцатеричные константы, я предпочитаю получать NaN несигнальным делением нуля на ноль с плавающей запятой.

+1 Аккуратно. Раньше я использовал макрос CompilerAssert от Microsoft, но и ваш неплохой. (#define CompilerAssert(exp) extern char _CompilerAssert[(exp)?1:-1])

Мне нравится метод перечисления. Подход, который я использовал раньше, использовал преимущество исключения мертвого кода: «if (something_bad) {void BLORG_IS_WOOZLED (void); BLORG_IS_WOOZLED ();}», который не приводил к ошибкам до времени компоновки, хотя он давал преимущество, позволяя программист узнает через сообщение об ошибке, что blorg был взорван.

Также полезно разделить строковую константу на несколько строк исходного кода без использования грязного символа `\`.

Это старый трюк, который неукоснительно используется некоторыми людьми, но я считаю, что многие компиляторы выдают предупреждение, когда видят, что if (count = 0) делает его несколько избыточным.