Что #define делает в компиляторе?

Имя макроса затем помечается как определенное, с пустым списком замены. Вас интересует исходный код компилятора? Более интересными для пользователей являются конкретные правила языка C, например en.cppreference.com/w/c/preprocessor/replace. «Как» — вопрос неопределенный.

@KamilCuk да, точный исходный код компилятора был бы великолепен. Спасибо за список замены, это помогло!

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

Я имею в виду файл (или, что еще лучше, функцию), в котором он обрабатывает токен определения.

вы думаете, что это простая функция?

@0___________ черт возьми, нет, но я думаю, что смогу обрисовать, что происходит, чтобы понять, что оно делает

На самом деле он мало чем отличается от #define NAME x. В данном случае x — это пустая строка, поэтому при использовании макроса она заменяется пустой строкой.

Как вы думаете, почему вам нужен исходный код, чтобы понять такую ​​базовую операцию? Считаете ли вы, что пустые строки требуют какой-либо сложной обработки?

@Barmar Мне не нужен исходный код. Я просил об этом, потому что KamiiCuk сказал: «Вас интересует исходный код компилятора», и я неправильно истолковал это как предложение указать мне исходный код компилятора, в котором он определен. Я не думаю, что пустые строки также не требуют сложной обработки. Спасибо за первый комментарий, он очень помогает.

Я думаю, он спросил тебя об этом, потому что ты использовал тег compiler-construction. Это говорит о том, что вас интересует то, как компилятор это реализует, а не только то, как это используется и что это означает.

Меня интересует, как это реализует компилятор. Я знаю, как оно используется, и, узнав, что оно означает (на случай, если это все, что кто-то мог мне сообщить), я надеялся понять, что с ним делает компилятор.

Эта конкретная конструкция называется защитой включения и предназначена для предотвращения многократного #include повторения одного и того же заголовочного файла. Большинство компиляторов предоставляют #pragma once для достижения той же цели, но это не стандартно.

Да, @ dan04, конкретный пример ОП выглядит как защита включения, но это ни в коем случае не единственное использование макросов с пустыми списками замены. Кажется, они заинтересованы в таких макросах в целом, а не только в тех, которые используются для защиты включения.

В контексте создания «защиты заголовка» ознакомьтесь с Создание собственного файла заголовка на C.

Этот ответ можно прочитать как утверждение, что единственное применение макроса, определенного с пустым списком замен, — это проверка его определенности. Это совсем не так. Действительно, возможность проверки определенности макросов во многом ортогональна содержимому списков замены макросов.

@JohnBollinger Это не подразумевается, это просто объем вопроса.

Это не объем вопроса, как я его прочитал. Это просто природа конкретного примера, приведенного внутри. «Что происходит, когда вы определяете что-то, не давая определения? [...] Это просто помечается как «определенное» [...]?» -- НЕТ. Он определяется как макрос с указанным списком замены, который оказывается пустым.

@JohnBollinger Кажется, вы хотите обсудить тонкое различие между «пустым списком» и «нет значения». Технически вы правы, в лучшем случае правы, но вопрос не в этом. Теперь я понимаю, какой бит подразумевает, что определенность - единственный вариант использования, я смягчу это.

Не совсем. Меня не волнует, скажете ли вы «определено как ничего» или «определено как пустой список». Меня волнует, что вы неправильно говорите: «нет определения». В конечном счете, важным моментом является то, что определение макроса с пустым списком/без замены не является особым случаем, вопреки тому, что думает ФП.

@JohnBollinger Имейте в виду, что ОП использует C уже год.

@Schwern год - это количество времени, в течение которого я полностью свободно владею C, например. способен превратить (большинство) полностью реализованных идей проекта в код

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

Нет, @Schwern, я подчеркиваю, что определение макроса, о котором спрашивает ОП, не является особым случаем. Видите жирный курсив? Он дает определение символа, какие бы слова вы ни использовали для этого, вопреки тому, что, по-видимому, предполагает ФП. Вся остальная семантика вытекает из этого. Что касается примеров использования, помимо проверки на определенность, я, конечно, мог бы их привести, но разве вы не настаивали в другом месте на строгом сосредоточении внимания на объеме вопроса?

ОП является новым для C, я сомневаюсь, что большая часть этого разговора имеет для них смысл. Вы эксперт, вы подчеркиваете это различие. Я предполагаю, что это важно в каком-то тонком смысле, но я этого не вижу. Для моего собственного образования не могли бы вы показать пример, где это различие важно?

Я бы не стал продавать короткий ОП, @Schwern, но, поскольку вы апеллируете к их предполагаемой неискушенности в отношении языка, я утверждаю, что «это не особый случай» имеет меньшую когнитивную нагрузку, чем «здесь есть специальные правила для этого». случай", а первый избегает замешательства, когда позже они обнаруживают случай, когда макрос, о котором они спрашивают, используется не только как флаг. Даже игнорируя второй из них, я просто не понимаю, почему вы предпочитаете описание особого случая. В любом случае, я привел пример, который, на мой взгляд, вполне доступен.

Спасибо за пример, и ваш ответ намного лучше. Думаю, я вижу различие, которое вы проводите: «EXTERN определяется как пустой список [чего?], который ничем не расширяется». Тогда как «EXTERN определяется как ничто и ни к чему не расширяется» подразумевает особый случай. Но для этого необходимо знать, что это список токенов (и что «ничего» и «пустой список» — это разные вещи), а это требует знания грамматики. Если вы это уже знаете, вы, вероятно, не зрители. «Ничто не превратится в ничто» — это естественное предположение. Это методика обучения, при которой сложность вводится постепенно, а не сразу.

@Schwern, не могли бы вы немного рассказать об этой сложности, пожалуйста? Приносим извинения за поздний ответ. Я выбрал C в качестве основного языка (хотя при необходимости могу использовать язык более высокого уровня, например Java), и после ознакомления с тем, как все работает, я хочу узнать больше о том, как это работает. Боюсь, мне не удалось найти конкретные детали достаточно хорошо, поэтому я создал этот пост, чтобы найти больше. Кстати, ваш ответ помог, спасибо за это.

@synnøve Например, можно сказать, что #define this x.y означает замену this на x.y, а #define this означает замену this ничем. Это короткое, понятное и полезное объяснение. Технически правильное объяснение заключается в том, что #define this x.y означает замену this списком замен токенов препроцессора x и . и y, тогда как #define this означает замену this пустым списком токенов препроцессора. Это сложнее понять, и возникают новые темы: что такое токен препроцессора? что значит заменить что-то пустым списком?

@synnøve Изучение C очень полезно, вы узнаете много нового о том, как на самом деле работают компьютеры. Однако, если вы только учитесь программировать, я бы посоветовал вам одновременно изучать язык более высокого уровня. C очень старый и, по современным меркам, довольно плохой язык (за это меня ждет ад), полный ловушек и подводных камней и требующий изучения многих вещей одновременно. Если вам нужен быстрый современный язык системного программирования, рассмотрите Rust или Go.