क्या प्रत्येक डेटा प्रकार केवल संकेत के साथ नोड्स को उबालता है?

Question

एक सरणी या वेक्टर सिर्फ मूल्यों का एक क्रम है। उन्हें निश्चित रूप से एक लिंक्ड सूची के साथ लागू किया जा सकता है। यह अगले नोड के लिए संकेत के साथ नोड्स का एक गुच्छा है।

आमतौर पर इंट्रो सीएस पाठ्यक्रम में पढ़ाए जाने वाले स्टैक और कतार दो अमूर्त डेटा प्रकार हैं। कक्षा में कहीं, छात्रों को अक्सर अंतर्निहित डेटा संरचना के रूप में एक लिंक की गई सूची का उपयोग करके ढेर और कतारों को लागू करना पड़ता है, जिसका अर्थ है कि हम उसी "नोड्स के संग्रह" विचार पर वापस आ गए हैं।

हीप का उपयोग करके वरीयता कतारें बनाई जा सकती हैं। एक ढेर को जड़ के न्यूनतम मूल्य के साथ एक पेड़ के रूप में माना जा सकता है। बीएसटी, एवीएल, हीप्स सहित सभी प्रकार के पेड़ों को किनारों से जुड़े नोड्स के संग्रह के रूप में सोचा जा सकता है। ये नोड्स एक साथ जुड़े हुए हैं जहां एक नोड दूसरे को इंगित करता है।

ऐसा लगता है कि हर डेटा कॉन्सेप्ट हमेशा कुछ अन्य उपयुक्त नोड को संकेत के साथ सिर्फ नोड्स तक उबाल सकता है। क्या वह सही है? यदि यह सरल है, तो पाठ्यपुस्तकें यह क्यों नहीं समझाती हैं कि डेटा केवल संकेत के साथ नोड्स का एक गुच्छा है? हम नोड्स से बाइनरी कोड तक कैसे जाते हैं?

Comments

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

— एरिक लिपर्ट

आप यह भी तर्क कर सकते हैं कि सभी डेटा संरचनाएं एक सरणी में उबलती हैं। आखिरकार, वे सभी स्मृति में समाप्त हो जाते हैं, जो सिर्फ एक बहुत बड़ी सरणी है।

— ब्लूराजा - डैनी पफ्लुघोफ्ट

यदि आप अनुक्रमणिका रखना चाहते हैं, तो आप किसी लिंक की गई सूची का उपयोग करके कोई सरणी लागू नहीं कर सकते । $O(1)$

— 15

क्षमा करें, लेकिन "नोड्स और पॉइंटर्स" के बारे में बात करने का मतलब है कि आपने पहले ही क्विक-ईटिंग खा लिया है। " जैसा कि सभी रियल प्रोग्रामर जानते हैं, एकमात्र उपयोगी डेटा संरचना एरे है। स्ट्रिंग्स, सूचियां, संरचनाएं, सेट - ये सभी सरणियों के विशेष मामले हैं और इस तरह से आसानी से इलाज किया जा सकता है बिना आपकी प्रोग्रामिंग भाषा को हर तरह से गड़बड़ किए बिना। जटिलताओं का। "Ref:" रियल प्रोग्रामर पास्कल का उपयोग न करें ", web.mit.edu/humor/Computers/real.programmers

— alephzero

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

— एलेफेज़ेरो

Answer 1

ठीक है, यह मूल रूप से सभी डेटा संरचनाओं को उबालने के लिए है। कनेक्शन के साथ डेटा। नोड्स सभी कृत्रिम हैं - वे वास्तव में शारीरिक रूप से मौजूद नहीं हैं। यह वह जगह है जहां द्विआधारी हिस्सा आता है। आपको C ++ में कुछ डेटा संरचनाएं बनाने और यह जांचना चाहिए कि आपकी ऑब्जेक्ट्स स्मृति में कहां हैं। यह जानना बहुत दिलचस्प हो सकता है कि डेटा को मेमोरी में कैसे रखा जाता है।

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

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

टीएल; डीआर: कंटेनर मूल रूप से सभी नोड्स और पॉइंटर्स हैं, लेकिन बहुत विशिष्ट उपयोग हैं और कुछ के लिए बेहतर हैं और दूसरों के लिए बदतर हैं।

