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

[Jiang Ma <majiang31312 at gmail dot com>]

Thanks  for the kindly reply!
> It would create a non-standard, non-portable dialect of C++. We prefer
> to avoid adding non-standard extensions these days. You could propose
>it to the C++ committee, but I'm pretty sure they would not want such
>a thing.
  Indeed, pragma is not portable.  I believe you are right that the
C++ committee would not want such a thing   :-)

> This doesn't have all the problems of "using namespace" in a header.
  Yes, This is a workaround I have considered.  I'm a C++ newbie, and
still not used to  put everything into a namespace. But I am agree
this probably is the best way.

Thanks again for your help!

Jonathan Wakely <jwakely.gcc@gmail.com> 于2020年1月15日周三 下午5:37写道：
>
> On Wed, 15 Jan 2020 at 08:15, 马江 <majiang31312@gmail.com> 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;}
> > };
> >
> >   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.
>
> It's really not that bad.
>
> >   Can we add something like "#pragma push_using"  (just like #pragma
> > pop_macro)? I believe it's feasible and probably not hard to
> > implement.
>
> It would create a non-standard, non-portable dialect of C++. We prefer
> to avoid adding non-standard extensions these days. You could propose
> it to the C++ committee, but I'm pretty sure they would not want such
> a thing.
>
> You can already do it anyway, if you put your own code in a namespace
> (which is a good idea anyway):
>
> #include <string>
>
> namespace foo
> {
>   using std::string;
>   class bar
>   {
>   string name_;
>   public
>     const string& name() const noexcept { return name_; }
>   };
> }
>
> This doesn't have all the problems of "using namespace" in a header.