Using declaration for a namespace name ?

[Timothy Madden]

Hello

I have a header file, generated with flex++, that declares a class
phpFlexLexer in the global namespace.

I would like to include this header in the yy namespaces, like this:

namespace yy
{
#include "FlexLexer.h"
}

so the class would than be yy:hpFlexLexer, but than the standard
headers included by FlexLexer.h would declare symbols in namespace
yy::std
this way. Is there a way to write a using-declaration that brings the
global name std into namespace yy ? So that if I later #include
<iostream>
from namespace yy, than any attempts to populate yy::std would really
populate the global namespace std ?

Or maybe it is just ok to populate yy::std and let things go this way ?

Thank you,
Timothy Madden

 

[Luca Risolia]

Hello

I have a header file, generated with flex++, that declares a class
phpFlexLexer in the global namespace.

I would like to include this header in the yy namespaces, like this:

namespace yy
{
#include "FlexLexer.h"
}

so the class would than be yy:hpFlexLexer, but than the standard
headers included by FlexLexer.h would declare symbols in namespace
yy::std
this way. Is there a way to write a using-declaration that brings the
global name std into namespace yy ? So that if I later #include
<iostream>

Cannot you modify FlexLexer.h, after it has been generated, for e.g.

// FlexLexer.h

#include <iostream>

namespace yy {
using namespace std;
// any FlexLexer-related declaration using symbols in std::
}

 

[Timothy Madden]

Cannot you modify FlexLexer.h, after it has been generated, for e.g.

// FlexLexer.h

#include <iostream>

namespace yy {
using namespace std;
// any FlexLexer-related declaration using symbols in std::
}

If I modify the file after it has been generated, than I would have to
modify it after each and every time it is generated.

My question is how to bring the name `std`, into my yy namespace, and
only that name. That using-declaration you showed me would bring in the
entire content of the std namespace (which is not what I want).

What I would like is to do something like this:

namespace std
{
}

namespace yy
{
using ::std;
#include <iostream>
}

That way, the included <iostream> would populate namespace ::std,
although it is included from namespace yy;

My question is if the using ::std; statement is correct in C++ and would
work as expected, or if there is a better alternative to it.

Thank you,
Timothy Madden

 

[Victor Bazarov]

Hello

I have a header file, generated with flex++, that declares a class
phpFlexLexer in the global namespace.

I would like to include this header in the yy namespaces, like this:

namespace yy
{
#include "FlexLexer.h"
}

That's A Bad Idea(tm). Why don't you include that header from within
another class defined in a function inside a macro expansion?

so the class would than be yy:hpFlexLexer, but than the standard
then

headers included by FlexLexer.h would declare symbols in namespace
yy::std

Would they? Perhaps it's a bad implementation. Why can't they declare
the symbos in ::std? Of course, normal library implementers rarely
write their headers to overcome inclusion inside another namespace...
because nobody writes it that way!

this way. Is there a way to write a using-declaration that brings the
global name std into namespace yy ? So that if I later #include
<iostream>
from namespace yy, than any attempts to populate yy::std would really
populate the global namespace std ?

I don't know of any way. Maybe a namespace alias?...

namespace yy {
namespace std = ::std;
...
}

Or maybe it is just ok to populate yy::std and let things go this way ?

So, you're saying that you haven't even tried?

V

 

[Victor Bazarov]

If I modify the file after it has been generated, than I would have to
modify it after each and every time it is generated.

Right. If you let some tool generate your headers, what stops you from
writing your own tool that, after the other tools is done generating the
header, makes a slight modification to it?

My question is how to bring the name `std`, into my yy namespace, and
only that name. That using-declaration you showed me would bring in the
entire content of the std namespace (which is not what I want).

What I would like is to do something like this:

namespace std
{
}

namespace yy
{
using ::std;

I'd try

namespace std = ::std;

#include<iostream>
}

That way, the included<iostream> would populate namespace ::std,
although it is included from namespace yy;

My question is if the using ::std; statement is correct in C++

No, since 'std' is not an entity name, it's a namespace.

and would
work as expected, or if there is a better alternative to it.

Perhaps a better alternative is to add your modification into the
generation of the header toolchain.

V

 

[Timothy Madden]

That's A Bad Idea(tm). Why don't you include that header from within
another class defined in a function inside a macro expansion?


Would they? Perhaps it's a bad implementation. Why can't they declare
the symbos in ::std? Of course, normal library implementers rarely write
their headers to overcome inclusion inside another namespace... because
nobody writes it that way!


I don't know of any way. Maybe a namespace alias?...

namespace yy {
namespace std = ::std;
...
}



