Larry Evans wrote:

There's a lively thread on c.l.c++.m about gc. One of the last posts:

http://groups-beta.google.com/group/comp.lang.c++.moderated/msg/0cc62e8dfb52...

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: http://boost-sandbox.sf.net/libs/xpressive In particular, read the section on Grammars and Nested Regexes at: http://tinyurl.com/d7637 Regexes in xpressive can be written as expression templates, which are compiled into an automoton and type-erased. It's a lot like Spirit (http://spirit.sf.net/) 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 www.boost-consulting.com