Skip to content
This repository has been archived by the owner on May 31, 2023. It is now read-only.

Switch to using pcre::regex instead of boost::regex #190

Closed
wants to merge 5 commits into from
Closed

Switch to using pcre::regex instead of boost::regex #190

wants to merge 5 commits into from

Commits on Sep 11, 2021

  1. Switch to using pcre::regex instead of boost::regex 

    Drop dependency on Boost.Regex library and use PCRE-based regex class
instead.

Using PCRE-based implementation is advantageous compared to using
std::regex because it has a much better performance and also supports
more regex features, notably the "?<=" look-behind assertions not
supported by the standard class, that are used in the existing code.

With PCRE, the only regex change needed was the one replacing "\l",
which is not recognized by PCRE (nor std::regex) as a character class
shorthand, with the explicit use of "[:lower:]".

Currently PCRE is used only under POSIX systems and so the fully
functional version of test_coding_rules tool can only be built there
and a stub version, which simply outputs an error, is built by default
under MSW. This shouldn't be a problem in practice, because this tool is
only used during lmi development, which is done only on POSIX platforms.

The regex unit test has been minimally modified to build, and pass,
without Boost.Regex.

Finally, remove the last vestiges of Boost libraries from configure and
automake makefiles.
    @vadz
    vadz committed Sep 11, 2021
    Configuration menu
    Copy the full SHA
    ef843cf View commit details
    Browse the repository at this point in the history

  2. Restrict test_coding_rules post link test to POSIX platforms only

    @vadz
    vadz committed Sep 11, 2021
    Configuration menu
    Copy the full SHA
    c7f3a97 View commit details
    Browse the repository at this point in the history

  3. Benchmark pcre::regex if available in regex_test.cpp 

    Compare PCRE performance with std::regex under POSIX systems, where PCRE
is available.

The results show that PCRE is 6-12 times faster, even with the simplest
possible regexes used in this test, with gcc 10 (previous
test_coding_rules benchmarks show that the difference is even more
pronounced with more complex regexes or older gcc versions).
    @vadz
    vadz committed Sep 11, 2021
    Configuration menu
    Copy the full SHA
    e5ddfda View commit details
    Browse the repository at this point in the history

  4. Fail concinnity check if there are any coding rules test failures 

    The changes of a9bc62f (Count coding-rules complaints, 2021-06-28)
made test_coding_rules exit with a non-zero exit code if any coding
rules violations were found, but the check_concinnity makefile target
still explicitly ignored the failure by using "-" in the make recipe.

It is not really clear why was the exit code of test_coding_rules
ignored in the first place, as it hadn't been done for the checks
performed in the makefile itself prior to the introduction of a separate
test_coding_rules program in 7afe844 (Quadruple the speed of 'make
check_conformity', 2006-01-18), but it remained the case ever since.

Stop doing it now and do fail if either any real problems are found or
when running the stub version of test_coding_rules built on the systems
without PCRE.
    @vadz
    vadz committed Sep 11, 2021
    Configuration menu
    Copy the full SHA
    cb43f1b View commit details
    Browse the repository at this point in the history

  5. Always use Linux version of test_coding_rules 

    Because only Linux version of this tool is fully functional (while the
MSW one just exits with an error), always use it, even in the build
targeting MSW.

This is enough to make concinnity checks to work in any build.
    @vadz
    vadz committed Sep 11, 2021
    Configuration menu
    Copy the full SHA
    5e49ea1 View commit details
    Browse the repository at this point in the history