help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %prefix with C++ namespaces


From: Joel E. Denny
Subject: Re: %prefix with C++ namespaces
Date: Mon, 1 Oct 2007 14:46:44 -0400 (EDT)

On Mon, 1 Oct 2007, Hans Aberg wrote:

> On 1 Oct 2007, at 03:10, Joel E. Denny wrote:
> 
> > > Should we accept a leading ::?
> > 
> > I think so.  I see it as redundant but not erroneous.
> 
> So I thought first, but it implies a name relative the global namespace. So if
> the Bison generated parser file is included in a namespace, like in:
>   namespace <name> { ... #include "parser.cc" ... }
> the implementation would formally erroneous, as I don't think it is possible
> to fix it within the C++ limited module handling.
> 
> So that speaks against admitting a leading "::".

We could argue that the generated parser.cc does declare stuff in the 
global namespace as requested.  If the user then contradicts himself by 
trying to wrap the file in another namespace, that's not Bison's fault.

It also occurs to me now that a leading "::" is not completely redundant.  
The given namespace is used in two ways: for declarations and for 
references.  The former needs the splitting we discussed.  I think the 
latter would use the given namespace unaltered.  In that case, the leading 
"::" would reference the global namespace absolutely.  I'm having trouble 
imagining important scenarios where this will actually help disambiguate a 
reference.  However, the C++ compiler would complain in the scenario you 
describe.

On the one hand, it might be nice to give the user the flexibility to do 
as he pleases.  I'm guessing most users wouldn't add the leading "::" 
unless they had a specific reason for it.  On the other hand, maybe we 
should avoid any messy situations this might bring and disallow the 
leading "::" until somebody presents a real scenario in which they need 
it.

What does everyone think?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]