Ich habe eine Klassenhierarchie, die ungefähr so funktioniert:
%Vor%Wenn ich versuche, mit clang (oder gcc, für diese Angelegenheit) zu kompilieren, gibt es mir die Warnung
%Vor% Was ich verstehe, aber sollte es wirklich diese Warnung geben? Schließlich kann DB nicht einmal die verborgene Funktion sehen (die möglicherweise sogar durch Zufall benannt wird).
Wenn es nicht privat war, konnte ich
verwenden %Vor% um klarzustellen, natürlich, aber die Funktion ist privat, DB weiß nicht einmal darüber, und sollte es sicherlich nicht entlarven.
Gibt es eine Möglichkeit, das zu beheben, ohne diese Warnung zu deaktivieren, d. h. dem Compiler mitzuteilen, dass alles so konzipiert ist, wie es beabsichtigt ist?
Schließlich kann DB nicht einmal die verborgene Funktion sehen (die vielleicht sogar durch Zufall benannt wird).
Zugänglichkeit und Sichtbarkeit sind unterschiedliche Konzepte in C ++. DA::f() ist standardmäßig sichtbar in DB (und dann von DB::f() ausgeblendet), aber es ist nicht zugänglich, da es in DA privat ist und DB nicht a ist Freund von DA . Man könnte argumentieren, dass das Ausblenden einer Funktion, auf die nicht zugegriffen werden kann, harmlos ist, weil sie ohnehin nicht aufgerufen werden kann. Die Unterscheidung zwischen versteckt und unzugänglich kann jedoch erheblich sein, da sichtbare und nicht zugängliche Funktionen an der Überladungsauflösung beteiligt sind. Wenn db ein Objekt vom Typ DB ist, was macht dann db.f(0) ? Wenn DA::f() sichtbar, aber nicht zugreifbar ist, wird es als beste Übereinstimmung ausgewählt, und der Compiler gibt eine Diagnose aus, weil es nicht zugänglich ist und daher nicht aufgerufen werden kann. Wenn DA::f() jedoch ausgeblendet ist, wählt der Compiler stattdessen die Überladung aus, die einen Zeiger akzeptiert, und behandelt das Literal 0 als Nullzeiger.
Was ich (vorerst) getan habe, ist die Verwendung von Komposition statt privater Vererbung. Also sieht mein Code momentan wie
aus %Vor% Ich bin nicht 100% zufrieden, da die d Mitglieder zusätzlichen syntaktischen Overhead verursachen, aber zumindest funktioniert es, ohne die öffentliche Schnittstelle zu ändern.
Tags und Links c++ inheritance g++ clang++