So, you're saying that you haven't even tried?

V

I know my #include inside a namespace is a bad idea, but flex has no
namespaces for its C++ interface, so the bad idea is all I can try to
get it.

Well I tried the namespace alias, and the compiler accepted the
statement, but I still get errors later in the included system headers
this way. So I resorted to making sure that I include any headers needed
by FlexLexer.h before I open yy namespace. That way, when FlexLexer.h
includes them, their include guards would simply skip all their content.

And yes, I have not even tried until now, because I am just learning
flex and bison, and believe me, trying to integrate them with their C++
interface, for the first time, is not fun!

Thank you,
Timothy Madden

 

[Rui Maciel]

I know my #include inside a namespace is a bad idea, but flex has no
namespaces for its C++ interface, so the bad idea is all I can try to
get it.

Why not file a bug report describing your problem? This appears to be an
important issue, which might affect a considerable number of users, and may
not be that hard to implement.


Rui Maciel

 

[Timothy Madden]

Why not file a bug report describing your problem? This appears to be an
important issue, which might affect a considerable number of users, and may
not be that hard to implement.

You mean a report for flex to support C++ in a proper way ? I posted a
question on gmane.comp.lex.flex.general, only to find out flex is no
longer being developed (only some minimal maintenance).

Trying to ask on gmain.comp.parsers.bison.general for an alternative to
flex I got no response, so I think there is none.

Anyway flex seem to lack even support for Unicode, which in my opinion
is much worse than lack of C++ namespaces.

http://thread.gmane.org/gmane.comp.lex.flex.general/2994
http://thread.gmane.org/gmane.comp.lex.flex.general

http://news.gmane.org/gmane.comp.parsers.bison.general

Thank you,
Timothy Madden

 

[Victor Bazarov]

[..] I posted a
question on gmane.comp.lex.flex.general, only to find out flex is no
longer being developed (only some minimal maintenance).

Trying to ask on gmain.comp.parsers.bison.general for an alternative to
flex I got no response, so I think there is none.

Anyway flex seem to lack even support for Unicode, which in my opinion
is much worse than lack of C++ namespaces.

http://thread.gmane.org/gmane.comp.lex.flex.general/2994
http://thread.gmane.org/gmane.comp.lex.flex.general

http://news.gmane.org/gmane.comp.parsers.bison.general

Seems like you're better off putting aside tools that don't work and
aren't supported/developed any longer, and turn your sights to the tools
that do and are. I am certain that if there is a need in the tools like
flex or bison, there are replacements. Good luck!

V

 

[Jorgen Grahn]

[..] I posted a
question on gmane.comp.lex.flex.general, only to find out flex is no
longer being developed (only some minimal maintenance).

Trying to ask on gmain.comp.parsers.bison.general for an alternative to
flex I got no response, so I think there is none.

Anyway flex seem to lack even support for Unicode, which in my opinion
is much worse than lack of C++ namespaces.

http://thread.gmane.org/gmane.comp.lex.flex.general/2994
http://thread.gmane.org/gmane.comp.lex.flex.general

http://news.gmane.org/gmane.comp.parsers.bison.general

Seems like you're better off putting aside tools that don't work and
aren't supported/developed any longer, and turn your sights to the tools
that do and are.

Just to clarify: noone in the referenced thread said flex isn't
maintained, just that it does "not currently have active developers".
Not surprising: apart from non-ASCII support there are probably not
too many interesting features left to implement after ~25 years.

(And to reiterate what I wrote here earlier: I wouldn't touch its
ancient experimental C++ code generator with a ten-foot pole.)

I am certain that if there is a need in the tools like
flex or bison, there are replacements. Good luck!

If flex is good enough for enough people, that might be a problem.

Also, since the heyday of lexers in the 1980s, CPU power had become
very cheap and powerful regex libraries and scripting languages have
become common. This is just speculation, but that may be another force
working against it.

But as Victor writes: good luck!

/Jorgen

 

[Jeff Flinn]

[..] I posted a
question on gmane.comp.lex.flex.general, only to find out flex is no
longer being developed (only some minimal maintenance).

....

(And to reiterate what I wrote here earlier: I wouldn't touch its
ancient experimental C++ code generator with a ten-foot pole.)

I am certain that if there is a need in the tools like
flex or bison, there are replacements. Good luck!

If flex is good enough for enough people, that might be a problem.

Also, since the heyday of lexers in the 1980s, CPU power had become
very cheap and powerful regex libraries and scripting languages have
become common. This is just speculation, but that may be another force
working against it.

Or use boost spirit qi to directly access ebnf/peg parsing technology
directly from C++.

Jeff