Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-09 12:42:02


John Maddock wrote:
>> Front end localization could change this also, I believe. For
>> instance if
> a
>> dll or message catalog substitutes '!' for '$' wouldn't I need to
>> escape
> '!'
>> instead of '$' in order to use '!' as a literal in an expression ?
>
> Yes, I was afraid you would bring that up :-)

Since I support the same localizations using your regex++ library in my
components, I have to. <g>

>
>> In this regard it would be helpful if the end-user could obtain back
>> at run-time the substitutions that are made due to localization. I
>> didn't see this as a function of the regex_traits class reference
>> but maybe it is there.
>
> No it's not - the internal data simply isn't structured in a way that
> allows that kind of query - however as you yourself said already -
> the end user
> *knows* what the special characters are (if they have been changed).

This is true. I was really suggesting it to forestall the objection that the
changes are normally in a file set up manually, such as a resource DLL, so
it is difficult to read the file back in and load the substitutions etc.
etc. to figure out what changes were made. Of course one needs to know what
the localization changes are to present valid regular expressions so the
objection is a weak one.

>
> The worst case scenario: the user has substituted a traits class that
> uses different characters for the \ x { and } regular characters, so
> that escape sequences like: \x{32} don't work anymore.

You forgot that the digit characters themselves can be changed also. <g>

I think, given the difficulty, but not the impossibility, for an end-user to
do it, you might consider a function in reg_expression which returns an
escaped string, like your example escape_regex function, for any regex
string passed to it, taking into account all the currently set flag
possibilities and possible localization changes.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk