Есть ли чистый способ предотвратить windows.h от создания макроса close & far?
Глубоко в WinDef.h есть эта реликвия из эры сегментированной памяти:
#define far
#define near
Это, очевидно, вызывает проблемы, если вы пытаетесь использовать приближенные или близкие имена переменных. Любые чистые обходные пути? Другие, тогда переименование моих переменных?
Ответы
Ответ 1
Вы можете безопасно определить их, вопреки утверждениям других. Причина в том, что они просто макросы. Они влияют только на препроцессор между их определением и их неопределенностью. В вашем случае это будет с самого раннего времени windows.h до последней строки windows.h. Если вам нужны дополнительные заголовки окон, вы должны включить их после windows.h и до #undef. В вашем коде препроцессор просто оставит символы неизменными, как и предполагалось.
Комментарий о старшем коде не имеет значения. Этот код будет находиться в отдельной библиотеке, скомпилированной независимо. Только при времени соединения они будут связаны, когда макросы уже давно ушли.
Ответ 2
Отменить любые макросы, которые вы не хотите, после включения windows.h
:
#include <windows.h>
#undef near
#undef far
Ответ 3
может быть:
#undef near
#undef far
может быть опасным, хотя...
Ответ 4
Вероятно, вы не хотите, чтобы undefined находились рядом и далеко повсюду. Но когда вам нужно использовать имена переменных, вы можете использовать следующее, чтобы локализовать макрос локально и добавить его обратно, когда вы закончите.
#pragma push_macro("near")
#undef near
//your code here.
#pragma pop_macro ("near")
Ответ 5
Лучше не делать этого. Они определены для обратной совместимости со старым кодом - если вы каким-то образом избавились от них, а затем вам понадобилось использовать часть этого старого кода, который вы бы сломали.
Ответ 6
Можно утверждать, что "близкие" и "далекие" не являются очень описательными именами переменных. Рассматривали ли вы просто дополнительную информацию в имени переменной, чтобы разрешить конфликт (т.е. Ближайшее_match, furthest_match). Просто мысль.