On Sat, 2007-03-17 at 16:19 +0100, Marco Barisione wrote: > Il giorno sab, 17/03/2007 alle 10.07 -0400, Matthias Clasen ha scritto: > > Btw, one thing we might want to consider doing (regardless if we go > > with separate pattern and matcher objects) is to make the pattern > > optimization an optional part of the constructor rather than a > > separate > > function. That will ensure that the pattern is truly immutable after > > construction. > > I prefer to keep it a separate function, what are the advantages of > having a truly immutable GRegex? Note that the _optimize function is > already thread-safe.
As long as it is thread safe (and it looks like it is) I don't think there is a big advantage. Still, I would wonder why you don't have "optimize" just as another compile flag. PCRE can't do that because of the allocation of an extra block of memory, but that doesn't affect GRegex. - Owen P.S. - The docs could really use more specific guidance on optimize; I'd say something like "call optimize() (use the OPTIMIZE flag) if you are going to match the regular expression against large amounts of text. Optimization provides faster operation in that case, at the expense of using more memory and slightly greater compilation time." The current docs will make it very hard for people to know whether they should optimize or not. P.P.S - Though unless it actually provides a 50% or more speedup in matching and a 50% slowdown in compilation, I'm not sure it's worth making people decide whether optimize or not. P.P.P.S. - I'm very glad you didn't call it _study(), since it is something entirely different than Perl's study() function. What was the PCRE author thinking with pcre_study? _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list