Win32-API में इतने सारे कस्टम प्रकार क्यों हैं?

मैं Win32 एपीआई के लिए नया हूँ और कई नए प्रकार मुझे भ्रमित करने के लिए शुरू करते हैं।Win32-API में इतने सारे कस्टम प्रकार क्यों हैं?

कुछ कार्य 1-2 ints और 3 UINTS तर्कों के रूप ले लो।

वे इनट्स का उपयोग क्यों नहीं कर सकते? यूआईएनटीएस क्या हैं?

फिर, उन अन्य प्रकार के होते हैं:

DWORD LPCWSTR LPBOOL

फिर से, मुझे लगता है कि "आदिम" सी प्रकार पर्याप्त होगा - क्यों 100 नए प्रकार के परिचय? WCHAR*

मैं इसे माध्यम से पुनरावृति और एक एसटीडी के लिए हर चरित्र push_back :: स्ट्रिंग के रूप में वहाँ एक और तरीका यह एक करने के लिए कन्वर्ट करने के लिए नहीं था पड़ा:

यह एक सिरदर्द होता था। भयानक।

क्यों WCHAR? पहिया को फिर से क्यों शुरू करें? वे इसके बजाय char* का इस्तेमाल कर सकते थे, या?

स्रोत

2010-04-15 sub

