অ্যারে বনাম লিঙ্ক-তালিকা


200

কেন কেউ অ্যারের উপরে একটি লিঙ্কযুক্ত তালিকা ব্যবহার করতে চান?

কোনও লিঙ্কযুক্ত তালিকার কোডিং করা কোনও সন্দেহ নেই, অ্যারের ব্যবহারের চেয়ে কিছুটা বেশি কাজ এবং অতিরিক্ত প্রচেষ্টাটি কী ন্যায়সঙ্গত হবে তা ভাবতে পারে one

আমি মনে করি একটি লিঙ্কযুক্ত তালিকায় নতুন উপাদান সন্নিবেশ তুচ্ছ তবে এটি অ্যারেতে একটি বড় কাজ ore অ্যারেতে স্টোর করে বনাম ডেটার সেট সেট করার জন্য লিঙ্কযুক্ত লিস্ট ব্যবহার করার অন্যান্য সুবিধা রয়েছে কি?

এই প্রশ্নের সদৃশ নয় এই প্রশ্নের কারণ অন্য প্রশ্ন একটি নির্দিষ্ট Java শ্রেণি সম্পর্কে বিশেষভাবে জিজ্ঞাসা করা হয় যখন এই প্রশ্ন সাধারণ ডাটা স্ট্রাকচার সাথে সংশ্লিষ্ট হয়।


1
সম্পর্কিত - কখন লিঙ্কলিস্ট <> ওভার অ্যারেলিস্ট <> ব্যবহার করবেন? - এটি জাভা, তবে অ্যারে (অ্যারেলিস্ট) এবং লিঙ্কযুক্ত তালিকাগুলি সম্ভবত কোনও ভাষায় একই কর্মক্ষমতা রয়েছে have
বার্নহার্ড বার্কার


1
@ রুটট্রেভেলার আসলে আসলে সেই প্রশ্নটি এই প্রশ্নের সদৃশ হবে কারণ আমার প্রশ্নটি আগে পোস্ট করা হয়েছিল।
ওনোরিও ক্যাটানাচি

উত্তর:


147
  • লিঙ্কযুক্ত তালিকায় বিভিন্ন আকারের ডেটা সঞ্চয় করা সহজ। একটি অ্যারে ধরে নেয় প্রতিটি উপাদান হুবহু একই আকার is
  • আপনি যেমনটি উল্লেখ করেছেন, একটি লিঙ্কযুক্ত তালিকার পক্ষে জৈবিকভাবে বৃদ্ধি করা সহজ। একটি অ্যারের আকার আগে সময়ের জানা উচিত, বা যখন এটি বাড়ার দরকার হয় তখন পুনরায় তৈরি করা উচিত।
  • কোনও লিঙ্কযুক্ত তালিকাগুলি পরিবর্তন করা কেবল কোনটি নির্দেশ করে তা পরিবর্তনের বিষয়। একটি অ্যারে বদলানো আরও জটিল এবং / বা আরও মেমরি লাগে।
  • যতক্ষণ না আপনার পুনরাবৃত্তি সমস্ত "ফোরচ" প্রসঙ্গে হয়, আপনি পুনরাবৃত্তিতে কোনও কার্যকারিতা হারাবেন না।

19
বিভিন্ন আকারের আইটেমগুলি কীভাবে আলাদাভাবে আচরণ করা হয়? একটি লিঙ্কযুক্ত তালিকা হয় পরবর্তী ক্ষেত্রের সাথে একটি স্থির কাঠামো ব্যবহার করে (নির্দিষ্ট আকারের প্রয়োজন হয়), বা গাড়ীর ডেটাতে একটি পয়েন্টার সঞ্চয় করে (পরিবর্তনশীল আকার ঠিক আছে)। উভয় পদ্ধতির একটি ভেক্টর দিয়ে ঠিক যেমন সহজ। বদলানোর জন্য একই।
ব্রায়ান

32
আমি বলব একটি অ্যারে বদলানো কম জটিল।
হিউ অ্যালেন

23
এই উত্তরটি ভুল এবং বিভ্রান্তিকর। (আপনি যখন এটির ঘোষণার সাথে সাথে অ্যারের আকার জানতে চান তা বাদে)
রবার্ট পলসন

35
ডেটা লোকালের কারণে কোনও লিঙ্কযুক্ত তালিকার পুনরাবৃত্তি কি ধীর হবে না?
ফিরস আসাদ

6
@ রিক, ভেক্টররা সাধারণত প্রয়োজনীয় স্থানটি সামগ্রিকভাবে গড়ে তোলেন যাতে মাপ বাড়ার সাথে সাথে তাদের নতুন স্থান বরাদ্দ করার প্রয়োজন হয় না। ফলস্বরূপ যে ভেক্টরগুলি সাধারণত মেমরি নিবিড়ভাবে কম থাকে, ততক্ষণে লিঙ্কযুক্ত তালিকাগুলি নয়।
উইনস্টন ইওয়ার্ট

179

আরেকটি ভাল কারণ হ'ল লিঙ্কযুক্ত তালিকাগুলি দক্ষ মাল্টি-থ্রেডযুক্ত বাস্তবায়নের জন্য নিজেকে সুন্দরভাবে ndণ দেয়। এর কারণ হ'ল পরিবর্তনগুলি স্থানীয় হতে থাকে - ডেটা কাঠামোর স্থানীয়করণের অংশে সন্নিবেশ করানোর জন্য এবং কেবলমাত্র একটি পয়েন্টার বা দুটিকে প্রভাবিত করে। সুতরাং, একই লিঙ্কযুক্ত তালিকায় আপনার অনেক থ্রেড কাজ করতে পারে। আরও বেশি, সিএএস-টাইপ ক্রিয়াকলাপগুলি ব্যবহার করে লক-মুক্ত সংস্করণ তৈরি করা এবং সম্পূর্ণরূপে ভারী ওজনের লকগুলি এড়ানো সম্ভব।

একটি লিঙ্কযুক্ত তালিকার সাথে, পুনরায় পরিবর্তনগুলি সংঘটিত হওয়ার সময় পুনরাবৃত্তিকারীরা তালিকাটিকেও অতিক্রম করতে পারে। আশাবাদী ক্ষেত্রে যেখানে পরিবর্তনগুলি সংঘর্ষে নয়, পুনরাবৃত্তিগুলি বিতর্ক ছাড়াই চালিয়ে যেতে পারে।

একটি অ্যারের সাথে অ্যারের আকার পরিবর্তন করে এমন কোনও পরিবর্তনের জন্য অ্যারের বৃহত অংশটি লক করা দরকার এবং বাস্তবে, এটি খুব কমই ঘটে যে পুরো অ্যারে জুড়ে কোনও বৈশ্বিক লক ছাড়াই এটি করা হয় যাতে পরিবর্তনগুলি বিশ্ব বিষয়বস্তু বন্ধ করে দেয়।


9
অ্যালেক্স - এটি একটি আকর্ষণীয় বিবেচনা যা আমার কাছে কখনও ঘটেনি। খুব ভাল উত্তর। আমি পারলে দু'বার উপবিষ্ট হব। :-)
ওনোরিও ক্যাটেনাচি

