constructor confusion



  • Entweder:
    - ist es für mich zu spät zum Denken
    - habe ich eine grundlegende Sache bei Konstruktoren mit Defaultargumenten verschlafen
    - oder ich habe einen bug gefunden? (G++ 4.8.2)

    In folgendem Code ist die Ausgabe lediglich "Hello World!".
    Was ich erwartet hätte wäre:

    "_1Hello World!"

    #include <iostream>
    
    class A
    {
    public:
        A(bool _1 = true, bool _2 = false);
        A() = delete;
    };
    
    A::A(bool _1, bool _2)
    {
        if (_1)
            std::cout << "_1";
        if (_2)
            std::cout << "_2";
    }
    
    int main()
    {
        //A a; // ambiguous, does work without deleted_ctor as expected
        A a(); // compiles
        // A* b = new A();   // ambiguous, does work without deleted_ctor as expected
        // A* b = new A;     // ambiguous, does work without deleted_ctor as expected
        std::cout << "Hello world!" << std::endl;
        return 0;
    }
    

    Ich dachte, dass vielleicht doch ein default ctor erstellt wird,
    sodass ich ihn deleten lasse, aber das scheint nicht der Fall zu sein.

    ideone.com gibt mir das gleiche Ergebnis.

    Dieses Verhalten hat mir ganz schön Schwierigkeiten bereitet, bis ich angefangen habe am ctor zu zweifeln.

    Klärt mich auf... bitte



  • Tim06TR schrieb:

    Entweder:
    - ist es für mich zu spät zum Denken

    Jo. Suchst an der flaschen Stelle rum.

    Tim06TR schrieb:

    A a(); // compiles
    

    Da deklarierst Du die Funktion a, die keine Paremeter nimmt und ein A zurückgibt. Du definierst keine lokale Variable namens a vom Typ A.

    Spaßig, durch

    A(bool _1 = true, bool _2 = false);
    

    ist der automatisch generierte Defaultkonstruktor weg, wie es sein soll.

    A()=default;
    

    tut ihn dennoch hin, was die Sache ambiq macht, soweit auch logisch.

    A()=delete;
    

    tut ihn auch hin und macht ambiq, das hätte ich nicht erwartet.



  • int main()
    {
        int A();
        A();
        return 0;
    }
    
    int A()
    {
        std::cout << "test";
        return 0;
    }
    

    oh ich wusste gar nicht, dass das legal ist.
    Auch gut 😃

    Hat das bei nicht-lambdas irgend ein nutzen?

    EDIT: ich finde das ist eine ziemliches Fettnäpfchen.



  • Tim06TR schrieb:

    Hat das bei nicht-lambdas irgend ein nutzen?

    Wüßte nicht. ALso das lokale Deklarieren geht schon immer, dachte ich. Sicher lange vor C++11.


  • Mod

    oh ich wusste gar nicht, dass das legal ist.

    Natürlich nicht. Es ist (zumindest meiner Meinung nach) völlig nutzlos, solange man Funktionen auch nicht in Funktionen definieren darf.

    Sicher lange vor C++11.

    Klar, schon in 98.



  • Tim06TR schrieb:

    EDIT: ich finde das ist eine ziemliches Fettnäpfchen.

    Als Gegenmittel wurde in C++11 die "Uniform initialization syntax and semantics" (siehe http://www.stroustrup.com/C++11FAQ.html#uniform-init) engefuhrt.



  • manni66 schrieb:

    Als Gegenmittel wurde in C++11 [ein weiteres Fettnäpfchen] engefuhrt.

    ftfy 🤡



  • Arcoth schrieb:

    Sicher lange vor C++11.

    Klar, schon in 98.

    Schon in C.



  • gcc mag deine Namensgebung '_1' nicht.



  • Jockelx schrieb:

    gcc mag deine Namensgebung '_1' nicht.

    gcc hat mit _1 überhaupt kein Problem.


  • Mod

    Jockelx schrieb:

    gcc mag deine Namensgebung '_1' nicht.

    Sollte er nicht, denn der Name ist nicht im globalen Namensraum und der Unterstrich wird nicht von einem Großbuchstaben gefolgt.

    Das einzige "Problemchen" könnte sein, dass ein anderer Bezeichner durch den Funktionsparameter verdeckt wird: (std::placeholders)::_1 . Ist aber unwichtig, weil der hier sowieso nicht benutzt wird.



  • Arcoth schrieb:

    Jockelx schrieb:

    gcc mag deine Namensgebung '_1' nicht.

    Sollte er nicht

    Stimmt.
    Der Code von Tim ist aber richtig (zumindest ohne das delete) und ich hab verstanden, bei ihm würde es nicht kompilieren.
    Deshalb hab ich geraten, dass das _1 stört.
    Funktioniert aber auch mit _1, auch auf ideone.


Anmelden zum Antworten