GNOME Bugzilla – Bug 636911
There is no Glib::MatchInfo in glibmm, making its regex API very limited
Last modified: 2010-12-13 04:07:20 UTC
There isn't any Glib::MatchInfo class in glibmm (corresponding to GMatchInfo in glib). This makes Glib::Regex almost useless, because the user cannot retrieve the actual matches (he/she can only test for matched / not matched). Using C API is an option, but it's a pain (especially with all the string handling needed for regular expressions). Thanks
Created attachment 176164 [details] [review] Patch to add a Glib::MatchInfo class. I believe the attached patch adds the new class. Keep in mind that the C functions in the new class are merely wrapped. There is no C++ like iterator provided because I thought that just wrapping things first would be best. The methods in Regex accepting a Glib::MatchInfo have also been wrapped. I should say that testing could be useful since I did not do that.
Thanks! A C++ iterator interface would be nice, but it's certainly not required. If I'm not mistaken, it could be added later without breaking ABI. A fetch_all() method seems to be still absent though (it should probably return some kind of array of ustrings). Thanks again.
(In reply to comment #2) > Thanks! > > A C++ iterator interface would be nice, but it's certainly not required. If I'm > not mistaken, it could be added later without breaking ABI. That's right. I was also sort of thinking a little and thought that an auto-increment operator, a boolean operator and a dereferencing operator could be added to the class so that it can have some of "iterating" capability that way. I suppose there might be better ideas so I'll leave that as a TODO. > > A fetch_all() method seems to be still absent though (it should probably return > some kind of array of ustrings). The following updated patch adds that method, using Glib::StringArrayHandle to wrap that method. As I understand it, temporary types (such as Glib::StringArrayHandle) are planned to be removed to avoid the confusion of new developers but since it is being used in Regex already, I wrapped it that way also. > > Thanks again.
Created attachment 176201 [details] [review] Updated patch adding a fetch_all() method.
Created attachment 176202 [details] [review] Correct updated patch adding a fetch_all() method. Sorry about that. The previous patch was not the right one.
I "tested" the latest patch (applied against glibmm-2.25.5 since I have glib-2.26.0). Well, basically it works correctly for the following code: Glib::RefPtr<Glib::Regex> regex = Glib::Regex::create("cd(.*)4(e).*"); Glib::ustring s("abcd1234efgh"); Glib::MatchInfo match_info; std::cout << "Pattern=" << regex->get_pattern() << ", with string=" << s << ", result=" << std::boolalpha << regex->match(s, match_info) << std::endl; std::cout << "Number of matches: " << match_info.get_match_count() << "\n"; for (int i = 0; i < match_info.get_match_count(); ++i) { std::cout << "Match " << i << ": " << match_info.fetch(i) << "\n"; } std::vector<Glib::ustring> all = match_info.fetch_all(); for (std::size_t i = 0; i < all.size(); ++i) { std::cout << "Match " << i << ": " << all.at(i) << "\n"; } This is not a comprehensive test of course, but the patch is trivial enough that I think it's safe to merge. Thanks!
Well then, pushed to git master so that the Regex API is more useful to those needing and/or using it.