source

어레이 대 링크드 리스트

manycodes 2023. 5. 21. 11:41
반응형

어레이 대 링크드 리스트

누군가 배열 위에 링크드 리스트를 사용하려는 이유는 무엇입니까?

연결된 목록을 코딩하는 것은 의심할 여지 없이 배열을 사용하는 것보다 약간 더 많은 작업이며 추가 작업을 정당화하는 것이 무엇인지 궁금해할 수 있습니다.

링크된 목록에서 새로운 요소를 삽입하는 것은 사소한 일이지만 배열에서 주요 작업이라고 생각합니다.연결된 목록을 사용하여 데이터 집합을 저장할 때 어레이에 저장할 때와 비교하여 다른 이점이 있습니까?

이 질문은 일반적인 데이터 구조와 관련된 반면 다른 질문은 특정 Java 클래스에 대해 구체적으로 질문하기 때문에 질문이 중복되지 않습니다.

또 다른 좋은 이유는 링크된 목록이 효율적인 멀티스레드 구현에 도움이 되기 때문입니다.이는 변경사항이 로컬인 경향이 있기 때문입니다. 즉, 데이터 구조의 현지화된 부분에서 삽입 및 제거를 위한 포인터 한두 개에만 영향을 미치기 때문입니다.따라서 여러 스레드가 동일한 연결 목록에서 작동할 수 있습니다.또한 CAS 유형 작업을 사용하여 잠금이 없는 버전을 생성하고 무거운 잠금을 방지할 수 있습니다.

링크된 목록을 사용하면 수정 중에도 반복자가 목록을 통과할 수 있습니다.수정 사항이 충돌하지 않는 낙관적인 경우, 반복자는 경합 없이 계속될 수 있습니다.

어레이의 경우 어레이의 크기를 수정하는 변경은 어레이의 많은 부분을 잠그는 것이 필요할 수 있습니다. 실제로 전체 어레이에 걸쳐 글로벌 잠금 없이 수행되는 경우는 드물기 때문에 수정 작업이 세계적인 문제를 해결하는 데 도움이 됩니다.

  • 다양한 크기의 데이터를 연결된 목록에 저장하는 것이 더 쉽습니다.배열은 모든 요소의 크기가 정확히 같다고 가정합니다.
  • 말씀하신 것처럼 링크된 목록이 유기적으로 증가하기 쉽습니다.어레이의 크기를 미리 알려주거나 확장이 필요할 때 다시 만들어야 합니다.
  • 링크된 목록을 섞는 것은 무엇을 무엇으로 바꾸느냐의 문제일 뿐입니다.배열을 섞는 것은 더 복잡하거나 더 많은 메모리가 필요합니다.
  • 모든 반복이 "각자" 맥락에서 발생하는 한, 반복 시 성능이 저하되지 않습니다.

위키백과는 차이점에 대한 좋은 섹션을 가지고 있습니다.

연결된 목록은 배열에 비해 몇 가지 이점이 있습니다.요소는 링크된 목록에 무한정 삽입될 수 있지만 어레이는 결국 가득 차거나 크기를 조정해야 하며, 메모리가 조각난 경우에도 비용이 많이 드는 작업이 불가능할 수 있습니다.마찬가지로, 많은 요소가 제거된 배열은 낭비적으로 비어 있거나 더 작게 만들어야 할 수 있습니다.

반면, 배열은 임의 액세스를 허용하는 반면, 연결된 목록은 요소에 대한 순차적 액세스만 허용합니다.실제로 단일 링크 목록은 한 방향으로만 이동할 수 있습니다.따라서 연결된 목록은 힙 정렬과 같이 인덱스를 기준으로 요소를 빠르게 검색하는 데 유용한 응용 프로그램에 적합하지 않습니다.참조 및 데이터 캐시의 인접성으로 인해 어레이에 대한 순차적 액세스도 많은 시스템의 링크된 목록보다 빠릅니다.연결된 목록은 캐시의 이점을 거의 받지 못합니다.

