$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [xpressive] Is there a way to test for an empty regex?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-11-20 14:16:36
Eric Niebler wrote:
> Michael Goldshteyn wrote:
>>
>> Perhaps something like unfilled(), bare(), or as you suggested
>> is_invalid() should be added to the actual implementation, instead of
>> user code? I would further argue that something so trivial and tightly
>> coupled to the implementation
>> (i.e., regex_id() being zero) should be a member function and not
>> stand alone.
>
> What is it about checking the regex_id() that bothers you? Is it the
> constant 0? You could instead write it like ...
>
> if(rex.regex_id() == sregex().regex_id())
>
> Default-constructing a regex is very cheap, FWIW.
I'm not very familiar with xpressive, but having a look from aside it
would never come into my mind that "rex.regex_id() == 0" is an emptyness
(or whatever) check. Sorry, this looks more like a hack to me.
I think a clear statement is needed: is a default-constructed regex
valid? If not, then why does it have a default constructor? If it is,
the default-constructed state should be easily detectable, since this is
a common practice in just about any domain:
- Boost.Regex, containers, strings, Boost.Function provide empty()
- Boost.Optional, Boost.SmartPtr provide unspecified bool conversions
and operator!, or equivalent facilities.
Personally, I like empty() naming, but if a more precise name can be
found, I would be fine. And I agree with Michael, such a function should
be a member of the class.
As for application, the empty state of regex may be useful when the
expression may, or may not be compiled. It's a sort of implicit
optional, but a simpler and more efficient one. However, I'm sure it's
not the only valid use case.