Path: csiph.com!xmission!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 12 Aug 2015 13:10:02 -0500
Sender: std-cpp-request@vandevoorde.com
Approved: james.dennett@gmail.com
Message-ID: <NZKdnQZa84VGn1bInZ2dnUU78dGdnZ2d@giganews.com>
Newsgroups: comp.std.c++
From: Jakob Bohm <jb-usenet@wisemo.com>
Subject: Re: Shouldn't there be a way to exclude member functions out of name lookup explicitly?
Organization: WiseMo A/S
References: <820594f6-b670-4dba-8254-26d352489616@googlegroups.com> <5e134e90-067e-4d71-bf40-c4396bfc52f4@googlegroups.com> <31d52d8d-796a-4b61-8e56-6da52f2136be@googlegroups.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Date: Wed, 12 Aug 2015 13:00:41 CST
Lines: 85
Xref: csiph.com comp.std.c++:768


On 02/08/2015 05:09, Johannes Gerd Becker wrote:

>
> Of course, defining a helper function outside the class is a workaround (=
as
> is first defining a base class, as described in my original post).
>
> The point I would like to make, however, is another one.
>
> There are workarounds, yet they get the more tedious the more often the
> problem arises, namely in templated code. (To begin with: templates live
> mostly in headers, so the helper functions must live in headers as well,
> and break encapsulation, pollute my namespace or are simply inconvenient =
as
> they have to be templates themselves).
>
> It seems consensus (more or less) now that non-member functions defined i=
n
> the same namespace as a class are part of the interface of that class,
> BECAUSE they will usually be found by ADL.
>
> Now the rule that, within a member function of some class, say B, member
> functions of B take absolute precendence when a name is looked up, has th=
e
> unwanted effect that some part of the interface of another, completely
> unrelated class A, namely the nonmember functions that belong to the
> interface of A, may become unusable from within B.
>
> Why can I write
>
> using namespace std;
> auto i = begin (vec);
>
> everywhere in my code, yet not within a class that has a member function
> named begin ()?
>
> I tempted to think this should be considered a design mistake.
>
> One could think of several approaches to solve that problem:
>
> 1.) Introduce a clause like
>
> using explicit this;
>
> which would locally force explicitly using this-> when you want to access=
 a
> member. Then I would write
>
> using namespace std;
> using explicit this;
> auto i = begin (vec); // ADL
> auto j = this->begin (); // member
>
> 2.) Introduce a special qualifier (like, e.g., .::) to indicate that the
> following name does *not* refer to a member function. Then I could write
>
> using namespace std;
> auto i = .::begin (vec); // ADL
> auto j = begin (); // member
>
>
Doesn't the existing :: qualifier do this already:

auto i == ::begin(vec); // ADL

Or did I miss some unfortunate interaction with the way named namespaces
were formally added to the language?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S=C3=B8borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]