अधिकांश ब्राउज़र C ++ में क्यों विकसित हुए हैं [बंद]


99

ऐसा लगता है कि अधिकांश सामान्य वेब ब्राउज़र (फ़ायरफ़ॉक्स, क्रोम, सफारी) C ++ का उपयोग करके विकसित किए गए हैं। वह कौन है?


28
फ़ायरफ़ॉक्स C ++ और जावास्क्रिप्ट में लिखा है, न कि केवल C ++ में।
जेसी मिलिकन

1
इस सवाल के कुछ पैट उत्तर होने की संभावना है, यह मानते हुए कि यह सटीक है (फ़ायरफ़ॉक्स पर जेसी की टिप्पणी पर ध्यान दें, और उन तीन और आईई के अलावा बहुत सारे ब्राउज़र हैं)। मुझे नहीं लगता कि यह एक उत्पादक है।
डेविड थॉर्नले

1
क्या यह इस प्रश्न का सही समूह है?
मार्टिन

6
@ जेसी सी इंटरप्रेटर सी ++ में नहीं लिखा है? कि थोड़े यह सब सी + + बना देगा, नहीं? (मैं गलत हो सकता हूं ..)
कैम्ब्रेका

5
@cambraca, उस तर्क के साथ, सब कुछ विधानसभा कोड है!
जुआन मेंड्स

जवाबों:


165

सवाल पूछने का दूसरा तरीका यह है कि ब्राउज़र को किस तरह के समर्थन की आवश्यकता है? छोटी सूची है:

  • पार्सिंग के लिए समर्थन ([X] HTML, CSS और [ECMA / Java] स्क्रिप्ट की समझ बनाने के लिए आवश्यक)
  • ट्री वॉकिंग / इंटरप्रिटिंग फीचर्स (पार्सिंग और बिल्डिंग UI का हिस्सा)
  • त्वरित ग्राफिक्स के लिए समर्थन
  • तेज नेटवर्किंग
  • अधिक उन्नत ब्राउज़रों के लिए: प्रक्रियाओं पर नियंत्रण और पृष्ठों के बीच मेमोरी को अलग करना
  • सभी समर्थित प्लेटफार्मों पर काम करना चाहिए

अधिकांश भाषाओं में कुछ प्रकार के पार्सिंग समर्थन होते हैं। आपके पास C, C ++, C #, Java, आदि के लिए पार्सर जनरेटर हैं। हालांकि, C और C ++ के बाकी विकल्पों पर काफी कुछ साल शुरू हैं, इसलिए एल्गोरिदम और कार्यान्वयन अधिक परिपक्व हैं। जावा में त्वरित ग्राफिक्स तक पहुंचना एक नहीं है, जब तक कि आपके पास इसे काम करने के लिए कुछ मूल एक्सटेंशन न हों। WPF on C # त्वरित ग्राफिक्स तक पहुँच प्रदान करता है, लेकिन तकनीक के साथ बनाया गया एक गंभीर ब्राउज़र होना बहुत नया है।

नेटवर्किंग वास्तव में जावा या C # पर C ++ चुनने के कारणों में से सबसे कम है। इसका कारण यह है कि शेष प्रसंस्करण उस पृष्ठ को प्रदर्शित करने की तुलना में संचार कई गुना धीमा है। तार की कच्ची गति सीमित कारक है। जावा और C # दोनों में गैर-अवरुद्ध IO समर्थन है, जैसा कि C ++ करता है। इसलिए वास्तव में इस क्षेत्र में कोई स्पष्ट विजेता नहीं है।

जावा क्यों नहीं? क्या आपने कभी जावा के साथ UI बनाने की कोशिश की है? यह वहाँ से बाहर कुछ और की तुलना में बोझिल और धीमा लगता है, क्योंकि यह है। कोई त्वरित ग्राफिक्स भी यहाँ एक बड़ा नकारात्मक नहीं है। जावा का सैंडबॉक्सिंग वास्तव में अच्छा है, और अगर यह सही तरीके से उपयोग किया जाता है, तो एक ब्राउज़र की सुरक्षा को बेहतर बनाने में मदद कर सकता है, लेकिन यह कॉन्फ़िगर करने और काम करने के लिए एक दर्द है। अधिकांश आधुनिक ब्राउज़रों के पीछे ग्राफिक्स प्रारूप समर्थन लैग्स का उल्लेख नहीं है।

C # क्यों नहीं? यदि आपका एकमात्र लक्ष्य विंडोज है, तो C # वास्तव में एक अच्छा प्रतिनिधित्व कर सकता है। समस्या तब आती है जब आप किसी और चीज का समर्थन करना चाहते हैं। मोनो को इस कार्य के लिए पर्याप्त रूप से क्रॉस प्लेटफॉर्म माना जाता है - विशेष रूप से त्वरित ग्राफिक्स समर्थन और WPF के साथ। कौन जानता है कि इसे बदलने में कितना समय लगेगा।

सी क्यों नहीं? वहाँ बस के बारे में हर प्लेटफॉर्म के लिए एक सी संकलक है (एम्बेडेड उपकरणों सहित)। हालाँकि, ऐसा बहुत कुछ है जो C आपके लिए नहीं करता है कि आपको इसके बारे में अतिरिक्त सतर्क रहना होगा। आपके पास एपीआई के सभी निम्नतम स्तरों तक पहुंच है, लेकिन अधिकांश सी डेवलपर्स जीयूआई नहीं करते हैं। यहां तक ​​कि सी GUI लाइब्रेरीज़ को ऑब्जेक्ट ओरिएंटेड तरीके से लिखा जाता है। जैसे ही आप यूआई बात करना शुरू करते हैं, एक वस्तु उन्मुख भाषा बेहतर समझ बनाने लगती है।

उद्देश्य सी क्यों नहीं? यदि आपका एकमात्र लक्ष्य Apple है, तो यह बहुत मायने रखता है। हालांकि, अधिकांश डेवलपर्स ऑब्जेक्टिव-सी को नहीं जानते हैं, और इसे सीखने का एकमात्र कारण NeXT या Apple बॉक्स पर काम करना है। सुनिश्चित करें कि आप किसी भी सी-लाइब्रेरी का उपयोग ऑब्जेक्टिव-सी के साथ कर सकते हैं, और कई प्लेटफार्मों के लिए कंपाइलर हैं, लेकिन लोगों को इस पर काम करना मुश्किल होगा। कौन जाने? हो सकता है कि Apple इस कथित कमी को चारों ओर मोड़ दे।