Comments

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

— derekchen14

Answer 2

ऐसा लगता है कि हर डेटा कॉन्सेप्ट हमेशा कुछ अन्य उपयुक्त नोड को संकेत के साथ सिर्फ नोड्स तक उबाल सकता है।

ओह, प्रिय नहीं। तुम मुझे तकलीफ दे रहे हो।

जैसे मैंने अन्यत्र समझाने की कोशिश की (" बाइनरी सर्च ट्री और बाइनरी हीप में क्या अंतर है? ") एक निश्चित डेटा संरचना के लिए भी इसे समझने के लिए कई स्तर हैं।

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

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

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

Answer 3

चलो गणित के साथ एक सादृश्य बनाते हैं। निम्नलिखित वाक्य पर विचार करें: " एक निरंतर कार्य है"। संबंधों को वास्तव में संबंधों के संदर्भ में परिभाषित किया गया है, जो सेट के संदर्भ में परिभाषित किए गए हैं। वास्तविक संख्याओं का समूह विशिष्ट पूर्ण रूप से क्रमबद्ध फ़ील्ड है: इन सभी अवधारणाओं की सरल शब्दों में परिभाषाएँ हैं। निरंतरता के बारे में बात करने के लिए आपको पड़ोस की अवधारणा की आवश्यकता होती है, जिसे एक टोपोलॉजी के संबंध में परिभाषित किया गया है ... और इसी तरह से सभी नीचे ZFC के स्वयंसिद्ध हैं।$f:\mathbb{R} \rightarrow \mathbb{R}$

कोई भी आपसे यह अपेक्षा नहीं करता है कि वह केवल एक सतत कार्य को परिभाषित करे, अन्यथा कोई भी किसी भी कार्य को पूरा करने में सक्षम नहीं होगा। हम सिर्फ "विश्वास" करते हैं कि किसी ने हमारे लिए उबाऊ काम किया।

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

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

Answer 4

यहां एक प्रति-उदाहरण दिया गया है: λ-पथरी में, प्रत्येक डेटा प्रकार कार्यों के लिए उबलता है। λ-पथरी में नोड्स या पॉइंटर्स नहीं होते हैं, केवल एक चीज है जिसमें फ़ंक्शन होते हैं, इसलिए फ़ंक्शन का उपयोग करके सब कुछ लागू किया जाना चाहिए।

यह ईसीएमएस्क्रिप्ट में लिखे कार्यों के रूप में बूलियन को एन्कोडिंग करने का एक उदाहरण है:

const T   = (thn, _  ) => thn,
      F   = (_  , els) => els,
      or  = (a  , b  ) => a(a, b),
      and = (a  , b  ) => a(b, a),
      not = a          => a(F, T),
      xor = (a  , b  ) => a(not(b), b),
      iff = (cnd, thn, els) => cnd(thn, els)();

और यह एक सूची है:

const cons = (hd, tl) => which => which(hd, tl),
      first  = list => list(T),
      rest   = list => list(F);

प्राकृतिक संख्याओं को पुनरावृत्त कार्यों के रूप में लागू किया जा सकता है।

एक सेट एक ही चीज है जो कि इसकी विशेषता फ़ंक्शन (यानी containsविधि) है।

ध्यान दें कि ऊपर चर्च ऑफ एन्कोडिंग ऑफ बुलियंस वास्तव में है कि कैसे स्मॉलटाक जैसी ओओ भाषाओं में सशर्त लागू किया जाता है, जिसमें भाषा निर्माण के रूप में बूलियन, सशर्त या लूप नहीं होते हैं और उन्हें पुस्तकालय की सुविधा के रूप में विशुद्ध रूप से लागू करते हैं। स्काला में एक उदाहरण:

sealed abstract trait Boolean {
  def apply[T, U <: T, V <: T](thn: => U)(els: => V): T
  def ∧(other: => Boolean): Boolean
  def ∨(other: => Boolean): Boolean
  val ¬ : Boolean

  final val unary_! = ¬
  final def &(other: => Boolean) = ∧(other)
  final def |(other: => Boolean) = ∨(other)
}

case object True extends Boolean {
  override def apply[T, U <: T, V <: T](thn: => U)(els: => V): U = thn
  override def ∧(other: => Boolean) = other
  override def ∨(other: => Boolean): this.type = this
  override final val ¬ = False
}