5
আপনি কোথায় যেতে পারেন সে সম্পর্কে ভাল ধারণা পাওয়ার জন্য স্কিপ লিস্টগুলি দেখুন (জাভা in-তে বিশেষত সমকালীন স্কিপলিস্টম্যাপ)। সিএসএলএম হ'ল দুর্দান্ত পারফরম্যান্স সহ একটি সাজানো, সমবর্তী মানচিত্র। সুসংগত, ট্রি ম্যাপের চেয়ে অনেক বেশি ভাল। tech.puredanger.com/2007/10/03/skip-lists
অ্যালেক্স মিলার

… এটি বাদে ConcurrentSkipListMapবা ConcurrentSkipListMapতালিকাগুলি নয়, এমনকি যদি তাদের নামের কোথাও "তালিকা" ঘটে থাকে। উভয়ের জন্য চাবিগুলি প্রয়োজনীয় যা সাজানো এবং অনন্য হবে। আপনার যদি এমন কোনও List, যেমন ডেটা স্ট্রাকচারের প্রয়োজন হয় যা একটি স্বেচ্ছাসেবী ক্রমে ডুপ্লিকেট উপাদানগুলিকে মঞ্জুরি দেয়, এটি উপযুক্ত নয় এবং LinkedListএকযোগে হালনাগাদযোগ্য জিনিসের মতো ডেটা স্ট্রাকচার তৈরি করতে আপনাকে বড় দৈর্ঘ্য অতিক্রম করতে হবে। আপনার যদি কেবল সমবর্তী সারির বা দ্বিধাগুলির প্রয়োজন হয় তবে ভাল হ্যাঁ, এখানে বিদ্যমান উদাহরণগুলিও রয়েছে তবে সমবর্তী List: আমি নিশ্চিত যে এটি এমনকি সম্ভব।
হোলগার

128

পার্থক্য সম্পর্কে উইকিপিডিয়ায় খুব ভাল বিভাগ রয়েছে।

লিঙ্কযুক্ত তালিকাগুলি অ্যারের তুলনায় বেশ কয়েকটি সুবিধা রয়েছে। উপাদানগুলি লিঙ্কযুক্ত তালিকায় অনির্দিষ্টকালের জন্য sertedোকানো যেতে পারে, যখন একটি অ্যারে অবশেষে পূরণ করবে বা পুনরায় আকার দেওয়ার দরকার হবে, একটি ব্যয়বহুল ক্রিয়াকলাপ যা মেমরির খণ্ডিত হয়ে থাকলে এমনকি সম্ভবও নাও হতে পারে। একইভাবে, এমন একটি অ্যারে যা থেকে অনেকগুলি উপাদান অপসারণ করা হয় অপব্যয় শূন্য হয়ে যেতে পারে বা আরও ছোট করা প্রয়োজন।

অন্যদিকে, অ্যারেগুলি এলোমেলো অ্যাক্সেসের অনুমতি দেয়, অন্যদিকে লিঙ্কযুক্ত তালিকাগুলি কেবলমাত্র উপাদানগুলিতে অনুক্রমিক অ্যাক্সেসের অনুমতি দেয়। একক লিঙ্কযুক্ত তালিকাগুলি, বাস্তবে কেবলমাত্র এক দিকেই যেতে পারে। এটি লিঙ্কযুক্ত তালিকাগুলিকে অ্যাপ্লিকেশনের জন্য অনুপযুক্ত করে তোলে যেখানে হিপসোর্টের মতো দ্রুত তার সূচক দ্বারা কোনও উপাদান অনুসন্ধান করা কার্যকর। রেফারেন্স এবং ডেটা ক্যাশের স্থানীয়তার কারণে অনেকগুলি মেশিনে লিঙ্কযুক্ত তালিকার চেয়ে অ্যারেগুলিতে ক্রমযুক্ত প্রবেশাধিকার আরও দ্রুত is লিঙ্কযুক্ত তালিকাগুলি ক্যাশে থেকে প্রায় কোনও সুবিধা পায় না।

লিঙ্কযুক্ত তালিকার আরেকটি অসুবিধা হ'ল রেফারেন্সের জন্য প্রয়োজনীয় অতিরিক্ত স্টোরেজ, যা প্রায়শই তাদের অক্ষর বা বুলিয়ান মানগুলির মতো ছোট ডেটা আইটেমের তালিকার জন্য অযৌক্তিক করে তোলে। এটি ধীরে ধীরেও হতে পারে এবং একটি নির্লজ্জ বরাদ্দকারী, অপ্রয়োজনীয়, প্রতিটি নতুন উপাদানগুলির জন্য আলাদাভাবে মেমরি বরাদ্দ করতে, মেমরি পুলগুলি ব্যবহার করে সাধারণত একটি সমস্যা সমাধান করা হয়।

http://en.wikipedia.org/wiki/Linked_list


4
এটি সঠিক উত্তর। উভয়টির সুবিধা এবং অসুবিধাগুলি সংক্ষিপ্ত বিবরণে বর্ণনা করা হয়েছে।
রিক

আপনাকে ধন্যবাদ)) মৃত সরল তবে আমি এটি উইকিতে দেখিনি)
তৈমুর ফয়েজরাখমানভ

58

আমি অন্য যুক্ত করব - তালিকাগুলি নিখুঁতভাবে কার্যকরী ডেটা স্ট্রাকচার হিসাবে কাজ করতে পারে ।

উদাহরণস্বরূপ, আপনার একই শেষ বিভাগটি ভাগ করে নেওয়ার জন্য সম্পূর্ণ ভিন্ন তালিকা থাকতে পারে

a = (1 2 3 4, ....)
b = (4 3 2 1 1 2 3 4 ...)
c = (3 4 ...)

অর্থাৎ,

b = 4 -> 3 -> 2 -> 1 -> a
c = a.next.next  

তথ্য কপি না করেও দ্বারা প্রতি ইঙ্গিত করা হচ্ছে aমধ্যে bএবং c

এ কারণেই এগুলি কার্যকরী ভাষাগুলিতে এত জনপ্রিয়, যা অপরিবর্তনীয় ভেরিয়েবলগুলি ব্যবহার করে - prependএবং tailঅরিজিনালগুলি মূল ডেটা অনুলিপি না করেই ঘটতে পারে - যখন আপনি ডেটাটিকে অপরিবর্তনীয় হিসাবে আচরণ করে তখন খুব গুরুত্বপূর্ণ বৈশিষ্ট্য।


4
তবুও আরেকটি খুব আকর্ষণীয় বিবেচনা যা আমি কখনই সামনে আসতে পারতাম না। ধন্যবাদ.
ওনোরিও ক্যাটানাচি

অজগরে আমি কীভাবে এটি করতে পারি?

29

তালিকার মাঝখানে easierোকানো সহজ হওয়া ছাড়াও - অ্যারের চেয়ে লিঙ্কযুক্ত তালিকার মাঝামাঝি থেকে মুছে ফেলাও অনেক সহজ।

তবে সত্যি বলতে, আমি কখনও লিঙ্কযুক্ত তালিকা ব্যবহার করিনি। যখনই আমার দ্রুত সন্নিবেশ এবং মুছে ফেলার দরকার ছিল, আমার দ্রুত অনুসন্ধানের প্রয়োজন ছিল, তাই আমি হ্যাশসেট বা অভিধানে গিয়েছিলাম।