C ++ क्यों? वहाँ बाहर बस के बारे में हर मंच के लिए एक सी ++ संकलक है। लगभग हर GUI लाइब्रेरी में C ++ इंटरफ़ेस है, कभी-कभी यह बेहतर होता है और कभी-कभी यह बस अलग होता है। उदाहरण के लिए, Microsoft का ATL win32 C फ़ंक्शन कॉल या MFC लाइब्रेरी से बहुत बेहतर है। यूनिक्स पर GTK के लिए C ++ रैपर हैं, और मुझे आश्चर्य होगा कि अगर किसी के पास Apple के ऑब्जेक्टिव-सी GUI लाइब्रेरी के आसपास C ++ रैपर नहीं था। जावा या C # की तुलना में C ++ में प्रक्रिया प्रबंधन आसान है (उन विवरणों को आपके लिए अलग कर दिया गया है)। यह माना जाता है कि यह गति कच्चे त्वरण की तुलना में हार्डवेयर त्वरण से अधिक होती है। C ++ आपके लिए कच्चे C (जैसे बंधे हुए तार) की तुलना में अधिक चीजों का ध्यान रखता है, लेकिन फिर भी आपको चीजों को ट्विस्ट करने की स्वतंत्रता देता है।

कुछ समय के लिए, C ++ विकल्पों को खत्म करता है।


4
गैर-Apple और गैर-नेक्सटी प्लेटफार्मों के लिए, GNUStep संग्रह है। यह ज्यादातर कोको के साथ संगत है, और हर जगह के पास लानत है।
ग्रेफेड

5
याद रखें कि जावा को GUI के लिए स्विंग (जो एक भद्दा पुस्तकालय है) का उपयोग नहीं करना चाहिए। उदाहरण के लिए, हमारे पास Qt बाइंडिंग हैं।
Anto


2
मैंने कभी नहीं कहा कि ओपेरा क्यूटी पर आधारित था। मेरा तात्पर्य यह है कि एक गैर-मुक्त ब्राउज़र को बेचने के लिए वास्तव में कठिन है जब बहुत सारे उत्कृष्ट मुफ्त विकल्प हैं।
बेरिन लोरिट्श

7
पार्सर जनरेटर की उपलब्धता वास्तव में प्रासंगिक नहीं है - सभी ब्राउज़रों में एचटीएमएल, एक्सएमएल, और जेएस पार्सर हाथ से लिखे गए हैं, और सीएसएस कुछ में है।
gsnedders

89

मैंने इस बारे में एक उपन्यास लिखने का फैसला किया है इस उम्मीद में कि लोग इस पर प्रकाश डालेंगे और मुझे उभारेंगे। नहीं, नहीं, बस मजाक कर रहे हैं! मैंने हर शब्द को झेला। हर शब्द, मैं आपको बताता हूं!

'क्यों' से पहले 'क्यों' पूछें

सभी प्रमुख वेब ब्राउज़र 90 के दशक में अपने मूल का पता लगा सकते हैं। कोनेकर सफारी और क्रोम बन गए; नेटस्केप फ़ायरफ़ॉक्स बन गया; IE और ओपेरा अभी भी IE और ओपेरा हैं। इन ब्राउज़रों में सभी 15 साल का सिर होता है।

मेरा सुझाव है कि आप एक स्वीकार्य क्रॉस-प्लेटफ़ॉर्म (विंडोज / मैक / यूनिक्स और इससे भी बदतर) भाषा का नाम देने का प्रयास करें जो 1995 के आसपास उपलब्ध थी जब आधुनिक ब्राउज़र की उत्पत्ति हुई थी। C / C ++ में कोर का निर्माण करने के लिए, आपको एक कंपाइलर और प्लेटफ़ॉर्म लाइब्रेरी को बनाना या खरीदना और बदलना होगा।

अाज कैसा रहेगा? विकल्प क्या हैं?

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

भाषा विकल्प कम से कम इन समस्याओं को प्रस्तुत करता है:

  1. ज्ञान की समस्याएं - डेवलपर्स को किराए पर लेना या प्रशिक्षण देना या योगदानकर्ताओं को आकर्षित करना
  2. संगठनात्मक / सामाजिक समस्याएं - भाषा स्वीकृति
  3. भाषा कार्यान्वयन: गति, प्लेटफ़ॉर्म समर्थन, टूलींग
  4. भाषा की शक्ति

1: ज्ञान की समस्याएं

आपको ऐसे लोग कहां मिलते हैं जो भाषा जानते हैं या इसे सीख सकते हैं? यह OCaml, F #, Haskell, Common Lisp और D जैसी भाषाओं के लिए एक बाधा है, जो तेज़ और उच्च-स्तरीय हैं जो किसी ब्राउज़र को अच्छी तरह से लिखने के लिए पर्याप्त हैं, लेकिन उनके कुछ अनुयायी हैं (10k-100k रेंज में, हो सकता है कि आप उदारतापूर्वक सभी शौक और शिक्षाविदों की गणना करें।

2: सामाजिक / संगठनात्मक समस्याएं

उपरोक्त कार्गो-पंथ उत्तर के लिए कोरोलरी:

  • एक खुला स्रोत सी, सी ++, C # या जावा का उपयोग नहीं कर ब्राउज़र होगा माना जाता है कि योगदानकर्ताओं के साथ कठिनाई होती है।
  • C, C ++, C # या Java का उपयोग न करने वाले एक मालिकाना ब्राउज़र को परियोजना प्रबंधकों को अधिकांश संगठनों में गंभीर रूप से चिल्लाया जाएगा।

3. तकनीकी समस्याएं

यहां तक ​​कि आधुनिक समय में, आपको पृष्ठों को प्रस्तुत करने और जावास्क्रिप्ट चलाने के गहन गहन भागों के लिए एक काफी तेज भाषा की आवश्यकता है। आप GUI तत्वों के निर्माण के लिए एक उच्च-स्तरीय भाषा के साथ पूरक करने का विकल्प चुन सकते हैं, आदि (जैसे सी ++ और जावास्क्रिप्ट का फ़ायरफ़ॉक्स दृष्टिकोण) लेकिन आपको भाषाओं के बीच घनिष्ठ एकीकरण करना होगा; आप बस "ठीक है, C # और Lua" नहीं कह सकते। जब तक आप आधार भाषा के रूप में C या C ++ नहीं चुनते, आपको संभवतः उस पुल का निर्माण और डीबग करना होगा।

