rationale for hiding data/function members and idea to add a "hide" keyword.

[Vicente J. Botet Escriba]

Hi,

Could someone give me a good use case, the rationale, for hiding data members

http://melpon.org/wandbox/permlink/mXshdsg9A3dY53Jn

I understand that the language allows shadowing a variable in an inner scope of a function, but hiding base data members seems to me more risky.

In the same way we have override when we are overriding a virtual function and we will get an error if there is no virtual function to override, we could have some kind of "hide"  data member. The compiler could then report a warning when the data member is hidden without an explicit "hide".

I believe the same could apply to hidden overloaded functions.

Vicente

[D. B.]

Surely the rationale is that shadowing occurs by the innermost symbol of any outer ones, just like in any other context.

The problem then is one of QoI, as frequently, not an issue - and certainly not an inconsistency - with the language.

[Ville Voutilainen]

On 11 January 2017 at 09:08, Vicente J. Botet Escriba

See http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2852.html
and in particular the [[hiding]] part. The later paper
http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.htm
provides the current context-sensitive keyword approach, from which the
"new" part was dropped before C++11 shipped. Mostly because
1) it wasn't requested by NBs
2) it's deemed far less necessary
3) implementations already warn
4) it's a lot of work specification-wise and implementation-wise to provide both
a way to check for hiding and to selectively turn it off, for
questionable benefit.

[Vicente J. Botet Escriba]

Le 11/01/2017 à 10:36, Ville Voutilainen a écrit :
> On 11 January 2017 at 09:08, Vicente J. Botet Escriba
> <vicent...@wanadoo.fr> wrote:
>> Hi,
>>
>>
>> Could someone give me a good use case, the rationale, for hiding data
>> members
>>
>> http://melpon.org/wandbox/permlink/mXshdsg9A3dY53Jn
>>
>> I understand that the language allows shadowing a variable in an inner scope
>> of a function, but hiding base data members seems to me more risky.
>>
>> In the same way we have override when we are overriding a virtual function
>> and we will get an error if there is no virtual function to override, we
>> could have some kind of "hide" data member. The compiler could then report
>> a warning when the data member is hidden without an explicit "hide".
>>
>> I believe the same could apply to hidden overloaded functions.
>
> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2852.html
> and in particular the [[hiding]] part. The later paper
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.htm
> provides the current context-sensitive keyword approach, from which the
> "new" part was dropped before C++11 shipped.

Thanks Ville. The "new" specifier corresponds quite closely to what I
was looking for.
Glad to see other had the same concern.

> Mostly because
> 1) it wasn't requested by NBs
> 2) it's deemed far less necessary

I agree it is a less usual error.
> 3) implementations already warn
Could you tell me which flags I need with gcc or clang to get a warning
in this case.

> 4) it's a lot of work specification-wise and implementation-wise to provide both
> a way to check for hiding and to selectively turn it off, for
> questionable benefit.
>

I'm sure this would some work, but given that there were already some
wording and that compilers are already reporting warnings, doesn't this
means that the works is almost already done for the big part?


Vicente

[Ville Voutilainen]

On 11 January 2017 at 20:30, Vicente J. Botet Escriba

<vicent...@wanadoo.fr> wrote:
>> 3) implementations already warn
>
> Could you tell me which flags I need with gcc or clang to get a warning in
> this case.

I don't know. See for example
https://msdn.microsoft.com/en-us/library/4b76ty10.aspx

>>
>> 4) it's a lot of work specification-wise and implementation-wise to
>> provide both
>> a way to check for hiding and to selectively turn it off, for
>> questionable benefit.
> I'm sure this would some work, but given that there were already some
> wording and that compilers are already reporting warnings, doesn't this
> means that the works is almost already done for the big part?

I would guess there are large parts of the work not done, especially
if you want to provide
the "check hiding declarations in this class" facility, and you want
to support members that
are not member functions. That was also a reason to drop that part, we
didn't think we have
enough time to do all that work for C++11, and doubted the benefit.

[Arthur O'Dwyer]

Sounds like maybe a place for a compiler warning, but I don't see any reason to change the language here.

Can you explain a bit more about what behavior you expected from that test case?

B defines an "a = new A()" but does not use it

C defines an "a = nullptr" and then calls "a->test()", which of course is UB

I also tried the obvious mutation of your code, which is to move the definition of doit() into B. Then:

B defines an "a = new A()" and then calls "a->test()", which works fine

C defines an "a = nullptr" but does not use it

Nothing unexpected happened.

It would be surprising to me if C's definition of "a" were somehow accessible within B (without the `virtual` keyword, anyway); but that didn't happen, so I wasn't surprised.

What did you expect, and what was the surprising observation?

–Arthur

[D. B.]

On Wed, Jan 11, 2017 at 6:30 PM, Vicente J. Botet Escriba <vicent...@wanadoo.fr> wrote:

3) implementations already warn

Could you tell me which flags I need with  gcc or clang to get a warning in this case.

At a guess, -Wshadow ?

[Ville Voutilainen]

No, but by all means keep on guessing if you think that's somehow entertaining.

[D. B.]

Wow, sorry for trying. I used that to reveal some warnings about shadowing in certain scopes, where I can't currently be sure whether those included member variables, and although I couldn't test it right now thought I'd post it in case it included class members and would be useful.

I won't bother trying next time.

[Edward Catmur]

On Thursday, 12 January 2017 07:12:11 UTC, D. B. wrote:

Wow, sorry for trying. I used that to reveal some warnings about shadowing in certain scopes, where I can't currently be sure whether those included member variables, and although I couldn't test it right now thought I'd post it in case it included class members and would be useful.

For the record: -Wshadow (clang, gcc, icc) and C4458 (MSVC) warn on local variables shadowing various names including class non-static data members. They do not warn on derived class NSDMs shadowing base class NSDMs.

At the risk of throwing some cold water on the thread, I think that if compiler vendors are not supplying warnings for derived-base NSDM shadowing/hiding that suggests that it is not considered much of a problem in practice. 

[Vicente J. Botet Escriba]

Le 12/01/2017 à 15:48, edward...@mavensecurities.com a écrit :

On Thursday, 12 January 2017 07:12:11 UTC, D. B. wrote:

Wow, sorry for trying. I used that to reveal some warnings about shadowing in certain scopes, where I can't currently be sure whether those included member variables, and although I couldn't test it right now thought I'd post it in case it included class members and would be useful.

For the record: -Wshadow (clang, gcc, icc) and C4458 (MSVC) warn on local variables shadowing various names including class non-static data members. They do not warn on derived class NSDMs shadowing base class NSDMs.

Thanks, this is what I was aware of.

At the risk of throwing some cold water on the thread, I think that if compiler vendors are not supplying warnings for derived-base NSDM shadowing/hiding that suggests that it is not considered much of a problem in practice.

You are surely right. I've found this kind of hiding code only once in my life.

I believe I would have to satisfy myself with a clang-tidy check.

Vicente