Re: %prefix with C++ namespaces

[Hans Aberg]

On 4 Oct 2007, at 05:05, Joel E. Denny wrote:

> > > Given this comment and given our discussion about how wrapping  
> > > parser.cc
> > > in a namespace probably won't ever work
>
> Well, I was wrong about that.  I tried this:
>
>   namespace foo {
>     #include "parser.cc"
>   }
>
> Now I see that it's actually pretty easy to work around the  
> compilation
> problems.  Just #include all standard library headers before the above
> code.

The problems I had in mind are the practical ones: one needs to keep  
track of namespace wrappings as the files are included. A file that  
includes a file doing that may get some unexpected namespace wrappings.

> > > , I think we agree that the leading
> > > "::" is redundant where Bison uses the user-supplied namespace to  
> > > generate
> > > a namespace declaration.  That is, the outermost namespace is  
> > > always the
> > > global namespace.
> >
> > Right. Until somebody finds a well motivation for otherwise :-).
>
> So, I guess my opinion is flipping again because I now see a potential
> motivation.  In scenarios like the above, the namespace declarations
> generated by Bison in parser.cc are *not* rooted at the global  
> namespace,
> and the code compiles fine.

Yes it compiles. But it is a complicated feature, making it hard to  
foresee any potential uses. This motivated my suggestion.

> > I suggest don't worry about it: in references, keep it as the user  
> > enters it.
>
> Agreed.  In the above scenario, relative references to symbols in the
> namespace might be necessary, and Bison shouldn't convert them to  
> absolute
> references.  In other scenarios, the user may need to add the  
> leading "::"
> if he uses Bison-generated references in a different scope.

Yes. Right now, I do not see any good uses of it. But somebody may  
want to try it. So therefore, I think it is best to leave it open. I  
leaves the stuff to the C++ compiler, so it should simplify Bison  
implementation as well.

  Hans Aberg