링크된 목록의 또 다른 단점은 참조에 필요한 추가 스토리지로, 문자나 부울 값과 같은 작은 데이터 항목의 목록에는 사용할 수 없다는 것입니다.또한 각 새로운 요소에 대해 메모리를 개별적으로 할당하는 것은 느리고 순진한 할당기를 사용하면 낭비가 될 수 있으며, 일반적으로 메모리 풀을 사용하여 해결되는 문제입니다.

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

목록이 순수하게 기능하는 데이터 구조로 작동할 수 있다는 점을 하나 더 추가하겠습니다.

예를 들어, 동일한 끝 섹션을 공유하는 완전히 다른 목록을 가질 수 있습니다.

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원본 데이터를 복사하지 않고도 자유롭게 작업을 수행할 수 있습니다. 즉, 데이터를 불변으로 취급할 때 매우 중요한 기능입니다.

목록 중간에 삽입하는 것이 더 쉬울 뿐만 아니라, 연결된 목록 중간에서 삭제하는 것이 배열보다 훨씬 쉽습니다.

하지만 솔직히, 저는 링크된 목록을 사용해 본 적이 없습니다.빠른 삽입과 삭제가 필요할 때마다 빠른 조회도 필요했기 때문에 해시셋이나 사전을 찾아갔습니다.

두 개의 연결된 목록(특히 이중으로 연결된 두 개의 목록)을 병합하는 것이 두 개의 배열을 병합하는 것보다 훨씬 빠릅니다(합병이 파괴적이라고 가정).전자는 O(1)이고 후자는 O(n)입니다.

편집: 명확히 하기 위해, 제 말은 병합 정렬이 아니라 순서가 없는 의미에서 "합병"을 의미했습니다.아마도 "연결"하는 것이 더 나은 단어였을 것입니다.

ArrayList 및 LinkedList에 대한 널리 인식되지 않는 인수는 LinkedList가 디버깅하는 동안 불편하다는 것입니다.유지보수 개발자가 프로그램을 이해하는 데 걸리는 시간(예: 버그, 증가 및 IMHO)은 때때로 엔터프라이즈 애플리케이션의 성능 향상 또는 메모리 소비 바이트 수에서 나노초를 정당화하지 못합니다.때로는(물론 애플리케이션 유형에 따라 다릅니다.) 몇 바이트를 낭비하면서 더 유지 관리 가능하거나 더 쉽게 이해할 수 있는 애플리케이션을 사용하는 것이 경우에 따라 다릅니다.

예를 들어, Java 환경에서 Eclipse 디버거를 사용하는 경우 ArrayList를 디버깅하면 매우 이해하기 쉬운 구조가 나타납니다.

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

반면에 LinkedList의 내용을 보고 특정 개체를 찾는 것은 LinkedList 내부를 필터링하는 데 필요한 인지 오버헤드는 말할 것도 없고 확장-더-트리 클릭 악몽이 됩니다.

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>

무엇보다도, C++에서 링크드 리스트는 배열보다 작업하는 데 훨씬 더 큰 어려움이 없을 것입니다.연결된 목록에는 std::list 또는 부스트 포인터 목록을 사용할 수 있습니다.연결된 목록과 어레이의 주요 문제는 포인터에 필요한 추가 공간과 끔찍한 랜덤 액세스입니다.링크된 목록을 사용해야 합니다.

  • 데이터에 임의로 액세스할 필요가 없습니다.
  • 특히 목록의 중간에 요소를 추가/삭제합니다.

저한테는 이런 거예요.

  1. 접근

    • 연결된 목록은 요소에 대한 순차적 액세스만 허용합니다.따라서 알고리즘 복잡도는 O(n)의 순서입니다.
    • 어레이는 해당 요소에 대한 랜덤 액세스를 허용하므로 복잡성은 O(1) 수준입니다.
  2. 보관소

    • 연결된 목록에는 참조를 위한 추가 저장소가 필요합니다.따라서 문자나 부울 값과 같은 작은 데이터 항목의 목록에서는 실용적이지 않습니다.
    • 어레이는 다음 데이터 항목을 가리키는 데 추가 스토리지가 필요하지 않습니다.각 요소는 인덱스를 통해 액세스할 수 있습니다.
  3. 크기

    • 연결된 목록의 크기는 기본적으로 동적입니다.
    • 배열 크기는 선언으로 제한됩니다.
  4. 삽입/삭제

    • 링크된 목록에서 요소를 무한정 삽입 및 삭제할 수 있습니다.
    • 배열에서 값을 삽입/삭제하는 데는 비용이 매우 많이 듭니다.메모리 재할당이 필요합니다.

