Re: [RFC] add push/pop pragma to control the scope of "using"

[Jiang Ma <majiang31312 at gmail dot com>]

Thanks for the kindly reply!
> Why is mytest in the global namespace?
I'm a C++ newbie, and still not used to  put everything into a
namespace. Sorry to bother...

> We try to avoid extensions in gcc, you may want to propose this to the C++
> standard committee first. However, you should first check if modules
> (C++20) affect the issue.
  Thanks for the detailed explanation!  It seems that my situation is
a corner case as normally definitions should be put into a namespace.
So I will not try to bother the C++ standard committee. Thanks you
again for your help!

Marc Glisse <marc.glisse@inria.fr> 于2020年1月15日周三 下午4:32写道：
>
> On Wed, 15 Jan 2020, 马江 wrote:
>
> > Hello,
> >  After  some google, I find there is no way to control the scope of
> > "using" for the moment.  This seems strange as we definitely need this
> > feature especially when writing inline member functions in c++
> > headers.
> >
> >  Currently I am trying to build a simple class in a c++ header file
> > as following:
> >
> > #include <string>
> > using namespace std;
> > class mytest
> > {
> >  string test_name;
> >  int test_val;
> > public:
> >  inline string & get_name () {return test_name;}
> > };
>
> Why is mytest in the global namespace?
>
> >  As a experienced  C coder, I know that inline functions must be put
> > into headers or else users could only rely on LTO. And I know that to
> > use "using" in a header file is a bad idea as it might silently change
> > meanings of other codes. However, after I put all my inline functions
> > into the header file, I found I must write many "std::string" instead
> > of "string" which is totally a torture.
> >  Can we add something like "#pragma push_using"  (just like #pragma
> > pop_macro)? I believe it's feasible and probably not hard to
> > implement.
>
> We try to avoid extensions in gcc, you may want to propose this to the C++
> standard committee first. However, you should first check if modules
> (C++20) affect the issue.
>
> --
> Marc Glisse