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