how to use regex library

[Dr Nick]

If all you pass it is a regex and a buffer pointer, why would you
expect it to do a "get next" on the second call? If you expect the
answer to be "because I passed the _same_ pointer both times, so it
should 'know' I meant to do 'get next' on it", then how would you ever
use it in a loop where the same buffer is passed, though the contents
have changed? (For example, something like "grep", which would print
any line that has a match to the regex.)

It could store a hash of the search string somewhere in the (opaque)
compiled regexp.

I know, I know. But I want to exercise my angels.

 

[Seebs]

It could store a hash of the search string somewhere in the (opaque)
compiled regexp.

That's const-qualified.

I'm pretty sure that it would, at the very least, violate the spirit of
the interface for the compiled regexp to be modified in any way.

-s

 

[Dr Nick]

That's const-qualified.

OK, so when you regcomp it could put a unique key into the compiled
regexp, that points into a hidden memory area where it stores ...

I'm pretty sure that it would, at the very least, violate the spirit of
the interface for the compiled regexp to be modified in any way.

Oh yes.

 

[Owner]

I was watching disscussions thinking,
Wow look at all those great replies to my topic.
( I only wrote 11 lines originally. )
Ultimately it's my wish to build wchar_t version of regexp,
it will be long way to go. Because in order to do so,
need to know how it works internally. I found tre regexp lib
googling by accident which supports wchar_t, I need to dig
in more inside. It's coded in C. I tried to compile, but
so far failed. compiling library is complicated

 

[Seebs]

Ultimately it's my wish to build wchar_t version of regexp,
it will be long way to go.

Yes, yes it will.

Because in order to do so,
need to know how it works internally. I found tre regexp lib
googling by accident which supports wchar_t, I need to dig
in more inside. It's coded in C. I tried to compile, but
so far failed. compiling library is complicated

Not to put to fine a point on it: While it could be a great learning
experience, if you are finding this complicated, writing, heck, even
DEFINING a wchar_t version of regular expressions is going to be a pretty
stiff challenge for you.

But honestly? Go for it! I never learned much by doing stuff that was
easy for me.

-s

 

[Shao Miller]

I was watching disscussions thinking,
Wow look at all those great replies to my topic.
( I only wrote 11 lines originally. )

If only my car got so much out of gasoline... *sigh*

 

[Owner]

Yes, yes it will.


Not to put to fine a point on it: While it could be a great learning
experience, if you are finding this complicated, writing, heck, even
DEFINING a wchar_t version of regular expressions is going to be a pretty
stiff challenge for you.

But honestly? Go for it! I never learned much by doing stuff that was
easy for me.

-s

Good News!
I was able to compile tre library which supports wchar_t and '
run it with visual c++ express 2008. There was a little
glitch in the project file like misspelling of "msvcprtd.lib"
in option and that prevented me from running the test program, and
any program linked with. Also turned off debug symbols so
output will say things only need to say.

Now I got a regexp library that support wchar_t.

 

[Michael Press]

I got one more problem. I dont' think Man page mentioned
about second matching on the same string, when I read it.
I tried call "i = regexec(r, argv[2]);" twice, but didn't move
forward after first match. I did found however
"i = regexec(r, r->endp[0]);" matches the second substring.
but I don't think it's meant to be used this way.
How do you match same pattern more than twice on the same line?

Well, typically, you would find a point in the line after the first
match, and use regexec to match there.

Why don't you think it's meant to be used this way? What seems unusual
to you about using the endpoint of a previous match as the starting place
to look to see whether there are any more matches? Why would you think
that it would "move forward" after the first match?

Because that is a quite reasonable expectation. Many search
facilities operate either operate that way or they have a 'next
instance' command. It is misleading to say that computers 'do what
you tell them to do'. Unless you are programming down to the bare
iron you don't tell computers what to do - you tell some piece of
software what to do. What that software does is (sometimes) what the
programmer who wrote it decided it ought to do. It is a serious
mistake to blame the computer for the design errors of the software
creators.

Even the bare iron was designed by a person/design team.
It is often useful to think of the carefully designed
constellation of programs as a machine. It responds the
same to the same inputs---very machine like. Yes, it is
also extremely useful to remember that the piece of
garbage frustrating my efforts to make good use of it
was put together by a brain damaged time server; but
Seebs metaphor of the human designed interface as a computer
is well taken where he used it.

 

[Dr Nick]

And when your grep-like code reads two identical lines in a row from the file?

Curse you! Foiled again.

 

[Tim Rentsch]

Maybe. The thing is, in a fair number of cases, other people can't
tell; this is why ESR's "smart questions" page exists. Perhaps more
importantly, in some cases, other people can't tell that they can't
tell, and no one gets anywhere until someone points out that the question
was vague.

In that case I suggest you wait a few days before responding.
It's likely that someone else will be able to help, and if
not the lack of response may prompt further thought on the
part of the OP. In either of those cases, you are spared
the effort of responding, and the S/N ratio of the newsgroup
goes up.

Having read a number of his posts, I would tend to consider him responsible
for his failure to clearly state what he's trying to do, because he clearly
has good enough English to read ESR's page and follow the guidelines there.
His questions strike me as not showing much of an effort to figure things
out before he posts, and I like to remind people that even a small amount
of effort can save a LOT of time.

Part of what I'm suggesting is that the reminders being sent,
even though you may like to send them, don't have a high
effectiveness hit ratio, and if they don't it's probably a
good idea to try a different strategy.

 

[Tim Rentsch]

Of course there is. Below I quote Mark Bluemel's response. It is an
excellent example of how to answer such a query. He was helpful. You
are not.

Right. It's one of the known limitations of the way I respond to questions;
I can only answer the question actually asked, I can't mind-read.
[snip elaboration]

Since it's your limitation, and since you know about it,
maybe it's better for you not to respond in such cases,
and let other people answer who are more able to help.
Yes? I understand your frustration at not being able
to provide a helpful answer, but the OP isn't responsible
for that frustation, even if his posting is part of what
caused it.

"I can't print. Fix it."

Yes, that was a real report we got once. No other details, even after
repeated requests for such.

How would you suggest fixing it? (Note that you are being paid to
support said user. This is not a case of "I read Usenet for
recreational purposes". Therefore, "sorry, go away" is not an
acceptable answer.)

I honestly don't know. If it were my job and for whatever
reason no one else could (or would) do it, I imagine I'd try
something, and something else, etc, hoping to get something
figured out. My point though is about the situation where
there is another person available and there is reason to
believe that one or more of these other folks are likely to
be more effective than I am in my bumbling non-eptitude --
in that case, I would hope one of the more competent folks
would work on that, and I would look for something to work
on which I would be more likely to be do effectively.