From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-09-02 07:17:43
John Maddock schrieb:
> > If that is true: Why does the flag regbase::use_except (officially)
> > exist?
> It's a historical accident and should have been removed from the docs.
OK. So it seems that I should not write code which explicitely mentions
> > Lets assume, that throwing boost::bad_expression is a general policy (I
> > can live with that),
> > it would be **very** nice to have at least one (probably static) member
> > function,
> > which takes a textual regular expression and an optional bunch of
> > regbase flags as arguments and
> > returns a bool, which simply returns true in case of a valid expression,
> > otherwise false. What
> > do you think of that?
> You could call the undocumented member function set_expression which would
> return 0 on success, alternatively you're back to rolling your own, BTW why
> do you want this? If a regular expression is valid, then presumably at some
> point you would want to use it? I ask because the job of checking the
> expression for validity is essentially the same as compiling it to a state
Thanks for the tip concerning "set_expression" (although I fear, that I should
its usage as deprecated, don't I?).
The reason for my proposal is quite simple: It is sometimes quite natural, that
is a long way between the actual user input of a regular expression in textual
lets say some GUI framework, and its actual interpretation via boost::regex.
Now consider the situation when you have two **separated** task:
1) Simply verify the validity of user input (Compare this situation with a test
whatever). This is not the place, where the actual evaluation of input is
2) The remote procedure which is the actual workhorse and does its job, and
possibly throws during exceptional situations.
You are right: In most cases its makes sense that evaluation and verification are
performed in one step, but if you are in an environment, where its not **an
situation to give an invalid textual reg expression as an argument to regex, it
natural (to me) to usage a verification function, which possibly needs not to make
as much work as the actual processor.
I think this situation comes near to problems of user input of filenames, which
several conditions can not be viewed as exceptional but nearly as a normal case.
This is one of the reasons I belief that the two ways of using iostreams (via
or not) is not such a bad Thing. I don't generally recommend to incorporate such a
dichotomous nature into boost::regex, but it is sometimes useful to just have a
for cases of nearly equal probability instead of exceptions for rare error
Similar valuable as 'has_facet' compared to 'use_facet' if you have the task to
system for its very long list of locales to check whether they provide some
Greetings from Bremen,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk