Re: Wrapping GHashTable, which approach?

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

Den 2016-11-29 kl. 04:04, skrev Robin Lee:
> Hi,
>
> 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?
>
> -robin
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.

Kjell