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
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison