Tại sao C ++ STL không cung cấp bất kỳ container nào trên cây

Tại sao C ++ STL không cung cấp bất kỳ thùng chứa "cây" nào và thay vào đó, thứ tốt nhất để sử dụng là gì?

Tôi muốn lưu trữ một hệ thống phân cấp của các đối tượng dưới dạng cây, thay vì sử dụng cây làm tăng cường hiệu suất ...

Có hai lý do bạn có thể muốn sử dụng cây:

Bạn muốn phản ánh vấn đề bằng cách sử dụng cấu trúc giống như cây:
Đối với điều này, chúng tôi có thư viện biểu đồ tăng

Hoặc bạn muốn một thùng chứa có đặc điểm truy cập giống như cây

• std::map(và std::multimap)
• std::set(và std::multiset)

Về cơ bản, đặc điểm của hai container này là chúng thực tế phải được thực hiện bằng cách sử dụng cây (mặc dù đây không thực sự là một yêu cầu).

Xem thêm câu hỏi này: Thực hiện cây C

Có lẽ vì lý do tương tự mà không có thùng chứa cây trong boost. Có nhiều cách để thực hiện một container như vậy, và không có cách nào tốt để làm hài lòng tất cả những người sẽ sử dụng nó.

Một số vấn đề cần xem xét:

• Là số lượng con cho một nút cố định hoặc biến?
• Bao nhiêu chi phí cho mỗi nút? - tức là, bạn có cần con trỏ cha mẹ, con trỏ anh chị em, vv
• Những thuật toán để cung cấp? - các trình vòng lặp khác nhau, các thuật toán tìm kiếm, v.v.

Cuối cùng, vấn đề cuối cùng là một thùng chứa cây đủ hữu ích cho mọi người, sẽ quá nặng để làm hài lòng hầu hết những người sử dụng nó. Nếu bạn đang tìm kiếm thứ gì đó mạnh mẽ, Thư viện đồ thị Boost về cơ bản là siêu bộ của những gì mà thư viện cây có thể được sử dụng.

Dưới đây là một số triển khai cây chung khác:

• Cây Kasper Peeters.hh
• Rừng của Adobe
• lõi :: cây

Triết lý của STL là bạn chọn một container dựa trên các đảm bảo và không dựa trên cách thức triển khai container. Ví dụ, sự lựa chọn container của bạn có thể dựa trên nhu cầu tra cứu nhanh. Đối với tất cả những gì bạn quan tâm, container có thể được triển khai như một danh sách đơn hướng - miễn là tìm kiếm rất nhanh, bạn sẽ rất vui. Đó là bởi vì dù sao bạn cũng không chạm vào bên trong, bạn đang sử dụng các hàm lặp hoặc hàm thành viên để truy cập. Mã của bạn không bị ràng buộc với cách thức container được triển khai mà là tốc độ của nó, hoặc liệu nó có một thứ tự cố định và được xác định hay không, liệu nó có hiệu quả trên không gian hay không, v.v.

"Tôi muốn lưu trữ một hệ thống phân cấp của các đối tượng như một cái cây"

C ++ 11 đã đến và biến mất và họ vẫn không thấy cần phải cung cấp std::tree, mặc dù ý tưởng đã xuất hiện (xem tại đây ). Có lẽ lý do họ chưa thêm điều này là vì việc xây dựng của riêng bạn trên các container hiện có rất dễ dàng. Ví dụ...

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

Một giao dịch đơn giản sẽ sử dụng đệ quy ...

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

Nếu bạn muốn duy trì một hệ thống phân cấp và bạn muốn nó hoạt động với các thuật toán STL , thì mọi thứ có thể trở nên phức tạp. Bạn có thể xây dựng các trình vòng lặp của riêng mình và đạt được một số khả năng tương thích, tuy nhiên nhiều thuật toán chỉ đơn giản là không có ý nghĩa gì đối với hệ thống phân cấp (ví dụ, bất cứ điều gì thay đổi thứ tự của một phạm vi). Ngay cả việc xác định một phạm vi trong một hệ thống phân cấp có thể là một doanh nghiệp lộn xộn.

Nếu bạn đang tìm kiếm một triển khai cây RB, thì stl_tree.h cũng có thể phù hợp với bạn.

bản đồ std :: dựa trên cây đen đỏ . Bạn cũng có thể sử dụng các thùng chứa khác để giúp bạn thực hiện các loại cây của riêng mình.

Theo một cách nào đó, std :: map là một cây (bắt buộc phải có các đặc tính hiệu suất tương tự như cây nhị phân cân bằng) nhưng nó không làm lộ chức năng của cây khác. Lý do có khả năng đằng sau không bao gồm cấu trúc dữ liệu cây thật có lẽ chỉ là vấn đề không bao gồm mọi thứ trong stl. Stl có thể được xem như là một khung để sử dụng trong việc thực hiện các thuật toán và cấu trúc dữ liệu của riêng bạn.

Nói chung, nếu có một chức năng thư viện cơ bản mà bạn muốn, đó không phải là trong stl, cách khắc phục là xem BOOST .

Mặt khác, có rất nhiều thư viện ngoài kia , tùy thuộc vào nhu cầu của cây của bạn.

Tất cả các thùng chứa STL được thể hiện bên ngoài dưới dạng "chuỗi" với một cơ chế lặp. Cây không theo thành ngữ này.

Bởi vì STL không phải là thư viện "mọi thứ". Nó chứa, về cơ bản, các cấu trúc tối thiểu cần thiết để xây dựng mọi thứ.