क्रॉस-प्लेटफॉर्म विकास कीड़े का एक और बैग है। आप C # या F # का उपयोग कर सकते हैं और भविष्य में GTK # और मोनो के जीवित और अच्छी तरह से अपनी उंगलियां पार कर सकते हैं। आप कॉमन लिस्प, हास्केल, ओकेमेल ... ... सौभाग्य पा सकते हैं, जो कि विंडोज और मैक और लिनक्स पर काम कर रहे हैं ।

4. भाषा शक्ति

उस सब के बाद, आपको एक बड़ी मात्रा में कार्यक्षमता का निर्माण करना होगा, इसलिए यदि आप एक निम्न-स्तरीय भाषा चुनते हैं, तो आपको पहले की तुलना में कोडर की भी एक समान सेना की आवश्यकता होती है। ध्यान दें कि किसी ने वास्तव में लगभग पंद्रह वर्षों में खरोंच से एक ब्राउज़र नहीं बनाया है। यह आंशिक रूप से है क्योंकि (आश्चर्य!) यह कठिन है।

विशेष रूप से, एक जावास्क्रिप्ट दुभाषिया होने में समस्या 3 (एक प्राप्त करें) या समस्या 4 (एक का निर्माण) है।

निष्कर्ष:

यदि आपने आज (2011 की शुरुआत में) एक तीन-प्लेटफ़ॉर्म (विंडोज / मैक / * निक्स) ब्राउज़र विकसित किया, तो कुछ विकल्प क्या हैं?

  • सी: देखें (2)। C ++ के लिए हर किसी को कोलाहल हो रहा है। एक क्रॉस-प्लेटफ़ॉर्म टूलकिट का चयन करने या एक (1, 2, 3 और 4) के निर्माण का मज़ा लें। यह भी देखें (4); मज़ेदार एक स्थिर, सुरक्षित ब्राउज़र का निर्माण करें।
  • C ++: क्रॉस-प्लेटफ़ॉर्म टूलकिट का चयन करने या एक (1, 2, 3 और 4) के निर्माण का मज़ा लें। मज़ेदार (4) स्थिर, सुरक्षित ब्राउज़र का निर्माण करें।
  • सी या सी ++ और एचएलएल: आपका सबसे अच्छा दांव। गतिशील भाषा पर अपना जहर उठाओ; देखें (1) और (2)। बहुत सारी अच्छी भाषाएँ, प्रत्येक के बहुत कम अनुयायी। (1, 2, 3 और 4) टूलकिट पर।
  • जावा: दूसरा सबसे अच्छा दांव, अगर आपको मध्य प्रबंधन को खुश करना है। देखें (4); जावा में विशाल चीजों का निर्माण इस सूची में किसी भी चीज़ की तुलना में बहुत अधिक कोड लेता है, लेकिन शायद सी।
  • स्काला: बीट्स जावा ऑन (4); (1) और (2) लेकिन यह पकड़ रहा है।
  • सी और जावास्क्रिप्ट: एक विशेष मामले के रूप में, यह अपील कर रहा है क्योंकि आपको पहले से ही जावास्क्रिप्ट इंटरप्रेटर का निर्माण या अधिग्रहण और आत्मसात करना होगा। (इसलिए फ़ायरफ़ॉक्स।) (1, 2, 3 और 4) टूलकिट पर; मोज़िला लोगों ने अपने IIRC का निर्माण किया।
  • C #: मज़े करो (3) पर। आप शायद जीटीके # के साथ फंस गए हैं, हालांकि यह अच्छा है, या जीटीके # और विंडोज फॉर्म के ऊपर अपनी खुद की परत और रेंडरर का निर्माण करना है।
  • Ruby / Python / Perl / Racket / Lua / Erlange आदि। आपको क्रॉस प्लेटफॉर्म विजेट लाइब्रेरी और गति पर (3) मिला है। मूर का नियम आपके साथ है (4) पर; ब्राउज़रों की बढ़ती मांग आपके खिलाफ है।
  • OCaml, Haskell, Common Lisp, Smalltalk: (1) और (2) हुकुम में। क्रॉस-प्लेटफ़ॉर्म विकास के लिए कोई गति मुद्दे, शायद, लेकिन (3) और आपको किसी भी तरह C / C ++ पुस्तकालयों को अपना सब कुछ या पुल बनाना होगा।
  • उद्देश्य-सी: (3) मुझे यकीन नहीं है कि क्रॉस-प्लेटफॉर्म विकास यहां कैसे काम करेगा।

यदि हम अगले कुछ वर्षों में एक और प्रमुख ब्राउज़र वृद्धि देखते हैं, तो मुझे यकीन है कि यह सी या सी ++ और एक गतिशील भाषा (जैसे फ़ायरफ़ॉक्स) में लिखा जाएगा, चाहे खुला स्रोत या मालिकाना।

संपादित करें (३१ जुलाई २०१३) : हैकर न्यूज़ पर टिप्पणी करने वालों का कहना है कि यह रस्ट एंड गो (विशेष रूप से मेरे उत्तर के संबंध में नहीं) का उल्लेख करता है, जो "विविध उपवास" बाल्टी में अस्पष्ट रूप से आते हैं। भाषाओं की इस सूची को समतावादी और अद्यतित रखने की कोशिश एक हारी हुई लड़ाई होगी, इसलिए इसके बजाय मैं इसे लिखने और इसे छोड़ने के समय के रूप में प्रतिनिधि नमूना कह रहा हूं।


4
+1 यह ध्यान देने के लिए कि पहली बार एक विशेष ब्राउज़र को भी विकसित किया गया था, एक महत्वपूर्ण भूमिका निभाता है।
स्पार्कली

