[HN Gopher] Compile time regular expression in C++
       ___________________________________________________________________
        
       Compile time regular expression in C++
        
       Author : Tideflat
       Score  : 41 points
       Date   : 2023-09-12 23:00 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | docandrew wrote:
       | This has been a part of the dlang standard library for some time:
       | https://dlang.org/phobos/std_regex.html
        
       | emmanueloga_ wrote:
       | Since people is posting other lang implementations... someone did
       | it for zig too (probably less polished than this C++ lib) [0]. It
       | is nice that the regexes can be used at compile time too [1].
       | 
       | --
       | 
       | 0: https://github.com/alexnask/ctregex.zig
       | 
       | 1: I think the difference between C++ template language and Zig
       | comptime is that Zig's comptime is almost equal as Zig's regular
       | language, whereas the experience of programming C++ templates
       | almost feels like learning a separate, equally complex language.
        
       | cracauer wrote:
       | C++ finally catches up to Perl :-)
        
       | nemoniac wrote:
       | This has been available in Lisp since at least 2004.
       | 
       | https://github.com/edicl/cl-ppcre/
        
         | paulddraper wrote:
         | Great thanks, I'll use that
        
         | 0xf00ff00f wrote:
         | C++ has had run-time regular expressions in its standard
         | library since C++11, but this is about compile-time regular
         | expressions
        
           | burntsushi wrote:
           | I've never used cl-ppcre myself, but its docs[1] claim that
           | it provides compile-time regexes:
           | 
           | > CL-PPCRE uses compiler macros to pre-compile scanners at
           | load time if possible. This happens if the compiler can
           | determine that the regular expression (no matter if it's a
           | string or an S-expression) is constant at compile time and is
           | intended to save the time for creating scanners at execution
           | time (probably creating the same scanner over and over in a
           | loop).
           | 
           | [1]: https://edicl.github.io/cl-ppcre/
        
             | foota wrote:
             | I think this is more like caching the regex than creating
             | it at compile time? Load time I think is basically runtime.
             | I think lisp can be loaded and then rehydrated later, but
             | I'm not sure how common that is.
        
       | burntsushi wrote:
       | I'd love for someone to add this to rebar[1] so that we can get a
       | good sense of how well it does against other general purpose
       | regex engines. It will be a little tricky to add (since the build
       | step will require emitting a C++ program and compiling it), but
       | it should be possible.
       | 
       | [1]: https://github.com/BurntSushi/rebar
        
         | staunton wrote:
         | The C++ standard library "general regex engine" is crap (at
         | speed), so there's no competition on that front at least...
        
       | ape4 wrote:
       | Hopefully the standard regex will be constexpr soon.
        
         | lainga wrote:
         | Not to mention, like... trig functions. I know std::cos et al.
         | need to set errno. Maybe cppfront will get rid of it.
        
           | jzwinck wrote:
           | Compile with -fno-math-errno. Almost nobody checks errno for
           | math functions, and disabling it can give a huge speedup.
        
             | lainga wrote:
             | That sets the cmath functions constexpr??
        
               | jzwinck wrote:
               | No.
        
           | leni536 wrote:
           | constexpr cmath is coming in C++23
        
           | sesuximo wrote:
           | Isn't the issue with functions like this that they are not
           | guaranteed to be the same on all hardware? So making it
           | constexpr could break programs or cause the constexpr
           | evaluated result to differ from the runtime result even for
           | the same inputs
        
           | Longhanks wrote:
           | What does cppfront have to do with it? You can
           | write/download/import/enable constexpr implementations of cos
           | with standard c++ compilers?
           | 
           | That's like saying you can't drive during winter with your
           | car because it came with summer tires... just change your
           | tires?
        
       ___________________________________________________________________
       (page generated 2023-09-14 23:00 UTC)