Mô hình cây Qt so với bản đồ lồng nhau để lưu trữ từ điển cho bản dịch

Question

Tôi đang viết một lớp bằng cách sử dụng Qt cần nhập từ điển sẽ được sử dụng để tra cứu lệnh và tạo câu lệnh. Các lệnh được sắp xếp theo cách phân cấp và có một khóa hex và định nghĩa giá trị tương ứng. Đối với mục đích minh họa, nó có thể trông như thế này:

 
01 : Volume 
     | - 01 : Step : 00=Down, 01=Up 
     | - 02 : Set : ceil(255/100 * x) 
02 : Power 
     | - 01 : Power : 00=Off, 01=On 
     | - 02 : Sleep : ...etc 

Tôi muốn tải từ điển này và sau đó có thể tìm kiếm nó cho "Volume/Set/50" và gửi lại câu lệnh "01 02 80" hoặc tìm lên "01 02 80" và trả về "Volume/Set/50". Việc thực hiện thực tế phức tạp hơn một chút và có các lệnh ở các mức khác nhau trong cấu trúc cây và có thể bao gồm bất kỳ số nào và kết hợp các lệnh từ các cấp khác nhau trong một câu duy nhất.

Edit:

Các bình luận được cung cấp bởi Volodymyr dưới đây giới thiệu một khái niệm (Trie) rằng tôi đã không quen thuộc với. Đây có thể là cách triển khai tốt nhất cho kịch bản cụ thể này, nhưng tôi phải nghiên cứu thêm một số điều nữa. Tôi vẫn quan tâm đến câu trả lời cho câu hỏi ban đầu của tôi (với việc bổ sung Trie):

Ưu điểm và nhược điểm của việc sử dụng từng phương pháp này để thực hiện điều này là gì?

• Qt Tree Mẫu
• Nested Maps
• Trie

câu hỏi ban đầu: (đối với bối cảnh)

Sẽ là một cây mẫu Qt, bản đồ lồng nhau hoặc một số khác có nghĩa là phù hợp hơn để lưu trữ từ điển? Tôi nhận ra rằng "tốt hơn" có thể là chủ quan, nhưng tôi muốn biết các lệnh giao dịch.

Tôi đã xây dựng Mô hình cây Qt để hiển thị một số dữ liệu khác trong QTreeView, vì vậy mã đó đã tồn tại và có thể dễ dàng được sử dụng. Mô hình cây có cho phép linh hoạt hơn trong việc tải từ điển với các cấu trúc khác nhau không? Có cách nào tốt hơn để làm điều này? hoặc có thể là một mẫu thiết kế tiêu chuẩn?

Answer 1

Theo ý kiến ​​của tôi, số lượng mục ở mỗi cấp trong cây lệnh quá nhỏ để biện minh bằng cách sử dụng một trie. Một trie (xem http://en.wikipedia.org/wiki/Trie), do yếu tố phân nhánh lớn của nó, là tốt nhất cho một số lượng lớn các mặt hàng - ví dụ như một từ điển ngôn ngữ tự nhiên, như volodymyr đã chỉ ra.

Thực tế, con số có thể quá nhỏ để biện minh cho cả std :: map. Nếu không có nhiều hơn một vài chục lệnh hoặc mã tại một điểm nhất định trong cây, tìm kiếm tuyến tính có thể nhanh như tìm kiếm trên bản đồ hoặc nhanh hơn. Biểu diễn bộ nhớ dưới dạng vectơ hoặc danh sách cũng sẽ nhỏ gọn hơn. Điều đó nói rằng, std :: giao diện của bản đồ có vẻ rất phù hợp với những gì bạn đang cố gắng làm, vì vậy, trong thực tế, nó có lẽ vẫn là sự lựa chọn tốt nhất tổng thể.

Tôi không thể thấy QTreeModel có thể tốt hơn std :: bản đồ từ bất kỳ quan điểm nào (tốc độ, bộ nhớ, dễ sử dụng), ngoại trừ việc nó có thể tốt hơn với phần còn lại của mã của bạn. -dựa trên. Tuy nhiên, nếu bạn thậm chí mơ hồ nghi ngờ rằng phần này có thể có một sử dụng mà không có Qt, tôi sẽ không ngần ngại chọn những thứ thư viện chuẩn (std :: map).Lý do thực sự thuyết phục để chọn QTreeModel trên std :: map sẽ là nếu bạn thực sự sử dụng nó trong một QTreeView.

Answer 2

Qt TreeModels được tối ưu hóa để làm việc với TreeViews và tốt cho việc sắp xếp vv Chúng không thực sự có nghĩa là không cho ánh xạ hai chiều ngẫu nhiên truy cập.

Bản đồ lồng nhau sẽ được tối ưu hóa để dịch theo một hướng. Để quay trở lại và chuyển tiếp hiệu quả, bạn thực sự cần phải phản ánh các bản đồ riêng biệt để chuyển tiếp và dịch ngược.

Xây dựng nó với tiêu chuẩn :: bản đồ. hồ sơ nó và tối ưu hóa nó nếu bạn cần.