Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > using keyword in C++

Reply
Thread Tools

using keyword in C++

 
 
MJ_India
Guest
Posts: n/a
 
      03-10-2011
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)
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      03-10-2011
On 3/10/2011 8:00 AM, MJ_India wrote:
> 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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
 
 
 
Joe Greer
Guest
Posts: n/a
 
      03-10-2011
MJ_India <(E-Mail Removed)> wrote in news:2a8c7f36-0cc3-4d35-
http://www.velocityreviews.com/forums/(E-Mail 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 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
 
Reply With Quote
 
MJ_India
Guest
Posts: n/a
 
      03-10-2011
On Mar 10, 10:17*pm, Victor Bazarov <(E-Mail Removed)> wrote:
> On 3/10/2011 8:00 AM, MJ_India wrote:
>
> > 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.
>
> *> 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
> --
> I do not respond to top-posted replies, please don't ask


 
Reply With Quote
 
MJ_India
Guest
Posts: n/a
 
      03-10-2011
On Mar 10, 10:31*pm, Joe Greer <(E-Mail Removed)> wrote:
> MJ_India <(E-Mail Removed)> wrote in news:2a8c7f36-0cc3-4d35-
> (E-Mail 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.
>
> and it would work just as you desire.
>
> joe


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      03-10-2011
On 3/10/2011 8:52 AM, MJ_India wrote:
> On Mar 10, 10:17 pm, Victor Bazarov<(E-Mail Removed)> wrote:
>> On 3/10/2011 8:00 AM, MJ_India wrote:
>>
>>> 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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
RaZiel
Guest
Posts: n/a
 
      03-10-2011
On 10.03.2011 14:52, MJ_India wrote:
> On Mar 10, 10:17 pm, Victor Bazarov<(E-Mail Removed)> wrote:
>> On 3/10/2011 8:00 AM, MJ_India wrote:

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RE: keyword checker - keyword.kwlist Hamilton, William Python 4 05-13-2007 06:31 AM
keyword checker - keyword.kwlist tom@finland.com Python 6 05-10-2007 04:53 PM
Opinion of using "this" keyword on C# ASP.NET pages? Thomas H ASP .Net 6 02-25-2005 08:23 PM
Re: Why does using keyword require a new scope? Jip from Paris ASP .Net 0 08-25-2003 08:02 AM
Re: Why does using keyword require a new scope? Herman Eldering ASP .Net 0 08-23-2003 11:32 PM



Advertisments