Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2005-06-14 17:30:30

Larry Evans wrote:
> There's a lively thread on c.l.c++.m about gc. One of the last
> posts:
> concerns xpressive. Could someone familiar with that library
> give a response?

I replied with:

Le Chaud Lapin wrote:

> Eric Niebler wrote at link above:
>>> I had to solve the same problem for xpressive, where regex objects can
>>> embed other regex objects, either "by value" or "by reference". This
>>> leads to all sorts of interesting cyclic ref-count scenarios. I use
>>> tracking_ptr to handle this.
> Without understanding the full context of Eric's regex project, my
> guess is that he could represent his structure as an associative
> polyarchy:
> STL::Assocative_Polyarchy<whatever, Expression>.
> Expression would consist of the string (derive from string?), as well
> has have a .compile() member function that builds the automaton. Note
> that this implies that STL has a tree<> class, which is doesn't.

You'll have to spell it out a bit more. Googling for "associative
polyarchy" returns exactly zero hits, and I don't know what that is.

If you mean that I should store regexes both as an automaton as well as
the string from which it was created, and then do string concatenation
for embeded regexes, then that won't work. In xpressive, not all regexes
start life as a string. You can read about what I'm doing here:

In particular, read the section on Grammars and Nested Regexes at:

Regexes in xpressive can be written as expression templates, which are
compiled into an automoton and type-erased. It's a lot like Spirit
( in that regard. I should point out that Spirit's
author chose not to deal with this particular issue -- in Spirit, the
"rule" object is not reference counted, so you can easily end up with
dangling references. You can consider that an argument in favor of
garbage collection.

Eric Niebler
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at