C ++ STL이 "트리"컨테이너를 제공하지 않는 이유는 무엇입니까?

C ++ STL이 "트리"컨테이너를 제공하지 않는 이유는 무엇이며 대신 가장 좋은 방법은 무엇입니까?

트리를 성능 향상으로 사용하는 대신 객체 계층 구조를 트리로 저장하고 싶습니다 ...

트리를 사용하려는 이유는 두 가지입니다.

트리와 같은 구조를 사용하여 문제를 반영하려고합니다.
이를 위해 부스트 그래프 라이브러리가 있습니다.

또는 접근 특성과 같은 트리를 가진 컨테이너를 원합니다.

• std::map(및 std::multimap)
• std::set(및 std::multiset)

기본적 으로이 두 컨테이너의 특성은 실제로 트리를 사용하여 구현해야한다는 것입니다 (실제로 요구 사항은 아닙니다).

이 질문도 참조하십시오 : C 트리 구현

아마도 부스트에 트리 컨테이너가없는 것과 같은 이유로. 이러한 컨테이너를 구현하는 방법에는 여러 가지가 있으며 컨테이너를 사용하는 모든 사람을 만족시키는 좋은 방법은 없습니다.

고려해야 할 몇 가지 문제 :

• 노드의 자식 수는 고정적이거나 가변적입니까?
• 노드 당 얼마나 많은 오버 헤드가 있습니까? -즉, 부모 포인터, 형제 포인터 등이 필요합니까?
• 어떤 알고리즘을 제공해야합니까? -다른 반복자, 검색 알고리즘 등

결국, 문제는 모든 사람에게 충분히 유용한 트리 컨테이너가 그것을 사용하는 대부분의 사람들을 만족 시키기에는 너무 무겁다는 것입니다. 강력한 무언가를 찾고 있다면 Boost Graph Library 는 기본적으로 트리 라이브러리가 사용할 수있는 것의 수퍼 세트입니다.

다른 일반적인 트리 구현은 다음과 같습니다.

• 카스퍼 피어스의 tree.hh
• 어도비의 숲
• 코어 :: 트리

STL의 철학은 컨테이너 구현 방식이 아니라 보증에 따라 컨테이너를 선택한다는 것입니다. 예를 들어, 컨테이너를 선택하면 빠른 조회가 필요합니다. 검색이 매우 빠르면 컨테이너는 단방향 목록으로 구현 될 수 있습니다. 어쨌든 내부를 건드리지 않고 액세스에 반복기 또는 멤버 함수를 사용하고 있기 때문입니다. 코드는 컨테이너가 구현되는 방식이 아니라 컨테이너의 속도, 고정 및 정의 된 순서가 있는지 또는 공간에서 효율적인지 등입니다.

"객체의 계층 구조를 트리로 저장하고 싶습니다"

C ++ 11은왔다 갔다 std::tree했지만 아이디어가 나왔지만 여전히을 제공 할 필요가 없었습니다 ( 여기 참조 ). 그들이 이것을 추가하지 않은 이유는 기존 컨테이너 위에 자신의 것을 쉽게 구축 할 수 있기 때문입니다. 예를 들어 ...

template< typename T >
struct tree_node
   {
   T t;
   std::vector<tree_node> children;
   };

간단한 순회는 재귀를 사용합니다 ...

template< typename T >
void tree_node<T>::walk_depth_first() const
   {
   cout<<t;
   for ( auto & n: children ) n.walk_depth_first();
   }

계층 구조를 유지하려는 경우 와 당신이 작업 할 STL 알고리즘 , 그러면 모든 일이 복잡 할 수 있습니다. 자체 반복자를 빌드하고 호환성을 얻을 수 있지만 많은 알고리즘은 단순히 계층 구조 (예 : 범위의 순서를 변경하는 것)에 대해서는 의미가 없습니다. 계층 구조 내에서 범위를 정의 하더라도 복잡한 비즈니스가 될 수 있습니다.

RB-tree 구현을 찾고 있다면 stl_tree.h 가 적합 할 수도 있습니다.

std :: map은 빨간색 검은 색 트리를 기반으로합니다 . 다른 컨테이너 를 사용 하여 고유 한 유형의 트리를 구현할 수도 있습니다 .

어떤 식 으로든 std :: map은 트리 (균형 이진 트리와 동일한 성능 특성을 가져야 함)이지만 다른 트리 기능을 노출하지는 않습니다. 실제 트리 데이터 구조를 포함하지 않는 이유는 아마도 stl에 모든 것을 포함하지 않는 것입니다. stl은 자체 알고리즘 및 데이터 구조를 구현하는 데 사용할 프레임 워크로 볼 수 있습니다.

일반적으로 원하는 기본 라이브러리 기능이 있지만 stl에는없는 경우 수정은 BOOST 를 보는 것입니다. 입니다.

그렇지 않으면, 거기 무리 의 라이브러리를 밖으로 거기 당신의 나무의 필요에 따라.

모든 STL 컨테이너는 외부 적으로 하나의 반복 메커니즘으로 "시퀀스"로 표시됩니다. 나무는이 관용구를 따르지 않습니다.

STL은 "모든 것"라이브러리가 아니기 때문입니다. 본질적으로 물건을 만드는 데 필요한 최소 구조가 포함되어 있습니다.

이것은 유망 해 보이고 찾고있는 것 같습니다 : http://tree.phi-sci.com/

