




может быть:
#undef near
#undef far
хотя может быть опасно ...
Лучше не делать этого. Они определены для обратной совместимости со старым кодом - если вы каким-то образом избавитесь от них, а затем вам понадобится использовать часть этого старого кода, вы сломаетесь.
Отмените определение любых макросов, которые вам не нужны после включения windows.h:
#include <windows.h>
#undef near
#undef far
Вероятно, вы не хотите, чтобы неопределенное значение было где-то рядом и далеко. Но когда вам нужно использовать имена переменных, вы можете использовать следующее, чтобы отменить определение макроса локально и добавить его обратно, когда вы закончите.
#pragma push_macro("near")
#undef near
//your code here.
#pragma pop_macro ("near")
Вы можете смело их переопределить, вопреки утверждениям других. Причина в том, что это просто макросы. Они влияют на препроцессор только между своим определением и неопределением. В вашем случае это будет с начала windows.h до последней строки windows.h. Если вам нужны дополнительные заголовки окон, вы должны включить их после windows.h и перед #undef. В вашем коде препроцессор просто оставит символы без изменений, как и предполагалось.
Комментарий о более старом коде не имеет значения. Этот код будет в отдельной библиотеке, скомпилированной независимо. Они будут подключены только во время компоновки, когда макросов уже не будет.
+1 за исправление безумия большинства других ответов.
Я согласен с комментарием о том, что старый код неуместен, но я не согласен с этим аргументом. Отдельные библиотеки включают файлы заголовков, которые могут использовать near и far.
32-битная и 64-битная Windows поддерживают только плоскую модель памяти, не сегментированную с указателями двух размеров. Если у вас есть код, который все еще использует
far char *p = ...или какой-либо другой правильный синтаксис, то 1. удалите его. 2. вы уже знаете, что вам нужны эти определения для компиляции этого древнего кода, и не ищете ответа на этот вопрос.