Dlaczego ten konstruktor jest lepszy?

Question

Witajcie. Na zajęciach ze struktur danych prowadzący nam ostatnio powiedział, że wcześniej nas okłamywał i tak naprawdę to konstruktory się powinno pisać w drugi z poniżej podanych sposobów. Dlaczego tak jest? Jakie są tego plusy? Pytałem Pana ale niezbyt zrozumiałem to co powiedział :(

Z góry dzięki :)

// Pierwszy sposób
Sznur::Node::Node(int d, Node* n)   // 1
{
    val = d;
    next = n;
}

// Drugi sposób
Sznur::Node::Node(int d, Node *n): val(d), next(n) {}

 

Comments

Tutaj jest to fajnie wytłumaczone z przykładem https://youtu.be/1nfuYMXjZsA

Answer 1

Chyba trochę komplikujecie w zasadzie prostą sprawę. Bez opisu.. kod:

#include <iostream>

// Usuwaj i dodawaj komentarz w linii 6
// by zobaczyć róźnicę pomiędzy inicjalizacją przez
// listę inicjalizacyjną i bez.
//#define INIT_LIST

struct Checker {
    Checker() {
        std::clog << "default constructor Checker\n";
    }
    Checker(int a): a{a} {
        std::clog << "int arg constructor Checker\n";
    }
private:
    int a;
};

struct MyClass {
#ifdef INIT_LIST
    MyClass(int a): checker{a} {
    }
#else
    MyClass(int a) {
        checker = a;
    }
#endif
private:
    Checker checker;
};

int main() {
    MyClass myClass{42};
}

Konsekwencją takiego działania jest konieczność inicjalizacji atrybutów stałych w liście inicjalizacyjnej.

Jeszcze tylko niespodzianka z kolejnością inicjalizacji. Odpowiednie ostrzeżenie w kompilatorze wytyka tę potencjalną pomyłkę.

#include <iostream>

struct Checker {
    Checker() {
        std::clog << "default constructor Checker\n";
    }
    Checker(int a): a{a} {
        std::clog << "int arg constructor Checker a = "
                  << a << '\n';
    }
    int getA() const {
        return a;
    }
private:
    int a;
};

struct MyClass {
    // Mimo innej kolejności w liście inicjalizacyjnej,
    // inicjalizacja przebiegnie w kolejności definicji atrybutów
    // w klasie czyli: checker1, checker2, checker3
    MyClass(int a): checker3{}, checker1{a}, checker2{12} {
    }
private:
    Checker checker1;
    Checker checker2;
    Checker checker3;
};

int main() {
    MyClass myClass{42};
}

I tu tylko należy uważać by inicjalizacja atrybutów nie była od siebie zależna bo zawsze wykonywana jest w kolejności definicji atrybutów.

Jak się da, inicjuj w liście. Jeśli się nie da/nie umiesz/niezręczna klasa, trzeba będzie to zrobić w konstruktorze wiedząc o koszcie lub... zmienić klasę która się temu nie poddaje :)

I tyle.. 

Answer 2

Ile w tym prawdy to nie wiem ale gdzieś kiedyś przeczytałem że przy tym zapisie operacje wykonują się szybciej ( jest bardziej zoptymalizowany ). I chyba nowy standard ale ręki nie dam sobie uciąć za to co napisałem.

Answer 3

Drugi zapis umożliwia inicjalizację stałych składowych klasy, pierwszy nie, gdyż przypisanie wartości następuje wtedy po deklaracji, co przy stałych jest niedozwolone. Również wywołanie konstruktora niedomyślnego składowej jest wtedy niemożliwe, jak i konstruktora niedomyślnego klasy bazowej.

Tak na prawdę lepiej używać zawsze drugiego zapisu, po prostu jest czytelniejszy, widać, co jest składową, a co nie. Dodając wymienione wyżej zalety nie ma sensu używać "klasycznego" konstruktora.

Answer 4

Witam,

w pierwszym sposobie występuje przypisanie zmiennych. W tym przypadku najpierw tworzony jest konstruktor z jakimiś losowymi wartościami val i next a dopiero potem są one przypisywane do wartości d oraz n. Jak można wywnioskować jest tu niepotrzebne marnowanie mocy obliczeniowej. Najpierw są do zmiennych przypisane losowe wartość a dopiero później wartości z argumentów konstruktora. 

W drugim przypadku wykorzystujesz listę inicjalizacyjną. W takim przypadku konstruktor jest tworzony od razu z wartościami z argumentu konstruktora tzn val równa się d a next jest n. Mniej operacji.Dodatkowo jeśli masz pola(zmienne) w klasie które mają modyfikator const bądź są referencyjne to musisz użyć drugiego sposobu tworzenie konstruktora.

Comments

w pierwszym sposobie występuje przypisanie zmiennych. W tym przypadku najpierw tworzony jest konstruktor z jakimiś losowymi wartościami val i next a dopiero potem są one przypisywane do wartości d oraz n. Jak można wywnioskować jest tu niepotrzebne marnowanie mocy obliczeniowej. Najpierw są do zmiennych przypisane losowe wartość a dopiero później wartości z argumentów konstruktora. 

W drugim przypadku wykorzystujesz listę inicjalizacyjną. W takim przypadku konstruktor jest tworzony od razu z wartościami z argumentu konstruktora tzn val równa się d a next jest n. Mniej operacji.

Nie sądzę 

---

@Bondrusiek, worzony jest konstruktor z jakimiś losowymi wartościami val i next 

co za totalna bzdura... po drugie jak " one są przypisywane do wartości d i n" :d chyba wartości d i n jak juz sa przypisywane do val i next.

Swoją drogą ...  Jak można wywnioskować jest tu niepotrzebne marnowanie mocy obliczeniowej. 

kolejna bzdura " niby coś wiesz, ale nie do końca" ... i mylisz pojęcia.  

Answer 5

Nie ma "lepsze". - to jest kwestia w programowaniu bardzo sporna, bardziej tu brzmi który model jest efektywniejszy od strony pracy programu.

Lista inicjalizacyjna po prostu jest poprawniejsza i szybsza.

W drugim mówisz "zainicjuj te zmienne wartościami 3, 4, 5", w pierwszym  "zainicjuj je domyślnie... a wiesz co, potem im przypisz wartości 3, 4, 5."

Z czego w jak ktoś tu nieumyślnie próbował wyjaśnić: zauważ, że nakłada się ilość operacji dla przypadku pierwszego - a ilość operacji zwiększa time complexity, czyli czas programu  nakładając n* takich sytuacji na n * konstruktorów rośnie nam czas znacznie przez co efektywność programu spada.