IMO, 생략. 그러나 STL에 트리 구조를 포함시키지 않는 좋은 이유가 있다고 생각합니다. 트리를 유지 관리하는 데에는 많은 논리가 있으며 , 기본 TreeNode개체에 멤버 함수로 작성하는 것이 가장 좋습니다 . TreeNodeSTL 헤더에 싸여 있으면 더 지저분 해집니다.

예를 들면 다음과 같습니다.

template <typename T>
struct TreeNode
{
  T* DATA ; // data of type T to be stored at this TreeNode

  vector< TreeNode<T>* > children ;

  // insertion logic for if an insert is asked of me.
  // may append to children, or may pass off to one of the child nodes
  void insert( T* newData ) ;

} ;

template <typename T>
struct Tree
{
  TreeNode<T>* root;

  // TREE LEVEL functions
  void clear() { delete root ; root=0; }

  void insert( T* data ) { if(root)root->insert(data); } 
} ;

STL 트리가없는 데는 몇 가지 이유가 있다고 생각합니다. 기본적으로 트리는 컨테이너 (리스트, 벡터, 세트)와 같이 재귀 데이터 구조의 형태로, 정확한 선택을 어렵게하는 매우 다른 미세 구조를 갖습니다. 또한 STL을 사용하여 기본 형식으로 구성하기가 매우 쉽습니다.

유한 루트 트리는 값 또는 페이로드를 갖는 컨테이너, 클래스 A의 인스턴스, 그리고 아마도 비어있는 루트 (서브) 트리 컬렉션으로 생각할 수 있습니다. 하위 트리의 빈 컬렉션이있는 나무는 나뭇잎으로 간주됩니다.

template<class A>
struct unordered_tree : std::set<unordered_tree>, A
{};

template<class A>
struct b_tree : std::vector<b_tree>, A
{};

template<class A>
struct planar_tree : std::list<planar_tree>, A
{};

반복자 디자인 등에 대해 약간 생각하고 나무 사이에서 정의하고 효율적으로 사용할 수있는 제품 및 공동 제품 작업-원본 STL을 잘 작성해야하므로 빈 세트, 벡터 또는 목록 컨테이너가 기본 경우 페이로드가 실제로 비어 있습니다.

나무는 많은 수학적 구조에서 중요한 역할을합니다 (정육점, 그로스 만 (Grossman) 및 라슨 (Larsen)의 고전 논문, 또한 합류 할 수있는 사례에 대한 Connes와 Kriemer의 논문 및 열거에 사용되는 방법 참조). 그들의 역할이 단순히 다른 작업을 용이하게하는 것이라고 생각하는 것은 옳지 않습니다. 오히려 데이터 구조로서의 기본 역할로 인해 이러한 작업을 용이하게합니다.

그러나 나무 외에 "공동 나무"도 있습니다. 위의 모든 나무는 루트를 삭제하면 모든 것을 삭제하는 속성을 갖습니다.

트리의 반복자를 고려하십시오. 아마도 그들은 반복자, 노드 및 상위 노드까지 루트까지의 간단한 스택으로 실현 될 것입니다.

template<class TREE>
struct node_iterator : std::stack<TREE::iterator>{
operator*() {return *back();}
...};

그러나 원하는만큼 가질 수 있습니다. 집합 적으로 그들은 "트리"를 형성하지만 모든 화살표가 루트 방향으로 흐르면이 코트 리는 반복자를 통해 사소한 반복기와 루트로 반복 될 수 있습니다. 그러나 모든 인스턴스를 추적하지 않는 한 반복하거나 다른 탐색자를 알 수 없으며 반복자의 앙상블을 삭제할 수 없습니다.

나무는 엄청나게 유용하고 구조가 많기 때문에 결정적으로 올바른 접근 방법을 얻는 것이 심각한 도전입니다. 제 생각에는 이것이 STL에서 구현되지 않은 이유입니다. 또한 과거에는 사람들이 종교적으로 이해하고 자신의 유형의 인스턴스를 포함하는 컨테이너 유형에 대한 아이디어를 찾는 것을 보았습니다. 그러나 그들은 직면해야합니다. 아마도 (더 작은) 나무의 빈 컬렉션입니다. 현재 언어는 기본 생성자를 제공하는 데 어려움없이 언어를 허용합니다 container<B>.B 등

이것이 좋은 형태로 표준에 도달하면 기뻐할 것입니다.

여기에서 대답을 통해 일반적인 명명 된 이유는 트리를 반복 할 수 없거나 트리가 다른 STL 컨테이너와 유사한 인터페이스를 가정하지 않으며 그러한 트리 구조와 함께 STL 알고리즘을 사용할 수 없다는 것입니다.

이를 염두에두고 STL과 같은 인터페이스를 제공하고 가능한 한 기존 STL 알고리즘과 함께 사용할 수있는 자체 트리 데이터 구조를 설계하려고했습니다.

내 생각은 트리가 기존 STL 컨테이너를 기반으로해야하며 컨테이너를 숨겨서는 안되므로 STL 알고리즘과 함께 사용할 수 있도록하는 것입니다.

트리가 제공해야하는 다른 중요한 기능은 순회 반복기입니다.

다음은 내가 생각해 낸 것입니다. https://github.com/igagis/utki/blob/master/src/utki/tree.hpp

다음 테스트가 있습니다 : https://github.com/igagis/utki/blob/master/tests/tree/tests.cpp

모든 STL 컨테이너는 반복자와 함께 사용할 수 있습니다. 트리를 통과하는``올바른 ''방법이 없기 때문에 반복자를 트리로 가질 수 없습니다.