3
यह ध्यान देने योग्य है कि जबकि IE आज क्रॉस-प्लेटफॉर्म नहीं हो सकता है , यह निश्चित रूप से एक समय में था, और इसकी वर्तमान बाजार हिस्सेदारी लगभग निश्चित रूप से उस क्रॉस-प्लेटफॉर्म की क्षमता से (कम से कम भाग में) प्राप्त होती है।
जेरी कॉफिन

2
ध्यान दें कि IE IE4 के आसपास एक बार क्रॉस-प्लेटफॉर्म था
जेसनफ्रंट

2
कब के लिए +1। वही एकमात्र कारण है। अगर किसी ने आज एक ब्राउज़र प्रोजेक्ट शुरू किया है, तो वे संभवतः
हेनरी

4
@ हेनरी, संभावना नहीं है कि वे C ++ का उपयोग करके बाहर कर देंगे। उत्तर नोट करता है कि C ++ अभी भी पहेली का हिस्सा है।
अनाम टाइप

36

गति

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

यही कारण है कि गेम, नॉन-कोर पार्ट्स (जैसे फ़ाइल इंपोर्टर्स) ऑफ़िस, और अधिक अभी भी C ++ में लिखे गए हैं।

MSalters से प्रतिक्रिया शामिल करने के लिए संपादित


3
खेलों के अलावा, मेरा मानना ​​है कि इन कारणों से उन ऐप्स को C ++ में लिखा जाता है। हालांकि यदि आपके पास पहले हाथ का ज्ञान है तो मुझे गलत साबित होने में खुशी होगी।
हेनरी

2
प्रत्यक्ष ज्ञान? वीएस 2010, ऑफिस 2010 दोनों विशाल ऐप सूट हैं फिर भी वे जो करते हैं उस पर बहुत तेज़ हैं। जबकि दोनों में एक बड़ी COM विरासत, और एमएस विरासत है, लेकिन प्रदर्शन अभी भी उपयोगकर्ताओं के लिए सबसे महत्वपूर्ण बात है।
अनाम टाइप

8
कार्यालय में और क्या लिखा जाएगा? वीबी? C और C ++ Microsoft के लिए एकमात्र विकल्प हैं कि वे बड़े ऐप्स लिख सकें। C # कृपया न कहें
टोबी एलन

4
@ विक्टर: मैंने VS2010 के लिए स्रोत नहीं देखा है, इसलिए यह पूरी तरह से सी # में पूरी तरह से लिखा जा सकता है।
रयान हेस

3
यदि कार्यालय C # ऐप है, तो मूल रिबन एक MFC नियंत्रण क्यों था, और हमें C # एक विकसित होने के लिए युगों की प्रतीक्षा करनी थी? इन विशाल ऐप्स में से कोई भी C # में फिर से नहीं लिखा जाएगा, उन्हें WPF gui (जैसे VS2010) में लपेटा जाएगा और पुराने कोड के थोक का पुन: उपयोग किया जाएगा। यहां तक ​​कि एमएस के पास अपने सबसे बड़े ऐप को पूरी तरह से फिर से लिखने के लिए संसाधन नहीं हैं - न कि अगर वे उनके लिए सुविधाओं को जोड़कर समय बिताना चाहते हैं।
gbjbaanb

17

पोर्टेबिलिटी

मैं केवल अनुमान लगा सकता हूं, लेकिन आप ऐसे सॉफ्टवेयर उत्पादों का उल्लेख कर रहे हैं जो कई प्लेटफार्मों को लक्षित करते हैं, और सी ++ को किसी भी मंच पर संकलित किया जा सकता है।


+10 - कच्चे प्रदर्शन के अलावा, मुझे लगता है कि यह वास्तविक कारण है कि अधिकांश ब्राउज़र IE के अपवाद के साथ C ++ में हैं। अधिकांश ब्राउज़र कई प्लेटफार्मों पर काम करते हैं और कुछ भाषाएं / रूपरेखाएं हैं जो समान स्तर पर प्रदर्शन कर सकते हैं और क्रॉस-प्लेटफॉर्म संगत हो सकते हैं।
जॉर्डन पार्मर

मैंने यह पहले भी सोचा था, लेकिन एक वेब ब्राउज़र की तरह एक जीयूआई केंद्रित अनुप्रयोग के लिए। क्या C ++ वास्तव में जावा कहने की तुलना में अन्य ऑपरेटिंग सिस्टम के लिए बहुत अधिक पोर्टेबल है?
जॉनफैक्स

1
क्या कोई ब्राउज़र वास्तव में GUI केंद्रित है?
क्रिस वान बाल

@JohnFx - सही है, GUI भाग शायद वह पोर्टेबल नहीं है। लेकिन उदाहरण के लिए एक ब्राउज़र एप्लिकेशन का मूल HTML को संभालने, DOM ट्री बनाने, जावास्क्रिप्ट को पार्स करने और इसे तेजी से निष्पादित करने के बारे में है। एक अच्छी तरह से डिज़ाइन किया गया एप्लिकेशन आसानी से एक ही कोर साझा कर सकता है और प्रत्येक प्लेटफ़ॉर्म के लिए अलग-अलग यूआई कोड हो सकता है। और हां, C ++ जावा (लेकिन GUI के बिना) की तुलना में बहुत अधिक पोर्टेबल है, क्योंकि C ++ के लिए आपको केवल सीपीयू को लक्षित करने वाले एक कंपाइलर की आवश्यकता है। जावा के लिए आपको पूर्ण रूपरेखा की आवश्यकता है।
पीट

यह मेरी समझ थी कि HTML प्रसंस्करण की अधिकांश हिम्मत कुछ मुख्य टूल जैसे WebKit द्वारा की जाती है। शायद यह इसलिए है क्योंकि वे सी ++ में हैं कि पूरे ब्राउज़र हैं?
जॉन एफएक्स 1'11

13

(मैं फ़ायरफ़ॉक्स पर लगभग पाँच वर्षों से काम कर रहा हूँ।)

प्रश्नकर्ता सही है कि फ़ायरफ़ॉक्स का बहुत सारा कोड C ++ है, और वास्तव में C ++ बहुमत है यदि आप कोड की पंक्तियों द्वारा गणना करते हैं (हालांकि यह पूरी कहानी नहीं बताता है, क्योंकि हमारे पास बहुत सारे जावास्क्रिप्ट हैं, और JS अधिक है C ++ से संक्षिप्त)।