2
খুব সত্য, সন্নিবেশ এবং মুছে ফেলা বেশিরভাগ সময় অনুসন্ধানের পরে আসে তাই সময় জটিলতার যোগফলগুলিও বিবেচনা করা দরকার।
এম এ হোসাইন টনু

28

দুটি সংযুক্ত তালিকার মার্জ করা (বিশেষত দুটি দ্বিগুণ লিঙ্কযুক্ত তালিকাগুলি) দুটি অ্যারে মার্জ করার চেয়ে অনেক দ্রুত (মার্জটিকে ধ্বংসাত্মক মনে করে)। পূর্বেরটি ও (1) নেয়, পরে ও (এন) নেয়।

সম্পাদনা: স্পষ্ট করার জন্য, আমার অর্থ এখানে "একত্রিত" অর্থহীন অর্থে ছিল, মার্জ সাজানোর মতো নয় sort সম্ভবত "কনকানেটেটিং" আরও ভাল শব্দ হত।


2
কেবলমাত্র যদি আপনি অন্য তালিকায় কেবল একটি তালিকা সংযোজন করেন। আপনি যদি দু'টি সাজানো তালিকাগুলি বাস্তবে মার্জ করে থাকেন তবে এটি ও (1) এর চেয়ে বেশি লগ নেবে।
হার্মস

3
@ হার্মস, তবে আপনি কোনও অতিরিক্ত মেমোরি বরাদ্দ না করে দুটি বাছাইযুক্ত লিঙ্কযুক্ত তালিকার একত্রীকরণ করতে পারেন, কেবল উভয় তালিকাকে অনুসরণ করে এবং পয়েন্টারগুলিকে যথাযথভাবে সেট করে। দুটি অ্যারে মার্জ করতে সাধারণত কমপক্ষে একটি অতিরিক্ত অ্যারে লাগবে।
পল টমলিন

1
হ্যাঁ, তালিকাগুলি মার্জ করা আরও মেমরির দক্ষ, তবে আমি যা বলছিলাম তা আসলে তা ছিল না। লিঙ্কযুক্ত তালিকাগুলি মার্জ করা ও (1) বলার বিষয়টি মামলার ব্যাখ্যা ছাড়াই অত্যন্ত বিভ্রান্তিকর।
হার্মস

@ হার্মস মার্জিং তালিকাগুলি কোনও বুদ্ধিমান ডেটা মডেলের অধীনে অ্যারে মার্জ করার চেয়ে বেশি মেমরির দক্ষ নয়।
আলেক্সি আভেরচেঙ্কো

2
আলেক্সি আভেরচেঙ্কো: ও (১) মেমরির সাহায্যে দুটি তালিকার প্রতিযোগিতা করা, বা এমনকি দুটি সাজানো তালিকাগুলি মার্জ করে বাছাই করা place দুটি অ্যারে সংমিশ্রণ করা O (n) মেমরিটিকে প্রয়োজনীয়ভাবে গ্রহণ করে, যদি না অ্যারে ইতিমধ্যে মেমরিতে সংলগ্ন থাকে। আমি মনে করি আপনি যে বিন্দুটিকে লক্ষ্য করছেন সেটি হ'ল এন উপাদানগুলির একটি তালিকা এবং এন উপাদানগুলির একটি অ্যারে উভয়ই ও (এন) মেমরি গ্রহণ করে তবে লিঙ্কযুক্ত তালিকার জন্য সহগটি বেশি।
রায়পুন

17

অ্যারেলিস্টের জন্য এবং লিংকডলিস্টের বিরুদ্ধে একটি বিস্তৃত অপ্রমাণিত যুক্তি হ'ল লিংকডলিস্টগুলি ডিবাগ করার সময় অস্বস্তি বোধ করে । প্রোগ্রামটি বোঝার জন্য রক্ষণাবেক্ষণ বিকাশকারীদের দ্বারা ব্যয় করা সময়, যেমন বাগ, বৃদ্ধি এবং আইএমএইচও কখনও কখনও কর্মক্ষমতা উন্নতিতে ন্যানোসেকেন্ডগুলিকে বা এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলিতে মেমরির ব্যবহারে বাইটগুলি সমর্থন করে না। কখনও কখনও (ভাল, অবশ্যই এটি অ্যাপ্লিকেশনগুলির ধরণের উপর নির্ভর করে), কয়েকটি বাইট নষ্ট করা ভাল তবে এমন একটি অ্যাপ্লিকেশন রয়েছে যা আরও রক্ষণাবেক্ষণযোগ্য বা বুঝতে সহজ।

উদাহরণস্বরূপ, একটি জাভা পরিবেশে এবং Eclipse ডিবাগার ব্যবহার করে একটি অ্যারেলিস্ট ডিবাগ করা কাঠামো বোঝার জন্য খুব সহজেই প্রকাশ করবে:

arrayList   ArrayList<String>
  elementData   Object[]
    [0] Object  "Foo"
    [1] Object  "Foo"
    [2] Object  "Foo"
    [3] Object  "Foo"
    [4] Object  "Foo"
    ...

অন্যদিকে, লিংকডলিস্টের বিষয়বস্তুগুলি দেখার এবং নির্দিষ্ট বিষয়গুলি সন্ধান করা একটি বিস্তৃত-গাছটি দুঃস্বপ্নে ক্লিক করে লিঙ্কডলিস্ট ইন্টার্নালগুলি ফিল্টার করার জন্য প্রয়োজনীয় জ্ঞানীয় ওভারহেডের উল্লেখ না করে:

linkedList  LinkedList<String>
    header  LinkedList$Entry<E>
        element E
        next    LinkedList$Entry<E>
            element E   "Foo"
            next    LinkedList$Entry<E>
                element E   "Foo"
                next    LinkedList$Entry<E>
                    element E   "Foo"
                    next    LinkedList$Entry<E>
                    previous    LinkedList$Entry<E>
                    ...
                previous    LinkedList$Entry<E>
            previous    LinkedList$Entry<E>
        previous    LinkedList$Entry<E>

17

প্রথমত, সি ++ লিঙ্ক-তালিকাগুলিতে অ্যারের চেয়ে বেশি কাজ করা উচিত নয়। সংযুক্ত তালিকার জন্য আপনি std :: তালিকা বা বুস্ট পয়েন্টার তালিকাটি ব্যবহার করতে পারেন । লিঙ্কযুক্ত তালিকা বনাম অ্যারেগুলির মূল সমস্যাগুলি হ'ল পয়েন্টার এবং ভয়ানক এলোমেলো অ্যাক্সেসের জন্য অতিরিক্ত স্থানের প্রয়োজন space আপনি যদি একটি লিঙ্কযুক্ত তালিকা ব্যবহার করা উচিত

  • আপনার ডেটাতে এলোমেলো অ্যাক্সেসের দরকার নেই
  • আপনি বিশেষ করে তালিকার মাঝখানে উপাদানগুলি যুক্ত / মুছবেন

14

