fbb-git / bisoncpp Goto Github PK

Hello,

In the skeleton for polymorphic SType : bisonc++/skeletons/bisonc++polymorphic
Correct me if I am wrong, but the Base class has no virtual destructor, so the delete d_base; statements at lines 187 and 224 do not call the appropriate Semantic<T> destructors. If I am correct, it seems that virtual function are unavoidable. In that case, why re-implementing virtual tables manually with function pointers? It seems to me that having a single pointer to the vtable in each object (the virtual functions implementation) is more lightweight than having the whole "vtable" in each object (the current implementation).

Also, it would be nice to use smart pointers instead of the raw new and delete statements, to be clearer about the intended semantics and to avoid possible memory leaks ; it seems to me that a unique_ptr<Base> would be appropriate here.

Hello,

using the bisonc++ version 4.13.01 with polymorphic semantic values, the semantic action for the production:
vertex: TK_KW_V coord coord coord { $$ = { $2, $3, $4, 1.0 }; }
was working fine (provided the vertex semantic type was an aggregate, in this case a class type with no protected or private members, no user-provided constructors, etc., and the semantic value of coord match the data members types of the class).
After upgrading to version 5.00.01 (from Debian testing repository) I got a compilation error:
parser.y: In member function ‘void Parser::executeAction(int)’: parser.y:85:19: error: no match for ‘operator=’ (operand types are ‘ParserBase::STYPE__ {aka Meta__::SType}’ and ‘<brace-enclosed initializer list>’) TK_KW_V coord coord coord { $$ = { $2, $3, $4, 1.0 }; } ^ parse.cc:636:8: note: candidate: Meta__::SType& Meta__::SType::operator=(const Meta__::SType&) SType &SType::operator=(SType const &other) ^
Substituting the action for:
vertex: TK_KW_V coord coord coord { $$ =vec4 { $2, $3, $4, 1.0 }; }
seems to fix the problem (but the resultant parser is painfully slower than the generated by the 4.13 version). NOTE: vec4 is the class type associated with the non-terminal vertex;
Is this an expected behavior for the newer version?

EDITED:

Found the problem (in fact, is not a problem, but an expected behavior for the newer version) with the copy-list-initialization, as can be read in the README.polymorphic-technical:

In the latter case (copy constructing from an existing object) Type must be a defined polymorphic semantic type (which a initializer-list isn't), as this allows the compiler to deduct the correct Tag__.

There are, still, the difference in performance between the parser generated by version 4.13.01 and the one generated by version 5.00.01 (the later is 30 times slower). The parser generated with version 5.01.00 seems faster than the generated by 5.00.01, but still much slower than the version 4.13.01, but it isn't related to this issue, so I'd consider this topic solved.

P.S. I'm sorry for the mistake (I should have read the changelog more carefully) and thanks for the great software.

I installed the latest version of bisonc++:

git clone https://github.com/fbb-git/bisoncpp/
cd bisoncpp/bisonc++
./build program strip
sudo ./build install LOG:.bisoncpp bs

but the log file .bisoncpp only contains:

dir /

which is not very useful...

Also, the command build install prints to stdout the following:

mkdir -p tmp/install/
  installing the executable `tmp/install/b//usr/bin/bisonc++'
mkdir -p tmp/install/b//usr/bin
cp tmp/bin/binary tmp/install/b//usr/bin/bisonc++
...

which seems weird because the string tmp/install/b/ is prepended to all the paths, but in reality the files are installed to e.g. /usr/bin/bisonc++. This weird behavior also applies to flexc++ and bobcat although their LOG files seem OK.

Building bisoncpp with clang results in:

./parser/parserbase.h:317:24: error: reference to non-static member function must be called; did you mean to call it with no arguments?

The full log can be found here:
http://clang.debian.net/logs/2016-08-30/bisonc++_5.02.00-1_unstable_clang.log