C ++ STL neden hiçbir "ağaç" kap sağlamaz?

Neden C ++ STL "ağaç" kapları sağlamaz ve bunun yerine kullanılacak en iyi şey nedir?

Performans yükseltmesi olarak bir ağacı kullanmak yerine bir nesne hiyerarşisini ağaç olarak saklamak istiyorum ...

Bir ağacı kullanmak istemenizin iki nedeni vardır:

Sorunu ağaç benzeri bir yapı kullanarak yansıtmak istiyorsunuz: Bunun
için grafik grafik kütüphanemiz var

Veya ağaç gibi erişim özelliklerine sahip bir kap istersiniz

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

Temel olarak bu iki konteynerin özellikleri, pratik olarak ağaçlar kullanılarak uygulanması gerektiği şekildedir (bu aslında bir gereklilik değildir).

Ayrıca bu soruya bakın: C ağacı Uygulaması

Muhtemelen aynı nedenden ötürü, güçlendirilmiş bir ağaç kabı yoktur. Böyle bir kabı uygulamanın birçok yolu vardır ve onu kullanacak herkesi tatmin etmenin iyi bir yolu yoktur.

Dikkate alınması gereken bazı konular:

• Bir düğümün çocuk sayısı sabit mi yoksa değişken mi?
• Düğüm başına ne kadar ek yük? - yani, ana işaretçiler, kardeş işaretçiler vb.
• Hangi algoritmalar sağlanmalı? - farklı yineleyiciler, arama algoritmaları vb.

Sonunda sorun, herkes için yeterince yararlı olacak bir ağaç kabının, onu kullanan insanların çoğunu tatmin etmek için çok ağır olacağıdır. Güçlü bir şey arıyorsanız, Grafik Kitaplığını Artırın aslında bir ağaç kütüphanesinin ne için kullanılabileceğinin bir üst kümesidir.

İşte diğer genel ağaç uygulamaları:

• Kasper Peeters 'in Instagram tree.hh Hesabındaki Resimleri tree.hh
• Adobe'nin ormanı
• Çekirdek :: ağacı

STL'nin felsefesi, konteynerin nasıl uygulandığına göre değil, garantilere dayalı bir kap seçmenizdir. Örneğin, kapsayıcı seçiminiz hızlı arama ihtiyacına dayalı olabilir. İlgilendiğiniz her şey için, konteyner tek yönlü bir liste olarak uygulanabilir - arama çok hızlı olduğu sürece mutlu olursunuz. Çünkü iç kısma dokunmuyorsunuz, erişim için yineleyicileri veya üye işlevlerini kullanıyorsunuz. Kodunuz, kabın nasıl uygulandığına değil, ne kadar hızlı olduğuna veya sabit ve tanımlanmış bir sıralamaya sahip olup olmadığına veya alan üzerinde etkili olup olmadığına ve benzerlerine bağlıdır.

"Nesneler hiyerarşisini ağaç olarak saklamak istiyorum"

C ++ 11 geldi ve gitti ve hala bir std::treefikir verme ihtiyacı görmediler, ancak fikir ortaya çıktı ( buraya bakın ). Belki de bunu eklememelerinin nedeni, mevcut kapların üzerine kendi yapınızı oluşturmanın çok kolay olmasıdır. Örneğin...

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

Basit bir geçiş özyineleme kullanır ...

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

Bir hiyerarşiyi korumak istiyorsanız ve bunun STL algoritmalarıyla çalışmasını istiyorsanız , işler karmaşıklaşabilir. Kendi yineleyicilerinizi oluşturabilir ve bazı uyumluluk elde edebilirsiniz, ancak algoritmaların çoğu hiyerarşi için bir anlam ifade etmez (örneğin, bir aralığın sırasını değiştiren herhangi bir şey). Bir hiyerarşi içinde bir aralığı tanımlamak bile dağınık bir iş olabilir.

Bir RB ağacı uygulaması arıyorsanız, stl_tree.h sizin için de uygun olabilir.

std :: map kırmızı siyah bir ağacı temel alır . Kendi ağaç türlerinizi uygulamanıza yardımcı olması için başka kaplar da kullanabilirsiniz .

Bir bakıma, std :: map bir ağaçtır (dengeli bir ikili ağaçla aynı performans özelliklerine sahip olmak gerekir), ancak diğer ağaç işlevlerini göstermez. Gerçek bir ağaç veri yapısı içermemesinin arkasındaki akıl yürütme, muhtemelen sadece stl'deki her şeyi dahil etmeme meselesiydi. Stl, kendi algoritmalarınızı ve veri yapılarınızı uygularken kullanabileceğiniz bir çerçeve olarak görülebilir.

Stl değil İstediğiniz temel kütüphane işlevi, varsa Genelde, düzeltme bakmak için BOOST .

Aksi takdirde, bir var demet ait kütüphaneler dışarı orada senin ağacının ihtiyaçlarına bağlı olarak,.

Tüm STL konteyneri harici olarak bir iterasyon mekanizması ile "sekanslar" olarak temsil edilir. Ağaçlar bu deyimi takip etmez.

