Yevgen Muntyan wrote: > [snip] > To me here the only good argument in favor of separate Match objects is > multi-thread uses. > Simply because we already have Match object, just hidden. If the best > way to fix GRegex > for multi-threading is a separate match object, then it should be a > separate match object. > In fact it's not a solution, right? Since if it's separate Match structure, then Regex still needs to keep state. So, the solution is to rename some stuff to make GRegex be a GRegexExp or something, and move the actual functionality to some new GMatcher, i.e. not change anything conceptually but explicitly separate Pattern and Matcher. Did I get it right?
Then usage would be something like /* Compile regex for future uses */ GRegexExp *re = g_compile_pattern("foo"); GMatcher *m = g_matcher_new (re); g_regex_exp_free(re); ... g_matcher_find_something(m, "blah"); ... /* Finally free it when program exits */ g_matcher_free(m); instead of current /* Compile regex for future uses */ GRegex *re = g_regex_new("foo"); ... g_regex_match(re, "blah"); ... /* Finally free it when program exits */ g_regex_free(re); And in multithreaded case threads would do g_matcher_new() instead of g_regex_copy(). g_regex_copy() is weird, that's clear. API is weird, true. But functionality right now is no different from what would be in case of some GMatcher objects, correct? Best regards, Yevgen _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list