Re: Performance implications of GRegex structure

[Owen Taylor <otaylor redhat com>]

On Sat, 2007-03-17 at 16:14 +0100, Marco Barisione wrote:
> I opened bug #419368[1] to track this issue, the API used by Owen in the
> examples could be inefficient in some cases, so in the next days I'm
> going to think to a usable and efficient API.
> How can I call the match object? GRegexMatcher? GMatcher? GMatch?
> GRegexMatch?

The choice of whether it's "Matcher" or "Match" depends on whether
it is a Java-style "Matcher" object or a Python-style "Match" object - 
that is, whether it is created before matching, or returned in the
case of a successful match.

(http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Matcher.html,
http://docs.python.org/lib/mamtch-objects.html)

My feeling was that the Java style object was a better fit, because
it allows for iteration through matches, as you currently
have with g_regex_match_next().

I don't think there is a strong argument either way for GRegexMatcher
vs. GMatcher. GMatcher produces shorter function names and less
typing...

> Owen: what should do exactly G_STATIC_REGEX_INIT?

I was imagining:

struct _GStaticRegex {
    GOnce once;
    GStaticRegex *regex;
    const gchar *pattern;
    GRegexCompileFlags flags;
}

#define G_STATIC_REGEX_INIT(pattern, flags) { \
    G_ONCE_INIT,                              \
    NULL,                                     \
    pattern,                                  \
    flags                                     \
}

						- Owen