Çünkü STL bir "her şey" kütüphanesi değildir. Esasen, bir şeyler inşa etmek için gereken minimum yapıları içerir.

Bu umut verici görünüyor ve aradığınız şey gibi görünüyor: http://tree.phi-sci.com/

IMO, bir ihmal. Ama bence STL'ye bir ağaç yapısı dahil etmemek için iyi bir neden var. En iyi temel TreeNodenesneye üye işlevleri olarak yazılan bir ağacın korunmasında çok fazla mantık vardır . Bir TreeNodeSTL başlığına sarıldığında, daha da karmaşıklaşır.

Örneğin:

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

Bence STL ağacı olmamasının birkaç nedeni var. Öncelikle Ağaçlar, bir kap (liste, vektör, set) gibi, doğru seçimleri zorlaştıran çok farklı ince yapıya sahip bir özyinelemeli veri yapısı biçimidir. Ayrıca STL kullanarak temel formda inşa etmek çok kolaydır.

Sonlu bir köklü ağaç, değeri veya yükü olan bir kap, örneğin bir A sınıfı örneği ve muhtemelen boş köklü (alt) ağaçlardan oluşan bir koleksiyon olarak düşünülebilir; ağaçların boş koleksiyonuna sahip ağaçlar yaprak olarak düşünülür.

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

Yineleyici tasarım vb. Hakkında biraz düşünmek gerekir ve ağaçlar arasında hangi ürün ve yardımcı ürün işlemlerini tanımlamaya ve verimli olmaya izin verir - ve orijinal STL iyi yazılmalıdır - böylece boş set, vektör veya liste kabı varsayılan durumda herhangi bir yükü gerçekten boş.

Ağaçlar pek çok matematiksel yapıda önemli bir rol oynar (Kasap, Grossman ve Larsen'in klasik belgelerine bakın; ayrıca birleştirilebilecekleri örnekleri ve nasıl numaralandırıldıklarına dair Connes ve Kriemer makaleleri). Rollerinin sadece diğer bazı operasyonları kolaylaştırmak olduğunu düşünmek doğru değildir. Aksine, veri yapısı olarak temel rolleri nedeniyle bu görevleri kolaylaştırırlar.

Ancak, ağaçlara ek olarak "ortak ağaçlar" da vardır; her şeyden önce ağaçların kökleri silerseniz her şeyi sildiğiniz özelliği vardır.

Ağaçtaki yineleyicileri düşünün, muhtemelen basit bir yineleyici yığını, bir düğüme ve ebeveynine, köküne kadar gerçekleştirileceklerdi.

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

Ancak, istediğiniz kadarına sahip olabilirsiniz; topluca bir "ağaç" oluştururlar, ancak tüm okların köke doğru aktığı yerde, bu ortak ağaç yineleyiciler aracılığıyla önemsiz yineleyici ve köke doğru tekrarlanabilir; ancak, diğer tüm yineleyiciler tarafından bilinemez) ve tüm örneklerin izlenmesi dışında yineleyiciler topluluğu silinemez.

Ağaçlar inanılmaz derecede faydalı, çok fazla yapıya sahipler, bu kesinlikle doğru yaklaşımı elde etmek için ciddi bir zorluk haline getiriyor. Bence bu yüzden STL'de uygulanmadılar. Dahası, geçmişte, insanların dindar olduklarını gördüm ve kendi türünün zorlayıcı örneklerini içeren bir tür kap fikrini buldum - ama yüzleşmek zorundalar - bu bir ağaç türünün temsil ettiği şeydir - bir muhtemelen (küçük) ağaçların boş koleksiyonu. Geçerli dil, varsayılan container<B>kurucunun öbek (veya başka bir yerde) için bir alan Bvb.

Bu, iyi bir biçimde, standarda doğru yolunu bulsaydı, memnun olurum.

Buradaki cevapları okuyarak, ortak adlandırılmış nedenler, bir kişinin ağaç üzerinde yinelenememesi veya ağacın diğer STL kaplarıyla benzer arayüzü almaması ve bu ağaç yapısına sahip STL algoritmalarını kullanamamasıdır.

Bunu göz önünde bulundurarak, STL benzeri bir arayüz sağlayacak ve mevcut STL algorthims ile mümkün olduğunca kullanılabilecek kendi ağaç veri yapımı tasarlamaya çalıştım.

Benim fikrim, ağacın mevcut STL kaplarına dayanması ve kapın gizlenmemesi gerektiğiydi, böylece STL algoritmalarıyla kullanılabilecekti.

Ağacın sağlaması gereken diğer önemli özellik, çapraz yineleyicilerdir.

İşte ben geldim ne: https://github.com/igagis/utki/blob/master/src/utki/tree.hpp

İşte testler: https://github.com/igagis/utki/blob/master/tests/tree/tests.cpp

Tüm STL kapları yineleyicilerle kullanılabilir. Bir yineleyiciye ve bir ağaca sahip olamazsınız, çünkü `` doğru '' bir yolunuz yoktur.