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.
