Fehler bei new []?!



  • Hallo,
    hab bei folgendem Code:

    long rows, cols;
    /*...*/
    t *tmp = new t[rows * cols];
    

    die folgende Fehlermeldung:

    fatal error C1001: Interner Compilerfehler.
    1>(Compilerdatei "msc1.cpp", Zeile 1411)
    1> Vereinfachen oder ändern Sie das Programm im Umfeld der oben aufgeführten Positionen. Wählen 
    1>Sie im Menü "Hilfe" von Visual C++ den Befehl "Technischer Support", 
    1>oder öffnen Sie die Hilfedatei des technischen Supports, um weitere Informationen zu erhalten.
    

    Hat jemand sowas schonmal gehabt oder kann mir da weiterhelfen. Ich weiß jedenfalls nicht wie ich das noch weiter vereinfachen soll, das Produkt vorher ausrechnen macht jedenfalls keinen Unterschied.
    Ich benutze Microsoft Visual Studio 2008.
    Danke schonmal im Voraus.
    Grüße



  • Ja, sowas hatte ich schon öfter mal. Aber eigentlich immer nur in Verbindung mit irgendwelchen Monster-Bibliotheken wie Qt oder extremen Templete-Konstrukten wie z.B. die in boost::spirit . Normalerweise reichte es da, ein zweites mal auf Compile zu drücken.



  • Ja, ich benutze Qt und habe das Problem bei einer Template-Klasse drin ^^
    Neu compilieren hat leider nicht geholfen 😞



  • Hast Du SP1 für Dein Visual Studio drauf? Wenn nicht, installier das mal, sofern möglich.
    Ansonsten könnte das Tauschen von Zeilen was bringen, sofern das möglich ist.



  • Weiß ich nicht genau, in der Info zum MSVS2008 steht was von SP1, aber ich lads nochmal runter, dann werd ich sehen obs wirklich schon installiert ist.


  • Administrator

    FreakyBKA schrieb:

    Ja, ich benutze Qt und habe das Problem bei einer Template-Klasse drin ^^
    Neu compilieren hat leider nicht geholfen 😞

    Was für einen Typ stellt t dar? Ich denke, dass wäre hier noch eine entscheidende Information. Wahrscheinlich ist nämlicher dieser Typ zu kompliziert 🙂

    Grüssli



  • t ist eine klasse für rationale zahlen, die ich mir geschrieben habe, diese wiederum ist abgeleitet von einer template-klasse für beliebige rationale objekte, also welche die aus zähler und nenner bestehen. für die rationalen zahlen hab ich als template-typ für den anfang einfach long genommen. später soll das dann ein typ werden, der beliebig große zahlen darstellen und verarbeiten kann.



  • FreakyBKA schrieb:

    fatal error C1001: Interner Compilerfehler.[/code]
    Hat jemand sowas schonmal gehabt ...

    Hallo FreakyBKA,

    ja habe ich schon gehabt. In MS-VC-Version vor 2008 recht häufig, aber inzwischen sogar in der neuesten Version MS-VC-2010!

    Interessant ist nicht die Zeile, in der der Fehler gemeldet wird, interessant ist Deine letzte Änderung zu der Variante, die sich fehlerlos übersetzen lies.
    Ansonsten gilt 'Teile & Herrsche'. Die Source-Code-Dateien möglichst nicht zu groß werden lassen, so lässt sich der Auslöser (nicht der Fehler) besser identifizieren und die Wahrscheinlichkeit sinkt, dass sowas auftritt.

    Wenn der Auslöser etwa eine Template-Instantiierung ist, so kann ein typedef eben dieses Typs helfen.
    Manchmal hilft es, die Reihenfolge von einigen Includes zu variieren.
    Manchmal ist es auch ein Compilerfehler, der den Compiler aber später zum Absturz bringt. Also nochmal genau die Sachen checken, die als letztes in der Datei hinzugefügt wurden.

    Wenn's gar nicht geht, einfach mal große Teile der Datei auskommentieren und schauen, wo es auftritt. So ala binäre Suche ..

    Viel Glück



  • also der fehler tritt genau dann auf, wenn ich den typ auf meine rationalen zahlen ändere. wenn t sowas wie float ist geht es ohne probleme. wobei ich die rationalen zahlen bzw float über eine typedef-bezeichnung einbinde, um halt im ganzen program schnell den typ anpassen zu können.
    also sowas wie

    typedef float t //damit gehts
    // alternativ, natürlich nicht beides gleichzeitig ;-)
    typedef crational_number t //damit nicht
    

    im rest wird dann immer mit t gearbeitet



  • aso, was ich vergessen hab zu erwähnen, vom C/C++ Optimierungscompiler gibts noch ne Fehlermeldung:

    Microsoft (R) C/C++-Optimierungscompiler hat ein Problem festgestellt und muss beendet werden.

    Vielleicht kann man da ja was einstellen, hab aber leider nichts gefunden und google hat mir diesbzgl auch nicht weiterhelfen können.


  • Mod

    In der Mehrzahl der ICE-Fälle ist ein Fehler im Quelltext der Grund, auf den der Compiler so nicht vorbereitet ist.
    Vermutlich hat das ganze mit dem new nichts zu tun, es tritt nur an dieser Stelle auf, weil dort die Templateklasse zum ersten mal instantiiert wird.
    Als erstes würde ich also prüfen, ob ein simples

    t foo;
    

    ebenfalls zu einem Fehler führt. Falls ja, kannst du versuchen, das Template schrittweise zu vereinfachen, bis der Fehler nicht mehr auftritt, um so die Quelle einzukreisen. Das Problem bei ICE ist ja, dass die Stelle, an der der Compiler aussteigt nahezu nichts mit dem zugrunde liegenden Problem zu tun hat.



  • also der fehler scheint in der rational_number klasse in kombination mit dem rational-template zu liegen, der aufbau ist im groben etwas so:

    template<class t>
    class rational
    {
    //...
    virtual void reduce_gcd(t &lhs, t &rhs) = 0;
    void simplify(); //ruft reduce_gcd auf
    //...
    }
    //...
    
    class rational_number : public rational<long>
    {
    //...
    void reduce_gcd(long &lhs, long &rhs){/*...*/};
    //...
    }
    

    ich bekomme dann die fehlermeldung:

    pure virtual function call
    

    an der stelle wo reduce_gcd() in der simplify-methode aufgerufen wird. allerdings sollte er doch die reduce_gcd()-methode von rational_number kennen und dann dort auch benutzen, oder sehe ich das falsch?



  • FreakyBKA schrieb:

    ich bekomme dann die fehlermeldung:

    pure virtual function call
    

    an der stelle wo reduce_gcd() in der simplify-methode aufgerufen wird.

    Du rufst nicht zufällig simplify aus dem rational-Konstruktor auf?



  • doch indirekt, nachdem der zähler und nenner gesetzt sind, soll ja quasi gekürzt werden (dafür ist die reduce_gcd()-methode da). wenn das falsch ist, dann wusste ich das nicht, würde micha ber interessieren, wie ich das dann beheben kann.



  • aso, der kennt die reduce_gcd-methode() von rational_number im rational-konstruktor ja noch gar nicht, oder?



  • FreakyBKA schrieb:

    aso, der kennt die reduce_gcd-methode() von rational_number im rational-konstruktor ja noch gar nicht, oder?

    Im rational-Konstruktor gibt es noch gar kein rational_number-Objekt. Man sollte in Konstruktoren und Destruktoren keine virtuellen Methoden aufrufen, bzw. man sollte wissen, was dann passiert.



  • ok, aber wie kann ich dann dafür sorge tragen, das nenner und zähler trotzdem gekürzt werden?



  • Muss reduce_gcd denn virtual sein?



  • naja, da rational ja eine template-klasse ist schon. den jeder typ kann eine andere methode erfordern den gcd zu entferen. bei long, int, etc. geht der euklidische algorithmus. wenn ich dann aber für t polynome mehrerer variablen einsetze dann brauche ich zB groebner-basen. bei polynomen in einer variable geht polynomdivision, aber das ist nur ein spezialfall von groebner-basen.

    rational soll quasi nur den kern aller rationalen objekte darstellen: zähler, nenner, grundoperationen und halt das man überall kürzen kann, sofern möglich.
    und für die einzelnen typen wird dann spezialisiert.



  • FreakyBKA schrieb:

    naja, da rational ja eine template-klasse ist schon. den jeder typ kann eine andere methode erfordern den gcd zu entferen.

    Gerade bei Templates bist du für solche Dinge nicht an Polymorphie durch Vererbung gebunden.

    Wie wäre es mit einem Policy-Templateparameter?


Anmelden zum Antworten