Re: C++.bison

[Akim Demaille]

| At 12:22 +0200 2002/04/04, Akim Demaille wrote:
| >>>>>> "Hans" == Hans Aberg <address@hidden> writes:
| >
| >Hans> Does anybody have a m4 processed bison.c++ skeleton file?
| >
| >What is the problem you have with installing GNU M4?
| >
| >/tmp % mkdir hans                                                nostromo
| >12:21
| >/tmp % cd hans                                                   nostromo
| >12:21
| >/tmp/hans % echo "%%exp: '1' { fprintf (stderr, \"one\\\n\"); };" > hans.y
| >/tmp/hans % bison -o hans.cc hans.y -S bison.c++                 nostromo
| >12:21
| >/tmp/hans % ls -ltr                                              nostromo
| >12:21
| 
| This still does not contain bison.c++ (after run through m4); is it CVS
| Bison that runs the skeleton file through m4 in order to produce multi-file
| output?

This sentence doesn't really make sense.  bison.c++ is fed to m4
together with another m4 file which reflects your parser.  So these
files are what is created after the m4 expansion, _and_ segmentation
by bison.

| Some notes:
| 
| - Why do you use uppercase names, when both C/C++ and Bison/Yacc use lower
| case? For consistent style, I think it should be yy::stack, not yy::Stack.
| (This is what namespaces are for: yy::Stack will not collide with
| std::stack.)

Why not, indeed.  That can change.  I'd call this a minor issue.  I
first would like that we settle an interface, and _then_ we decide for
names etc.  Same for the skeletons names, they are not fixed yet.

| - The operator[] of your stack class should probably use std::advance, so
| that it works will other containers.

Point taken, thanks.  I leave this to Robert (Anisko), who,
unfortunately is a bit busy currently.

| - The standard choice for std::stack is std::deque, perhaps because it for
| some reason is more efficient. So perhaps you should use that default as
| well.

I don't understand your point here.  You suggest that we drop vectors?
I think vectors are certainly more efficient, but you may benchmark it :)
That would be nice input...


Nevertheless, the SGI's STL documentation seems clear: we don't need deque:

        A deque [1] is very much like a vector: like vector, it is a
        sequence that supports random access to elements, constant
        time insertion and removal of elements at the end of the
        sequence, and linear time insertion and removal of elements in
        the middle.

        The main way in which deque differs from vector is that deque
        also supports constant time insertion and removal of elements
        at the beginning of the sequence [2]. Additionally, deque does
        not have any member functions analogous to vector's capacity()
        and reserve(), and does not provide any of the guarantees on
        iterator validity that are associated with those member
        functions. [3]


| - It is more efficient to use only one stack (I did that in my C++ skeleton
| file).

This is really a surprise to me.  I suppose it depends on how heavily
you use $n etc. since you pay an additional indirection for each
member.  It is definitely cuter/simpler with a single stack, but I
expected it to be less efficient.

Anyway, it has a serious impact of the actions (we have to recode the
translation of $n etc.), which we have not language-independentized :)


| - You should use the C++ IO standard streams, not the C compatibility ones
| in <cstdio>. Even though the streams are the same, I think that when using
| both, their buffers must be synchronized (or so I recall); which can cause
| a performance penalty. (I did this change in my skeleton file.)

Correct.  But printf is sooooo much more pleasant...

| - In the case of the zero length rule default action, I think that you can
| change to $$ = YYSTYPE(): Under C++, unlike (old) C, basic types have
| default constructors. -- I think this was added in order to ensure various
| template functions working. So one can just as well assume that the types
| used have such a default constructor.

We are aware of this big problem.  It is to be quicked, indeed.  But I
fear backward compatibility issues here :(  I rely on $$ = $1 being
performed.  I'm not a problem: I _will_ adjust my code.  But I don't
know if out there, some people don't rely on this.