আমার জন্য এটি এই রকম,

  1. প্রবেশ

    • লিঙ্কযুক্ত তালিকাগুলি কেবলমাত্র উপাদানগুলিতে অনুক্রমিক অ্যাক্সেসের অনুমতি দেয়। সুতরাং অ্যালগরিদমিক জটিলতা হ'ল হ'ল অর্ডার (এন)
    • অ্যারেগুলি এর উপাদানগুলিতে এলোমেলো অ্যাক্সেসের অনুমতি দেয় এবং এইভাবে জটিলতা হ'ল অর্ডার (1)
  2. সংগ্রহস্থল

    • লিঙ্কযুক্ত তালিকাগুলি রেফারেন্সের জন্য অতিরিক্ত স্টোরেজ প্রয়োজন। এটি অক্ষর বা বুলিয়ান মানগুলির মতো ছোট ডেটা আইটেমের তালিকাগুলির জন্য অযৌক্তিক করে তোলে।
    • অ্যারেগুলিকে পরবর্তী ডেটা আইটেমটিতে নির্দেশ করতে অতিরিক্ত স্টোরেজ প্রয়োজন হয় না। প্রতিটি উপাদান সূচকের মাধ্যমে অ্যাক্সেস করা যেতে পারে।
  3. আয়তন

    • লিঙ্কযুক্ত তালিকার আকার প্রকৃতির দ্বারা গতিশীল।
    • অ্যারের আকার ঘোষণার মধ্যে সীমাবদ্ধ।
  4. সন্নিবেশ / বিলোপে

    • উপাদানগুলি লিঙ্কযুক্ত তালিকায় অনির্দিষ্টকালের জন্য serted োকানো এবং মুছতে পারে।
    • অ্যারেগুলিতে মান সন্নিবেশ / মুছে ফেলা খুব ব্যয়বহুল। এটির জন্য স্মৃতি পুনর্বিবেচনার প্রয়োজন।

আপনার 2 নম্বর 2, এবং 2 নম্বর 3 :) আছে
হেনগামে

আমরা একটি খালি অ্যারে ঘোষণা করতে পারি এবং তারপরে প্রয়োজনীয় হিসাবে ডেটা যুক্ত করতে থাকি। এটি কীভাবে এখনও একটি নির্দিষ্ট আকার তৈরি করে?
HebleV

11

দুটি জিনিস:

কোনও লিঙ্কযুক্ত তালিকার কোডিং করা কোনও সন্দেহ নেই, অ্যারের ব্যবহারের চেয়ে কিছুটা বেশি কাজ এবং তিনি আরও আশ্চর্য হয়েছিলেন যে অতিরিক্ত প্রচেষ্টাটি কী ন্যায়সঙ্গত হবে।

সি ++ ব্যবহার করার সময় কোনও লিঙ্কযুক্ত তালিকাকে কোড করবেন না। কেবল এসটিএল ব্যবহার করুন। এটি প্রয়োগ করা কতটা কঠিন তা কখনই অন্যের উপর একটি ডেটা কাঠামো বেছে নেওয়ার কারণ হিসাবে দেখা উচিত না কারণ বেশিরভাগ ইতিমধ্যে সেখানে প্রয়োগ করা হয়েছে।

অ্যারে এবং একটি লিঙ্কযুক্ত তালিকার মধ্যে প্রকৃত পার্থক্য সম্পর্কে, আমার কাছে বড় বিষয় হ'ল আপনি কীভাবে কাঠামোটি ব্যবহারের পরিকল্পনা করছেন। আমি ভেক্টর শব্দটি ব্যবহার করব যেহেতু এটিই সি ++ তে পরিবর্তনযোগ্য অ্যারের জন্য শব্দ।

একটি লিঙ্কযুক্ত তালিকার সূচকটি ধীর গতির কারণ আপনাকে প্রদত্ত সূচকে পেতে তালিকাটি অতিক্রম করতে হবে, যখন কোনও ভেক্টর স্মৃতিতে স্বচ্ছল এবং আপনি পয়েন্টার ম্যাথ ব্যবহার করে সেখানে যেতে পারেন।

কোনও লিঙ্কযুক্ত তালিকার শেষ বা শুরুতে যুক্ত করা সহজ, যেহেতু আপনাকে কেবল একটি লিঙ্ক আপডেট করতে হবে, যেখানে কোনও ভেক্টরে আপনাকে পুনরায় আকার দিতে হবে এবং সামগ্রীগুলি অনুলিপি করতে হবে।

তালিকা থেকে কোনও আইটেম সরিয়ে ফেলা সহজ, যেহেতু আপনাকে কেবল একটি জোড়া লিঙ্ক ভাঙতে হবে এবং তারপরে এগুলি আবার সংযুক্ত করতে হবে। কোনও ভেক্টর থেকে কোনও আইটেম সরিয়ে নেওয়া দ্রুত বা ধীর হতে পারে, যদি আপনি অর্ডারের বিষয়ে চিন্তা করেন তবে। আপনি যে আইটেমটি সরাতে চান তার উপরের আইটেমের উপরে অদলবদল দ্রুততর, যখন সমস্ত কিছু নীচে নেওয়ার পরে স্থানান্তর করা ধীর হয় তবে ক্রম বজায় রাখে।


আমি উপরের কাউকে যেমন বলেছিলাম, প্রশ্নটি আমার কাছে যেভাবে করা হয়েছিল আমি কেবল তা সম্পর্কিত করার চেষ্টা করছিলাম। আমি যেভাবে যাইহোক সি ++ এ কোনও অ্যারে (বা রোল-আমার নিজস্ব লিঙ্কযুক্ত তালিকা) ব্যবহার করব না - আমি সেগুলির দুটিটিরই এসটিএল সংস্করণ ব্যবহার করব।
ওনোরিও ক্যাটানাচি

10

এরিকগুলি রক্ষণশীলভাবে ব্যবহার করা উচিত তার একটি কারণ নিয়ে সম্প্রতি এরিক লিপার্টের একটি পোস্ট ছিল ।


2
স্বীকৃতভাবে একটি ভাল পোস্ট, তবে অ্যারে এর আলোচনার বিপরীতে লিঙ্কযুক্ত তালিকায় প্রাসঙ্গিক নয়।
রবার্ট পলসন

2
আমি প্রস্তাব দিয়েছি যে এরিকের বেশিরভাগ নিবন্ধ প্রাসঙ্গিক, কারণ এটি অ্যারের অসুবিধাগুলি এবং তালিকা কার্যকর করার বিষয়ে নির্বিশেষে তালিকাগুলির সুবিধা উভয় নিয়েই আলোচনা করেছে।
বেভান

8

দ্রুত সন্নিবেশ এবং অপসারণ লিঙ্কযুক্ত তালিকার জন্য সর্বোত্তম যুক্তি। যদি আপনার কাঠামোটি গতিশীলভাবে বৃদ্ধি পায় এবং কোনও উপাদানগুলিতে ধ্রুবক অ্যাক্সেসের প্রয়োজন হয় না (যেমন গতিশীল স্ট্যাক এবং সারি), লিঙ্কযুক্ত তালিকাগুলি একটি ভাল পছন্দ।


7

এখানে একটি দ্রুত: আইটেমগুলি অপসারণ দ্রুত।


7

