3 ms·

that's nice, you and me will be in a cycle of immediately replacing each other's code. Seriously, lex+yacc / flex+bison absolutely suck, good luck when you have

that's nice, you and me will be in a cycle of immediately replacing each other's code. Seriously, lex+yacc / flex+bison absolutely suck, good luck when you have to put them as part of a complex cross-compilation build pipeline or run on windows. Also, have fun when you have multiple grammars in the same program and you don't want "colorful" ODR issues due to LTO, etc... they are entirely unfit for the job. In contrast Spirit just works for me after spending an hour reading the tutorial (my main problem was the sad issue common with expression templates and auto). It also does not require to link anything, just -I/path/to/boost no matter the platform and tada, you get a fairly performant parser.

klodolph 5y ago
Flex / Bison are manageable if you spend a bit of extra time reading the manual. I admit that there are often better options out there these days, I'm just saying that some of these complaints about Flex / Bison may be a bit outdated. Multiple grammars are fine, you just instruct Flex and Bison to use static or add prefixes. No worries about ODR or LTO. If your build system can't handle generated code, that's an indictment of your build system. I know that's a bit harsh, but there are plenty of build systems which can handle generated code and cross-compile just fine. Flex and Bison work fine on Windows.
- jcelerier 5y ago
  It's good that prefixes are now possible, but it's still something additional to know (I have never seen them in the wild and I've seen a lot of yacc in various projects), while most C++ programmers don't have to search inside some manual to know that two parsers must not have the same name : while with yacc / bison, you generally only discover it when it crashes at run-time. Also http://gnuwin32.sourceforge.net/packages/bison.htm http://gnuwin32.sourceforge.net/packages/bison.htm is not what "work fine on Windows" mean (hell, it does not even have the prefix thing you mentioned in the other comment). If there's anything ressembling a ./configure / some step that requires bash in its build pipeline then it's a complete no-go and given the GNU history of bison I doubt it'd use CMake. Though even if all of this was solved, it'd still not be as convenient as Spirit.
  - klodolph 5y ago
    When I integrate third-party dependencies I often port the build system to the build system I'm using. For projects made with autotools, that means ignoring the configure script, hand-writing a "correct" version of config.h.in, and reading Makefile.am. I'm sure this practice would offend some people. In my experience, this practice is quite common in industry. I've done this enough times that using Bison on Windows was no problem at all. In my case, I wasn't really interested in Bison itself, but I was using a different third-party dependency which itself depended on Bison.
kazinator 5y ago
Bison now supports multiple start symbols. So that is to say, you can build multiple grammars in the same file that have their own start symbols, but otherwise share rules. > or run on windows If you're using Flex and Bison, you should arrange your project so that it can build without running the tools. Only someone who needs to make changes to the grammar files should require the tools to be installed at all. That's your first line of defense. If you want people to be able to develop the grammar files on Windows, you can do it. There are ports of these things to Windows. Cygwin, MinGW-W32 and others.
otabdeveloper4 5y ago
I have used compile-time parsing in production for great effect. Think protobufs except without the preprocessing steps - you can embed a human-readable schema right into your C++ sources.

klodolph 5y ago

Flex / Bison are manageable if you spend a bit of extra time reading the manual. I admit that there are often better options out there these days, I'm just saying that some of these complaints about Flex / Bison may be a bit outdated. Multiple grammars are fine, you just instruct Flex and Bison to use static or add prefixes. No worries about ODR or LTO. If your build system can't handle generated code, that's an indictment of your build system. I know that's a bit harsh, but there are plenty of build systems which can handle generated code and cross-compile just fine. Flex and Bison work fine on Windows.

jcelerier 5y ago
It's good that prefixes are now possible, but it's still something additional to know (I have never seen them in the wild and I've seen a lot of yacc in various projects), while most C++ programmers don't have to search inside some manual to know that two parsers must not have the same name : while with yacc / bison, you generally only discover it when it crashes at run-time. Also http://gnuwin32.sourceforge.net/packages/bison.htm http://gnuwin32.sourceforge.net/packages/bison.htm is not what "work fine on Windows" mean (hell, it does not even have the prefix thing you mentioned in the other comment). If there's anything ressembling a ./configure / some step that requires bash in its build pipeline then it's a complete no-go and given the GNU history of bison I doubt it'd use CMake. Though even if all of this was solved, it'd still not be as convenient as Spirit.
- klodolph 5y ago
  When I integrate third-party dependencies I often port the build system to the build system I'm using. For projects made with autotools, that means ignoring the configure script, hand-writing a "correct" version of config.h.in, and reading Makefile.am. I'm sure this practice would offend some people. In my experience, this practice is quite common in industry. I've done this enough times that using Bison on Windows was no problem at all. In my case, I wasn't really interested in Bison itself, but I was using a different third-party dependency which itself depended on Bison.

kazinator 5y ago

Bison now supports multiple start symbols. So that is to say, you can build multiple grammars in the same file that have their own start symbols, but otherwise share rules. > or run on windows If you're using Flex and Bison, you should arrange your project so that it can build without running the tools. Only someone who needs to make changes to the grammar files should require the tools to be installed at all. That's your first line of defense. If you want people to be able to develop the grammar files on Windows, you can do it. There are ports of these things to Windows. Cygwin, MinGW-W32 and others.

otabdeveloper4 5y ago

I have used compile-time parsing in production for great effect. Think protobufs except without the preprocessing steps - you can embed a human-readable schema right into your C++ sources.