4. XE8: Interner Compilerfehler bei Klassenhierachie mit Templates

XE8: Interner Compilerfehler bei Klassenhierachie mit Templates


  • Hallo zusammen,

    ich habe das Problem, dass der X8 eine bestimmte Klasse im release-Modus nicht übersetzen will und mit einem Internen Compilerfehler abbricht. Im Debug Modus geht es allerdings.
    Der Code ist etwas kompliziert, aber Standard C++ und der Codegear 2007 übersetzt ihn anstandslos.

    Es gibt folgenden Datenklassen (alles starkt vereinfacht):

    class BaseData
{
   ...
};

class ChartData : public BaseData
{
   ...
};

class ReportData : public BaseData
{
   ...
};

    Dazu gehören folgende Daten-Lese-Klassen:

    template<typename DataType>
class DataReader
{
   DataType Data_;
};

template<typename DataType>
class SomeFormatDataReader : public DataReader<DataType>
{
  ...
};

class SomeFormatDataReaderChart : public SomeFormatDataReader<ChartData>
{
   ...
};

class SomeFormatDataReaderReport : public SomeFormatDataReader<ReportData>
{
   ...
};

    Aus irgendwelchen Gründen bleibt der Compiler beim Übersetzen der Klasse SomeFormatDataReaderReport mit einem internen Compilerfehler stehen und beschwert sich über eine bestimmte Quelltextzeile in der Basisklasse SomeFormatDataReader :

    bcc32 Befehlszeile schrieb:

    bcc32 Befehlszeile für "SomeFormatDataReaderReport.cpp"
    [bcc32 Fataler Fehler] SomeFormatDataReaderReport.cpp(26): F1004 Interner Compiler-Fehler at 0x24c652cd with base 0x24c10000

    Die Klasse SomeFormatDataReaderChart wird anstandslos übersetzt, obwohl die Basisklasse fast identisch ist (bis auf das Datenelement Data_ ).
    Alle Klassen außer SomeFormatDataReaderReport lassen sich problemlos übersetzen und instanzieren, das bekommt der Compiler anscheinend hin:

    void f()
{
   ChartData cd;
   Reportdata rd;

   SomeFormatDataReaderChart ChartReader ;
}

    Im ersten Schritt habe ich sämtlichen Code in den Funktionsrümpfen der Klasse SomeFormatDataReaderReport auskommentiert: Keine Verbesserung.

    Danach habe ich die Template-Eigenschaft Klasse SomeFormatDataReaderReport entfernt und den template Parameter durch den konkreten Datentyp ersetzt:

    // template<typename DataType>
// class SomeFormatReader : public DataReader<DataType>
class SomeFormatReader : public DataReader<ReportData>
{
   ...
};

