Por que o C ++ STL não fornece nenhum contêiner "em árvore"?

Por que o C ++ STL não fornece nenhum contêiner de "árvore" e qual é a melhor coisa a ser usada?

Quero armazenar uma hierarquia de objetos como uma árvore, em vez de usá-la como um aprimoramento de desempenho ...

Há duas razões pelas quais você pode querer usar uma árvore:

Você deseja espelhar o problema usando uma estrutura semelhante a uma árvore:
Para isso, temos a biblioteca de gráficos boost

Ou você quer um contêiner que tenha características de acesso semelhantes a árvores. Para isso, temos

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

Basicamente, as características desses dois contêineres são tais que praticamente precisam ser implementadas usando árvores (embora isso não seja realmente um requisito).

Veja também esta pergunta: Implementação da árvore C

Provavelmente pela mesma razão que não há um contêiner de árvore no impulso. Existem várias maneiras de implementar esse contêiner e não há uma boa maneira de satisfazer todos que o usariam.

Algumas questões a serem consideradas:

• O número de filhos de um nó é fixo ou variável?
• Quanta sobrecarga por nó? - ou seja, você precisa de ponteiros pai, ponteiros irmãos, etc.
• Quais algoritmos fornecer? - diferentes iteradores, algoritmos de pesquisa, etc.

No final, o problema acaba sendo que um contêiner de árvore que seria útil o suficiente para todos seria muito pesado para satisfazer a maioria das pessoas que o usavam. Se você está procurando algo poderoso, a Boost Graph Library é essencialmente um superconjunto do que uma biblioteca em árvore pode ser usada.

Aqui estão algumas outras implementações genéricas de árvores:

• Tree.hh de Kasper Peeters
• Floresta da Adobe
• core :: tree

A filosofia da STL é que você escolha um contêiner com base em garantias e não em como o contêiner é implementado. Por exemplo, sua escolha de contêiner pode se basear na necessidade de pesquisas rápidas. Para todos os cuidados, o contêiner pode ser implementado como uma lista unidirecional - desde que a pesquisa seja muito rápida, você ficará feliz. Isso porque você não está tocando os internos de qualquer maneira, está usando iteradores ou funções de membro para o acesso. Seu código não está vinculado à maneira como o contêiner é implementado, mas à rapidez com que ele é, ou se possui uma ordem fixa e definida, ou se é eficiente no espaço e assim por diante.

"Eu quero armazenar uma hierarquia de objetos como uma árvore"

O C ++ 11 veio e se foi e eles ainda não viram a necessidade de fornecer um std::tree, embora a idéia tenha surgido (veja aqui ). Talvez a razão pela qual eles não tenham adicionado isso seja o fato de ser trivialmente fácil criar o seu próprio sobre os contêineres existentes. Por exemplo...

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

Uma travessia simples usaria recursão ...

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

Se você deseja manter uma hierarquia e trabalhar com algoritmos STL , as coisas podem ficar complicadas. Você pode criar seus próprios iteradores e obter alguma compatibilidade, no entanto, muitos dos algoritmos simplesmente não fazem sentido para uma hierarquia (qualquer coisa que mude a ordem de um intervalo, por exemplo). Mesmo definir um intervalo dentro de uma hierarquia pode ser um negócio confuso.

Se você está procurando uma implementação de árvore RB, stl_tree.h também pode ser apropriado para você.

o std :: map é baseado em uma árvore vermelha e preta . Você também pode usar outros contêineres para ajudá-lo a implementar seus próprios tipos de árvores.

De certa forma, std :: map é uma árvore (é necessário ter as mesmas características de desempenho que uma árvore binária balanceada), mas não expõe outras funcionalidades da árvore. O provável raciocínio por trás da não inclusão de uma estrutura de dados em árvore real provavelmente foi apenas uma questão de não incluir tudo no stl. O stl pode ser visto como uma estrutura a ser usada na implementação de seus próprios algoritmos e estruturas de dados.

Em geral, se você deseja uma funcionalidade básica da biblioteca, que não esteja no stl, a correção é procurar o BOOST .

Caso contrário, há um monte de bibliotecas para fora lá , dependendo das necessidades de sua árvore.

Todos os contêineres STL são representados externamente como "sequências" com um mecanismo de iteração. As árvores não seguem esse idioma.

