Unterdrückend "Basisklasse 'Klasse X' sollte im Kopierkonstruktor explizit initialisiert werden" aus Bibliothekskopf für Vorlagenklasse

9

Ich habe ein ähnliches Problem wie diesen .

Ich verwende eine Drittanbieter-Bibliothek. Es definiert Klassen wie hier (fälscht alle Namen aufgrund von Lizenzproblemen), in der Datei headers/things.h :

%Vor%

Zusätzlich noch im Header der Bibliothek:

%Vor%

Die Fehlermeldung lautet:

%Vor%

In things.cpp habe ich:

%Vor%

Dateilayout ist:

%Vor%

Ich bin mir bewusst, was diese Warnung bedeutet, und darum bitte ich nicht. Da es in einer Third-Party-Bibliothek ist, zögere ich sehr, es aus Wartungsgründen zu modifizieren (zu reparieren). Ich möchte diese Warnung einfach ignorieren.

Ich kompiliere meinen Code mit:

%Vor%

Ich verwende -isystem für die Angabe des Verzeichnisses, weil die gcc-Dokumente Folgendes angeben:

  

Alle Warnungen, die nicht durch "#warning" (siehe Diagnose) generiert wurden, werden unterdrückt, während GCC einen Systemheader verarbeitet.   (...)   Die Befehlszeilenoption -isystem fügt der Liste der Verzeichnisse, in denen nach Kopfzeilen gesucht wird, ihr Argument hinzu, genau wie -I. Alle Header in diesem Verzeichnis werden als Systemheader betrachtet.

Dies scheint im Allgemeinen zu funktionieren, da fast alle Warnungen aus der Third-Party-Bibliothek tatsächlich unterdrückt werden.

Da diese Deklaration zufällig eine Instanz einer typedef 'd-Klasse ist, denkt der Compiler, dass es mein Code ist, den er kompiliert, nicht der (falsche) System-Header .

Wie in der referenzierten Frage gesagt, ist es unmöglich, nur diese Warnung zu unterdrücken, und ich müsste stattdessen -Wextra deaktivieren, was ich nicht tun möchte.

Frage : Kann diese Warnung irgendwie unterdrückt werden? Um gcc bewusst zu machen, ist es nicht mein Code, sondern der Bibliothekscode?

Ich verwende gcc 4.1.2.

    
rubikonx9 05.02.2015, 14:00
quelle

1 Antwort

1

Wie andere bereits erwähnt haben, scheint die Verwendung eines neueren Compilers ein besserer Ansatz zu sein als der folgende, aber da Ihre Hände scheinbar gebunden sind, sollten Sie den folgenden Ansatz in Betracht ziehen:

Erstellen Sie Wrapper-Klassen um die Third-Party-Bibliotheksklassen herum in der Art von

%Vor%

Leiten Sie alle relevanten Funktionsaufrufe weiter, um die Wrapper so transparent zu machen, wie Sie es für nötig halten. Alternativ könnten Sie etwas wie BOOST_STRONG_TYPEDEF verwenden.

Die Header, in denen diese Wrapper definiert sind, könnten dann am Anfang der a-Datei stehen:

%Vor%

Hoffentlich unterdrückt das Pragma die Warnung in dem only Client, der die Bibliothek direkt verwendet, während der gesamte andere Code stattdessen die Wrapper verwenden kann und somit das Pragma nicht benötigt.

    
Matthias Vegh 22.04.2015 12:50
quelle

Tags und Links