using keyword in C++

[MJ_India]

struct foo { static const int bar = 0; };
int baz() {
using foo::bar; // [1]
return bar; // [2]
}

[1] is invalid in standard C++ because standard C++ allows _using_
keyword only in 3 ways (For namespace, a member of namespace or in
derived classes to avoid shadowing or to increase privateness of
inherited member)

To make statement [2] work without fully qualified name I need some
workaround(a reference or define).

My question is, what is the advantage of not allowing [1] as valid C++
grammar?
I sometimes think allowing [1] may be useful in some scenarios and
cannot think of a reason why it was decided incorrect. Only advantage
I see here is, it makes compiler implementation little easy (Does it
really? may be.)
But I don't think this is one of the possible answer for my question,
considering C++ complexities. (generic programming etc)

 

[Victor Bazarov]

struct foo { static const int bar = 0; };
int baz() {
using foo::bar; // [1]
return bar; // [2]
}

[1] is invalid in standard C++ because standard C++ allows _using_
keyword only in 3 ways (For namespace, a member of namespace or in
derived classes to avoid shadowing or to increase privateness of
inherited member)

To make statement [2] work without fully qualified name I need some
workaround(a reference or define).

I would like to see a reason to prefer

<some trick to bring foo::bar into scope>
return bar;

over

return foo::bar;

.. Please provide it.

My question is, what is the advantage of not allowing [1] as valid C++
grammar?

The advantage is simplification of the language.

I sometimes think allowing [1] may be useful in some scenarios

Name at least one, please.

and
cannot think of a reason why it was decided incorrect. Only advantage
I see here is, it makes compiler implementation little easy (Does it
really? may be.)
But I don't think this is one of the possible answer for my question,
considering C++ complexities. (generic programming etc)

Huh?

V

 

[Joe Greer]

struct foo { static const int bar = 0; };
int baz() {
using foo::bar; // [1]
return bar; // [2]
}

[1] is invalid in standard C++ because standard C++ allows _using_
keyword only in 3 ways (For namespace, a member of namespace or in
derived classes to avoid shadowing or to increase privateness of
inherited member)

To make statement [2] work without fully qualified name I need some
workaround(a reference or define).

My question is, what is the advantage of not allowing [1] as valid C++
grammar?
I sometimes think allowing [1] may be useful in some scenarios and
cannot think of a reason why it was decided incorrect. Only advantage
I see here is, it makes compiler implementation little easy (Does it
really? may be.)
But I don't think this is one of the possible answer for my question,
considering C++ complexities. (generic programming etc)

I can't give any sort of official answer, but it seems to me that items
that are declared in a struct/class should have a special association
with that struct/class and shouldn't be manipulated outside of it without
going through some pains. If you just want a global, you should put the
variable in a namespace and then the using would work as you desire.
That is, there is no reason for the above example that it couldn't be
written as:

namespace foo {
const int bar = 0;
}
int baz() {
using foo::bar;
return bar;
}

and it would work just as you desire.

joe

 

[MJ_India]

struct foo { static const int bar = 0; };
int baz() {
     using foo::bar;    // [1]
     return bar;          // [2]
}

[1] is invalid in standard C++ because standard C++ allows _using_
keyword only in 3 ways (For namespace, a member of namespace or in
derived classes to avoid shadowing or to increase privateness of
inherited member)

To make statement [2] work without fully qualified name I need some
workaround(a reference or define).

I would like to see a reason to prefer

     <some trick to bring foo::bar into scope>
     return bar;

over

     return foo::bar;

.  Please provide it.

1. Okay, it is analogous to some_member over
a_namespace_name::some_member. (Which is allowed)
2. It can sometimes increase readability.

My question is, what is the advantage of not allowing [1] as valid C++
grammar?

The advantage is simplification of the language.

I sometimes think allowing [1] may be useful in some scenarios

Name at least one, please.

There are 2 classes I can not change.
class CPdf {
public:
static const performance_parameter_01 = 0;
...
};

class CDoc {
public:
static const performance_parameter_01 = 100;
static const performance_parameter_02 = 200;
...
};

namespace default_parameter {
static const performance_parameter_01 = 50;
static const performance_parameter_02 = 250;
}

using namespace default_parameter;
result viewer(CPdf &pdf) {
using CPdf:erformance_parameter_01;
...
TunePerformance(performance_parameter_01, performance_parameter_02);
...
}

result viewer(CDoc &doc) {
using CDoc:erformance_parameter_01;
using CDoc:erformance_parameter_02;
...
TunePerformance(performance_parameter_01, performance_parameter_02);
...
}

I don't remember exact scenario, but it happened long back.
I was using some library and I felt if I can write some code like
above, it was more readable.
But I ended up writing many big named classes, sub classes, final
members and many scope resolution operators because of the code layout
of that module writer and lack of using class_name::member.

 

[MJ_India]

(e-mail address removed):

