compile-time-regular-expressions VS staticvec

CTRE (https://github.com/hanickadot/compile-time-regular-expressions) ranges::views (filter, transform, etc.) (C++20) str.find() + str.substr() freopen to stdin + cin >> extraction Parser libraries

There are suggestions that should be replaced by the high performance ctre implementation: https://github.com/hanickadot/compile-time-regular-expressions

operator"" can be used in a similar way to expression templates (DSLs), where the type of the resulting expression is dependent on the string contents. For example ctre makes use of this to build efficient regular expression parsers, and kumi uses this in conjunction with operator[] to make tuple indexing quite elegant

Check out https://github.com/hanickadot/compile-time-regular-expressions anything is possible 😂

Yes to regex, no to std::regex. Better to use CTRE. Something like "^Hello [0-9]+ how are you" should allow checking if there's a match

You could compare your implementation with https://github.com/hanickadot/compile-time-regular-expressions and see if there are any ideas you can copy.

std::compile_time_regex would be a nice addition. Something similar to ctre https://github.com/hanickadot/compile-time-regular-expressions Simply letting the compiler generate all the regex parsing machinery at compile time.... And benefitting from compiler optimizations, vectorization, etc...

ctre

This crate of mine for example is currently literally unusable until the deeply fundamental features that John Random kinda-sorta removed in this pull request, ostensibly in preparation for whatever shittily stated syntax is ultimately establihed by whatever the hell "keyword generics" actually is (I really don't know, like this isn't a joke, I fundamentally do not understand what the fuck they're proposing at all in any way or how it's meaningfully and usefullly different from the previous syntax).

If you're on nightly, I have a crate that I'd say would seem to be exactly what you're looking for.

I'd say the module system can sometimes get in the way of even the most technically well-documented crate out there. It's why for example I carefully rexport the various types implemented by my crate StaticVec from lib.rs such that the main docs page looks like this, even though "under the hood" everything is actually about as modular as you might expect it to be.

Here.

Your link there is rather outdated. mem::unitialized() is deprecated and not recommended for use. MaybeUninit works more than fine in my experience, anyways.

The lack of decltype-esque functionality has consequences that are far-reaching enough to be worthy of more than a throwaway mention, IMO. See this ongoing issue for a crate of mine, for example.

If you're on nightly, my crate StaticVec definitely has your use case covered and then some.

Looks like this crate uses the full const_generics instead of min_const_generics (see here), along with a couple dozen other unstable features. I'm not sure how much of that could easily be removed, since it is often the tendency to enable tons of unstable features when you are already on nightly because of something like const generics.