लेकिन वास्तव में, फ़ायरफ़ॉक्स बहुत अलग-अलग भाषाओं में लिखा गया है:

  • सी ++
  • सी (एनएसएस, एनएसपीआर, हमारे द्वारा आयात किए गए विभिन्न पुस्तकालय)
  • x86 और एआरएम विधानसभा
  • जावास्क्रिप्ट
  • XUL (HTML- जैसी मार्कअप भाषा) और CSS
  • उद्देश्य C (MacOS- केवल कोड)
  • जावा (केवल Android कोड)
  • एकाधिक कस्टम इंटरफ़ेस-परिभाषा भाषाएँ (XPIDL, IPDL)
  • WebIDL (एक अन्य इंटरफ़ेस-परिभाषा भाषा, लेकिन यह कस्टम नहीं है, हालांकि कोड जनरेटर है)
  • अजगर (कोड जनरेटर)

मुझे यकीन है कि कुछ भूल रहा हूँ।

यह सूची महत्वपूर्ण है क्योंकि यह अविश्वसनीय जटिलता पर संकेत देती है जो वेब ब्राउज़र के पीछे बैठती है।

हां, फ़ायरफ़ॉक्स में बहुत सी + + कोड है, और हाँ, इस तथ्य के साथ कुछ करना है कि नेटस्केप की स्थापना के समय सी ++ इस तरह की सबसे अच्छी भाषा थी। लेकिन मैं यह भी मानता हूं कि हम जो करते हैं, उसके लिए आज कोई बेहतर भाषा नहीं है।

किसी अन्य भाषा में पुस्तकालयों का एक पारिस्थितिकी तंत्र उतना मजबूत नहीं है (हम बाहरी कोड पर बहुत अधिक भरोसा करते हैं)। कुछ अन्य भाषाएं आपको C ++ की तरह पूर्ण-स्टैक नियंत्रण प्रदान करती हैं (हम नियमित रूप से हमारे कस्टम हीप एलोकेटर को ट्वीक करते हैं और सभी प्रकार की मेमोरी-असुरक्षित चीजों को तेज या कम मेमोरी का उपयोग करने के लिए करते हैं)। कुछ अन्य भाषाओं ने आपको एक मानक तरीके से अधिकांश पुस्तकालय को फिर से लागू करने दिया (हमारे पास हमारे स्वयं के तार और संग्रह कार्यान्वयन हैं, जो हमारी आवश्यकताओं के अनुरूप हैं)। कुछ अन्य भाषाओं में आप अपने स्वयं के कचरा संग्रहकर्ता को लागू कर सकते हैं। और इसी तरह।

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


क्या ये मेमोरी-असुरक्षित कार्य सुरक्षा समस्याओं के स्रोत हैं?
डेमी

12

ठीक है, आप प्राप्त करने के लिए उन उत्पादों सीधे के डेवलपर्स पूछना होगा जवाब है, लेकिन मुझे लगता है यह अपनेपन का एक संयोजन है (के रूप में करने का विरोध किया बाईटकोड एक देशी बाइनरी संकलन), प्रदर्शन, और (यह क्या उन डेवलपर्स सबसे अच्छा पता था कि है) उपकरण (सी, सी ++ जैसी भाषाओं की तुलना में एसटीएल जैसे अच्छे श्रम-बचत वाले गैजेट से भरा है)।


10

इतिहास

प्रत्येक ब्राउज़र में कुछ इतिहास होता है जिसने भाषा की पसंद को प्रभावित किया है।

उदाहरण के लिए, क्रोम और सफारी दोनों ही WebKit पर आधारित हैं, जिसका मूल KDE प्रोजेक्ट के KHTML भाग में है। KDE मूल रूप से Qt GUI टूलकिट के प्रदर्शन के रूप में (भाग में) बनाया गया था, इसलिए KDE, कुल मिलाकर, C ++ प्रोजेक्ट है। केडीई के सभी नए प्रोजेक्ट उस समय पूरी तरह से C ++ में लिखे गए थे, इसलिए यह KHTML के लिए एक तार्किक विकल्प था। इसके बाद से अन्य GUI टूलकिट का उपयोग करने के लिए पोर्ट किया गया है।

ओपेरा का प्रेस्टो इंजन प्रदर्शन और छोटे बाइनरी आकार को ध्यान में रखकर लिखा गया था: सी ++ तार्किक विकल्प था।

Microsoft के IE को ActiveX घटकों के संग्रह के रूप में लिखा गया था, जिसे COM बाइंडिंग वाली किसी भी भाषा में लिखा जा सकता था, लेकिन संभवतः C ++ के सबसेट में लिखा गया था, क्योंकि उनके कोडबेस का अधिकांश हिस्सा पहले से ही उस भाषा में लिखा गया है।

नेटस्केप के मोज़िला को C ++ संभावना में लिखा गया था क्योंकि पोर्टेबिलिटी उनकी एक प्रमुख चिंता थी। C और C ++ कंपाइलर (वस्तुतः) सर्वव्यापी हैं, और इसलिए यह एक तार्किक विकल्प था।

इन विकल्पों का कोई अंतर्निहित तकनीकी कारण नहीं है । यह "उस समय एक अच्छे विचार की तरह लग रहा था।"


8

C और C ++ में नेटवर्किंग करना आसान है, क्योंकि यदि आप नहीं चाहते हैं तो आपको पुस्तकालयों का उपयोग नहीं करना है। मुझे संदेह है कि C ++ पसंद की भाषा है क्योंकि यह C के फायदों की अनुमति देता है:

  • गति
  • अनुकूलन
  • पोर्टेबिलिटी की एक निश्चित राशि
  • संकलित भाषा, व्याख्या नहीं

OOP के लाभों के साथ युग्मित:

  • तानाना
  • आसान दृश्य
  • गैर-महत्वपूर्ण कार्यों जैसे स्ट्रिंग प्रसंस्करण और डेटा संरचनाओं के लिए बेहतर पुस्तकालय समर्थन

क्या जावा या C # के वे फायदे नहीं हैं?
निपुण

