1) Instead of testing for == FAIL below,we test for != ACCEPT (in which ACCEPT has a value of zero). When compiling on a MSVC 2010 platform using cygwin's Flex and Bison,we note that the return value from parse() is not -1 but rather +1. It is more likely that on different platforms the return value of zero will be used consistantly to indicate an accept state. Whereas, the value of the abort or fail state will be more likely not to be a specific value but rather a value that is not equal to zero.
2) The expression:
if (p != nullptr) delete p;
can be rewritten more concisely
delete p;
since delete is well behaved when passed a nullptr.
3) One should release the pointer to the old scanner and parser
before allocating a new one. Otherwise, you will have memory leaks
if MC_Driver::parse() is call more than once per instance.
1) Instead of testing for == FAIL below,we test for != ACCEPT (in which ACCEPT has a value of zero). When compiling on a MSVC 2010 platform using cygwin's Flex and Bison,we note that the return value from parse() is not -1 but rather +1. It is more likely that on different platforms the return value of zero will be used consistantly to indicate an accept state. Whereas, the value of the abort or fail state will be more likely not to be a specific value but rather a value that is not equal to zero.
2) The expression: if (p != nullptr) delete p; can be rewritten more concisely delete p; since delete is well behaved when passed a nullptr.
3) One should release the pointer to the old scanner and parser before allocating a new one. Otherwise, you will have memory leaks if MC_Driver::parse() is call more than once per instance.