Immer wieder dieser Compiler...



  • Ich renne in letzter Zeit immer wieder in interne Compiler Fehler, bei gcc, vc12 und auch clang.

    Wie sieht es bei euch aus, oder habe ich einfach Pech?
    Was habt ihr schon gefunden?

    gcc:

    void foo (Type = {});
    

    vc12:
    2 Sachen, die ich nicht reproduzieren kann

    clang:
    variadic template friend wurde im enclosing scope nicht gefunden.
    (Getestet mit GCC)



  • Tim06TR schrieb:

    Ich renne in letzter Zeit immer wieder in interne Compiler Fehler, bei gcc, vc12 und auch clang.

    Mit BCC32 passiert mir das dauernd 😃

    Den VC++-Compiler habe ich bisher noch nicht zum Abstürzen gebracht.



  • audacia schrieb:

    Tim06TR schrieb:

    Ich renne in letzter Zeit immer wieder in interne Compiler Fehler, bei gcc, vc12 und auch clang.

    Mit BCC32 passiert mir das dauernd 😃

    Wie schön das Andere die gleichen Probleme haben xD...

    Ärgerlich finde ich nur, das sich dies auch nicht nach einem Umstieg auf neuere Versionen bessert... (2007 und XE4 nehmen sich hier z.B. nichts).

    audacia schrieb:

    Den VC++-Compiler habe ich bisher noch nicht zum Abstürzen gebracht.

    Ich schon, aber da war die Konfiguration scheinbar auch defekt.



  • asc schrieb:

    Ärgerlich finde ich nur, das sich dies auch nach einem Umstieg auf neuere Versionen bessert... (2007 und XE4 nehmen sich hier z.B. nichts).

    Finde ich auch ärgerlich, daß neue Versionen besser sind als die vorherigen 😉
    Da fehlt wohl ein "nicht", oder?



  • Th69 schrieb:

    asc schrieb:

    Ärgerlich finde ich nur, das sich dies auch nach einem Umstieg auf neuere Versionen bessert... (2007 und XE4 nehmen sich hier z.B. nichts).

    Finde ich auch ärgerlich, daß neue Versionen besser sind als die vorherigen 😉
    Da fehlt wohl ein "nicht", oder?

    Jupp, nachgetragen 😉



  • asc schrieb:

    Ärgerlich finde ich nur, das sich dies auch nicht nach einem Umstieg auf neuere Versionen bessert... (2007 und XE4 nehmen sich hier z.B. nichts).

    Am BCC32 machen sie halt so gut wie nichts mehr, weil er im nächsten oder übernächsten Release vollends durch Clang ersetzt werden soll.



  • audacia schrieb:

    Am BCC32 machen sie halt so gut wie nichts mehr, weil er im nächsten oder übernächsten Release vollends durch Clang ersetzt werden soll.

    Ich glaube es erst, wenn die Version draußen ist. Davon abgesehen das die IDE auch schon sehr instabil ist (zumindest haben wir auf verschienden Rechnern und OS-Versionen mit der IDE ca. 1 Absturz pro Tag, von anderen Unschönheiten wie das nicht reproduzierbare verschwinden von Databindings usw. - und das egal ob 2007 oder XE4).



  • ich finde ja auch die Fehlermeldung von Microsoft Compiler lustig
    "Please try to simplify the code [...] here"

    G++ schreit ein gleich an, dass man es unverzüglich melden soll.



  • audacia schrieb:

    Tim06TR schrieb:

    Ich renne in letzter Zeit immer wieder in interne Compiler Fehler, bei gcc, vc12 und auch clang.

    Mit BCC32 passiert mir das dauernd 😃

    Den VC++-Compiler habe ich bisher noch nicht zum Abstürzen gebracht.

    Compiler-Fehler != Compiler stürzt ab.
    Obwohl man auch das mit MSVC öfter mal hat. Hab' schon genügend "ICE" (C1001) gesehen.



  • Tim06TR schrieb:

    ich finde ja auch die Fehlermeldung von Microsoft Compiler lustig
    "Please try to simplify the code [...] here"

    Ist doch nett dass er dir wenigstens die Stelle sagt wo er ein Problem bekommen hat.
    Dann kann man wenigstens versuchen es zum Laufen zu bekommen indem man dort was verändert. Was so ziemlich die einzige praktikable Möglichkeit ist die man hat.

    Auf Hotfixes bei MSVC wartet man normalerweise recht lange. Und "recht lange" heisst meistens "ewig". Zumindest wenn man die nächste Visual Studio Version nicht mitzählt. Und auch da ist nicht garantiert dass der Fehler behoben wurde.

    Bei GCC geht das eher schneller, da macht dann ein "bitte melden!" auch mehr Sinn.



  • Ich kann einen der VC12 Fehler übrigens doch reproduzieren:

    #include <iostream>
    #include <string>
    
    std::string foo (std::string::iterator begin, std::string::iterator end)
    {
    	++begin;
    	return {begin--, end}; // begin-- mag er nicht
    }
    
    int _tmain(int argc, _TCHAR* argv[])
    {
    	std::string test;
    	std::cout << foo (test.begin(), test.end());
    	return 0;
    }
    

    EDIT: Fix:

    std::string foo (std::string::iterator begin, std::string::iterator end)
    {
    	++begin;
    	return std::string{begin--, end};
    }
    


  • hustbaer schrieb:

    audacia schrieb:

    Den VC++-Compiler habe ich bisher noch nicht zum Abstürzen gebracht.

    Compiler-Fehler != Compiler stürzt ab.

    Der typische ICE ist ein Bugcheck im Compiler ( assert() , Zugriffsverletzung), und das ist ein typischer Absturzauslöser. Daß der Compiler nicht wirklich "abstürzt", liegt eher daran, daß die meisten Compiler (anders als gewöhnliche Programme) irgendwo ein unkonditionelles SEH- __except {} haben, damit der Benutzer eine gewöhnliche Fehlermeldung ("ICE") im Buildprozeß bekommt und nicht von Windows über ein nichtfunktionierendes Programm benachrichtigt werden muß.



  • #include <iostream>
    #include <string>
    
    void foo (std::string const& B, std::string const& A = {})
    // commented out, because it works:
    //void foo (std::string const& B, std::string const& A = std::string{})
    {
    	std::cout << B << ": " << A;
    }
    
    int main()
    {
    	foo ("test");
    	return 0;
    }
    

    führt zu einer nullptr exception zur runtime unter vc12.
    Das hat mich gerade 20 Minuten gekostet...

    EDIT: Ich habe sehr viel Probleme mit der vereinheitlichten Syntax für Initialisierung. Die führt immer wieder zu Fehlern.



  • Wenn du mit den neuesten Sprachfeatures rumprobierst, würde ich auch die neueste VS-Version nehmen (also VS 2013), da besteht nämlich eine gute Chance, daß sie deine Probleme bereits behoben haben. Oder hat es einen bestimmten Grund, daß du mit VS 2012 arbeitest?



  • ich nehme die neuste, ich hatte nur die versionen confused.

    EDIT: Und eigentlich bin ich über das experimentieren hinaus 🙂
    Ich schaue mir gerade VVTTPs an



  • clang:
    variadic template friend wurde im enclosing scope nicht gefunden.
    (Getestet mit GCC)

    Bitte den Code posten! Hört sich direkt nach einem PEBKAC an. Und Clang traue ich mittlerweile ein wenig mehr als dem GCC.



  • das ist nun wirklich nichts super kompliziertes.
    GCC baut und gibt "yay" aus.
    Clang sagt:

    error: use of undeclared identifier 'CreateTask'"

    using namespace std;
    
    class Task {
    private:
        std::function <void()> f_;
    public:
        template <typename T, typename ... Args>
        friend Task CreateTask(T func, Args ... args) {
            Task tsk;
            tsk.f_ = std::bind<void>(func, args...);
            return tsk;
        }
    
        void operator()() const {
            f_();
        }
    };
    
    int main(int argc, char *argv[])
    {
        auto task = CreateTask([](){ std::cout << "yay\n"; });
    
        task();
        return 0;
    }
    


  • Edit: Anscheinend habe ich den falschen Compiler eingestellt. Clang 3.4 meckert hier. Vielleicht ist der Code tatsächlich falsch.



  • EDIT: dein edit
    Ich kann gerade keine weiteren Compiler testen, ich bin grad nebenbei am programmieren. Sonst hätte ich das Betriebsystem gewechselt.
    Ich sehe aber nichts, was falsch sein könnte.



  • Tim06TR schrieb:

    Ich sehe aber nichts, was falsch sein könnte.

    Wie soll die Funktion CreateTask gefunden werden? Sie könnte nur gefunden werden, wenn als Argument ein Task übergeben wird, weil so ADL das Funktionstemplate findet, was ja in der Klasse deklariert wurde.

    Vereinfachtes Beispiel:

    struct Task
    {
        friend Task CreateTask(int func);
    };
    
    int main()
    {
        auto b = CreateTask( Task{} ); // kompiliert
        auto a = CreateTask(4); // ... nicht. 
    }
    

    Noch einfacheres Beispiel:

    struct Task
    {
        friend void CreateTask(int func);
    };
    
    int main()
    {
        CreateTask(4); // Fehler - die obige Create-Task-Funktion ist in ihrem Namensraum (dem globalen) nicht sichtbar.
    }
    

Anmelden zum Antworten