두 가지:

연결된 목록을 코딩하는 것은 의심할 여지 없이 배열을 사용하는 것보다 조금 더 많은 작업입니다. 그는 무엇이 추가적인 노력을 정당화하는지 궁금했습니다.

C++를 사용할 때는 연결된 목록을 코드화하지 마십시오.그냥 STL을 사용하세요.대부분이 이미 구현되어 있기 때문에 구현이 얼마나 어려운지가 데이터 구조를 선택하는 이유가 되어서는 안 됩니다.

배열과 링크된 목록의 실제 차이에 대해 말하자면, 저에게 가장 중요한 것은 구조를 어떻게 사용할 것인가 하는 것입니다.벡터라는 용어는 C++에서 크기 조정 가능한 배열을 의미하기 때문에 사용하겠습니다.

지정된 인덱스에 도달하려면 목록을 통과해야 하기 때문에 링크된 목록으로 인덱싱하는 속도가 느리며, 메모리에는 벡터가 인접해 있으며 포인터 연산을 사용하여 해당 목록에 도달할 수 있습니다.

링크 목록의 끝이나 시작 부분에 추가하는 것은 쉽습니다. 벡터에서 내용의 크기를 조정하고 복사해야 하는 링크를 하나만 업데이트하면 되기 때문입니다.

목록에서 항목을 제거하는 것은 한 쌍의 링크를 끊고 다시 연결하기만 하면 되므로 쉽습니다.벡터에서 항목을 제거하는 것은 순서에 따라 더 빠르거나 느릴 수 있습니다.제거할 항목 위에 있는 마지막 항목을 스왑하는 것이 더 빠르며, 제거 후 모든 항목을 이동하는 것이 더 느리지만 순서를 유지합니다.

Eric Lippert는 최근 어레이를 보수적으로 사용해야 하는 이유 중 하나에 대한 게시물을 게시했습니다.

빠른 삽입 및 제거는 실제로 링크된 목록에 대한 최상의 인수입니다.구조가 동적으로 증가하고 요소(예: 동적 스택 및 대기열)에 대한 상시 액세스가 필요하지 않은 경우 링크된 목록을 선택하는 것이 좋습니다.

여기 간단한 것이 있습니다. 항목을 제거하는 것이 더 빠릅니다.

링크드 리스트는 컬렉션이 지속적으로 증가하거나 축소되는 경우 특히 유용합니다.예를 들어, 배열을 사용하여 큐(끝에 추가, 앞에서 제거)를 구현하는 것은 상상하기 어렵습니다. 모든 시간을 아래로 이동하는 데 사용할 것입니다.반면에, 링크드 리스트는 사소한 것입니다.

목록 중간에 추가하거나 제거하는 것 외에 링크된 목록은 동적으로 증가하고 축소할 수 있기 때문에 더 좋아합니다.

어레이 및 링크된 목록:

  1. 메모리 조각 때문에 어레이 메모리 할당이 실패하는 경우가 있습니다.
  2. 모든 요소에 연속적인 메모리 공간이 할당되므로 캐슁이 어레이에서 더 효율적입니다.
  3. 코딩은 배열보다 더 복잡합니다.
  4. 어레이와 달리 연결된 목록에 크기 제한 없음
  5. 삽입/삭제는 Linked List에서 더 빠르고 액세스는 Array에서 더 빠릅니다.
  6. 멀티스레딩 관점에서 Linked List를 더 효과적으로 사용할 수 있습니다.

아무도 더 이상 자신의 링크 리스트를 코딩하지 않습니다.그건 바보 같은 소리야.링크된 목록을 사용하는 데 더 많은 코드가 필요하다는 전제는 잘못된 것입니다.

