Re: C++.bison

[Akim Demaille]

| At 17:28 +0200 2002/04/19, Akim Demaille wrote:
| >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.
| 
| As I do not have the setup, I merely made a guess: From the stuff you sent
| me, it looked as though a simple -S bison.c++ could produce multiple file
| output. How do you achieve that? Why can't I simply compile the standard
| Bison and then feed a pre-processed bison.c++ skeleton file to that?

Because you need GNU M4, and bison will do that itself.


| I merely point this out, giving you a chance to look it up.

Actually, for reason of work force, I would much prefer argumented
suggestion, as opposed to additional work.


| >| - 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.
| 
| The truth will be revealed by profiling. :-)

Does this sentence implies you did not try?

| The current C stack is like a single stack spread on three block within the
| same allocation. It makes it efficient when re-allocating.
| 
| But if one copies that directly over to C++, one gets three stacks, which
| each will call its own re-allocation function. In addition, push and pop
| will be called two or three time for every stack operation.

We all know all this.  We need facts.



| My Bison version (perhaps "HABison" :-) ) translates $n into YYVSP(yyvsp,
| 1, yylen).

We try hard to avoid relying on macros, as not all languages have
macros.  That's one of the reason we now use M4.  But the general idea
is exactly what we are aiming at.


| Another solution might be to later on integrating M4 with Bison. -- Then
| one lands on my ideas of a "formatter" language for Bison skeleton files.

We don't _need_ to integrate it, calling it from Bison is enough.



| For an official Bison C++ version, in view of the synchronization problem,
| I think you may need a choice: The default would then be the true C++ IO's,
| the C compatibility as a choice.

You misunderstood my point.  Yes, we will use C++ streams.
Nevertheless, I personally prefer printf.  These sentences are not
related.


| Also not that C++ has three standard output streams, std::cout, std::cerr,
| and std::clog, that can be deflected to different output streams. std::cerr
| differs from std::clog in that it may have less buffering.
| 
| Thus user output should go to std::cout, errors to std:cerr and debugging
| to std::clog, I believe.

I don't think it is needed.  Having the logs and err synchronized is
crucial when debugging.


| >| 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.
| 
| Under C++, it makes no difference, as there is no official C++ version out
| there yet: So I think these can be different, keep C as it is (because it
| works under C), and change it for C++.

The point is that the internals of Bison should be language independent.


-- 
Ashamed.