Điều này có vẻ đầy hứa hẹn và dường như là những gì bạn đang tìm kiếm: http://tree.phi-sci.com/

IMO, một thiếu sót. Nhưng tôi nghĩ có lý do chính đáng để không đưa cấu trúc Cây vào STL. Có rất nhiều logic trong việc duy trì một cây, được viết tốt nhất là các hàm thành viên vào TreeNodeđối tượng cơ sở . Khi nàoTreeNode được gói trong một tiêu đề STL, nó sẽ trở nên rắc rối hơn.

Ví dụ:

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

Tôi nghĩ rằng có một số lý do tại sao không có cây STL. Cây chủ yếu là một dạng cấu trúc dữ liệu đệ quy, giống như một thùng chứa (danh sách, vectơ, tập hợp), có cấu trúc tốt rất khác nhau khiến cho các lựa chọn chính xác trở nên khó khăn. Chúng cũng rất dễ dàng để xây dựng ở dạng cơ bản bằng cách sử dụng STL.

Một cây gốc hữu hạn có thể được coi là một thùng chứa có giá trị hoặc tải trọng, giả sử là một thể hiện của lớp A và, một bộ sưu tập các cây gốc (phụ) có thể trống; cây với bộ sưu tập trống của cây con được coi là lá.

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

Người ta phải suy nghĩ một chút về thiết kế lặp, v.v. và hoạt động của sản phẩm và đồng sản phẩm nào cho phép xác định và hiệu quả giữa các cây - và STL ban đầu phải được viết tốt - sao cho bộ chứa, vectơ hoặc danh sách trống thực sự trống rỗng của bất kỳ tải trọng nào trong trường hợp mặc định.

Cây xanh đóng một vai trò thiết yếu trong nhiều cấu trúc toán học (xem các bài báo cổ điển của Butcher, Grossman và Larsen; cũng là các bài báo của Connes và Kriemer để biết ví dụ về chúng có thể được tham gia và cách chúng được sử dụng để liệt kê). Thật không đúng khi nghĩ rằng vai trò của họ chỉ đơn giản là tạo điều kiện cho một số hoạt động khác. Thay vào đó, họ tạo điều kiện cho các nhiệm vụ đó vì vai trò cơ bản của chúng là cấu trúc dữ liệu.

Tuy nhiên, ngoài cây còn có "đồng cây"; các cây ở trên đều có thuộc tính mà nếu bạn xóa gốc bạn sẽ xóa mọi thứ.

Hãy xem xét các trình vòng lặp trên cây, có lẽ chúng sẽ được nhận ra như một chồng các trình vòng lặp đơn giản, đến một nút và với cha mẹ của nó, ... cho đến tận gốc.

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

Tuy nhiên, bạn có thể có bao nhiêu tùy thích; gọi chung chúng tạo thành một "cây" nhưng trong đó tất cả các mũi tên chảy theo hướng về phía gốc, cây đồng này có thể được lặp qua các vòng lặp hướng tới trình lặp và gốc không quan trọng; tuy nhiên nó không thể được điều hướng qua hoặc xuống (các trình vòng lặp khác không được biết đến) cũng như không thể xóa toàn bộ các trình vòng lặp trừ khi theo dõi tất cả các trường hợp.

Cây rất hữu ích, chúng có rất nhiều cấu trúc, điều này làm cho nó trở thành một thách thức nghiêm trọng để có được cách tiếp cận chính xác. Theo quan điểm của tôi đây là lý do tại sao chúng không được thực hiện trong STL. Hơn nữa, trong quá khứ, tôi đã thấy mọi người tôn giáo và tìm thấy ý tưởng về một loại container chứa các trường hợp thuộc loại riêng của nó đầy thách thức - nhưng họ phải đối mặt với nó - đó là những gì một loại cây đại diện - đó là một nút chứa một có thể bộ sưu tập trống của cây (nhỏ hơn). Ngôn ngữ hiện tại cho phép nó mà không có thách thức khi cung cấp hàm tạo mặc định cho việc container<B>không phân bổ không gian trên heap (hoặc bất kỳ nơi nào khác) cho một B, v.v.

Tôi cho một người sẽ hài lòng nếu điều này đã làm, trong một hình thức tốt, tìm đường đến tiêu chuẩn.

Đọc qua các câu trả lời ở đây, lý do được đặt tên phổ biến là người ta không thể lặp qua cây hoặc cây không có giao diện tương tự với các thùng chứa STL khác và người ta không thể sử dụng thuật toán STL với cấu trúc cây như vậy.

Trong tâm trí đó, tôi đã cố gắng thiết kế cấu trúc dữ liệu cây của riêng mình, nó sẽ cung cấp giao diện giống STL và sẽ có thể sử dụng được với các đại số STL hiện có càng nhiều càng tốt.

Ý tưởng của tôi là cây phải dựa trên các container STL hiện có và nó không được ẩn container, để nó có thể truy cập được để sử dụng với các thuật toán STL.

Tính năng quan trọng khác mà cây phải cung cấp là các trình vòng lặp đi qua.

Đây là những gì tôi đã có thể đến với: https://github.com/igagis/utki/blob/master/src/utki/tree.hpp

Và đây là các bài kiểm tra: https://github.com/igagis/utki/blob/master/tests/tree/tests.cpp

Tất cả các container STL có thể được sử dụng với các trình vòng lặp. Bạn không thể có một trình vòng lặp một cây, bởi vì bạn không có cách '' một quyền '' để đi qua cây.