case object False extends Boolean {
  override def apply[T, U <: T, V <: T](thn: => U)(els: => V): V = els
  override def ∧(other: => Boolean): this.type = this
  override def ∨(other: => Boolean) = other
  override final val ¬ = True
}

object BooleanExtension {
  import scala.language.implicitConversions
  implicit def boolean2Boolean(b: => scala.Boolean) = if (b) True else False
}

import BooleanExtension._

(2 < 3) { println("2 is less than 3") } { println("2 is greater than 3") }
// 2 is less than 3

Comments

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

— जॉर्ग डब्ल्यू मित्तग

... शुद्धतम ओओ भाषा!

— जोर्ग डब्ल्यू मित्तग

स्मालटाक के साथ एक बुरा दिन C ++ :-)

— बॉब जार्विस के

@ JörgWMittag मुझे नहीं लगता कि आपका निष्कर्ष आपकी धारणा से निकला है, मुझे नहीं लगता कि आपकी धारणा भी सच है, और मुझे निश्चित रूप से नहीं लगता कि आपका निष्कर्ष सही है।

— मील्स राउत

Answer 5

कई (सबसे?) डेटा संरचनाएं नोड्स और पॉइंटर्स से निर्मित होती हैं। Arrays कुछ डेटा संरचनाओं का एक और महत्वपूर्ण तत्व है।

अंततः, प्रत्येक डेटा संरचना केवल स्मृति में शब्दों का एक गुच्छा है, या बस बिट्स का एक गुच्छा है। यह है कि वे कैसे संरचित हैं और हम कैसे व्याख्या करते हैं और उनका उपयोग करते हैं जो मायने रखता है।

Comments

अंततः, बिट्स एक तार पर विद्युत संकेतों का एक गुच्छा होता है, या फाइबर ऑप्टिक केबल में प्रकाश संकेत, या विशेष रूप से तरंग दैर्ध्य, या, या, या के रेडियो तरंगों पर विशेष रूप से चुंबकित कण होते हैं। तो सवाल यह है कि आप कितने गहरे जाना चाहते हैं? :)

— वाइल्डकार्ड

Answer 6

डेटा संरचनाओं के कार्यान्वयन को हमेशा नोड्स और पॉइंटर्स के लिए फोड़ा जाता है, हाँ।

लेकिन वहां क्यों रुके? नोड्स और पॉइंटर्स के कार्यान्वयन बिट्स के लिए फोड़े ।

बिट्स का कार्यान्वयन विद्युत संकेतों, चुंबकीय भंडारण, शायद फाइबरोप्टिक केबल्स, आदि के लिए उबालता है (एक शब्द में, भौतिकी।)।

यह कथन का रिडक्टियो विज्ञापन अनुपस्थिति है, "सभी डेटा संरचनाएं नोड्स और पॉइंटर्स को उबालती हैं।" यह सच है - लेकिन यह केवल कार्यान्वयन से संबंधित है ।

---

क्रिस डेट कार्यान्वयन और मॉडल के बीच बहुत अंतर करता है , हालांकि उनका निबंध विशेष रूप से डेटाबेस पर लक्षित है।

हम थोड़ा और आगे बढ़ सकते हैं अगर हमें पता चले कि मॉडल और कार्यान्वयन के बीच एक भी विभाजन रेखा नहीं है । यह "मतिहीनता की परतों" की अवधारणा के समान है (यदि समान नहीं है)।

अमूर्तता की एक दी गई परत पर, आप (आप जिन परतों का निर्माण कर रहे हैं) के नीचे की परतें केवल "कार्यान्वयन विवरण" हैं, जो अमूर्त या मॉडल के लिए हैं, जिसे आप संबोधित कर रहे हैं।

हालांकि, अमूर्त की निचली परतों में स्वयं कार्यान्वयन विवरण हैं।

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

यदि आप सॉफ़्टवेयर के टुकड़े का कार्यान्वयन विवरण सीखते हैं , तो आप सीखेंगे कि रचनाकारों ने उन अमूर्तियों को कैसे रेखांकित किया जो उन्होंने बनाई थी। "कार्यान्वयन विवरण" में अन्य चीजों के अलावा डेटा संरचना और एल्गोरिदम शामिल हो सकते हैं।

