traits getProtection

deadalnix deadalnix at gmail.com
Thu Apr 5 15:20:19 PDT 2012


Le 04/04/2012 19:43, Jonathan M Davis a écrit :
> In Posix-land, _everything_ is exported. AFAK, this whole idea of marking
> functions as exported or not is a Windows-only thing. And honestly, it's one
> of my biggest complaints about programming in Windows. It's seriously annoying
> to have to deal with constantly exporting stuff on Windows. On Linux, it
> _just works_. IMHO, shared libraries is one area where Windows seriously
> dropped the ball in comparison to *nix. In my experience, there are _far_
> fewer issues with them on Linux than Windows with its export and its nonsense
> of having to link against a specific version of a static library to be able
> to link against a dynamic one.
>

New version of gcc implemented extensions to not export everything in 
posix world. IIRC, clang provide this as well.

Again, this is an implementation problem and shouldn't be fixed with 
language design decisions.

> Regardless, export is a Windows-only thing and is completely unusable for any
> kind of optimizations in the general case.
>

This is why extensions are made for C/C++ compilers on posix systems.

> Allowing private in interfaces is already getting weird, because of what
> interfaces are for and how they work, and doing so is already arguably special
> casing things. Certainly, the reasons for having private in interfaces is
> _completely_ different from having it in classes. private in interfaces is
> _only_ intended for NVI, whereas NVI is _not_ the reason for having private in
> classes, and in fact is fairly rare thing to do with private. I don't think
> that it's _possible_ to overload private in any language other than C++, and I
> believe that a large number of C++ programmers are completely unaware that
> it's possible in C++. Making private in classes work the same way as it does
> in interfaces would be detrimental to classes just for an idiom which many
> programmers _never_ use (though it _is_ a useful one) - and one which works
> just fine with protected.
>

I understand your point about this being weird in interfaces. Now, 
granted that it is likely to be like this in interfaces, let's make 
things consistent.

> I don't believe that it's currently the plan, but I don't see any problem with
> just making it so that protected is used in interfaces for NVI instead of
> private. As I already pointed out, in C++, the derived classes can already
> call their versions of the NVI functions, since they're private to _them_, not
> the base class, even if they can't call the base class implementation (if
> there even is one), but interfaces don't _have_ a base class implementation,
> so there's nothing to protect from being called anyway. So, using protected
> wouldn't really change anything, and it would be completely consistent with
> how protected is used normally.
>

I have to agree. The difference, as stated in TDPL, is that you cannot 
call the private one, only override it.

>>>> Second, the same method can be declared in the base class and in an
>>>> interface, and in this case, we cause compile error for nothing.
>>>
>>> Why would there be a compilation error? The base class cannot call the
>>> interface's private function, so any reference to that function would be
>>> the base class' function.
>>
>> You have a class C and an interface I, both define the private method foo.
>>
>> In MyClass : C, I, if I define foo, I get an error because foo isn't
>> virtual in C, and if I don't, I don't implement I.
>
> All it has to do is ignore C's private function in MyClass, because it's non-
> virtual and _can't_ be overloaded.
>

This is possible, but this have quite a lot of implication, on 
reflection for instance. What about both being defined in the same 
module, where private stuff are accessible.


More information about the Digitalmars-d mailing list