5
मैंने दोनों में ऐप विकसित किए हैं, और मैं कहूंगा कि सीमित नेटवर्क कार्यक्षमता के लिए वे ठीक हैं। हालाँकि, मैं ऐसा कुछ भी नहीं बनाना चाहूंगा जो एक ब्राउज़र के रूप में नेटवर्क हिस्से पर केंद्रित हो। मैं जो कुछ हो रहा था, उस पर बहुत अधिक नियंत्रण चाहता हूं, और मैं एक संकलित भाषा चाहता हूं ।
माइकल के

जावा और C # भी संकलित हैं। किसी भी ब्राउज़र का महत्वपूर्ण हिस्सा - GUI के निर्माण की बात आते ही C # का जावा पर लाभ होगा। जावा पोर्टेबिलिटी के साथ एक फायदा होगा। जावा और C # दोनों को लक्ष्य प्लेटफ़ॉर्म पर पुनः स्थापित किया गया है - यकीनन बेहतर गति सुधार के लिए।
बेरिन लोरेट्स

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

1
आप इसे और अधिक पीछे नहीं कर सकते थे! नेटवर्किंग; आप कर्ल के लिए खोल सकते हैं और ब्राउज़र बस के रूप में तेजी से होगा। नेटवर्क CODE धीमा सा नहीं है। और अगर यह एक पुस्तकालय नहीं है तो क्या है? स्ट्रिंग प्रसंस्करण; यह किसी भी html ब्राउज़र का मूल है, यह गैर-महत्वपूर्ण नहीं है और मैं एक भी भाषा के बारे में नहीं सोच सकता, जिसमें सी + + के अलावा अन्य से भी बदतर स्ट्रिंग हैंडलिंग हो
हेनरी

4

जब ब्राउज़रों के पहले दौर के लिए कोड की पहली पंक्तियाँ लिखी गईं, तो C # और Java मौजूद नहीं थे। न ही रूबी ने। पाइथन आसपास रहा हो सकता है, लेकिन यह अभी भी उस बिंदु पर एक छोटा होमब्रेव प्रोजेक्ट था।

असल में, वास्तव में C ++ के अलावा कोई अन्य विकल्प नहीं थे , जो कि एक ऐसे ब्राउज़र का निर्माण करने की अनुमति देता जो तेज और कई अलग-अलग प्लेटफार्मों पर चलता हो।

तो उन्हें C ++ में क्यों लिखा गया? क्योंकि वह एकमात्र ऐसी भाषा उपलब्ध थी, जिसमें उन्हें लिखा जा सकता था।


1
यकीन नहीं होता कि 'नए दौर' से आपका क्या मतलब है। लेकिन FF और IE में कोड बेस होते हैं जो 90 के दशक के मध्य में वापस चले जाते हैं, और अधिकांश नए ब्राउज़र रेंडरिंग इंजनों में से एक का उपयोग करते हैं (उदाहरण के लिए, क्रोम WebKit का उपयोग करता है)
ग्रैंडमास्टरबी

2
एफएफ ने विरासत नेटस्केप कोड (यानी कि 90 के दशक के मध्य तक) से छुटकारा पा लिया और अपने स्वयं के रेंडरिंग इंजन को लागू किया। WebKit एक तुलनात्मक रूप से नया रेंडरिंग इंजन (क्रोम और सफारी द्वारा प्रयुक्त) भी है। IE अभी भी विरासत ब्लोट है जो इसे नीचे तौलना जारी रखता है। इसलिए मैं यहाँ असहमत हूँ।
बेरिन लोरिट्श

2
विकिपीडिया के अनुसार कम से कम, जेको और वेबकिट दोनों 1998 के आसपास शुरू हुए। सी # उस समय के आसपास नहीं था, और जावा दृश्य पर नया था (और सुपर सुस्त और फिर गुई की पीठ पर भयानक था), ताकि यह एक उपयुक्त विकल्प नहीं रहा। इसलिए मुझे नहीं पता कि अन्य भाषाएं क्या उपयुक्त होंगी। शायद पास्कल।
ग्रैंडमास्टरबी

1
@Berin Loritsch: हां, लेकिन किसी भी बिंदु पर उन्होंने बस सभी मौजूदा कोड को बाहर नहीं फेंका और बहुत शुरुआत से ही (सब कुछ पर) शुरू कर दिया, जो कि उन्हें दूसरी भाषा में बदलने के लिए बहुत कुछ करना था। इसके अलावा, जो लोग एफएफ के बारे में अपने निर्णय के लिए सी ++ को अच्छी तरह से जानते / जानते हैं वे वैसे भी एक अलग भाषा में स्विच करने की संभावना होगी।
जेरी कॉफिन

2
@ बेरिन लोरिट्श बकवास। FF अभी भी गेको (1997) पर आधारित है और वेबकिट khtml (1998) पर आधारित है।
हेनरी

4

क्योंकि अन्य भाषाओं में लिखे गए ब्राउज़र (जैसे, हॉटजवा, जाहिर तौर पर जावा में पर्याप्त लिखे गए) को कभी भी बाजार में स्वीकृति / प्रवेश की कोई पर्याप्त डिग्री हासिल नहीं हुई है।

मैं वर्तमान यात्रा के बारे में कुछ नहीं कह सकता (या सबसे हाल ही में - HotJava के काफी समय से अपडेट नहीं किया गया है), लेकिन जब मैंने इसे आज़माया, तो बाजार में पैठ की कमी (कम से कम मुझे) बेहद आसान समझ में आई - यह काफी कुछ वेब पेजों के साथ बदसूरत, धीमा और असंगत था। अंततः, यह एक आधार पर आधारित प्रतीत होता है जो कभी भी बाहर नहीं निकलता है: कि वेब में मुख्य रूप से जावा एप्लेट शामिल होंगे, जिसमें HTML एक रैपर की तुलना में थोड़ा अधिक होता है, जो बताता है कि एप्लेट्स कहां प्रदर्शित होते हैं।

इसका एक हिस्सा संभवतः ऐतिहासिक भी है: अधिकांश बड़े वेब ब्राउज़र लंबे समय से हैं। जब वे पहली बार लिखे गए थे, तो परिदृश्य बहुत अलग था: सी ++ एक "गर्म" नई भाषा थी, इसलिए इसका उपयोग बहुत सारे नए विकास के लिए किया जा रहा था। ब्राउज़र्स आस-पास के सबसे अधिक उपयोग किए जाने वाले सॉफ़्टवेयर में से कुछ बन गए हैं, जबकि उस समय के कई अन्य लोग गुमनामी में बदल गए हैं।