न केवल यह सी है, बल्कि Win16 (यानी 16 बिट) से Win32 तक बड़े स्विच से बचा है। कुछ प्रकार (वास्तव में # परिभाषित) भी कुख्यात हंगरी नोटेशन के पहलुओं को व्यक्त करते हैं जो उस समय प्रचलित थे। इसके अलावा, # परिभाषाओं के पीछे वास्तविक प्रकार छुपाकर, एमएस विभिन्न सी संकलक विक्रेताओं का समर्थन करने में सक्षम था; मान लीजिए या नहीं, फिर कई अलग-अलग सी कंपाइलर विक्रेता थे। जाली सी, वाटकॉम सी, और कई अन्य लोगों के नाम भूल गए। आह .... यादें। – kmontgom

यूनिट "हस्ताक्षरित int" है। –

WCHAR एक * चौड़ा * चरित्र, यूटीएफ -16LE है। यह प्रति चरित्र 2 बाइट लेता है। इसे ध्यान में रखते हुए, आप शायद अनुमान लगा सकते हैं कि क्या होगा यदि आपने इसे नियमित रूप से चार सरणी के रूप में उपयोग करने का प्रयास किया था। –

Windows API पहले 1980 के दशक में वापस बनाया गया था, और पिछले कुछ वर्षों में कई अलग अलग सीपीयू आर्किटेक्चर और compilers समर्थन करने के लिए पड़ा है। वे एकल-उपयोगकर्ता एकल-प्रक्रिया स्टैंडअलोन सिस्टम से नेटवर्क किए गए बहु-उपयोगकर्ता बहु-कोर सुरक्षा-जागरूक सिस्टम में चले गए हैं। उन्हें 16-बिट बनाम 32-बिट प्रोसेसर, और अब 64-बिट प्रोसेसर के साथ समस्याओं के आसपास काम करना पड़ा। उन्हें प्री-एएनएसआई सी कंपाइलर्स के साथ मुद्दों के आसपास काम करना पड़ा। उन्हें शुरुआती गैर-मानकीकृत समय में सी ++ कंपाइलर्स का समर्थन करना पड़ा। उन्हें खंडित स्मृति से निपटना पड़ा। यूनिकोड अस्तित्व से पहले उन्हें अंतर्राष्ट्रीयकरण का समर्थन करना पड़ा। उन्हें एमएस-डॉस के साथ ओएस/2 और मैक ओएस के साथ कुछ स्रोत-स्तरीय संगतता का समर्थन करना पड़ा। उन्हें इंटेल चिप्स, और पावरपीसी, और एमआईपीएस, और अल्फा, और एआरएम की कई पीढ़ियों पर चलना पड़ा। डेस्कटॉप, सर्वर, मोबाइल और एम्बेडेड सिस्टम के लिए एक ही मूल एपीआई का उपयोग किया जाता है।

1980 के दशक में वापस, सी, एक उच्च स्तरीय भाषा (हाँ माना जाता था वास्तव में!) और कई लोगों ने इसे आदिम int, char, या void * के रूप में सबकुछ निर्दिष्ट करने के बजाय अमूर्त प्रकारों का उपयोग करने के लिए अच्छा रूप माना। वापस जब हमारे पास इंटेलिसेन्स और इंफोटिप्स और कोड ब्राउज़र और ऑनलाइन दस्तावेज़ नहीं थे और जैसे, ऐसे उपयोग संकेत उपयोगी थे, और यह विभिन्न कंपेलरों और विभिन्न प्रोग्रामिंग भाषाओं के बीच पोर्ट कोड को आसान बनाता है।

हां, यह एक भयानक गड़बड़ है, लेकिन इसका मतलब यह नहीं है कि उन्होंने कुछ भी गलत किया है।

स्रोत

2010-04-15 18:36:46

विंडोज एपीआई विरासत के अधिक स्पष्ट कलाकृतियों में से एक 'एलपी'' उपसर्ग कई पॉइंटर प्रकारों पर प्रयोग किया जाता है - यह उपसर्ग 'लम्बी सूचक' (जिसे 'दूर पॉइंटर' भी कहा जाता है) के लिए खड़ा होता है और Win16 के अंतर्निहित खंडित आर्किटेक्चर के कारण कई मानकों के लिए आवश्यक था, जहां एक सूचक 'पास' (अनुमानित सेगमेंट के भीतर इंगित करना) या 'दूर' (जहां सेगमेंट को सूचक के हिस्से के रूप में निर्दिष्ट किया गया था) हो सकता था। Win32 के साथ पास और दूर पॉइंटर्स लंबे समय तक चले गए हैं, लेकिन नाम वही रहते हैं। –

यह मजाकिया है। विंडोज प्लेटफार्म हेडर अभी भी एफएआर पॉइंटर्स के लिए परिभाषित हैं। अजीब वे अभी भी 20 या इतने सालों के बाद, गड़बड़ी को साफ नहीं किया है। सी Win32 एपीआई लगता है जैसे यह छोड़ दिया गया है और भूल गया है। –

@ मैड्स: भूल गए? मुश्किल से। पुरानी परिभाषाओं को ध्यान में रखते हुए पुराने ऐप्स को उन्हें फिर से लिखने के बिना अपडेट किया जा सकता है। –

मेरा एक सहकर्मी कहता है, "कोई समस्या नहीं है जिसे संकेत के स्तर से हल नहीं किया जा सकता है (obfuscated?)।" WIN32 में आप WCHAR, UINT, आदि से निपटेंगे और आप इसका उपयोग करेंगे। जब आप उस डीएलएल को तैनात करते हैं तो आपको चिंता करने की ज़रूरत नहीं है, जो मूल प्रकार एक WCHAR या यूनिट संकलित करता है - यह "बस काम करेगा"।

से कुछ प्रलेखन के माध्यम से पढ़ने के लिए बेस्ट इसकी आदत हो लिए। विशेष रूप से वाइड चार समर्थन (WCHAR, आदि) पर। एक अच्छा definition on MSDN for WCHAR है।

स्रोत

2010-04-15 18:33:48 AlG

"प्रोग्रामिंग में कोई जटिलता समस्या नहीं है जिसे संकेत की परत जोड़कर आसानी नहीं किया जा सकता है। और प्रोग्रामिंग में कोई प्रदर्शन समस्या नहीं है जिसे संकेत की परत को हटाकर आसानी से नहीं किया जा सकता है।" - डोनाल्ड Knuth –

uint एक अहस्ताक्षरित पूर्णांक है। यदि कोई पैरामीटर मान नकारात्मक नहीं होगा/नहीं, तो यह हस्ताक्षरित निर्दिष्ट करने के लिए समझ में आता है। एलपीसीडब्लूस्ट्रैंड चौड़ा चार सरणी का सूचक सूचक है, जबकि डब्ल्यूएचएचएआर * गैर-कॉन्स है।

आप शायद जब विस्तृत वर्ण के साथ काम करने यूनिकोड के लिए अपने अनुप्रयोग संकलन या एक रूपांतरण दिनचर्या का उपयोग संकीर्ण से चौड़ा करने के लिए कन्वर्ट करने के लिए करना चाहिए।
http://msdn.microsoft.com/en-us/library/dd319072%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/dd374083%28v=VS.85%29.aspx

स्रोत

2010-04-15 18:36:31

Win32 वास्तव में बहुत कम प्राचीन प्रकार हैं। जो आप देख रहे हैं वह दशकों का बिल्ट-अप # डिफाइन और टाइपपीफ और हंगेरियन नोटेशन है। क्योंकि बहुत कम प्रकार थे और बहुत कम या कोई इंटेलिजेंस डेवलपर्स ने खुद को "सुराग" दिया था कि वास्तव में एक विशेष प्रकार को क्या करना था।

उदाहरण के लिए, कोई बुलियन प्रकार नहीं है लेकिन एक पूर्णांक का "अलियाज्ड" प्रतिनिधित्व होता है जो आपको बताता है कि एक विशेष चर को बूलियन के रूप में माना जाना चाहिए। मेरा मतलब क्या है यह देखने के लिए WinDef.h की सामग्री पर नज़र डालें।

आप यहां एक नज़र डाल सकते हैं: http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx बर्फबारी की सही नोक पर एक चोटी के लिए। उदाहरण के लिए, ध्यान दें कि हैंडल एक अन्य ऑब्जेक्ट के लिए आधार टाइपिफ़ है जो विंडोज ऑब्जेक्ट में "हैंडल" है। बेशक हैंडल को किसी अन्य प्रकार के रूप में परिभाषित किया गया है।

स्रोत

2010-04-15 18:46:35

Win32-API में इतने सारे कस्टम प्रकार क्यों हैं?

उत्तर

संबंधित मुद्दे