요즘, 연결된 목록을 만드는 것은 학생들이 개념을 이해할 수 있도록 하기 위한 연습일 뿐입니다.대신 모든 사용자가 미리 작성된 목록을 사용합니다.벡터(C++ 서에설기면초하명, 그아도마 stl것의다입니미할터벡)를 의미할 것입니다.#include <vector>).

따라서 연결된 목록과 배열을 선택하는 은 전적으로 앱의 필요에 따라 각 구조의 다른 특성을 저울질하는 것입니다.추가적인 프로그래밍 부담을 극복하는 것은 결정에 영향을 미치지 않아야 합니다.

효율성의 문제입니다. 링크된 목록 내에서 요소를 삽입, 제거 또는 이동하는 오버헤드는 최소입니다. 즉, 작업 자체가 배열에 대해 O(1), 절 O(n)입니다.데이터 목록에서 작업량이 많은 경우 이로 인해 상당한 차이가 발생할 수 있습니다.데이터 유형에 대한 작업 방식에 따라 데이터 유형을 선택하고 사용 중인 알고리즘에 가장 효율적인 유형을 선택합니다.

배열은 정확한 항목 수를 알 수 있는 위치와 인덱스로 검색하는 위치를 의미합니다.예를 들어, 압축 없이 주어진 순간에 비디오 출력의 정확한 상태를 저장하려면 크기가 [1024][768]인 어레이를 사용할 것입니다.이것은 제가 필요로 하는 것을 정확히 제공할 것이고, 주어진 픽셀의 값을 얻기 위해서는 목록이 훨씬 더 느릴 것입니다.배열이 의미가 없는 곳에서는 일반적으로 데이터를 효과적으로 처리하기 위해 목록보다 더 나은 데이터 유형이 있습니다.

어레이는 본질적으로 정적이기 때문에 메모리 할당과 같은 모든 작업은 컴파일 시에만 수행됩니다.따라서 프로세서는 런타임에 더 적은 노력을 기울여야 합니다.

요소를 추가 및 제거하여 수정하려는 순서 집합이 있다고 가정합니다.또한 나중에 이전 또는 다음 요소를 얻을 수 있도록 요소에 대한 참조를 유지할 수 있는 기능이 필요합니다.예를 들어, 책의 작업관리 목록 또는 문단 집합입니다.

먼저 집합 자체 외부의 개체에 대한 참조를 유지하려는 경우 개체 자체를 저장하는 것이 아니라 배열에 포인터를 저장하게 될 가능성이 높습니다.그렇지 않으면 배열에 개체를 삽입할 수 없습니다. 개체가 배열에 포함되어 있으면 삽입 중에 개체가 이동하고 개체에 대한 포인터가 유효하지 않게 됩니다.어레이 인덱스도 마찬가지입니다.

당신이 스스로 지적했듯이, 당신의 첫 번째 문제는 삽입 - 연결된 목록은 O(1)에 삽입할 수 있지만 배열은 일반적으로 O(n)를 필요로 합니다.이 문제는 부분적으로 극복할 수 있습니다. 읽기와 쓰기가 모두 최악의 경우 로그인 배열과 같은 순서별 액세스 인터페이스를 제공하는 데이터 구조를 만들 수 있습니다.

두 번째이자 더 심각한 문제는 다음 원소를 찾는 원소가 O(n)라는 것입니다.세트가 수정되지 않은 경우 포인터 대신 요소의 인덱스를 참조로 유지하여 O(1) 작업을 수행할 수 있지만, 개체 자체에 대한 포인터만 있을 뿐 전체 "어레이"를 스캔하는 것 외에는 어레이에서 현재 인덱스를 확인할 수 없습니다.이것은 어레이에서 극복할 수 없는 문제입니다. 삽입을 최적화할 수 있더라도 다음 유형 찾기 작업을 최적화하기 위해 할 수 있는 일은 없습니다.

배열에서는 O(1) 시간 내에 모든 요소에 액세스할 수 있는 권한이 있습니다.그래서 이진 검색 빠른 정렬 등의 작업에 적합합니다.반면에 링크된 목록은 O(1) 시간에 삽입 삭제에 적합합니다.둘 다 장점도 있고 단점도 있고, 둘 중 하나를 선호하는 것은 구현하고 싶은 것으로 요약됩니다.

