This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] add push/pop pragma to control the scope of "using"
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: 马江 <majiang31312 at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 15 Jan 2020 09:37:02 +0000
- Subject: Re: [RFC] add push/pop pragma to control the scope of "using"
- References: <CAL2ChXcC_CB=3YXT9vdfeHTCYkEq9Q9jkFPPnQQyPzX5-8r0dA@mail.gmail.com>
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.