No offense to you personally (I even used an "S" so you'd be happy ;-)), I think regex is a critical language feature that should be built into the program itself. Requiring people to download a library, not to mention a pay-for library, is a huge liability to BYOND.

Worse, I don't think the Hub really clarifies that the "subscription" still allows you to keep your copy even after the subscription expires, so I imagine most people are instantly turned off by that.

No offense to you personally (I even used an "S" so you'd be happy ;-)), I think regex is a critical language feature that should be built into the program itself. Requiring people to download a library, not to mention a pay-for library, is a huge liability to BYOND.

I agree here; if there are readily available c++ RegEx libraries, I don't see a reason not to have it as a language feature. Its enough of a feature to deserve its own mention as being an integrated part of the language, which certainly helps with advertising.

GRETA appears to rely on the standard template library. For maintenance purposes, we avoid STL in BYOND's code. I don't know what the licensing is for this one. Assuming it can be made to work without STL and it doesn't involve selling our kidneys to Microsoft, it could have potential.

PCRE had to be ported to Windows, which is odd because a basic regex library really should already be portable--indeed it'd have to be for us to use it. The Windows version is a few versions behind. It uses the BSD license which I believe is one we can live with--anything with copyleft is absolutely out of the question.

I've seen Regex++ and Boost before, and frankly still don't understand them. I don't know what to make of the Boost license or what would be involved in using any of that, but my general feeling is that tacking on this whole other big library would not be a good thing for BYOND.

Unless there is some back-end reason not to use the STL this statement is just a paradox. I found that switching over to the STL not only improved the readability but also increased maintainability.

I've seen Regex++ and Boost before, and frankly still don't understand them. I don't know what to make of the Boost license or what would be involved in using any of that, but my general feeling is that tacking on this whole other big library would not be a good thing for BYOND.

Boost is a little hazy about their license in my opinion. I can contact them about the specifics though.

It is my understanding that the ported versions of PCRE are for Microsoft Windows DLL generation. I think the the standard library will work fine as a static library. precpp.h is the C++ wrapper for the library.

Boost Software License

Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:
The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

This is the regex functionality from glibc 2.5 extracted into a
separate library, for Win32. It may be built, from the sources
provided, using the command sequence:--
./configure [--options...] && make
For a list of available configuration options, run:--
./configure --help
After building, as above, the resultant DLL, and optionally the
associated development kit, may be installed by:--
make install
while redistributable binary DLL and development library kits may
be created by:--
make dist
The original sources, on which this port is based, remain
copyright of their respective authors, or of the Free Software
Foundation Inc., as indicated in individual file headers; all are
redistributed with permission, as granted by the GNU Lesser
General Public License.
This is free software. It is provided AS IS, in the hope that
it may be useful, but WITHOUT WARRANTY OF ANY KIND, not even an
IMPLIED WARRANTY of MERCHANTABILITY, nor of FITNESS FOR ANY
PARTICULAR PURPOSE.
Permission is granted to redistribute this software, either
"as is" or in modified form, under the terms of the GNU Lesser
General Public License, as published by the Free Software
Foundation; either version 2.1, or (at your option) any later
version.
You should have received a copy of the GNU Lesser General Public
License along with this software; see the file COPYING.LIB. If
not, write to the Free Software Foundation, 51 Franklin St -
Fifth Floor, Boston, MA 02110-1301, USA.
The original port of this functionality was implemented by Tor
Lillqvist; I've adapted his work, to make it somewhat more MinGW
friendly. I have *not* modified any of the `C' sources provided
by Tor; nor have I changed the naming conventions he adopted for
generated distributables. I *have*:--
1) Replaced Tor's original `Makefile' with an autoconf generated
configure script, and a backwardly compatible `Makefile.in';
this provides a more flexible build procedure, which I find
more convenient, when cross-compiling on a GNU/Linux host.
2) Added VPATH support, for `out of tree' builds.
3) Adapted the build procedure, to avoid a dependency on the `lib'
program from Microsoft's MSVC tool chain. This is achieved by
providing an option to configure, which is disabled by default;
it may by activated by specifying `--enable-msvc-implib' on the
configure command line. If this option is not activated, or if
the MSVC `lib' tool is not present, the Makefile is configured
without binding the rule for building an MSVC compatible import
library, to the default target, (although the rule is left in
place for explicit use).
If the `--enable-msvc-implib' option is specified, but `lib' is
not present, then configure will issue a warning message, and
will again configure the Makefile without binding this rule to
the default target.
Only if the `--enable-msvc-implib' option is specified, *and*
the `lib' tool is present, will building of an MSVC compatible
import library be configured as a default deliverable.
4) Added `install', `install-dll' and `install-dev' targets, to
support direct installation of the DLL, and its associated
development kit.
5) Changed the default packaging format for distributables, from
Tor's exclusive choice of `zip', to my own preferred `tar.gz';
`zip' format remains available, as an option, by configuring
with `--enable-dist=zip'.
6) Added `bindist', `devdist' and `srcdist' targets, for greater
flexibility in building distribution kits.
The original text of Tor's README file will be found below.
--Keith Marshall <keithmarshall@users.sourceforge.net>
I call the DLL libgnurx-0.dll which hopefully should be unique. At
least it isn't "regex.dll" which has been used by the
gnuwin32.sourceforge.net site for *two* incompatible DLLs. (That mess,
and the mess with their build of Henry Spencer's regex library, was
what lead me to build my own GNU regex library. See the
gnuwin32-users mailing list archives from December 2006.)
The "-0" is so that if at some point I build a release that isn't
binary compatible, I can then increment that and use a different name.
The import library for gcc is called libgnurx.dll.a, but I also
distribute a copy of it called libregex.a so that configure scripts
that look for -lregex will work.
Note that none of the wide-character and i18n functionality which is
built when this is part of glibc gets compiled. Thus things like
character classes most probably work only for single-byte codepages.
Compiling that stuff would drag in lots of glibc's locale handling
stuff which is completely incompatible with Microsoft's C library's
locale handling anyway. Also, I am not sure whether the GNU regex code
is prepared to handle a two-byte wchar_t, or does it assume that
wchar_t is int as it is on Linux? Hmm, actually there is lots of
sizeof(wchar_t) in glibc, so maybe it *is* prepared? Maybe
later... But anyway, it would presumably mean we should have not just
the regex functionality but a larger subset of glibc that would
include all locale, ctype, wchar, mbs, etc stuff, presumably ending up
with a very large part of glibc (not the system calls,
obviously). Indeed, something to save for later, or never...
--Tor Lillqvist <tml@iki.fi>, <tml@novell.com>

Unless there is some back-end reason not to use the STL this statement is just a paradox. I found that switching over to the STL not only improved the readability but also increased maintainability.

When I first implemented the DD ban system, the backend handled it all via STL. However, this adds a layer of complexity to BYOND's code because so much is done without STL, and it's just one more thing to deal with from a maintenance standpoint. Per Tom's request I replaced the STL with more familiar stuff.

I'm all on board with STL being elegant and performing some tasks (like handling strings) very well--it's just that it complicates code that is already especially complicated.

I've seen Regex++ and Boost before, and frankly still don't understand them. I don't know what to make of the Boost license or what would be involved in using any of that, but my general feeling is that tacking on this whole other big library would not be a good thing for BYOND.

Boost is a little hazy about their license in my opinion. I can contact them about the specifics though.

It doesn't seem worth it to me to implement Regex++ since this whole other library comes with it as baggage. More baggage is the last thing BYOND needs. A relatively simple regex engine on the other hand that didn't have to have a zillion other things with it in order to compile, that'd be handy.

Sounds like that one is easier to build, but being under LGPL I don't think it's suitable. Any copyleft whatsoever is anathema. Or to put it another way, no GNUs is good news.

I believe LGPL is ok, but we'd of course want to review it before jumping in.

And for the record (before this turns into an open-source debate), I'm not actually against open-source for BYOND, but if we did it I'd want to do it correctly, with a clean API and documentation, and that is just too big of an effort to deal with at the moment.