क्या windows.h को निकट और दूर मैक्रो बनाने से रोकने का कोई साफ तरीका है?

Question

WinDef.h में गहराई से खंडित स्मृति युग से यह अवशेष है:

#define far 
#define near 

यह स्पष्ट रूप से समस्याओं का कारण बनता है यदि आप चर या नाम के रूप में उपयोग करने का प्रयास करते हैं। कोई साफ कामकाज? अन्य तो मेरे चर का नाम बदल रहे हैं?

Answer 1

आप दूसरों से दावों के विपरीत सुरक्षित रूप से उन्हें परिभाषित कर सकते हैं। कारण यह है कि वे सिर्फ मैक्रोज़ हैं। वे केवल अपनी परिभाषा और उनके अनिश्चितता के बीच प्रीप्रोसेसर को प्रभावित करते हैं। आपके मामले में, यह windows.h में शुरुआती से windows.h की अंतिम पंक्ति तक होगा। यदि आपको अतिरिक्त विंडोज हेडर की आवश्यकता है, तो आप उन्हें windows.h के बाद और #undef से पहले शामिल करेंगे। आपके कोड में, प्रीप्रोसेसर इरादे के रूप में प्रतीकों को अपरिवर्तित छोड़ देगा।

पुराने कोड के बारे में टिप्पणी अप्रासंगिक है। वह कोड अलग पुस्तकालय में होगा, जिसे स्वतंत्र रूप से संकलित किया जाएगा। केवल लिंक समय पर ये कनेक्ट हो जाएंगे, जब मैक्रोज़ लंबे समय तक चले जाएंगे।

Answer 2

शायद:

#undef near 
#undef far 

हो सकता है, हालांकि खतरनाक ...

Answer 3

नहीं करने के लिए सबसे अच्छा। उन्हें पुराने कोड के साथ पिछड़ा संगतता के लिए परिभाषित किया गया है - यदि आप किसी भी तरह से छुटकारा पा चुके हैं और बाद में उस पुराने कोड का उपयोग करने की आवश्यकता है जिसे आप तोड़ देंगे।

Answer 4

undefine किसी मैक्रो आप windows.h सहित के बाद नहीं करना चाहती:

#include <windows.h> 
#undef near 
#undef far 

Answer 5

आप शायद नहीं करना चाहती अपरिभाषित और दूर के पास हर जगह के लिए। लेकिन जब आपको परिवर्तनीय नामों का उपयोग करने की आवश्यकता होती है, तो आप मैक्रो को स्थानीय रूप से अपरिभाषित करने के लिए निम्न का उपयोग कर सकते हैं और जब आप पूरा कर लेते हैं तो इसे वापस जोड़ सकते हैं।

#pragma push_macro("near") 
#undef near 
//your code here. 
#pragma pop_macro ("near") 

Answer 6

कोई तर्क दे सकता है कि "निकट" और "दूर" बहुत वर्णनात्मक चर नाम नहीं हैं। क्या आपने संघर्ष को हल करने के लिए बस अपने चर नाम पर अतिरिक्त विवरण प्रदान किया है (यानी निकटतम_मैच, furthest_match)। सिर्फ एक विचार।