3 ms·

Why don't you write it? I don't mean this in a snarky way - I don't share this particular problem, but other people writing C++ code probably do. It sounds like

Why don't you write it? I don't mean this in a snarky way - I don't share this particular problem, but other people writing C++ code probably do. It sounds like you're 1) experienced in writing C++, 2) reasonably knowledgeable about the landscape of regular expression libraries in C++, and 3) aware of a clear gap in the functionality of available libraries. Whatever you develop might not make it into the STL, but I bet a bunch of other people would find it useful. If it's a matter of personak time and this is a professional need, maybe you can write it for your employer.

mehrdadn 8y ago
Haha, great question, and in fact, I started to do exactly this, back in... 2015? is what Git tells me. I forgot about it and it sat gathering dust for a few years and I think it was this year when I got around to finishing implementing the actual parsing the regex pattern (which, as a side effect I now have a library to reverse a regex! which might be operation #6 they should all support!), but while my 'basic_regex' has been written, my 'basic_nfa' class has yet to have its guts filled in, and a 'basic_dfa' has yet to be started. First reason why I haven't implemented this already is obviously time... it's not exactly a trivial undertaking, and no, it's by no means a professional need; it's something I've needed in my side projects. Second reason is that while I know enough about the theory to be (probably) able to do it given sufficient time, I don't know enough to do it in what I feel is a comfortable amount of time -- it's my first time implementing a regex engine, and I would still need to learn how to do capturing groups and DFA minimization efficiently, for example (and probably other things I can't think of right now). And lastly, I have this nasty habit of trying to make code ultra-optimal and -extensible when I hope to see widespread usage (e.g. avoiding unnecessary heap allocations like crazy, making it fast, and making it so that it can be elegantly generalized to or used within a CFG parser). And if I'm doing it, it better be perfect for all of my own uses -- I'm not going to write a second one because this one is inadequate!! This also doesn't make the job any easier. But the main obstacles are the first two, not this last one.

mehrdadn 8y ago

Haha, great question, and in fact, I started to do exactly this, back in... 2015? is what Git tells me. I forgot about it and it sat gathering dust for a few years and I think it was this year when I got around to finishing implementing the actual parsing the regex pattern (which, as a side effect I now have a library to reverse a regex! which might be operation #6 they should all support!), but while my 'basic_regex' has been written, my 'basic_nfa' class has yet to have its guts filled in, and a 'basic_dfa' has yet to be started. First reason why I haven't implemented this already is obviously time... it's not exactly a trivial undertaking, and no, it's by no means a professional need; it's something I've needed in my side projects. Second reason is that while I know enough about the theory to be (probably) able to do it given sufficient time, I don't know enough to do it in what I feel is a comfortable amount of time -- it's my first time implementing a regex engine, and I would still need to learn how to do capturing groups and DFA minimization efficiently, for example (and probably other things I can't think of right now). And lastly, I have this nasty habit of trying to make code ultra-optimal and -extensible when I hope to see widespread usage (e.g. avoiding unnecessary heap allocations like crazy, making it fast, and making it so that it can be elegantly generalized to or used within a CFG parser). And if I'm doing it, it better be perfect for all of my own uses -- I'm not going to write a second one because this one is inadequate!! This also doesn't make the job any easier. But the main obstacles are the first two, not this last one.