[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)