4 ms·
Flex and Bison depend on global variables by default, but you can eliminate the global variables if you like (e.g. %option reentrant) and change the prefix if y
by klodolph 5y ago
Flex and Bison depend on global variables by default, but you can eliminate the global variables if you like (e.g. %option reentrant) and change the prefix if you like (%option prefix="mylexer_"). Bison has similar options.
I'm sure you could only have one lexer back at some point in the distant past, but that particular issue has been solvable for a long time by now.
- EuAndreh 5y agolex and yacc depend on global variables, flex and bison, which are one the implementations of lex and yacc, don't.
- klodolph 5y agoIs there a reason why you'd be stuck on lex / yacc and unable to use flex / bison? The main reason I can think of is that you are in a legacy code base which already uses lex / yacc.
- EuAndreh 5y agolex and yacc are part of POSIX, while flex and bison aren't.
- klodolph 5y agoSure, and C++ isn't part of POSIX. So if you must stick to strictly POSIX utilities, you cannot use C++.
- ncmncm 5y agoC++ and Posix are both ISO Standards.
- klodolph 5y agoAre you constrained to only use software which is standardized by ISO? I'm just trying to figure out what you're saying here.
- ncmncm 5y agoI am not so constrained, but some are. But in general, for anybody deploying software widely, any time you can avoid a necessary build dependency on another tool, you come out ahead.
- klodolph 5y agoCould you tell me more about who is constrained this way? I'm curious about what kind of organization has these kinds of constraints. I have some friends who work in aerospace or at defense contractors and these constraints sound a little extreme even by their standards.
- ncmncm 5y agoThey would know better than I do.
- kazinator 5y agoYou can avoid a build dependency on Bison or Flex by shipping their output. Their output is intended to be portable and standard-conforming. https://www.gnu.org/software/bison/manual/bison.html#Versioning https://www.gnu.org/software/bison/manual/bison.html#Version... Even if you have standard-conforming lex and yacc source code that, theoretically, work with any yacc or lex implementation, it's still wise to pick a good implementation and generate code with it, and ship that code. You don't want some random tool from the user's installation writing C code into your project. And POSIX does not guarantee the presence of a yacc command in an installation; it just describes what it does if it is present. There are Unix-like systems with no dev tools on them; requiring lex plus yacc plus a compiler is a bigger dependency than just requiring a compiler.