সংযোগ ক্রমাগতভাবে বাড়ছে এবং সঙ্কুচিত হয় যখন লিঙ্কযুক্ত তালিকাটি বিশেষত কার্যকর হয়। উদাহরণস্বরূপ, একটি অ্যারে ব্যবহার করে একটি সারি প্রয়োগ করার চেষ্টা করা (শেষ পর্যন্ত যুক্ত করুন, সামনে থেকে সরান) কল্পনা করা শক্ত - আপনি আপনার সমস্ত সময় জিনিসকে সরিয়ে নেওয়ার জন্য ব্যয় করবেন। অন্যদিকে, এটি একটি লিঙ্কযুক্ত তালিকার সাথে তুচ্ছ।


4
আপনার খুব বেশি কাজ ছাড়াই একটি অ্যারে-ভিত্তিক সারি থাকতে পারে যা এখনও দ্রুত / দক্ষ ছিল। কোন সূচকটি "প্রধান" এবং কোনটি "লেজ" ছিল তা আপনাকে কেবল খতিয়ে রাখতে হবে। আপনার যদি স্থির-আকারের সারি প্রয়োজন হয় (উদাহরণস্বরূপ, কার্নেলের মধ্যে কীবোর্ড বাফার) তবে এটি বেশ ভাল কাজ করে।
হার্মস

3
এবং যদি এটি আপনার প্রিয় অ্যালগরিদম রেফারেন্সে সন্ধান করতে চান তবে তাকে একটি "বিজ্ঞপ্তিযুক্ত বাফার" বলা হয়।
স্টিভ জেসপ

7

তালিকার মাঝামাঝি থেকে যোগ করা এবং অপসারণ করা ছাড়াও, আমি লিঙ্কযুক্ত তালিকাগুলি বেশি পছন্দ করি কারণ তারা গতিশীলভাবে বাড়তে এবং সঙ্কুচিত করতে পারে।


6
ভেক্টর (= মূলত অ্যারেগুলি) এটিও করতে পারে এবং লোকাল-অফ-রেফারেন্স ইস্যুগুলির কারণে তাদের জন্য আনুপাতিক ব্যয় সাধারণত তালিকাগুলির চেয়ে কম হয়।
কনরাড রুডল্ফ

7

আর কেউ তাদের নিজস্ব লিঙ্ক তালিকার কোড করে না। এটা নির্বোধ হতে হবে। একটি লিঙ্কযুক্ত তালিকা ব্যবহার করা আরও কোড নেয় এমন ভিত্তিটি ভুল।

আজকাল, লিঙ্কযুক্ত তালিকা তৈরি করা শিক্ষার্থীদের জন্য একটি অনুশীলন যাতে তারা ধারণাটি বুঝতে পারে। পরিবর্তে, প্রত্যেকে একটি পূর্ব-নির্মিত তালিকা ব্যবহার করে। সি ++ তে, আমাদের প্রশ্নের বর্ণনার ভিত্তিতে, এর অর্থ সম্ভবত একটি স্টাইল ভেক্টর ( #include <vector>)।

অতএব, একটি লিঙ্ক তালিকা একটি অ্যারের বনাম নির্বাচন করা হয় সম্পূর্ণরূপে আপনার অ্যাপের চাহিদা আপেক্ষিক প্রতিটি কাঠামো বিভিন্ন বৈশিষ্ট্যের ওজনের সম্পর্কে। অতিরিক্ত প্রোগ্রামিং বোঝা কাটিয়ে ওঠা সিদ্ধান্তের শূন্য প্রভাব ফেলতে হবে।


2
Er..umm .. std :: ভেক্টর একটি অ্যারে, সংযুক্ত-তালিকা নয়। স্ট্যান্ডার্ড লিংক-তালিকাটি, ভাল, স্টাড :: তালিকা।
জেমস কারান 14

1
হ্যাঁ, তবে আমি মনে করি ভেক্টর অপের কাছে যা চেয়েছে তার কাছাকাছি- একটি গতিশীল অ্যারে প্রতিস্থাপন।
জোয়েল কোহর্ন 14

@ জোয়েল, আমি এই প্রশ্নটি কেবল তখনই সম্পর্কিত করার চেষ্টা করছিলাম যেহেতু এটি আমার কাছে এই সহকর্মী দিয়েছিলেন যা সি ++ শিখার চেষ্টা করছেন। আমি নিজের লিঙ্কযুক্ত তালিকার কোডিংয়ের সাথে বিরক্ত করব না তবে সে আমাকে জিজ্ঞাসা করেছিল। :-)
ওনোরিও ক্যাটেনাচি

মেমরি-সীমাবদ্ধ পরিবেশে (মাইক্রোকন্ট্রোলার) যার জন্য কাস্টম সংকলক রয়েছে, সমস্ত ভাষার নয় (যেমন, সি ++ এর পাত্রে) প্রয়োগ করা হয় না। সুতরাং এটি হতে পারে যে আপনাকে নিজের লিঙ্কযুক্ত তালিকার কোড করতে হবে। nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus
মিন ট্রান

6

এটি সত্যিই দক্ষতার বিষয়, একটি লিঙ্কযুক্ত তালিকার ভিতরে উপাদানগুলি সন্নিবেশ করা, সরাতে বা সরানো (যেখানে আপনি কেবল সোয়াপিং করছেন না) উপাদানগুলি ন্যূনতম, অর্থাত ক্রিয়াকলাপটি হ'ল (1), একটি অ্যারের জন্য আয়াত ও (এন)। আপনি যদি কোনও তথ্যের তালিকায় প্রচুর পরিমাণে পরিচালনা করছেন তবে এটি একটি তাত্পর্যপূর্ণ পার্থক্য আনতে পারে। আপনি কীভাবে সেগুলি পরিচালনা করছেন তার উপর ভিত্তি করে আপনি আপনার ডেটা-প্রকারগুলি চয়ন করেছেন এবং আপনি যে অ্যালগরিদম ব্যবহার করছেন তার জন্য সবচেয়ে দক্ষ চয়ন করুন।


6

