Re: [Sc-devel] regexp support revisited :)

[Florian Schmidt <mista.tapas@xxxxxxx>]

On Monday 26 November 2007, Florian Schmidt wrote:
> On Monday 26 November 2007, Florian Schmidt wrote:
> > On Monday 26 November 2007, Jan Trutzschler wrote:
> > > ok, i checked it in ...
> > > could someone please try to update recompile and see if this works:
> > >
> > > "foobar".findRegexp("o*bar");
> > >
> > > "32424 334 /**aaaaaa*/".findRegexp("/\\*\\*a*\\*/");
> > >
> > > "foobar".findRegexp("(o*)(bar)");
> > >
> > > "aaaabaaa".findAllRegexp("a+");
> >
> > I don't see the change here yet.. Is anonymous svn lagging on SF?
>
> Oh i do see it. As you said you moved it to another file..

Funny btw: This mailinglist seems to remove the CC addresses. Or did i do it 
by myself? I don't think so. I have a habit of hitting "reply all" on ML 
posts...

Anyways, looking at your code i have a few comments/questions:

[1] I don't yet quite understand the linking issues that forced you to move 
the code to a seperate file. Mind to explain? Maybe we can work it out..

[2] Since the presence of libicu is not a question of "Mac OS X or no Mac OS 
X" but rather simply whether libicu is installed we should probably simply 
add a test for libicu in the SConstruct. If this test fails we could fallback 
to the libc version (this means we have to define an preprocessor macro e.g. 
HAVE_ICU which can then be used in the code to conditionally include the one 
or the other version). I'm not too familiar with scons, so i wouldn't know 
where to test for the lib and how to define the preprocessor macro. Any hints 
anyone?

[3] It seems you have taken over a quirk from my libc implementation which was 
kinda forced on me by the way the libc regex matching API is designed. In the 
libc regex API you must perallocate an array for the different group matches 
and pass that on to the regexec function along with the size of this array. 

int regexec(const regex_t *preg, const char *string, size_t nmatch, regmatch_t 
pmatch[], int eflags);

This was the factor which forced me to define this MAX_NUM_OF_MATCHES macro 
which was just to have a well visible place to tune this API imposed limit 
(There would have been a way around it by shifting through the input string 
manually always using a MAX_NUM_OF_MATCHES == 1 but i was too lazy at the 
time. I was kinda awaiting a roar of outrage about my laziness). It seems to 
me the ICU API does not show such a design (i only briefly looked over it).. 
Looking at the ICU API it seems we could simply do a single while loop which 
consecutively fetches the next match, resizes the output array accordingly 
and stores the result in it..

Do you agree/disagree on this? Or do i miss something? If so, just shout at 
me ;)

Regards,
Flo


-- 
Palimm Palimm!
http://tapas.affenbande.org