class SomeFormatReaderReport : public SomeFormatReader 
{
   ...
};

    und das übersetzt anstandslos. Auch

    void f()
{
   SomeFormatReader Reader;
   SomeFormatReaderReport ReportReader
}

    lassen sich jetzt übersetzen. Diese Tests zeigen, dass der Code jeder einzelnen Klasse für sich ok ist (schließlich übersetzt es ja auch der CG2007) und dass der Fehler wohl irgendwie mit den Einstellungen der Release-Konfiguration zusammenhängen muss.

    Lösungsversuche:
    Hab jetzt versucht, für die Klasse lokale Optionen einzustellen, sodass keine Optimierungen für diese Klasse durchgeführt wird, und das wird dann auch übersetzt. Allerdings kann ich das ganze Projekt nicht mehr übersetzen, weil MSBuild beim Übersetzen der Dateien mit lokalen Einstellungen mit der Fehlermeldung

    bcc32 Befehlszeile schrieb:

    [MSBuild Fehler] The <ProjectExtensions> element occurs more than once.
    [InvokeMSBuild Fehler] The <ProjectExtensions> element occurs more than once.

    stehenbleibt und sich nicht fortsetzen lässt. In den Projekteinstellungen ist die Stapel-Übersetzung deaktiviert, damit wird jede .cpp Datei separat übersetzt.

    Bin ziemlich ratlos 😕

    0
  • A

    DocShoe schrieb:

    Aus irgendwelchen Gründen bleibt der Compiler beim Übersetzen der Klasse SomeFormatDataReaderReport mit einem internen Compilerfehler stehen und beschwert sich über eine bestimmte Quelltextzeile in der Basisklasse SomeFormatDataReader :

    bcc32 Befehlszeile schrieb:

    bcc32 Befehlszeile für "SomeFormatDataReaderReport.cpp"
    [bcc32 Fataler Fehler] SomeFormatDataReaderReport.cpp(26): F1004 Interner Compiler-Fehler at 0x24c652cd with base 0x24c10000

    Der Auszug, den du hier gepostet hast, reicht aber nicht, um das Problem zu reproduzieren, oder?

    DocShoe schrieb:

    Im ersten Schritt habe ich sämtlichen Code in den Funktionsrümpfen der Klasse SomeFormatDataReaderReport auskommentiert: Keine Verbesserung.

    Könntest du mal die Funktionsdefinitionen in SomeFormatDataReaderReport zeigen?

    DocShoe schrieb:

    bcc32 Befehlszeile schrieb:

    [MSBuild Fehler] The <ProjectExtensions> element occurs more than once.
    [InvokeMSBuild Fehler] The <ProjectExtensions> element occurs more than once.

    Das klingt, als hätte die IDE Unfug in die Projektdatei geschrieben. Schau doch mal mit einem Texteditor nach, ob du das selbst trivial beheben kannst.

    0

  • Ich habe ja geschrieben, dass das Ganze stark vereinfacht ist. Das sind insgesamt sicher einige tausend Zeilen Quelltext (durch die Vererbungshierachie), das lässt sich hier nicht posten.
    Im Prinzip erwarte ich ja nichts, musste nur etwas machen, bevor ich den Monitor vom Schreibtisch fege 😉

    Edit:
    Ja, wenn ich für einzelne Dateien lokale Optionen festlege schreibt die IDE die Projektdatei kaputt. Bei jeder Änderung fügt sie in der vorletzten Zeile einen leeren ProjectExtensions Knoten ein. Der Compiler läuft grade, mal sehen, wie weit er kommt.

    aber zunächst ein Mal Danke für den Hinweis.

    0
  • O

    DocShoe schrieb:

    ... wenn ich für einzelne Dateien lokale Optionen festlege schreibt die IDE die Projektdatei kaputt. ...

    Zumindest bei älteren C++Builder Versionen gab es die Möglichkeit, Optionen im Quelltext (nur für diese Datei) zu setzen. Google mal nach ' #pragma option push / pop ', vielleicht hilft es dir weiter.

    0

  • So, hab´s gefunden. Klein, subtil und gemein war´s.

    Es lag an der Reihenfolge der #include Anweisungen. Durch meine Anordnungen war ein Template-Parameter in einer Basisklasse ein incomplete type, und das führte zum Internal Compiler Error. Überhaupt tritt dieser Internal Compiler Error gerne auf, wenn man folgende Konstrukt benutzt:

    class ClassA : public ClassB<ClassC>
{};

    und ClassB oder ClassC Fehler enthalten und sich nicht übersetzen lassen. Für ClassC ist das relativ einfach herauszufinden, indem man sie einfach übersetzt, aber für das Klassentemplate ClassB kann´s schon knifflig werden.

    0

  • Das war´s wohl doch nicht 😞

    0

  • Hast du das Problem auch zusätzlich an Code Central gemeldet?

    0
  • A

    DocShoe schrieb:

    Ich habe ja geschrieben, dass das Ganze stark vereinfacht ist. Das sind insgesamt sicher einige tausend Zeilen Quelltext (durch die Vererbungshierachie), das lässt sich hier nicht posten.

    Dann mach doch mal Folgendes:

    - ein Duplikat der Datei erstellen und mit dem Kommandozeilencompiler übersetzen (ggf. Flag- und Pfadargumente aus dem "Build"-Tab in der IDE rauskopieren)
    - alle Funktionsrümpfe leeren
    - alle referenzierten nichttrivialen Typen (alles, was in irgendwelchen Headern definiert wird) durch Dummys ( typedef struct {} Dummy; oder int / char /...) ersetzen
    - soweit möglich alle eingebundenen Headerdateien entfernen
    - den Präprozessor über die Datei laufen lassen (dazu gibts im Projektmanager einen Kontextmenueintrag)
    - vom Inhalt der restlichen Headerdateien alles Irrelevante entfernen
    - jetzt sollte nur noch die fragliche Klassenhierarchie übrig sein. Von Basisklasse zu den abgeleiteten Klassen sukzessive alle Funktionen entfernen
    - schließlich eine nach der anderen Funktionsdeklaration auskommentieren

    Dabei in jedem der Schritte den Kommandozeilencompiler einmal drüberlaufen lassen, um sicherzugehen, daß der Fehler immer noch auftritt.

    Burkhi schrieb:

    Hast du das Problem auch zusätzlich an Code Central gemeldet?

    Das finde ich zwar im Allgemeinen unterstützenswert, aber beim BCC würde nicht mal ich mir noch Hoffnungen machen, daß daraus irgendwas folgt. Im neuesten Release gibt es ja einen Clang-basierten Nachfolger auch für 32-Bit. Am BCC wird nichts mehr getan werden, was nicht unbedingt überlebenswichtig ist.

    0

  • @audacia

    erst ein Mal Danke für die Hilfe.

    Ich denke nicht, dass ich das aktuelle Design mit dem XE8 noch irgendwie übersetzt kriege. Ich schiebe jetzt seit 3.5 Tagen erfolglos Quelltextzeilen hin und her und fummel an irgendwelchen Projekteinstellungen rum. Will da auch nicht weiter rumspielen und noch mehr Zeit verbrennen.
    Ich mache jetzt noch aus der Template-Klasse eine normale und hoffe, dass das dann funktioniert.
    Wir hatten im Juni eine Vertrieblerin im Haus als wir die XE8 Lizenzen gekauft haben, die sich bemühen wollte, uns ein kostenloses Upgrade auf den XE10 zu besorgen. Damit könnte man versuchen, die clang Toolchain einzusetzen.

    Wenn das nix wird schließe ich mich Zero01 an und sage fu.. y.. Embarcadero.
    Wird aber doch nix nützen, die haben ja sowieso schon den Draht zu den Kunden verloren.

    0
  • A

    DocShoe schrieb:

    Ja, wenn ich für einzelne Dateien lokale Optionen festlege schreibt die IDE die Projektdatei kaputt. Bei jeder Änderung fügt sie in der vorletzten Zeile einen leeren ProjectExtensions Knoten ein. Der Compiler läuft grade, mal sehen, wie weit er kommt.

    Das ist schon auch lustig. In früheren Versionen hat das ja funktioniert; bei so einem elementaren Fehler mutmaßt man, daß die womöglich keinen Integration-Test für lokale Projektoptionen in ihrer Suite haben.

    DocShoe schrieb:

    Wir hatten im Juni eine Vertrieblerin im Haus als wir die XE8 Lizenzen gekauft haben, die sich bemühen wollte, uns ein kostenloses Upgrade auf den XE10 zu besorgen. Damit könnte man versuchen, die clang Toolchain einzusetzen.

    Das wäre ein schöner Zug. Wobei ich noch keine Erfahrung mit dem 32-Bit-Clang habe; vielleicht braucht der auch ein paar Releases, bis er einigermaßen stabil ist.

    DocShoe schrieb:

    Wenn das nix wird schließe ich mich Zero01 an und sage fu.. y.. Embarcadero.

    Die Hotfixes und Updates waren ja noch nie besonders umfassend, aber mit der aktuellen Updatepolitik ist das Erwerben einer Version ohne Subscription unsinnig geworden. Die Subscription hingegen ist nicht nur auf dem Papier viel teurer, sondern verursacht durch das ständige Migrieren der Komponenten und Projekte, das erforderlich ist, um Bugfixes zu bekommen, enormen zusätzlichen Arbeitsaufwand. Für den schnellebigen App-Markt mag das hinnehmbar sein, für normale Windows-Projekte aber nicht.

    Ich finds wirklich schade, weil die VCL meiner Meinung nach immer noch mit Abstand die schönste GUI-Bibliothek für Windows-Programme ist. Wenn Windows 7 und 8 irgendwann ausgelaufen sind, können wir meinetwegen alle Universal Apps schreiben, aber bis dahin wollte ich die VCL eigentlich noch benutzen 😞

    0
Anmelden zum Antworten