더 큰 문제는 우리가 두 가지의 혼합물을 가질 수 있을까 하는 것입니다.파이썬과 펄이 목록으로 구현하는 것과 같은 것입니다.

연결된 목록

삽입에 관해서는 더 선호됩니다!기본적으로 하는 일은 포인터를 다루는 것입니다.

1 -> 3 -> 4

삽입(2)

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

마침내.

1 -> 2 -> 3 -> 4

3점에서 2점에서 1개의 화살표, 2점에서 1개의 화살표

간단!

그러나 배열에서

| 1 | 3 | 4 |

삽입 (2) | 1 | 3 | 4 | 1 | 3 | 4 | 3 | 4 | 1 | 2 | 3 | 4 |

누구나 그 차이를 시각화할 수 있습니다!단지 4개의 인덱스에 대해 우리는 3단계를 수행하고 있습니다.

그러면 배열 길이가 백만이면 어떨까요?어레이가 효율적입니까?답은 NO입니다! :)

삭제할 때도 마찬가지입니다.Linked List에서 우리는 포인터를 사용하여 요소와 객체 클래스의 다음을 무효화할 수 있습니다!그러나 어레이의 경우 ShiftLeft()를 수행해야 합니다.

도움이 되길 바랍니다! :)

Linked List는 어레이보다 유지 관리해야 하는 오버헤드에 가깝습니다. 이 모든 사항에 동의하는 추가 메모리 스토리지도 필요합니다.하지만 어레이가 할 수 없는 몇 가지가 있습니다.대부분의 경우 길이가 10^9인 배열을 원한다고 가정합니다. 하나의 연속 메모리 위치를 얻어야 하기 때문에 얻을 수 없습니다.링크된 목록이 여기서 구원자가 될 수 있습니다.

여러 항목을 데이터와 함께 저장하여 연결된 목록에서 쉽게 확장할 수 있다고 가정합니다.

STL 컨테이너는 일반적으로 씬(scene) 뒤에 링크드 리스트 구현이 있습니다.

1- Linked List는 메모리 할당 및 할당 해제를 통해 런타임에 증가하고 축소할 수 있는 동적 데이터 구조입니다.따라서 링크된 목록의 초기 크기를 지정할 필요가 없습니다.노드를 삽입하고 삭제하는 것이 매우 쉽습니다.

2-연결된 목록의 크기는 실행 시 증가하거나 감소할 수 있으므로 메모리 낭비가 없습니다.어레이의 경우 크기가 10인 어레이를 선언하고 6개의 요소만 저장하면 4개의 요소 공간이 낭비되는 등 메모리 사용량이 많습니다.필요한 경우에만 메모리가 할당되므로 연결된 목록에는 이러한 문제가 없습니다.

3 - 연결된 목록을 사용하여 스택, 큐 등의 데이터 구조를 쉽게 구현할 수 있습니다.

링크된 목록을 사용하는 유일한 이유는 요소를 쉽게 삽입할 수 있기 때문입니다(제거도 가능).

단점은 포인터가 많은 공간을 차지한다는 것입니다.

그리고 그 코딩에 대해서는 더 어렵습니다.일반적으로 코드 연결 목록(또는 한 번만)이 STL에 포함되어 있고 여전히 해야 한다면 그렇게 복잡하지 않습니다.

저는 또한 링크 목록이 배열보다 더 낫다고 생각합니다.우리는 링크 목록에서 순회를 하지만 배열에서는 하지 않기 때문입니다.

언어에 따라 다음과 같은 단점과 장점을 고려할 수 있습니다.

C 프로그래밍 언어:연결된 목록을 사용할 때(일반적으로 구조 포인터를 통해) 메모리가 누출되지 않도록 특별히 고려해야 합니다.앞에서 언급했듯이 링크된 목록은 포인터를 바꾸는 것이기 때문에 섞기 쉽습니다. 하지만 우리는 모든 것을 자유롭게 하는 것을 기억할 것인가요?

Java: Java에는 자동 가비지 수집 기능이 있으므로 메모리 누수는 문제가 되지 않지만 상위 레벨의 프로그래머로부터 숨겨지는 것이 링크된 목록이 무엇인지에 대한 구현 세부 사항입니다.목록 중간에서 노드를 제거하는 것과 같은 방법은 일부 언어 사용자가 예상하는 것보다 절차가 더 복잡합니다.

