अशक्त-समाप्त स्ट्रिंग (नल्ल-टर्मिनेटेड स्ट्रिंग): Difference between revisions
(Created page with "{{Short description|Data structure}} {{Redirect|CString|the garment|Thong}} {{see also|String (computer science)#Null-terminated}} {{Use dmy dates|date=August 2021}} कं...") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Short description|Data structure}} | {{Short description|Data structure}} | ||
{{Redirect|CString|the garment|Thong}} | {{Redirect|CString|the garment|Thong}} | ||
{{see also| | {{see also|स्ट्रिंग (कंप्यूटर विज्ञान)#अशक्त-समाप्त | ||
}} | |||
( | [[कंप्यूटर प्रोग्रामिंग]] में, एक '''रिक्त-टर्मिनेटेड स्ट्रिंग''' एक [[वर्ण स्ट्रिंग]] है जिसे वर्णों वाले एक [[सरणी डेटा संरचना]] के रूप में संग्रहीत किया जाता है और एक शून्य वर्ण (शून्य के मान वाला एक वर्ण, जिसे इस आलेख में एनयूएल कहा जाता है) के साथ समाप्त किया जाता है। वैकल्पिक नाम C स्ट्रिंग हैं, जो C प्रोग्रामिंग भाषा और ASCIIZ को संदर्भित करता है हालाँकि [[सी (प्रोग्रामिंग भाषा)]] और एएससीआईआईजेड के अलावा अन्य एन्कोडिंग का उपयोग कर सकता है।{{citation needed|date=November 2021}} | ||
एक स्ट्रिंग की लंबाई (प्रथम) एनयूएल की खोज करके पाई जाती है। यह धीमा हो सकता है क्योंकि इसमें स्ट्रिंग की लंबाई के संबंध में O(n) (रैखिक समय) लगता है। इसका यह भी अर्थ है कि एक स्ट्रिंग में NUL नहीं हो सकता (मेमोरी में एक NUL है, लेकिन यह अंतिम वर्ण के बाद है जो स्ट्रिंग में "नहीं" है)। | |||
== इतिहास == | == इतिहास == | ||
शून्य-समाप्त स्ट्रिंग्स को [[पीडीपी-11]] असेंबली भाषाओं के <code>.ASCIZ</code> निर्देश और [[PDP-10]] के लिए मैक्रो-10 मैक्रो असेंबली भाषा के <code>ASCIZ</code> निर्देश द्वारा निर्मित किया गया था। ये सी प्रोग्रामिंग भाषा के विकास से पहले के हैं, लेकिन स्ट्रिंग के अन्य रूपों का अक्सर उपयोग किया जाता था। | |||
जिस समय C (और जिन भाषाओं से इसे प्राप्त किया गया था) का विकास हुआ था, मेमोरी बेहद सीमित थी, इसलिए स्ट्रिंग की लंबाई को संग्रहीत करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना आकर्षक था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे सामान्यतः "पास्कल स्ट्रिंग" कहा जाता है (एक अधिक आधुनिक शब्द "लंबाई-उपसर्ग" है), स्ट्रिंग की लंबाई को संग्रहीत करने के लिए एक अग्रणी बाइट का उपयोग करता था। यह स्ट्रिंग को NUL रखने की अनुमति देता है और पहले से संग्रहीत स्ट्रिंग की लंबाई खोजने के लिए केवल एक मेमोरी एक्सेस (O(1) (स्थिर) समय) की आवश्यकता होती है, लेकिन स्ट्रिंग की लंबाई 255 वर्णों तक सीमित होती है (8-बिट बाइट्स का उपयोग करने वाली मशीन पर) . सी डिजाइनर [[डेनिस रिची]] ने एक स्ट्रिंग की लंबाई पर सीमा से बचने के लिए नल-टर्मिनेशन के सम्मेलन का पालन करना चुना और क्योंकि गिनती बनाए रखना, उनके अनुभव में, टर्मिनेटर का उपयोग करने से कम सुविधाजनक लगता था।<ref>{{cite conference | first = Dennis M. | last = Ritchie | date = April 1993 | location = Cambridge, MA | title = सी भाषा का विकास| conference = Second History of Programming Languages conference | url = https://www.bell-labs.com/usr/dmr/www/chist.html }}</ref><ref>{{cite book | first = Dennis M. | last = Ritchie | article = The development of the C language | title = History of Programming Languages | edition = 2 | editor-first1= Thomas J. | editor-last1= Bergin, Jr. | editor-first2 = Richard G. | editor-last2 = Gibson, Jr. | publisher = ACM Press | location = New York | via = Addison-Wesley (Reading, Mass) | year = 1996 | isbn = 0-201-89502-1 }}</ref> | |||
इसका सीपीयू अनुदेश सेट डिज़ाइन पर कुछ प्रभाव पड़ा। 1970 और 1980 के दशक में कुछ सीपीयू, जैसे ज़िलॉग ज़ेड80 और डीईसी [[VAX]], में लंबाई-उपसर्ग स्ट्रिंग को संभालने के लिए समर्पित निर्देश थे। हालाँकि, जैसे-जैसे नल-टर्मिनेटेड स्ट्रिंग ने कर्षण प्राप्त किया, सीपीयू डिजाइनरों ने इसे ध्यान में रखना शुरू कर दिया, जैसा कि उदाहरण के लिए आईबीएम के 1992 में ईएस/9000 520 में "लॉजिकल स्ट्रिंग असिस्ट" निर्देशों और 2015 में [[IBM z13 (माइक्रोप्रोसेसर)]] के लिए वेक्टर स्ट्रिंग निर्देशों को जोड़ने के निर्णय में देखा गया था। <ref name="pop">[http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf IBM z/Architecture Principles of Operation]</ref> | |||
[[FreeBSD|फ्रीबीएसडी]] डेवलपर [[Poul-Henning Kamp|पॉल-हेनिंग काम्प]] ने [[ACM Queue|एसीएम क्यू]] में लिखते हुए, 2-बाइट (एक-बाइट नहीं) लंबाई पर नल-टर्मिनेटेड स्ट्रिंग्स की जीत को "अब तक की सबसे महंगी एक-बाइट गलती" के रूप में संदर्भित किया है।<ref>{{citation |last=Kamp |first=Poul-Henning |date=25 July 2011 |title=The Most Expensive One-byte Mistake |journal=ACM Queue |volume=9 |number=7 |pages=40–43 |doi=10.1145/2001562.2010365 |s2cid=30282393 |issn=1542-7730|url=http://queue.acm.org/detail.cfm?id=2010365 |doi-access=free }}</ref> | |||
== सीमाएं == | == सीमाएं == | ||
प्रयुक्त करने में सरल होने के बावजूद, यह प्रतिनिधित्व त्रुटियों और प्रदर्शन समस्याओं से ग्रस्त रहा है। | |||
अशक्त-समाप्ति ने ऐतिहासिक रूप से | अशक्त-समाप्ति ने ऐतिहासिक रूप से सुरक्षा समस्याएँ पैदा की हैं।<ref>{{cite journal|url= http://insecure.org/news/P55-07.txt |author=Rain Forest Puppy |title=पर्ल सीजीआई समस्याएं|journal=Phrack Magazine |publisher=artofhacking.com |date=9 September 1999 |volume=9 |issue=55 |page=7 |access-date=3 January 2016}}</ref> स्ट्रिंग के बीच में डाला गया NUL इसे अप्रत्याशित रूप से छोटा कर देगा।[6] एक सामान्य बग एनयूएल के लिए अतिरिक्त स्थान आवंटित नहीं करना था, इसलिए इसे आसन्न मेमोरी पर लिखा गया था। दूसरा यह था कि एनयूएल बिल्कुल न लिखा जाए, जिसे अक्सर परीक्षण के दौरान पता नहीं लगाया जा सका क्योंकि मेमोरी के ब्लॉक में पहले से ही शून्य था। लंबाई खोजने के खर्च के कारण कई प्रोग्राम किसी स्ट्रिंग को एक निश्चित आकार के [[डेटा बफ़र]] में कॉपी करने से पहले परेशान नहीं होते थे, जिससे अगर यह बहुत लंबा होता तो बफर ओवरफ्लो हो जाता। | ||
शून्य को | शून्य को संग्रहीत करने में असमर्थता के लिए आवश्यक है कि पाठ और बाइनरी डेटा को अलग-अलग रखा जाए और विभिन्न कार्यों द्वारा नियंत्रित किया जाए (बाद वाले को डेटा की लंबाई भी प्रदान करने की आवश्यकता होती है)। गलत फ़ंक्शन का उपयोग करने पर इससे कोड अतिरेक और त्रुटियां हो सकती हैं। | ||
लंबाई खोजने | लंबाई खोजने में गति की समस्याओं को सामान्यतः किसी अन्य ऑपरेशन के साथ जोड़कर कम किया जा सकता है जो कि O(n) है, जैसे कि <code>[[strlcpy]]</code> में। हालाँकि, इसका परिणाम हमेशा एक सहज [[एपीआई]] नहीं होता है। | ||
== कैरेक्टर एनकोडिंग == | == कैरेक्टर एनकोडिंग == | ||
अशक्त-समाप्त | अशक्त-समाप्त स्ट्रिंग के लिए आवश्यक है कि एन्कोडिंग कहीं भी शून्य बाइट (0x00) का उपयोग न करे; इसलिए हर संभव [[ASCII]] या [[UTF-8|यूटीएफ-8]] स्ट्रिंग को संग्रहीत करना संभव नहीं है।<ref>{{cite web|title=UTF-8, a transformation format of ISO 10646|url=http://tools.ietf.org/html/rfc3629#section-3|access-date=19 September 2013}}</ref><ref><!-- This is the encoding table provided as a resource by the Unicode consortium: http://www.unicode.org/resources/utf8.html -->{{cite web|title=Unicode/UTF-8-character table|url=http://www.utf8-chartable.de/|access-date=13 September 2013}}</ref><ref>{{cite web|last=Kuhn|first=Markus|title=UTF-8 and Unicode FAQ|url=http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8|access-date=13 September 2013}}</ref> हालाँकि, ASCII या यूटीएफ-8 के उपसमुच्चय - NUL को छोड़कर प्रत्येक वर्ण - को शून्य-समाप्त स्ट्रिंग में संग्रहीत करना आम बात है। कुछ सिस्टम "[[संशोधित UTF-8|संशोधित यूटीएफ-8]]" का उपयोग करते हैं जो एनयूएल को दो गैर-शून्य बाइट्स (0xC0, 0x80) के रूप में एन्कोड करता है और इस प्रकार सभी संभावित स्ट्रिंग्स को संग्रहीत करने की अनुमति देता है। यूटीएफ-8 मानक द्वारा इसकी अनुमति नहीं है, क्योंकि यह एक लंबी एन्कोडिंग है, और इसे सुरक्षा जोखिम के रूप में देखा जाता है। इसके अतिरिक्त कुछ अन्य बाइट को स्ट्रिंग के अंत के रूप में उपयोग किया जा सकता है, जैसे 0xFE या 0xFF, जिनका उपयोग यूटीएफ-8 में नहीं किया जाता है। | ||
यूटीएफ-16 2-बाइट पूर्णांकों का उपयोग करता है और चूँकि कोई भी बाइट शून्य हो सकती है (और वास्तव में हर दूसरा बाइट, जब एएससीआईआई पाठ का प्रतिनिधित्व करता है), शून्य-समाप्त बाइट स्ट्रिंग में संग्रहीत नहीं किया जा सकता है। हालाँकि, कुछ भाषाएँ 16-बिट यूटीएफ-16 वर्णों की एक स्ट्रिंग प्रयुक्त करती हैं, जो 16-बिट एनयूएल (0x0000) द्वारा समाप्त होती है। | |||
== सुधार == | == सुधार == | ||
सी स्ट्रिंग को कम त्रुटि प्रवण बनाने के कई प्रयास किए गए हैं। एक रणनीति | सी स्ट्रिंग हैंडलिंग को कम त्रुटि प्रवण बनाने के लिए कई प्रयास किए गए हैं। एक रणनीति <code>[[strdup]]</code> और <code>[[strlcpy]]</code> जैसे सुरक्षित कार्यों को जोड़ना है, जबकि <code>[[gets() | gets]]</code> जैसे असुरक्षित कार्यों के उपयोग को अस्वीकार करना है। दूसरा है सी स्ट्रिंग्स के चारों ओर एक ऑब्जेक्ट-ओरिएंटेड रैपर जोड़ना ताकि केवल सुरक्षित कॉल ही की जा सके। हालाँकि, असुरक्षित फ़ंक्शंस को कॉल करना वैसे भी संभव है। | ||
अधिकांश आधुनिक | अधिकांश आधुनिक लाइब्रेरी सी स्ट्रिंग्स को 32-बिट या बड़ी लंबाई मान वाली संरचना के साथ प्रतिस्थापित करती हैं (लंबाई-उपसर्ग स्ट्रिंग्स के लिए पहले से कहीं अधिक माना जाता था), और अक्सर रूपांतरण को तेज करने के लिए एक और पॉइंटर, एक संदर्भ गिनती और यहां तक कि एक एनयूएल भी जोड़ते हैं। C स्ट्रिंग पर वापस जाएँ। मेमोरी अब बहुत बड़ी है, जैसे कि यदि प्रत्येक स्ट्रिंग में 3 (या 16, या अधिक) बाइट्स जोड़ना एक वास्तविक समस्या है, तो सॉफ़्टवेयर को इतने सारे छोटे स्ट्रिंग्स से निपटना होगा कि कोई अन्य भंडारण विधि और भी अधिक मेमोरी बचाएगी। (उदाहरण के लिए, इतने सारे डुप्लिकेट हो सकते हैं कि एक [[ हैश तालिका |हैश तालिका]] कम मेमोरी का उपयोग करेगी)। उदाहरणों में [[C++]] [[मानक टेम्पलेट लाइब्रेरी]] <code>[[String (C++)|std::string]]</code>[[क्यूटी (टूलकिट)|Qt QString]] <code>QString</code>, [[माइक्रोसॉफ्ट फाउंडेशन क्लास लाइब्रेरी]] <code>CString</code> और कोर फाउंडेशन से C-आधारित कार्यान्वयन <code>CFString</code> और साथ ही एप्पल द्वारा फाउंडेशन से इसके ऑब्जेक्टिव-सी सहोदर <code>NSString</code> सम्मिलित हैं। [[रस्सी (कंप्यूटर विज्ञान)]] जैसे तारों को संग्रहीत करने के लिए अधिक जटिल संरचनाओं का भी उपयोग किया जा सकता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 10:08, 24 June 2023
कंप्यूटर प्रोग्रामिंग में, एक रिक्त-टर्मिनेटेड स्ट्रिंग एक वर्ण स्ट्रिंग है जिसे वर्णों वाले एक सरणी डेटा संरचना के रूप में संग्रहीत किया जाता है और एक शून्य वर्ण (शून्य के मान वाला एक वर्ण, जिसे इस आलेख में एनयूएल कहा जाता है) के साथ समाप्त किया जाता है। वैकल्पिक नाम C स्ट्रिंग हैं, जो C प्रोग्रामिंग भाषा और ASCIIZ को संदर्भित करता है हालाँकि सी (प्रोग्रामिंग भाषा) और एएससीआईआईजेड के अलावा अन्य एन्कोडिंग का उपयोग कर सकता है।[citation needed]
एक स्ट्रिंग की लंबाई (प्रथम) एनयूएल की खोज करके पाई जाती है। यह धीमा हो सकता है क्योंकि इसमें स्ट्रिंग की लंबाई के संबंध में O(n) (रैखिक समय) लगता है। इसका यह भी अर्थ है कि एक स्ट्रिंग में NUL नहीं हो सकता (मेमोरी में एक NUL है, लेकिन यह अंतिम वर्ण के बाद है जो स्ट्रिंग में "नहीं" है)।
इतिहास
शून्य-समाप्त स्ट्रिंग्स को पीडीपी-11 असेंबली भाषाओं के .ASCIZ निर्देश और PDP-10 के लिए मैक्रो-10 मैक्रो असेंबली भाषा के ASCIZ निर्देश द्वारा निर्मित किया गया था। ये सी प्रोग्रामिंग भाषा के विकास से पहले के हैं, लेकिन स्ट्रिंग के अन्य रूपों का अक्सर उपयोग किया जाता था।
जिस समय C (और जिन भाषाओं से इसे प्राप्त किया गया था) का विकास हुआ था, मेमोरी बेहद सीमित थी, इसलिए स्ट्रिंग की लंबाई को संग्रहीत करने के लिए ओवरहेड के केवल एक बाइट का उपयोग करना आकर्षक था। उस समय का एकमात्र लोकप्रिय विकल्प, जिसे सामान्यतः "पास्कल स्ट्रिंग" कहा जाता है (एक अधिक आधुनिक शब्द "लंबाई-उपसर्ग" है), स्ट्रिंग की लंबाई को संग्रहीत करने के लिए एक अग्रणी बाइट का उपयोग करता था। यह स्ट्रिंग को NUL रखने की अनुमति देता है और पहले से संग्रहीत स्ट्रिंग की लंबाई खोजने के लिए केवल एक मेमोरी एक्सेस (O(1) (स्थिर) समय) की आवश्यकता होती है, लेकिन स्ट्रिंग की लंबाई 255 वर्णों तक सीमित होती है (8-बिट बाइट्स का उपयोग करने वाली मशीन पर) . सी डिजाइनर डेनिस रिची ने एक स्ट्रिंग की लंबाई पर सीमा से बचने के लिए नल-टर्मिनेशन के सम्मेलन का पालन करना चुना और क्योंकि गिनती बनाए रखना, उनके अनुभव में, टर्मिनेटर का उपयोग करने से कम सुविधाजनक लगता था।[1][2]
इसका सीपीयू अनुदेश सेट डिज़ाइन पर कुछ प्रभाव पड़ा। 1970 और 1980 के दशक में कुछ सीपीयू, जैसे ज़िलॉग ज़ेड80 और डीईसी VAX, में लंबाई-उपसर्ग स्ट्रिंग को संभालने के लिए समर्पित निर्देश थे। हालाँकि, जैसे-जैसे नल-टर्मिनेटेड स्ट्रिंग ने कर्षण प्राप्त किया, सीपीयू डिजाइनरों ने इसे ध्यान में रखना शुरू कर दिया, जैसा कि उदाहरण के लिए आईबीएम के 1992 में ईएस/9000 520 में "लॉजिकल स्ट्रिंग असिस्ट" निर्देशों और 2015 में IBM z13 (माइक्रोप्रोसेसर) के लिए वेक्टर स्ट्रिंग निर्देशों को जोड़ने के निर्णय में देखा गया था। [3]
फ्रीबीएसडी डेवलपर पॉल-हेनिंग काम्प ने एसीएम क्यू में लिखते हुए, 2-बाइट (एक-बाइट नहीं) लंबाई पर नल-टर्मिनेटेड स्ट्रिंग्स की जीत को "अब तक की सबसे महंगी एक-बाइट गलती" के रूप में संदर्भित किया है।[4]
सीमाएं
प्रयुक्त करने में सरल होने के बावजूद, यह प्रतिनिधित्व त्रुटियों और प्रदर्शन समस्याओं से ग्रस्त रहा है।
अशक्त-समाप्ति ने ऐतिहासिक रूप से सुरक्षा समस्याएँ पैदा की हैं।[5] स्ट्रिंग के बीच में डाला गया NUL इसे अप्रत्याशित रूप से छोटा कर देगा।[6] एक सामान्य बग एनयूएल के लिए अतिरिक्त स्थान आवंटित नहीं करना था, इसलिए इसे आसन्न मेमोरी पर लिखा गया था। दूसरा यह था कि एनयूएल बिल्कुल न लिखा जाए, जिसे अक्सर परीक्षण के दौरान पता नहीं लगाया जा सका क्योंकि मेमोरी के ब्लॉक में पहले से ही शून्य था। लंबाई खोजने के खर्च के कारण कई प्रोग्राम किसी स्ट्रिंग को एक निश्चित आकार के डेटा बफ़र में कॉपी करने से पहले परेशान नहीं होते थे, जिससे अगर यह बहुत लंबा होता तो बफर ओवरफ्लो हो जाता।
शून्य को संग्रहीत करने में असमर्थता के लिए आवश्यक है कि पाठ और बाइनरी डेटा को अलग-अलग रखा जाए और विभिन्न कार्यों द्वारा नियंत्रित किया जाए (बाद वाले को डेटा की लंबाई भी प्रदान करने की आवश्यकता होती है)। गलत फ़ंक्शन का उपयोग करने पर इससे कोड अतिरेक और त्रुटियां हो सकती हैं।
लंबाई खोजने में गति की समस्याओं को सामान्यतः किसी अन्य ऑपरेशन के साथ जोड़कर कम किया जा सकता है जो कि O(n) है, जैसे कि strlcpy में। हालाँकि, इसका परिणाम हमेशा एक सहज एपीआई नहीं होता है।
कैरेक्टर एनकोडिंग
अशक्त-समाप्त स्ट्रिंग के लिए आवश्यक है कि एन्कोडिंग कहीं भी शून्य बाइट (0x00) का उपयोग न करे; इसलिए हर संभव ASCII या यूटीएफ-8 स्ट्रिंग को संग्रहीत करना संभव नहीं है।[6][7][8] हालाँकि, ASCII या यूटीएफ-8 के उपसमुच्चय - NUL को छोड़कर प्रत्येक वर्ण - को शून्य-समाप्त स्ट्रिंग में संग्रहीत करना आम बात है। कुछ सिस्टम "संशोधित यूटीएफ-8" का उपयोग करते हैं जो एनयूएल को दो गैर-शून्य बाइट्स (0xC0, 0x80) के रूप में एन्कोड करता है और इस प्रकार सभी संभावित स्ट्रिंग्स को संग्रहीत करने की अनुमति देता है। यूटीएफ-8 मानक द्वारा इसकी अनुमति नहीं है, क्योंकि यह एक लंबी एन्कोडिंग है, और इसे सुरक्षा जोखिम के रूप में देखा जाता है। इसके अतिरिक्त कुछ अन्य बाइट को स्ट्रिंग के अंत के रूप में उपयोग किया जा सकता है, जैसे 0xFE या 0xFF, जिनका उपयोग यूटीएफ-8 में नहीं किया जाता है।
यूटीएफ-16 2-बाइट पूर्णांकों का उपयोग करता है और चूँकि कोई भी बाइट शून्य हो सकती है (और वास्तव में हर दूसरा बाइट, जब एएससीआईआई पाठ का प्रतिनिधित्व करता है), शून्य-समाप्त बाइट स्ट्रिंग में संग्रहीत नहीं किया जा सकता है। हालाँकि, कुछ भाषाएँ 16-बिट यूटीएफ-16 वर्णों की एक स्ट्रिंग प्रयुक्त करती हैं, जो 16-बिट एनयूएल (0x0000) द्वारा समाप्त होती है।
सुधार
सी स्ट्रिंग हैंडलिंग को कम त्रुटि प्रवण बनाने के लिए कई प्रयास किए गए हैं। एक रणनीति strdup और strlcpy जैसे सुरक्षित कार्यों को जोड़ना है, जबकि gets जैसे असुरक्षित कार्यों के उपयोग को अस्वीकार करना है। दूसरा है सी स्ट्रिंग्स के चारों ओर एक ऑब्जेक्ट-ओरिएंटेड रैपर जोड़ना ताकि केवल सुरक्षित कॉल ही की जा सके। हालाँकि, असुरक्षित फ़ंक्शंस को कॉल करना वैसे भी संभव है।
अधिकांश आधुनिक लाइब्रेरी सी स्ट्रिंग्स को 32-बिट या बड़ी लंबाई मान वाली संरचना के साथ प्रतिस्थापित करती हैं (लंबाई-उपसर्ग स्ट्रिंग्स के लिए पहले से कहीं अधिक माना जाता था), और अक्सर रूपांतरण को तेज करने के लिए एक और पॉइंटर, एक संदर्भ गिनती और यहां तक कि एक एनयूएल भी जोड़ते हैं। C स्ट्रिंग पर वापस जाएँ। मेमोरी अब बहुत बड़ी है, जैसे कि यदि प्रत्येक स्ट्रिंग में 3 (या 16, या अधिक) बाइट्स जोड़ना एक वास्तविक समस्या है, तो सॉफ़्टवेयर को इतने सारे छोटे स्ट्रिंग्स से निपटना होगा कि कोई अन्य भंडारण विधि और भी अधिक मेमोरी बचाएगी। (उदाहरण के लिए, इतने सारे डुप्लिकेट हो सकते हैं कि एक हैश तालिका कम मेमोरी का उपयोग करेगी)। उदाहरणों में C++ मानक टेम्पलेट लाइब्रेरी std::stringQt QString QString, माइक्रोसॉफ्ट फाउंडेशन क्लास लाइब्रेरी CString और कोर फाउंडेशन से C-आधारित कार्यान्वयन CFString और साथ ही एप्पल द्वारा फाउंडेशन से इसके ऑब्जेक्टिव-सी सहोदर NSString सम्मिलित हैं। रस्सी (कंप्यूटर विज्ञान) जैसे तारों को संग्रहीत करने के लिए अधिक जटिल संरचनाओं का भी उपयोग किया जा सकता है।
यह भी देखें
संदर्भ
- ↑ Ritchie, Dennis M. (April 1993). सी भाषा का विकास. Second History of Programming Languages conference. Cambridge, MA.
- ↑ Ritchie, Dennis M. (1996). "The development of the C language". In Bergin, Jr., Thomas J.; Gibson, Jr., Richard G. (eds.). History of Programming Languages (2 ed.). New York: ACM Press. ISBN 0-201-89502-1 – via Addison-Wesley (Reading, Mass).
- ↑ IBM z/Architecture Principles of Operation
- ↑ Kamp, Poul-Henning (25 July 2011), "The Most Expensive One-byte Mistake", ACM Queue, 9 (7): 40–43, doi:10.1145/2001562.2010365, ISSN 1542-7730, S2CID 30282393
- ↑ Rain Forest Puppy (9 September 1999). "पर्ल सीजीआई समस्याएं". Phrack Magazine. artofhacking.com. 9 (55): 7. Retrieved 3 January 2016.
- ↑ "UTF-8, a transformation format of ISO 10646". Retrieved 19 September 2013.
- ↑ "Unicode/UTF-8-character table". Retrieved 13 September 2013.
- ↑ Kuhn, Markus. "UTF-8 and Unicode FAQ". Retrieved 13 September 2013.
| Features | |
|---|---|
| Standard library | |
| Standard library implementations | |
| Compilers | |
| IDEs | |
| Comparison with other languages | |
| Descendant languages | |