অ্যারেগুলি বোঝায় যে আইটেমগুলির সঠিক সংখ্যাটি কোথায় পরিচিত হবে এবং যেখানে সূচী দ্বারা অনুসন্ধান করা অর্থবোধ করে। উদাহরণস্বরূপ, আমি যদি কোনও সংক্ষেপণ ছাড়াই একটি নির্দিষ্ট মুহুর্তে আমার ভিডিও আউটপুটটির সঠিক স্থিতি সঞ্চয় করতে চাই তবে আমি সম্ভবত আকারের অ্যারে ব্যবহার করব [1024] [[6868] এটি আমাকে যা আমার প্রয়োজন ঠিক তা সরবরাহ করবে এবং প্রদত্ত পিক্সেলের মান পেতে একটি তালিকা অনেক বেশি ধীর হবে। যে জায়গাগুলিতে অ্যারেটি বোঝা যায় না সেখানে কার্যকরভাবে ডেটার সাথে ডিল করার জন্য তালিকার চেয়ে আরও ভাল ডেটা ধরণের রয়েছে।


6

অ্যারে বনাম লিঙ্কযুক্ত তালিকা:

  1. খণ্ডিত মেমরির কারণে অ্যারে মেমরির বরাদ্দ কখনও কখনও ব্যর্থ হয়।
  2. অ্যারেগুলিতে ক্যাচিং আরও ভাল কারণ সমস্ত উপাদানকে মেমরির স্থির পরিমাণ বরাদ্দ করা হয়।
  3. কোডিং অ্যারেগুলির চেয়ে জটিল।
  4. লিঙ্কযুক্ত তালিকায় অ্যারেগুলির বিপরীতে আকারের কোনও বাধা নেই
  5. লিঙ্কযুক্ত তালিকায় সন্নিবেশ / মুছে ফেলা দ্রুত এবং অ্যারেতে অ্যাক্সেস দ্রুততর।
  6. মাল্টি-থ্রেডিং দৃষ্টিকোণ থেকে লিঙ্কযুক্ত তালিকা আরও ভাল।

-1: এই সমস্তগুলি কেবল গণনা করা উচিত নয়, প্রমাণ করা দরকার।
জন স্যান্ডার্স

প্রতিটি বিষয় ইতিমধ্যে উপরের উত্তরে ব্যাখ্যা করা হয়েছে। দেরী হওয়ার কারণে আমার কাছে গণনা করা ছাড়া আর কোন উপায় ছিল না। বিটিডব্লিউ, আপনি কোনটি ব্যাখ্যা করতে চান?
একেএস

যদি তাদের ইতিমধ্যে ব্যাখ্যা করা হয়ে থাকে তবে আপনি উত্তর দিচ্ছেন কেন?
জন স্যান্ডার্স

2
যাতে এটি আপনাকে আলোচনার সংক্ষিপ্ত বিবরণ দেয়। এবং আমি এই জাতীয় উত্তরগুলি পছন্দ করি যাতে আমাকে বারবার একই ব্যাখ্যা না পড়তে হয়। এবং আমি সেই লোকদের জন্য এটি করেছি যারা আমার মতো চিন্তাভাবনা করে style বিভিন্ন পিপিএল বিভিন্ন স্টাইল আছে। নতুন কিছুই নেই.
একেএস

3

অ্যারে প্রকৃতিতে স্থির থাকায় মেমরি বরাদ্দকরণের মতো সমস্ত ক্রিয়াকলাপ কেবল সংকলনের সময় ঘটে of সুতরাং প্রসেসরটি তার রানটাইমটিতে কম প্রচেষ্টা করতে হবে।


3

ধরুন আপনার একটি অর্ডার করা সেট রয়েছে, যা আপনি উপাদানগুলি যুক্ত করে এবং মুছে ফেলাতে চান। আরও, আপনার কোনও এলিমেন্টের রেফারেন্সটি এমনভাবে ধরে রাখার সক্ষমতা প্রয়োজন যাতে পরে আপনি কোনও পূর্ববর্তী বা পরবর্তী উপাদান পেতে পারেন। উদাহরণস্বরূপ, কোনও বইয়ের কোনও করণীয় তালিকা বা অনুচ্ছেদের সেট।

প্রথমে আমাদের নোট করা উচিত যে আপনি যদি সেটগুলির বাইরেও অবজেক্টের রেফারেন্স ধরে রাখতে চান, তবে আপনি সম্ভবত বস্তুগুলি নিজেরাই সংরক্ষণ করার পরিবর্তে অ্যারেতে পয়েন্টারগুলি সংরক্ষণ করবেন। অন্যথায় আপনি অ্যারেতে সন্নিবেশ করতে সক্ষম হবেন না - যদি বস্তুগুলি অ্যারেতে এম্বেড করা থাকে তবে তারা সন্নিবেশের সময় সরানো হবে এবং তাদের কাছে কোনও পয়েন্টার অবৈধ হয়ে যাবে। অ্যারে সূচকগুলির ক্ষেত্রেও এটি সত্য।

আপনার প্রথম সমস্যাটি যেমন আপনি নিজেরাই লক্ষ্য করেছেন, সন্নিবেশ - লিঙ্কযুক্ত তালিকাকে ও (1) এ সন্নিবেশ করার অনুমতি দেয় তবে একটি অ্যারে সাধারণত ও (এন) প্রয়োজন হয়। এই সমস্যাটি আংশিকভাবে কাটিয়ে উঠতে পারে - এমন ডেটা স্ট্রাকচার তৈরি করা সম্ভব যা অ্যারে-এর মতো বাই-অর্ডিনাল অ্যাক্সেস ইন্টারফেস দেয় যেখানে পড়া এবং লেখা উভয়ই সবচেয়ে খারাপ, লগারিদমিক।

আপনার দ্বিতীয় এবং আরও গুরুতর সমস্যা হ'ল পরের উপাদানটি অনুসন্ধানকারী একটি উপাদানটি হ'ল হে (এন)। যদি সেটটি সংশোধন না করা হয় তবে আপনি মৌলটির সূচকটি পয়েন্টারের পরিবর্তে রেফারেন্স হিসাবে ধরে রাখতে পারবেন এভাবে একটি ও (1) ক্রিয়াকলাপ সন্ধান করতে পারেন, তবে এটি আপনার সমস্ত বস্তুরই পয়েন্টার এবং নিজেই কোনও উপায় নয় সম্পূর্ণ "অ্যারে" স্ক্যান করেই অ্যারেতে বর্তমান সূচি নির্ধারণ করতে। এটি অ্যারেগুলির জন্য একটি অনিবার্য সমস্যা - এমনকি আপনি সন্নিবেশকে অনুকূলিত করতে পারেন, সন্ধানের পরবর্তী ধরণের ক্রিয়াকে অপ্টিমাইজ করার জন্য আপনার কিছুই করার নেই।


আপনি কী দয়া করে এটিকে বিস্তারিতভাবে বর্ণনা করতে পারেন: "এমন একটি ডেটা স্ট্রাকচার তৈরি করা সম্ভব যা অ্যারে-এর মতো বাই-অর্ডিনাল অ্যাক্সেস ইন্টারফেস দেয় যেখানে পড়া এবং লেখা উভয়ই সবচেয়ে খারাপ, লগারিদমিক।"
হেনগামে

1
ডায়নামিক অ্যারে / ভায়েন্টস বিভাগের অধীনে উইকিপিডিয়ায় কিছু স্টাফ রয়েছে। যদিও এটি আমার মনে ছিল তা পুরোপুরি নয় ... পৃষ্ঠাগুলির সাথে কাঠামোর মতো একটি বি + গাছের কল্পনা করুন তবে কোনও কী নেই, পরিবর্তে প্রতিটি মধ্যবর্তী পৃষ্ঠায় প্রতিটি উপ-পৃষ্ঠায় কতগুলি উপাদান রয়েছে তা মনে আছে, যখন পাতাগুলির পাতা কেবল একটি ছোট অ্যারে উপাদান। কোনও পাতার পৃষ্ঠায় কোনও উপাদান tingোকানোর সময় আপনাকে ঘর তৈরি করতে অর্ধেক পৃষ্ঠা সরিয়ে নিতে হবে, তারপরে যান এবং সমস্ত পূর্বপুরুষের পৃষ্ঠায় আইটেম গণনা আপডেট করুন। একটি উপাদান # এন সন্ধান করার সময়, আপনি এন পার না হওয়া পর্যন্ত কেবল অধস্তন পৃষ্ঠার আইটেমের গণনা যোগ করুন এবং তারপরে সেই
সাবট্রিতে

3

একটি অ্যারেতে আপনার ও (1) সময়ে কোনও উপাদান অ্যাক্সেস করার সুবিধা রয়েছে। সুতরাং এটি বাইনারি অনুসন্ধান কুইক বাছাই ইত্যাদির মতো অপারেশনের জন্য উপযুক্ত the উভয়ের সুবিধাগুলি পাশাপাশি অসুবিধাগুলি রয়েছে এবং আপনি যেটি প্রয়োগ করতে চান তার চেয়ে কম অন্যটির তুলনায় একজনকে পছন্দ করা।

- বড় প্রশ্ন হ'ল আমাদের উভয়ের সংকর থাকতে পারে। পাইথন এবং পার্ল কীভাবে তালিকা হিসাবে প্রয়োগ করে।


3

যোজিত তালিকা

এটি সন্নিবেশ সম্পর্কে আরও বেশি পছন্দনীয়! মূলত যা হয় তা হ'ল এটি পয়েন্টারের সাথে কাজ করে

1 -> 3 -> 4

Sertোকান (2)

1 ........ 3 ...... 4
..... 2

পরিশেষে

1 -> 2 -> 3 -> 4

3 এ 2 পয়েন্ট থেকে একটি তীর এবং 2 এ 1 পয়েন্টের তীর

সরল!

কিন্তু অ্যারে থেকে

| 1 | 3 | 4 |

2োকান (2) | 1 | 3 | | 4 | | 1 | | 3 | 4 | | 1 | 2 | 3 | 4 |

আচ্ছা যে কেউ পার্থক্যটি কল্পনা করতে পারে! মাত্র 4 সূচকের জন্য আমরা 3 টি পদক্ষেপ নিচ্ছি

অ্যারের দৈর্ঘ্য যদি এক মিলিয়ন হয় তবে কী হবে? অ্যারে দক্ষ? উত্তর নেই! :)