어레이에 연결된 목록을 선택해야 하는 이유몇몇 사람들이 이미 말했듯이, 삽입과 삭제의 속도가 더 빠릅니다.

하지만 어쩌면 우리는 둘 다의 한계를 감수하고 동시에 둘 다의 장점을 누릴 필요는 없을지도 모릅니다.

배열 삭제의 경우 '삭제됨' 바이트를 사용하여 행이 삭제되었음을 나타낼 수 있으므로 더 이상 배열을 다시 정렬할 필요가 없습니다.삽입 또는 데이터를 빠르게 변경하는 부담을 줄이려면 연결된 목록을 사용합니다.그런 다음, 그들을 언급할 때, 당신의 논리가 먼저 하나를 검색하고, 그 다음에 다른 하나를 검색하도록 하라.따라서 이러한 기능을 조합하여 사용하면 두 가지를 모두 활용할 수 있습니다.

만약 당신이 정말 큰 배열을 가지고 있다면, 당신은 그것을 다른 훨씬 작은 배열이나 링크된 목록과 결합할 수 있습니다. 작은 배열은 가장 최근에 사용된 20, 50, 100개의 항목을 포함합니다.필요한 것이 더 짧은 연결 목록이나 배열에 없으면 큰 배열로 이동합니다.이 목록이 발견되면 '가장 최근에 사용한 항목이 재사용될 가능성이 가장 높다'는 가정 하에 링크된 작은 목록/배열에 추가할 수 있습니다(그리고 예, 목록에서 가장 최근에 사용하지 않은 항목과 충돌할 수도 있습니다).이는 많은 경우에 해당하며 .ASP 보안 권한 확인 모듈에서 해결해야 했던 문제를 쉽고 우아하며 놀라운 속도로 해결했습니다.

링크드 리스트 대 어레이의 주요 adv./dis에 대해 언급한 적이 있지만, 대부분의 비교는 어느 쪽이 다른 쪽보다 나은지/나쁜지에 대한 것입니다.예: 어레이에서는 랜덤 액세스가 가능하지만 연결된 목록 등에서는 불가능합니다.그러나 이는 링크 목록과 배열이 유사한 응용 프로그램에 적용될 것이라고 가정합니다.하지만 정답은 특정 애플리케이션 배포에서 어레이보다 링크 목록을 선호하는 방법과 그 반대의 경우입니다.만약 당신이 사전 애플리케이션을 구현하고 싶다면, 무엇을 사용하시겠습니까?배열: 음, 이진 검색과 다른 검색 알고리즘을 통해 쉽게 검색할 수 있지만, 링크 목록이 어떻게 더 나아질 수 있는지 생각해 봅시다.사전에서 "블럽"을 검색하고 싶다고 해보세요.A->B->C->D->Z의 링크 목록과 각 목록 요소도 해당 문자로 시작하는 배열 또는 다른 모든 단어 목록을 가리키는 것이 말이 됩니까?

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

이제 위의 접근 방식이 더 나은가 아니면 [Adam, Apple, Bana, Blob, Cat, Cave]의 평평한 배열입니까? 배열로 가능할까요?따라서 링크 목록의 주요 이점은 다음 요소뿐만 아니라 다른 링크 목록/어레이/히프/또는 다른 메모리 위치를 가리키는 요소를 가질 수 있다는 것입니다.어레이는 저장할 요소의 블록 크기로 분할된 하나의 평평한 연속 메모리입니다.반면에 링크 목록은 인접하지 않은 메모리 장치(모든 크기가 될 수 있고 무엇이든 저장할 수 있음)의 덩어리이며 원하는 방식으로 서로를 가리킵니다.마찬가지로 USB 드라이브를 만든다고 가정해 보겠습니다.이제 파일을 어레이 또는 링크 목록으로 저장하시겠습니까?당신은 제가 무엇을 가리키고 있는지 이해한다고 생각합니다 :)

언급URL : https://stackoverflow.com/questions/166884/array-versus-linked-list

반응형