Re: [Boost-users] Regex Design trap

Subject: Re: [Boost-users] Regex Design trap
From: Sven Bauhan (Sven.Bauhan_at_[hidden])
Date: 2010-09-09 04:02:43

> As you say, it's performance related - had match_results copied the string
> the cost would be at least 10 times the normal cost of a call to
> regex_search (all due to the memory allocations).  You also lose positional
> information if you store copies rather than iterators.
>
Ok this sounds sensual. I read the documentation again and found that it uses 
regex_iterator for the matches. I recently read over this information.

> Sigh... you mean like the deprecated RegEx class:
> http://www.boost.org/doc/libs/1_44_0/libs/regex/doc/html/boost_regex/ref/de
>precated_interfaces/old_regex.html
>
It comes close, but the match and search methods also return bool not the 
matches.

> The current interface is closely modeled on the C++ standard library, and
> of course will *be part of the next C++ standard*.  The idea is that
> objects store data, and free functions operate upon them (as with the
> standard library containers and algorithms for example).  One advantage of
> this approach is that the user can extend the range of operations
> available, something that is basically impossible with a "closed" OO design
> where everything is in the class.  For example one could easily define a
> new variation on regex_replace that performed a customized replace
> operation.
>
Ok, this explains why the RegEx class is now deprecated. I was wondering 
before.

But one point stays open yet: Why returning the matches as out parameter 
instead as return value?
If you want to have the possibility to check if the match succeeds, class 
match_results<> would just need a unspecified-bool-type operator. This is 
also done in other classes e.g. shared_ptr<>.

Greetings, Sven