On Mon, 8 Oct 2007, Akim Demaille wrote:
>
> Le 8 oct. 07 à 12:10, Joel E. Denny a écrit :
>
> > Improve C++ namespace support.
>
> Impressive work. Your m4fu is quite mature. How about
> maintaining Autoconf? ;)
Thanks! I wish I had more time for free software.
Le 8 oct. 07 à 12:10, Joel E. Denny a écrit :
Improve C++ namespace support.
Impressive work. Your m4fu is quite mature. How about
maintaining Autoconf? ;)
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
On Sat, 29 Sep 2007, Sebastian Pipping wrote:
> (2) Nested namespaces do not work:
> %prefix=abc::def should give
>
> namespace abc {
> namespace def {
> ..
> }
> }
>
> instead of
>
> namespace abc::def {
> ..
> }
>
> I guess?
I
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 eas
On Tue, 2 Oct 2007, Hans Aberg 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
On 2 Oct 2007, at 21:43, Akim Demaille wrote:
If, as in one of your
scenarios, we are enclosed in nested "namespace foo { ... }", afaik,
we can't use "namespace ::bar { ... }" to escape them.
Or maybe I have missed something in the thread?
I would just strip it.
When creating namespace nam
Le 2 oct. 07 à 19:55, Joel E. Denny a écrit :
On Tue, 2 Oct 2007, Hans Aberg 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 s
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.
On Tue, 2 Oct 2007, Hans Aberg 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 absol
On 2 Oct 2007, at 07:03, Joel E. Denny wrote:
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 namespac
Sebastian Pipping wrote:
Joel E. Denny wrote:
I figured the namespace name is meant to be relative to the global
namespace, so a leading "::" is implicit if not specified.
I'm not sure if this is true. Could it be that without "::"
it's relative to the namespace the call was made from instead
o
On Mon, 1 Oct 2007, Sebastian Pipping wrote:
> Joel E. Denny wrote:
> > Well, if we document how the splitting is done, then I figure they can't
> > complain too much. I certainly don't want to see Bison parse complex C++
> > constructs. Let the C++ compiler catch those errors.
>
> Wouldn't it
On Mon, 1 Oct 2007, Hans Aberg wrote:
> > 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 namesp
On 1 Oct 2007, at 20:46, 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:
namespac
Joel E. Denny wrote:
Well, if we document how the splitting is done, then I figure they can't
complain too much. I certainly don't want to see Bison parse complex C++
constructs. Let the C++ compiler catch those errors.
Wouldn't it be both easy and powerful to solve that namespace thing
usin
Joel E. Denny wrote:
If we start "parsing" namespace names, we will have a million
new questions to answer. What is the output of "::foo",
I figured the namespace name is meant to be relative to the global
namespace, so a leading "::" is implicit if not specified.
I'm not sure if this is tr
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 par
Joel E. Denny wrote:
>> (1) %prefix=abc renames function yylex to "abclex"
>> instead of putting it in namespace abc.
>
> You can write:
>
> %name-prefix="abc::"
> %define "namespace" "abc"
Works like a charm, thank you!
Sebastian
___
help-
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:
namesp
On Sun, 30 Sep 2007, Akim Demaille wrote:
>
> Le 30 sept. 07 ? 09:00, Joel E. Denny a ?crit :
>
> > > "foo::", etc.?
> >
> > This seems like an error to me.
>
> Sure! But who should catch it?
We have facilities for the skeletons to call warn, complain, or fatal.
> Should we accept a leading
On 30 Sep 2007, at 10:37, Akim Demaille wrote:
Should we accept a leading ::?
Strictly speaking, I think that a leading :: implies that it is
relative the (top level) global namespace, like an absolute path in a
UNIX filesystem. So if that is not implementable, it should generate
an erro
On 30 Sep 2007, at 09:00, Joel E. Denny wrote:
If we start "parsing" namespace names, we will have a million
new questions to answer. What is the output of "::foo",
I figured the namespace name is meant to be relative to the global
namespace, so a leading "::" is implicit if not specified.
On 30 Sep 2007, at 08:15, Akim Demaille wrote:
(1) %prefix=abc renames function yylex to "abclex"
instead of putting it in namespace abc.
Well, that was on purpose, to match the lex interface.
I'm unsure it is wise to invite the scanner into the
parser's namespace: we might have to deal wi
Le 30 sept. 07 à 09:00, Joel E. Denny a écrit :
"foo::", etc.?
This seems like an error to me.
Sure! But who should catch it? Should we accept a leading ::?
Other than that, isn't it just a matter of splitting on "::"? Am I
forgetting something?
No, I don't think you do, it's just th
On Sun, 30 Sep 2007, Akim Demaille wrote:
> > (2) Nested namespaces do not work:
> > %prefix=abc::def should give
> >
> > namespace abc {
> > namespace def {
> > ..
> > }
> > }
> >
> > instead of
> >
> > namespace abc::def {
> > ..
> >
Le 29 sept. 07 à 04:06, Sebastian Pipping a écrit :
Hello Bison people!
I noticed two things with %prefix when combined
with a C++ parser that might be bugs:
(1) %prefix=abc renames function yylex to "abclex"
instead of putting it in namespace abc.
Well, that was on purpose, to match
On Sat, 29 Sep 2007, Sebastian Pipping wrote:
> I noticed two things with %prefix when combined
> with a C++ parser that might be bugs:
>
>
> (1) %prefix=abc renames function yylex to "abclex"
> instead of putting it in namespace abc.
You can write:
%name-prefix="abc::"
%define "namesp
On 29 Sep 2007, at 04:06, Sebastian Pipping wrote:
I noticed two things with %prefix when combined
with a C++ parser that might be bugs:
(1) %prefix=abc renames function yylex to "abclex"
instead of putting it in namespace abc.
You are right, it should be in a namespace, though I think i
Hello Bison people!
I noticed two things with %prefix when combined
with a C++ parser that might be bugs:
(1) %prefix=abc renames function yylex to "abclex"
instead of putting it in namespace abc.
(2) Nested namespaces do not work:
%prefix=abc::def should give
namespace abc {
29 matches
Mail list logo