हालाँकि, आप किसी भी विशेष सॉफ़्टवेयर के लिए "माप विवरण" का हिस्सा होने के लिए वोल्टेज माप पर विचार नहीं करेंगे , भले ही यह "बिट्स" और "बाइट्स" और "भंडारण" वास्तव में भौतिक कंप्यूटर पर काम करता हो।

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

---

एक प्रणाली को वास्तव में समझने का एक बड़ा हिस्सा यह समझ में आता है कि अमूर्त परतें एक साथ कैसे फिट होती हैं। इसलिए यह समझना महत्वपूर्ण है कि डेटा संरचनाओं को कैसे लागू किया जाता है। लेकिन तथ्य यह है कि वे कर रहे हैं लागू किया, मतलब नहीं है कि डेटा संरचनाओं की अमूर्त नहीं है मौजूद हैं।

Answer 7

एक सरणी या वेक्टर सिर्फ मूल्यों का एक क्रम है। उन्हें निश्चित रूप से एक लिंक्ड सूची के साथ लागू किया जा सकता है। यह अगले नोड के लिए संकेत के साथ नोड्स का एक गुच्छा है।

एक सरणी या एक वेक्टर एक लिंक्ड सूची के साथ लागू किया जा सकता है, लेकिन लगभग कभी नहीं होना चाहिए।

$n$$n$$\Theta(n)$$\Theta(\log n)$$\Theta(1)$(यानी रैंडम एक्सेस मेमोरी का क्रमिक ब्लॉक)। इसके अलावा, सीपीयू पर, वास्तविक सरणी तक पहुंच को कार्यान्वित करना और तेजी से निष्पादित करने के लिए बहुत सरल है, और अलग-अलग नोड्स के बीच पॉइंटर्स पर किसी भी स्थान को बर्बाद नहीं करने के कारण इसे कम मेमोरी लगती है।

$\Theta(n)$$\Theta(1)$$\Theta(1)$अतिरिक्त मेमोरी के एक स्थिर कारक की कीमत पर, औसतन, सरणी के वास्तविक आवंटित आकार को गोल करके, जैसे कि 2. की निकटतम शक्ति। लेकिन अगर आपको बहुत सारे सम्मिलन करने और / या हटाने की आवश्यकता है आपकी सूची के बीच में तत्व, एक भौतिक सरणी आपके डेटा संरचना के लिए सर्वोत्तम कार्यान्वयन नहीं हो सकती है। बहुत बार, हालांकि, आप स्वैप के साथ सम्मिलन और निष्कासन को बदल सकते हैं, जो सस्ते हैं।

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

$\Theta(1)$उलटा संचालन)। व्यवहार में, हालांकि, उन सुविधाओं को इसकी कमियों को दूर करने के लिए शायद ही कभी उपयोगी होता है, जिसमें अतिरिक्त कार्यान्वयन जटिलता और मानक कचरा संग्रह योजनाओं के साथ असंगति शामिल है ।

Answer 8

यदि यह सरल है, तो पाठ्यपुस्तकें यह क्यों नहीं समझाती हैं कि डेटा केवल संकेत के साथ नोड्स का एक गुच्छा है?

क्योंकि ऐसा नहीं है कि "डेटा" का अर्थ है। आप कार्यान्वयन के साथ अमूर्त विचारों का सामना कर रहे हैं। "डेटा" एक अत्यधिक सार विचार है: यह "जानकारी के लिए सिर्फ एक और नाम है।" पॉइंटर्स (उर्फ, एक "लिंक्ड डेटा स्ट्रक्चर") के साथ लिंक किए गए नोड्स का एक गुच्छा अधिक ठोस विचार है: यह सूचना का प्रतिनिधित्व करने और व्यवस्थित करने का एक विशिष्ट तरीका है।

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

ढेर और कतारें बीच में कहीं गिर जाती हैं। ऐसे समय होते हैं जब किसी स्टैक के लिंक किए गए कार्यान्वयन को करने के लिए बहुत अधिक समझ में आता है। ऐसे समय होते हैं जब यह एक सरणी और एकल "स्टैक पॉइंटर" का उपयोग करने के लिए बहुत अधिक समझ में आता है।