struct foo { static const int bar = 0; };
int baz() {
    using foo::bar;    // [1]
    return bar;          // [2]
}

[1] is invalid in standard C++ because standard C++ allows _using_
keyword only in 3 ways (For namespace, a member of namespace or in
derived classes to avoid shadowing or to increase privateness of
inherited member)

To make statement [2] work without fully qualified name I need some
workaround(a reference or define).

My question is, what is the advantage of not allowing [1] as valid C++
grammar?
I sometimes think allowing [1] may be useful in some scenarios and
cannot think of a reason why it was decided incorrect. Only advantage
I see here is, it makes compiler implementation little easy (Does it
really? may be.)
But I don't think this is one of the possible answer for my question,
considering C++ complexities. (generic programming etc)

I can't give any sort of official answer, but it seems to me that items
that are declared in a struct/class should have a special association
with that struct/class and shouldn't be manipulated outside of it without
going through some pains.  If you just want a global, you should putthe

Thinking this (↑) way helped me to resolve my confusion. Thank you for
the above paragraph.

variable in a namespace and then the using would work as you desire.  
That is, there is no reason for the above example that it couldn't be
written as:

namespace foo {
   const int bar = 0;}

int baz() {
   using foo::bar;
   return bar;

}

Actually I cooked a minimal example to demonstrate my question.
After bar, foo may be continue to be a complex class containing all
possible type of members.

 

[Victor Bazarov]

struct foo { static const int bar = 0; };
int baz() {
using foo::bar; // [1]
return bar; // [2]
}

[1] is invalid in standard C++ because standard C++ allows _using_
keyword only in 3 ways (For namespace, a member of namespace or in
derived classes to avoid shadowing or to increase privateness of
inherited member)

To make statement [2] work without fully qualified name I need some
workaround(a reference or define).

I would like to see a reason to prefer

<some trick to bring foo::bar into scope>
return bar;

over

return foo::bar;

. Please provide it.

1. Okay, it is analogous to some_member over
a_namespace_name::some_member. (Which is allowed)
2. It can sometimes increase readability.

Use references. Like

const int& bar = foo::bar;
..
return bar;

There, I just increased readability. Or did I? How is hiding the
source of 'bar' symbol increasing readability? No, really. How?

My question is, what is the advantage of not allowing [1] as valid C++
grammar?

The advantage is simplification of the language.

I sometimes think allowing [1] may be useful in some scenarios

Name at least one, please.

There are 2 classes I can not change.
class CPdf {
public:
static const performance_parameter_01 = 0;
...
};

class CDoc {
public:
static const performance_parameter_01 = 100;
static const performance_parameter_02 = 200;
...
};

namespace default_parameter {
static const performance_parameter_01 = 50;
static const performance_parameter_02 = 250;
}

using namespace default_parameter;
result viewer(CPdf&pdf) {
using CPdf:erformance_parameter_01;
...
TunePerformance(performance_parameter_01, performance_parameter_02);
...
}

result viewer(CDoc&doc) {
using CDoc:erformance_parameter_01;
using CDoc:erformance_parameter_02;
...
TunePerformance(performance_parameter_01, performance_parameter_02);
...
}

Which part of this is yours and which part can't you change?

I don't remember exact scenario, but it happened long back.
I was using some library and I felt if I can write some code like
above, it was more readable.

Well, readability in the eye of the beholder. Besides, there are other
ways to make the code more readable, like giving meaningful names to
variables.

But I ended up writing many big named classes, sub classes, final
members and many scope resolution operators because of the code layout
of that module writer and lack of using class_name::member.

The code was apparently awful to begin with (from your readability
standpoint). Adding a couple of scope resolution operators (qualifying
some names to help compiler resolve them) didn't really hurt it, did it?

V

 

[RaZiel]

There are 2 classes I can not change.
class CPdf {
public:
static const performance_parameter_01 = 0;
...
};

class CDoc {
public:
static const performance_parameter_01 = 100;
static const performance_parameter_02 = 200;
...
};

namespace default_parameter {
static const performance_parameter_01 = 50;
static const performance_parameter_02 = 250;
}

using namespace default_parameter;
result viewer(CPdf&pdf) {
using CPdf:erformance_parameter_01;
...
TunePerformance(performance_parameter_01, performance_parameter_02);
...
}

result viewer(CDoc&doc) {
using CDoc:erformance_parameter_01;
using CDoc:erformance_parameter_02;
...
TunePerformance(performance_parameter_01, performance_parameter_02);
...
}

I don't remember exact scenario, but it happened long back.
I was using some library and I felt if I can write some code like
above, it was more readable.
But I ended up writing many big named classes, sub classes, final
members and many scope resolution operators because of the code layout
of that module writer and lack of using class_name::member.

I'm sure you don't want to make a copy, but why don't you use a const
reference?

int& const performance_parameter_01 = CDoc:erformance_parameter_01;


- RaZiel