Czy powinno się tworzyć tzw. "konstruktory hałaśliwe" ?

Question

Witam, mam np. taki konstruktor

Kl::Kl(){
    std::cin>>jakies_pole; 
}

Nie ustawiam tu wartości żadnych składowych na podstawie parametrów konstruktora. Obiekt mogę utworzyć tak:

Kl k;

Wtedy automatyczne będę musiał wpisać jakieś dane. Jednak czy takie coś jest bezpieczne/stosowane/zgodne z przeznaczeniem?

* Dalsza część pytania nieaktualna bo komplikuje temat i wprowadza w błąd, nie usunąłem jej by nie postąpić nieuczciwie wobec tych co napisali komentarze. Po prostu chodzi mi o to czy powinno się tworzyć konstruktory które coś wypisują na ekranie lub pobierają dane z klawiatury czy raczej jedyne co powinny robić to przypisywać wartości składowym:

W razie dalszych wątpliwości:

class KL{
public:
    int x;
    KL(){
        std::cout<<"witaj! Podaj ile masz lat: ";
        std::cin>>x;
    }
};

int main(){
    KL t; //nie wywołaliśmy jawnie żadnej metody a zadeklarowanie obiektu działa dokładnie jak funkcja, takie coś kompiluje się poprawnie... ale czy ma prawo bytu w c++? Czy warto takiego rodzaju konstruktorów używać? 
}

Zastanawiam się nad tym bo mam zadanie do zrobienia, i muszę mieć 2 konstruktory. Przeznaczony do sztywnego przekazania argumentów (zainicjalizowania obiektu) i drugi przeznaczony do tego (raczej nie koniecznie takie instrukcje musi zawierać) żeby użytkownik sam wpisał interaktywnie dane. Tzn. że ten konstruktor np może przyjmować jako argument zainicjalizowany już obiekt albo prosić użytkownika w swojej definicji o podanie danych. Co powinienem użyć? Co jest lepsze?

Dziękuje serdecznie za pomoc :)

Comments

muszę mieć 2 konstruktory

(...)

Co powinienem użyć?

W związku z powyższym nie bardzo rozumiem istoty pytania.

---

Podaj treść tego zadania. Z twojego opisu trudno cokolwiek wywnioskować.

---

@draghan

@Wiciorny

Słuchajcie, to nie o to chodzi że ja nie wiem jak zrobić zadanie... ;(

Mam na myśli tylko to czy powinno się stosować konstruktory które coś wypisują na ekranie albo proszą użytkownika o podanie informacji czy raczej powinny one tylko nadawać wartości obiektom pól klasy.

 

Answer 1

IMHO brzydko to wygląda i mieszasz w ten sposób warstwy swojej apki. Warstwa komunikacji z userem zawsze jest tą najwyższą, a obiekt możesz chcieć stworzyć gdziekolwiek. Wg mnie powinno to wyglądać tak, że input usera przechwytujesz tam gdzie jest to w kodzie widoczne (np. jakaś funkcja w stylu 'handleInput' w klasie gdzies na górze hierarchii) i tam po otrzymaniu inputu podajesz go do konstruktora obiektu, potencjalnie przechodząc przez kolejnych kilka warstw abstakcji jeśli obiekt jest gdzieś głęboko (np. przekazując otrzymany input przez parametry funkcji...). Jakby tera uruchomił apke i zostałbym poproszony o input, to bez debugera bardzo ciężko byłoby się dowiedzieć skąd to się wzięło.
tl;dr: jakikolwiek input powinien być przechwytywany w jednym miejscu, żeby kod chociaż miał szanse być utrzymywalny.

Comments

imo - jakby ktoś zobaczył nagłówek takiego konstruktora (albo ide by mu podpowiedziało) że nie potrzebuje żadnych parametrów, a pisałby niekonsolową aplikację to wtedy mógłby się zdziwić.

Answer 2

Mam na myśli tylko to czy powinno się stosować konstruktory które coś wypisują na ekranie albo proszą użytkownika o podanie informacji czy raczej powinny one tylko nadawać wartości obiektom pól klasy.

Konstruktor to metoda, która ma zostawić po sobie poprawnie zainicjalizowany obiekt. Nie mniej, nie więcej. Jeśli wymaga to pobrania danych z zewnątrz, to - w mojej opinii - jak najbardziej taka konstrukcja ma rację bytu. A co do wypisywania na ekranie - całkiem to przydatne przy debugowaniu.

Answer 3

Kl::Kl(){
    std::cin>>jakies_pole; 
}

No masz konstruktor - na bazie domyślnego, ale 

Kl k;

Tu nie tworzysz żadnego obiektu, na razie deklarujesz tylko że zmienna k bedzie typu KL, ale w danej chwili oprócz referencji do miejsca Kl jest niczym... na pewno nie obiektem.

Czy jest to bezpieczne? Nie da się jednoznacznie określić  nie znając celu/kodu. Na pewno jest to "nie praktyczne" i nie widzę żeby miało jakieś zastosowanie bo problem pojawia się taki, że urzytkownik może wpisać co-kolwiek, np nie bedzie polakiem i nie zrozumie tego ... zwiększa to problem z obsługa błedów czy smieciami w  zapisie do pól

Jeśli potrzebujesz 2 konstruktory to jeden musi być bezargumentowy drugi z argumentami :)