মুছে ফেলার জন্য একই জিনিস! লিঙ্কযুক্ত তালিকায় আমরা কেবল পয়েন্টারটি ব্যবহার করতে পারি এবং অবজেক্ট ক্লাসে উপাদানটি এবং পরবর্তীটি বাতিল করতে পারি! তবে অ্যারের জন্য, আমাদের শিফট লেফট () সম্পাদন করা দরকার

আশা করি এইটি কাজ করবে! :)


3

লিঙ্কযুক্ত তালিকা অ্যারের চেয়ে বজায় রাখার জন্য একটি ওভারহেডের বেশি, এটির জন্য অতিরিক্ত মেমরি স্টোরেজও দরকার এই সমস্ত পয়েন্ট একমত হয় are তবে কিছু জিনিস রয়েছে যা অ্যারে করতে পারে না। অনেক ক্ষেত্রে মনে করুন আপনি 10 ^ 9 দৈর্ঘ্যের একটি অ্যারে চান তবে আপনি এটি পেতে পারেন না কারণ একটি ক্রমাগত মেমরির অবস্থান পেয়ে সেখানে থাকতে হবে। লিঙ্কযুক্ত তালিকাটি এখানে ত্রাণকর্তা হতে পারে।

মনে করুন আপনি ডেটা সহ একাধিক জিনিস সঞ্চয় করতে চান তবে সেগুলি লিঙ্কযুক্ত তালিকায় সহজেই বাড়ানো যেতে পারে।

এসটিএল পাত্রে সাধারণত দৃশ্যের পিছনে তালিকা বাস্তবায়ন যুক্ত থাকে।


3

1- লিঙ্কযুক্ত তালিকাটি একটি গতিশীল ডেটা স্ট্রাকচার তাই এটি মেমরি বরাদ্দকরণ এবং বিলোপ করে রানটাইমের সময় বাড়তে এবং সঙ্কুচিত করতে পারে। সুতরাং লিঙ্কযুক্ত তালিকার প্রাথমিক আকার দেওয়ার দরকার নেই। নোড সন্নিবেশ এবং মুছে ফেলা সত্যিই সহজ।

2- লিঙ্কযুক্ত তালিকার আকার রান সময় বাড়াতে বা হ্রাস করতে পারে যাতে কোনও স্মৃতির অপচয় হয় না। অ্যারের ক্ষেত্রে মেমরির প্রচুর অপচয় হয়, যেমন আমরা যদি 10 মাপের একটি অ্যারে ঘোষণা করি এবং এটিতে কেবল 6 টি উপাদান সংরক্ষণ করি তবে 4 উপাদানগুলির স্থান নষ্ট হবে। লিঙ্কযুক্ত তালিকায় এ জাতীয় কোনও সমস্যা নেই কারণ শুধুমাত্র যখন প্রয়োজন হয় তখন মেমরি বরাদ্দ করা হয়।

3- স্ট্যাক এবং সারিগুলির মতো ডেটা স্ট্রাকচারগুলি লিঙ্কযুক্ত তালিকার সাহায্যে সহজেই প্রয়োগ করা যেতে পারে।


2

লিঙ্কযুক্ত তালিকা ব্যবহারের একমাত্র কারণ হ'ল উপাদানটি সন্নিবেশ করা সহজ (এছাড়াও অপসারণ)।

ডিসডাভেটিজ হতে পারে যে পয়েন্টারগুলি অনেক বেশি জায়গা নেয়।

এবং সেই সম্পর্কে কোডিংটি আরও শক্ত: সাধারণত আপনার কোড লিঙ্কযুক্ত তালিকার প্রয়োজন হয় না (বা কেবল একবারেই) সেগুলি এসটিএলে অন্তর্ভুক্ত করা হয় এবং এটি আপনাকে এখনও করতে হয় তবে এটি এত জটিল নয়।


2
পয়েন্টার অনেক জায়গা নেয়? আসলে তা না. আপনি যদি বুলিয়ানগুলির একটি লিঙ্কযুক্ত তালিকাটি সংরক্ষণ করেন তবে নিশ্চিত হন, শতাংশের ভিত্তিতে পয়েন্টাররা অনেক বেশি জায়গা নেয়। তবে আপনি যদি জটিল বস্তুগুলি সংরক্ষণ করেন (যা সাধারণত এটি হয়) তবে পয়েন্টারগুলি সম্ভবত নগণ্য হবে।
হার্মেস

হাসি ভুলে গেছেন :) তবে বলেছিলেন 'পারে না' তা '।
ব্যবহারকারী 15453

1

আমি আরও মনে করি যে লিঙ্কের তালিকা অ্যারেগুলির চেয়ে আরও ভাল। কারণ আমরা লিঙ্ক তালিকায় ট্র্যাভারসিং করি তবে অ্যারেগুলিতে নয়


1

আপনার ভাষার উপর নির্ভর করে, এই অসুবিধাগুলি এবং সুবিধার কয়েকটি বিবেচনা করা যেতে পারে:

সি প্রোগ্রামিং ল্যাঙ্গুয়েজ : একটি লিঙ্কযুক্ত তালিকা ব্যবহার করার সময় (সাধারণত স্ট্রাক পয়েন্টারগুলির মাধ্যমে), বিশেষভাবে বিবেচনা করা উচিত যে আপনি মেমরি ফাঁস করছেন না। যেমনটি আগেই উল্লেখ করা হয়েছিল, লিঙ্কযুক্ত তালিকাগুলি বদলানো সহজ, কারণ সমস্তগুলি করছিল পয়েন্টারগুলি পরিবর্তন করা, তবে আমরা কি সমস্ত কিছু মুক্ত করার কথা মনে রাখতে পারি?

জাভা : জাভাতে একটি স্বয়ংক্রিয় আবর্জনা সংগ্রহ রয়েছে, সুতরাং মেমরি ফাঁস হওয়া কোনও সমস্যা হবে না, তবে উচ্চ পর্যায়ের প্রোগ্রামার থেকে গোপনীয়ত লিঙ্কযুক্ত তালিকাটি কী তা বাস্তবায়নের বিশদ। তালিকার মাঝামাঝি থেকে নোড অপসারণ করার পদ্ধতিগুলি এমন কোনও পদ্ধতির ক্ষেত্রে জটিল যা ভাষার কিছু ব্যবহারকারী এটি প্রত্যাশা করে তার চেয়ে বেশি জটিল।


1

একটি অ্যারের উপরে লিঙ্কযুক্ত তালিকা কেন? পাশাপাশি কিছু ইতিমধ্যে বলেছে, সন্নিবেশ এবং মোছার আরও বেশি গতি।

তবে সম্ভবত আমাদের দুজনেরই সীমাবদ্ধতা নিয়ে বেঁচে থাকতে হবে না, এবং একই সাথে দু'জনের সেরাটাও পেতে হবে ... এহ?

অ্যারে মুছে ফেলার জন্য, আপনি একটি 'মুছে ফেলা' বাইট ব্যবহার করতে পারেন, এই সত্তার প্রতিনিধিত্ব করতে যে একটি সারি মুছে ফেলা হয়েছে, সুতরাং অ্যারেটিকে পুনরায় ভাগ করা আর দরকার নেই। সন্নিবেশগুলি বা দ্রুত ডেটা পরিবর্তন করার বোঝাটি সহজ করার জন্য, এর জন্য একটি লিঙ্কযুক্ত তালিকা ব্যবহার করুন। তারপরে তাদের উল্লেখ করার সময়, প্রথমে আপনার যুক্তি সন্ধান করুন, তারপরে অন্যটি। সুতরাং, তাদের সংমিশ্রণে ব্যবহার করা আপনাকে উভয়ের মধ্যে সেরা দেয়।

আপনার যদি সত্যিই বড় অ্যারে থাকে তবে আপনি এটিকে অন্য, অনেক ছোট অ্যারে বা লিঙ্কযুক্ত তালিকার সাথে একত্রিত করতে পারেন যেখানে ছোট একটিতে সম্প্রতি ব্যবহৃত 20, 50, 100 টি ব্যবহৃত আইটেম রয়েছে। যদি প্রয়োজনীয় একটি সংক্ষিপ্ত সংযুক্ত তালিকায় বা অ্যারে না থাকে তবে আপনি বড় অ্যারেতে যান। যদি সেখানে পাওয়া যায়, তবে আপনি এটির পরিবর্তে ছোট সংযুক্ত তালিকায় / অ্যারে যুক্ত করতে পারেন যে 'সর্বাধিক ব্যবহৃত জিনিসগুলি পুনরায় ব্যবহার করা খুব পছন্দসই' (এবং হ্যাঁ, সম্ভবত তালিকা থেকে সর্বাধিক ব্যবহৃত আইটেমটি ধাক্কা দেওয়া)। যা অনেক ক্ষেত্রে সত্য এবং একটি সমস্যার সমাধান করেছিলাম যা আমাকে একটি .এএসপি সুরক্ষা অনুমতিগুলির চেকিং মডিউল, স্বাচ্ছন্দ্য, কমনীয়তা এবং চিত্তাকর্ষক গতির সাথে মোকাবিলা করতে হয়েছিল।


1

আপনারা অনেকে লিখিত তালিকায় বনাম অ্যারের প্রধান পরামর্শদাতাদের উপর নজর রেখেছেন, তবে বেশিরভাগ তুলনা হ'ল একজন কীভাবে অপরটির চেয়ে ভাল / খারাপ। আপনি অ্যারেতে এলোমেলো অ্যাক্সেস করতে পারেন তবে লিঙ্কযুক্ত তালিকায় এবং অন্যগুলিতে সম্ভব নয়। যাইহোক, এটি ধরে নিচ্ছে লিঙ্ক তালিকাগুলি এবং অ্যারে একই ধরণের অ্যাপ্লিকেশনটিতে প্রয়োগ হতে চলেছে। তবে একটি সঠিক উত্তর হ'ল একটি নির্দিষ্ট অ্যাপ্লিকেশন মোতায়েনের ক্ষেত্রে অ্যারের তুলনায় লিঙ্ক তালিকার কীভাবে অগ্রাধিকার দেওয়া হবে। মনে করুন আপনি অভিধানের প্রয়োগ প্রয়োগ করতে চান, আপনি কী ব্যবহার করবেন? অ্যারে: মিমি এটি বাইনারি অনুসন্ধান এবং অন্যান্য অনুসন্ধানের মাধ্যমে সহজে পুনরুদ্ধারের মঞ্জুরি দেয় .. তবে কীভাবে লিঙ্কের তালিকা আরও ভাল হতে পারে তা ভাবতে দিন..তাই আপনি অভিধানে "ব্লব" অনুসন্ধান করতে চান। এটি-> বি-> সি-> ডি ----> এর একটি লিঙ্ক তালিকা থাকা কি বোধগম্য হবে?

A -> B -> C -> ...Z
|    |    |
|    |    [Cat, Cave]
|    [Banana, Blob]
[Adam, Apple]

এখন উপরোক্ত পদ্ধতিটি আরও ভাল বা [অ্যাডাম, অ্যাপল, কলা, ব্লব, বিড়াল, গুহা] এর সমতল অ্যারে? এটি অ্যারে দিয়েও সম্ভব হবে? সুতরাং লিঙ্ক তালিকার একটি বড় সুবিধা হ'ল আপনার কাছে এমন একটি উপাদান থাকতে পারে যা কেবলমাত্র পরবর্তী উপাদানগুলিতে নির্দেশ না করে অন্য কোনও লিঙ্ক তালিকা / অ্যারে / হিপ / বা অন্য কোনও মেমোরি অবস্থানের দিকেও নির্দেশ করে। অ্যারে হ'ল এটির উপাদানগুলির ব্লক আকারে টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো লিঙ্কের তালিকা অন্যভাবে আপনি চান। একইভাবে বলতে দিন যে আপনি একটি ইউএসবি ড্রাইভ তৈরি করছেন। এখন আপনি কি ফাইলগুলি কোনও অ্যারে বা লিঙ্ক তালিকার হিসাবে সংরক্ষণ করা চান? আমি মনে করি আপনি কী ধারণাটি পেয়েছেন আমি যা নির্দেশ করছি :)

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.