मुझे लगता है कि भाषा के प्रदर्शित "रवैये" पर भी प्रभाव पड़ता है: सी ++ (जैसे सी पहले) ने हमेशा व्यावहारिकता और व्यावहारिकता पर जोर दिया है। यह मूल रवैया उन प्रोग्रामर्स को आकर्षित करता है जो व्यावहारिक भी हैं। कई अन्य भाषाएं लालित्य जैसी चीजों पर बहुत अधिक जोर देती हैं - और ऐसा करने में, वे प्रोग्रामर को आकर्षित करते हैं जो उसी तरह सोचते हैं। इसके साथ समस्या यह है कि मुझे "लिस्प प्रभाव" कहा जाता है। लक्षणों में शामिल हैं:

  1. सबसे तुच्छ चीजों के सबसे सुरुचिपूर्ण कार्यान्वयन पर अंतहीन तर्क ।
  2. फीचर्स को फ्रीज करने और कुछ को खत्म करने में असमर्थता (यहां तक ​​कि खामियों के साथ)
  3. समझौता करने में असमर्थता। जो कोई भी मुझसे असहमत है, वह सिर्फ गलत नहीं है, बल्कि मूर्ख या दुष्ट होना चाहिए।

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

ऐसी भाषाएं भी हैं जो निस्संदेह ठीक काम करेंगी, लेकिन (सही या गलत तरीके से) बस (या महत्वपूर्ण समय पर, नहीं है) किसी के लिए बाजार में हिस्सेदारी कभी भी उनमें एक ब्राउज़र लिखा है। एक पूर्ण ब्राउज़र के आकार और जटिलता को देखते हुए, यह बहुत से लोगों और एक को विकसित करने में काफी समय लेता है। उस तरह के निवेश से, बहुत से लोग विकास उपकरण जैसी चीजों के बारे में अपेक्षाकृत रूढ़िवादी हो जाते हैं।


1
WRT बिंदु 3, मैं निश्चित रूप से योग्यता के बिना जोर होगा, कि लेखन नेटवर्क की ओर मुख सी परिवार में सॉफ्टवेयर है या तो मूर्ख है या बुरा है, क्योंकि यह जरूरत पर जोर देता या तो अनजाने में (बेवकूफ) या जानबूझकर (बुराई) एक प्रणाली व्यापक रूप से सुरक्षा लागू करने के लिए जाना जाता है के साथ काम छेद है कि होगा अपने उपयोगकर्ताओं के लिए नुकसान का कारण। यह नैतिक रूप से इस पर चित्रित लक्ष्य के साथ एक सैनिक बॉडी कवच ​​देने के बराबर है।
मेसन व्हीलर

9
@ मेसन: प्रश्न में वास्तव में बड़ी-बड़ी बातों का आपका प्रदर्शन निश्चित ही काबिले तारीफ है।
जेरी कॉफिन

2
@ मेसन: बकवास। एक सुरक्षा छेद (जो पहले से ही तय किया गया था, लेकिन कई sysadmins ने अपडेट कोड स्थापित करने की जहमत नहीं उठाई थी) यह भी सबूत के करीब नहीं है कि एक ही भाषा में लिखे गए सभी कोड "नुकसान पहुंचाएंगे" या किसी भी प्रकार का। OpenBSD (एक उदाहरण के लिए) का MacOS के पास्कल-आधारित संस्करण की तुलना में काफी बेहतर सुरक्षा इतिहास है, यहां तक ​​कि इसके आकांक्षी भी।
जेरी कॉफिन

5
@ मेसन: नहीं, आप हैं। सबसे पहले, मॉरिस वर्म ने एक प्रोरम का इस्तेमाल किया getsजो कि इस्तेमाल किया गया था , जो एक भयानक कार्य है, लेकिन शायद ही अपरिहार्य है (और निश्चित रूप से भाषा के लिए "मौलिक" या ऐसा कुछ भी नहीं)। दूसरा, C ++ किसी भी मामले में C जैसी भाषा नहीं है। तीसरा, ओपनबीएसडी काफी अच्छी तरह से प्रदर्शित करता है कि सुरक्षित सॉफ्टवेयर कर सकते हैं और सी में लिखा है। कोई "अंतर्निहित भाषा दोष" नहीं है जो सी में ठोस, सुरक्षित सॉफ्टवेयर को लिखने से रोकता है। ओपनबीएसडी का छोटा बाजार हिस्सा इंगित करता है कि सुरक्षा सबसे बड़ी चिंता का विषय नहीं है। लोग।
जेरी कॉफिन

6
@ मेसन: बफ़र ओवररन getsइस तथ्य का एक सरल परिणाम है कि आप इसे उस बफ़र की लंबाई से नहीं गुज़ारते हैं जिसका आप उपयोग कर रहे हैं। इसके बारे में भाषा के लिए कुछ भी मौलिक नहीं है - आप पास्कल (और मेरे पास) में एक ही काम कर सकते हैं। एक बुद्धिमान हमलावर के खिलाफ सुरक्षित सॉफ्टवेयर लिखना भाषा की परवाह किए बिना आसान नहीं है। तीनों में अनुभव के आधार पर, यह पास्कल की तुलना में सी में थोड़ा आसान है, और सी में की तुलना में सी ++ में बहुत आसान है
जेरी कॉफिन

3

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

एक समझदार दुनिया में, नेटवर्क-सामना करने वाले सॉफ़्टवेयर लिखने वाले लोगों को एक ऐसी भाषा का उपयोग करने के बारे में सोचा जाएगा, जो सी के सभी अंतर्निहित सुरक्षा मुद्दों से दुखी होती है, और वास्तव में ऐसा करना आपराधिक लापरवाही का कार्य होगा। (अभी देखें कि पिछले 15 वर्षों में विभिन्न ब्राउज़रों के खिलाफ कितने बफर अतिप्रवाह कारनामे पाए गए हैं? ये कोडर कितने मिलियन डॉलर के नुकसान के लिए जिम्मेदार हैं?)

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

