Re: Wrapping GHashTable, which approach?

Den 2016-11-29 kl. 04:04, skrev Robin Lee:


I am learning to wrap a GObject-based library with gmmproc and encounter a
signal callback that comes with an argument of type GHashTable. But there is
no wrapper for this type, so I am figuring out what to do next.

One straight approach is wrapping GHashTable like Glib::BalancedTree for GTree.

But I also found that glibmm is following a trend that use std::vector in API instead of exposing wrappers of Glib data structures. So for GHashTable, we
may replace the argument with type std::unordered_map, and make a
HashTableHandler for the conversion.

Any ideas?


Yes, the trend is to not wrap glib classes with the same functionality as standard C++ classes. As an example, the Glib::Thread and Glib::Threads::Thread classes have been deprecated, and will be removed from the coming ABI-breaking glibmm-2.52 release, because there is the std::thread class in C++11. I don't know why GTree was ever wrapped in glibmm. The commit message of the commit that added it does not explain why it was added, nor does it refer to a bug report.

The best approach is to use std::unordered_map in your library's API. If you make a HashTableHandler, use it only internally in your library's own code, like e.g. ArrayHandler is used in gtkmm-3.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]