help-bison
[Top][All Lists]
Advanced

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

Re: %prefix with C++ namespaces


From: Hans Aberg
Subject: Re: %prefix with C++ namespaces
Date: Tue, 2 Oct 2007 20:47:28 +0200

On 2 Oct 2007, at 19:55, Joel E. Denny wrote:

I do not think the leading "::"-issue is very important - but it would be
nice
showing one has given thought to it. :-)

So, I'm seeing no reason to disallow it.  If the user wants absolute
references, he should probably get absolute references.

It is OK with me whatever you do. Admitting a leading "::", and merely
stripping it out in the "namespace" nesting seems fine.

Given this comment and given our discussion about how wrapping parser.cc in a namespace probably won't ever work, 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 :-).

Where Bison uses the user-supplied namespace as a reference, I'm now
thinking it should use the same approach.  That is, the outermost
namespace should always be the global namespace. The only way to be sure
of this is for Bison to add a leading "::" if it's not already there.
For example, the C++ skeleton #define's YYSTYPE to a name that starts with the user-supplied namespace. If the user uses YYSTYPE in a scope other than the global scope, the reference might be ambiguous unless the leading
"::" is there.

I suggest don't worry about it: in references, keep it as the user enters it. No obligation approach. This somebody can experiment with it, and perhaps can clarify it better.

The YYSTYPE situation I've described may be rare, but I think it shows why
this approach is cleaner.  If the namespace declarations must assume a
leading "::", then so should the references.  In other words, `%define
namespace "NS"' should consistently interpret NS relative to the global
namespace.

Then you do not have to worry about things like this. Let the C++ compiler take care of it.

  Hans Aberg






reply via email to

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