Porque o STL não é uma biblioteca "tudo". Ele contém, essencialmente, as estruturas mínimas necessárias para construir coisas.

Este parece promissor e parece ser o que você está procurando: http://tree.phi-sci.com/

OMI, uma omissão. Mas acho que há boas razões para não incluir uma estrutura em árvore no STL. Há muita lógica na manutenção de uma árvore, que é melhor gravada como funções de membro no TreeNodeobjeto base . Quando TreeNodeé embrulhado em um cabeçalho STL, fica mais confuso.

Por exemplo:

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); } 
} ;

Eu acho que existem várias razões pelas quais não existem árvores STL. Principalmente Árvores são uma forma de estrutura de dados recursiva que, como um contêiner (lista, vetor, conjunto), possui uma estrutura fina muito diferente, o que torna as escolhas corretas complicadas. Eles também são muito fáceis de construir de forma básica usando o STL.

Uma árvore enraizada finita pode ser vista como um contêiner que possui um valor ou carga útil, por exemplo, uma instância de uma classe A e uma coleção possivelmente vazia de (sub) árvores enraizadas; as árvores com uma coleção vazia de subárvores são consideradas folhas.

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
{};

É preciso pensar um pouco sobre o design do iterador etc. e quais operações de produto e coproduto se permite definir e ser eficiente entre árvores - e o STL original deve ser bem escrito - para que o conjunto vazio, o vetor ou o contêiner de lista seja realmente vazio de qualquer carga útil no caso padrão.

As árvores desempenham um papel essencial em muitas estruturas matemáticas (veja os artigos clássicos de Butcher, Grossman e Larsen; também os artigos de Connes e Kriemer, para exemplos de como podem ser unidos e como são usados ​​para enumerar). Não é correto pensar que o papel deles é simplesmente facilitar outras operações. Em vez disso, eles facilitam essas tarefas devido ao seu papel fundamental como estrutura de dados.

No entanto, além das árvores, também existem "co-árvores"; acima de tudo, as árvores têm a propriedade de que, se você excluir a raiz, excluirá tudo.

Considere os iteradores na árvore, provavelmente eles seriam realizados como uma simples pilha de iteradores, para um nó e seu pai, ... até a raiz.

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

No entanto, você pode ter quantos quiser; coletivamente, formam uma "árvore", mas onde todas as setas fluem na direção da raiz, essa co-árvore pode ser iterada através de iteradores em direção ao iterador e raiz triviais; no entanto, ele não pode ser navegado entre ou para baixo (os outros iteradores não são conhecidos por ele) nem o conjunto de iteradores pode ser excluído, exceto acompanhando todas as instâncias.

As árvores são incrivelmente úteis, possuem muita estrutura, o que torna um sério desafio obter a abordagem definitivamente correta. Na minha opinião, é por isso que eles não são implementados no STL. Além disso, no passado, eu vi pessoas se tornarem religiosas e encontrar a idéia de um tipo de contêiner contendo instâncias de seu próprio tipo desafiador - mas elas precisam encarar - é isso que um tipo de árvore representa - é um nó que contém um coleção possivelmente vazia de árvores (menores). O idioma atual permite isso sem desafio, desde que o construtor padrão container<B>não aloque espaço no heap (ou em qualquer outro lugar) para um B, etc.

Eu ficaria satisfeito se isso, em boa forma, encontrasse seu caminho no padrão.

Lendo as respostas aqui, os motivos comuns mencionados são que não se pode iterar pela árvore ou que a árvore não assume a interface semelhante a outros contêineres STL e não se pode usar algoritmos STL com essa estrutura em árvore.

Tendo isso em mente, tentei projetar minha própria estrutura de dados em árvore, que fornecerá uma interface semelhante a STL e será utilizável com os valores de STL existentes o máximo possível.

Minha idéia foi que a árvore deve ser baseada nos contêineres STL existentes e que não oculte o contêiner, para que seja acessível para uso com os algoritmos STL.

O outro recurso importante que a árvore deve fornecer são os iteradores que atravessam.

Aqui está o que eu consegui: https://github.com/igagis/utki/blob/master/src/utki/tree.hpp

E aqui estão os testes: https://github.com/igagis/utki/blob/master/tests/tree/tests.cpp

Todos os contêineres STL podem ser usados ​​com iteradores. Você não pode ter um iterador e uma árvore, porque você não tem um caminho 'certo' para atravessar a árvore.