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