A  nie musisz pól wypełniać na starcie,  pola mogą być wypełnione setterami 

https://stackoverflow.com/questions/760777/c-getters-setters-coding-style

https://forum.pasja-informatyki.pl/37282/czym-sa-gettery-i-settery-w-c  odnośnik do naszego forum też 

 

zainicjalizowany już obiekt 

nie myl Obiektu ze zmienną czy zwykłym argumentem, jesli mówisz o przekazaniu obiektu, to faktycznie musi to być "JAKIS TYP" - byt rozbudowany, a nie np prymitywna wartość int/char/byte/ etc 

Comments

Tu nie tworzysz żadnego obiektu, na razie deklarujesz tylko że zmienna k bedzie typu KL, ale w danej chwili oprócz referencji do miejsca Kl jest niczym... na pewno nie obiektem.

Oczywiście, że w tym miejscu tworzy obiekt. C++ to nie Java, żeby używać zawsze operatora new. 

---

@Wiciorny, Kolega @Patrycerz już napisał że jesteś w błędzie.

Czy jest to bezpieczne? Nie da się jednoznacznie określić  nie znając celu/kodu. Na pewno jest to "nie praktyczne" i nie widzę żeby miało jakieś zastosowanie bo problem pojawia się taki, że urzytkownik może wpisać co-kolwiek, np nie bedzie polakiem i nie zrozumie tego ... zwiększa to problem z obsługa błedów czy smieciami w  zapisie do pól

Także jesteś w błędzie. Sprawdź czy będzie wygodne używanie konstruktora z argumentami w przypadku gdy obiekty chcesz umieścić w tablicy.  Do wywodu "polak/nie polak" nie będę się odnosił bo nie ma sensu w świetle pierwszego błędu.

Co widzisz niebezpiecznego i "generującego śmieci" w tej konstrukcji?

std::vector<int> myVec;

Jeśli potrzebujesz 2 konstruktory to jeden musi być bezargumentowy drugi z argumentami :)

Znów błąd. Możesz mieć wiele konstruktorów z argumentami oraz nie mieć bezargumentowego. Możesz także mieć 1 konstruktor z argumentem/argumentami domyślnymi a kompilator w trakcie użycia wygeneruje odpowiedni do wywołania.

#include <iostream>

// Komunikaty na ekran w celu edukacyjnym...
struct X {
    X(int a_ = 10, int b_ = 20): a{a_}, b{b_} {
        std::cout << "Wywołanie konstruktora z a_ = " << a_
            << " b_ = " << b_ << '\n';
    }
    X(double a_): a{static_cast<int>(a_)}, b{90} {
        std::cout << "Wywołanie konstruktora z arg. double "
            << "a_ = " << a_ << " b_ = " << 90 << '\n';
    }
private:
    int a;
    int b;
};

int main() {
    std::cout << "Bez argumentów\n";
    X x1;
    std::cout << "Z argumentem 12\n";
    X x2(12);
    std::cout << "Z argumentami 40, 30\n";
    X x3(40, 30);
    std::cout << "Z argumentem double\n";
    X x4(3.14);
}

O kombinacji z delete czy default nie będę wspominał.