मजेदार तथ्य: मॉरिस वर्म ने 1988 में इंटरनेट पर हिट किया, तब तक सी में OSes और नेटवर्क-फेसिंग सॉफ्टवेयर के साथ समस्याओं का निर्णायक प्रदर्शन किया, (जो आज भी हल नहीं हुए हैं, क्योंकि वे भाषा में निहित दोष हैं ,) Apple सबसे उन्नत ऑपरेटिंग सिस्टम जारी कर रहा था जिसे दुनिया ने अब तक देखा था, कई सालों के लिए, पास्कल में पहले से ही लिखा हुआ था।


15
है ना? मुझे मैक ओएस बहुत अच्छा लगा, लेकिन इसे दुनिया का सबसे उन्नत ओएस कहा जाता है जो मूर्खतापूर्ण है। यह यूनिक्स और वीएमएस के रूप में एक ही बॉल पार्क में नहीं था, अकेले आईबीएम बड़े लोहे के सिस्टम को चलो: एकल उपयोगकर्ता, कोई वर्चुअल मेमोरी, सीमित प्रक्रिया प्रबंधन। यह सुनिश्चित करने के लिए कि यह एक बहुत अच्छी खिड़की प्रणाली थी, लेकिन यहां तक ​​कि ज़ेरॉक्स पार्स और व्युत्पन्न शैक्षणिक परियोजनाओं से व्युत्पन्न था। मुझे यह भी लगता है कि मैक ओएस का अधिकांश भाग वास्तव में M68k असेंबली में लिखा गया था। पुस्तकालयों ने पास्कल फ़ंक्शन कॉल मानकों का उपयोग किया क्योंकि यह उम्मीद थी कि पास्कल प्राथमिक अनुप्रयोग भाषा होगी।
चार्ल्स ई। ग्रांट

5
2000 के पूर्व के Apple के ऑपरेटिंग सिस्टम MS समकक्ष के मुकाबले अधिक स्थिर नहीं थे। जब मैं 90 के दशक में दो प्रोजेक्ट्स पर काम कर रहा था, एक मैक ओएस के साथ और दूसरा NT के साथ, मेरे पास समान क्रैश और रीबूट की आवश्यकता थी। अब वे सभी सी आधारित भाषा के कुछ प्रकार हैं। (Apple अपने वर्तमान सामान के लिए Objective-C का उपयोग करता है)। C आधारित भाषाओं में सुरक्षा अधिक कठिन हो सकती है, लेकिन किसी भिन्न भाषा का उपयोग करना इसे अचानक अधिक सुरक्षित नहीं बनाता है।
बेरिन लोरिट्श

13
@ मेसन, तथ्य यह है कि मैक को उस समय उन विशेषताओं की आवश्यकता नहीं थी, इसका मतलब यह नहीं है कि वे महत्वहीन हैं। आपने एक अयोग्य कथन दिया कि Apple OS दुनिया में सबसे उन्नत था, लेकिन जाहिर है कि आपका वास्तव में मतलब यह था कि इसमें सबसे परिष्कृत उपयोगकर्ता इंटरफ़ेस था। यह एक रक्षात्मक बयान है, लेकिन जितना आपने लिखा है उससे कम भव्य नहीं है। एक प्रयोग करने योग्य GUI लिखना कठिन है। एक विश्वसनीय पेजेड मेमोरी सिस्टम लिखना कठिन है। यह कहना कि एक और अधिक महत्वपूर्ण है तो दूसरा मूर्खतापूर्ण है। उपभोक्ता स्तर की गणना जैसा कि हम जानते हैं कि यह अब दोनों के बिना मौजूद नहीं हो सकता है।
चार्ल्स ई। ग्रांट

5
@ मेसन: आपका अनुभव स्पष्ट रूप से (बेहद) किसी और सभी से अलग है - कई मामलों में। :-)
जैरी कॉफ़िन

3
@ मेसन: पूर्व-मैक OSX को "उन्नत" के रूप में संदर्भित करने के लिए LOL। Apple OS दुर्घटनाओं का एक निरंतर स्रोत था, कम से कम इसकी अत्यंत अल्पविकसित फ़ाइल प्रणाली के कारण नहीं।
अनाम टाइप

2

सिस्टम-स्तरीय एपीआई तक पहुंच

सभी ब्राउज़रों को कुछ बिंदु पर ओएस के साथ इंटरफेस करना पड़ता है, और अधिकांश प्रमुख ओएस में अच्छी तरह से स्थापित सी और सी ++ एपीआई और लाइब्रेरी हैं। आमतौर पर लिखने वालों के बजाय C या C ++ में उन API के साथ काम करना आसान होता है।


0

नियंत्रण और पोर्टेबिलिटी

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


0

विरासत की संगतता - पुराने कोड को फेंक नहीं सकते

इसका सी ++ बनाम अन्य भाषाओं के गुणों से कोई लेना-देना नहीं है। आप निश्चित रूप से हास्केल जैसी भाषा में खरोंच से बेहतर ब्राउज़र लिख सकते हैं; एक परियोजना यह महत्वपूर्ण भी अपने स्वयं के JVM को लागू कर सकता है अगर उन्हें कुछ प्रदर्शन विशेषताओं की गारंटी देने की आवश्यकता होती है। जैसे कि फेसबुक ने अपने खुद के PHP कंपाइलर / ऑप्टिमाइज़र कैसे लिखे।

एक ब्राउज़र जो गैर-मानक मार्कअप पर टूट जाता है, बेकार से भी बदतर है। लिगेसी कॉम्पिटिटर्स इतना क्रिटिकल और इतना जटिल है कि फिर से लिखना एक विकल्प नहीं है। बहुत सारे पैसे और समय का निवेश युद्ध-परीक्षण सुरक्षा आदि में किया जाता है, आप बस उस निवेश को फेंक नहीं सकते। फिर, जैसे फेसबुक अभी भी PHP में कैसे लिखा जाता है।


मैं समझ सकता हूं कि लोग इसे क्यों नहीं अपग्रेड कर सकते हैं ... लेकिन डाउनवोटेड? वह अजीब है। यहाँ आपके लिए +1 है।
थॉमस एडिंग

आपके पास एक (छोटा) बिंदु है, लेकिन आपका पहला वाक्य उसे दूर फेंकता है। बेशक यह सी ++ बनाम अन्य भाषाओं के गुणों के साथ भी करना है।
चायल दस ब्रिंक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.