Qt/C++ - funkcje zwrotne vs sygnały i sloty

0

Pytanie zakładam z ciekawości, może dowiem się czegoś ciekawego

czy LEPIEJ pisać funkcje zwrotne ? Czy sygnały i sloty ?

np

int FunkcjaZwrotna(int arg)
{
   //coś się robi

   if(warunek){
        return cos;
   }
   if(warunek2){
       return cos_innego;
   }

    return jezeli_powyzsze_warunki_sa_niespelnione_zwroc_cos_innego;
}

int FunkcjaGlowna(int (*wsk)(int))
{
    int liczba = 0;

    liczba = (*wsk)(12);
   
    //coś się robi

    return cos_innego;
}

int main()
{
    int (*wsk)(int);

    wsk = &FunkcjaZwrotna;

    FunkcjaGlowna(wsk);

return 0;
}

domyślam się, że sygnały i sloty powstały po to aby nie trzeba było pisać funkcji zwrotnych. Który wariant lepiej stosować ? Bo wydaje mi się, że warto umieć pisać funkcje zwrotne

2

Dla core czyli części biznesowej radziłbym pattern listener bo to przenośne i zostanie nawet po przestawieniu całego systemu na borland buildera.
Dla pozostałej części ma być jak najbardziej natywnie, czyli w przypadku Qt - słoty.

3

Tzw "funkcja zwrotna" i wskażnik funkcyjny jest koncepcją na poziomie C.
Występuje tez w API systemów operacyjnych
Warto to umieć ze względów j/w, choć w C++ zmniejsza znaczenie

Pozostałem to koncepcjie obiektowe

2

C++ alternatywy:

  • szablon
template<typename F>
auto FunkcjaGlowna(F f) -> int // może jakieś SFINAE
{
    int liczba = 0;

    liczba = f(12);

    return cos_innego;
}
  • std::function
auto FunkcjaGlowna(std::function<int(int)> f) -> int
{
    int liczba = 0;

    liczba = f(12);

    return cos_innego;
}
  • interface
class ICallback
{
public:
     int f(int) = 0;
};

class FunkcjaZwrotna : public ICallback
{
public: 
     int f(int) override {
           return 3;
     }
};

auto FunkcjaGlowna(ICallback& o) -> int
{
    int liczba = 0;

    liczba = o->f(12);

    return cos_innego;
}

FunkcjaZwrotna  o;
x = FunkcjaGlowna(o);

Sygnały sloty w tym kontekście pasują mi jak pięść do oka. Niby na czym miało by to polegać?
Sygnały is sloty wiążą ze sobą dwa QObject, a w tym przykładzie nie ma nawet zwykłej klasy.

1

Nie ma "lepiej". Callbacki są proste, żeby nie powiedzieć - prymitywne, ale zadziałają na większości platform gdzie masz C (albo i wszystkich, jeśli to faktycznie C. Nie wiem jak pewne małe uC bez stosu sobie tu poradzą, no ale to pomijalnie mały ułamek). Problem z nimi taki, że mogą pojawić się trudności np. w przekazywaniu danych z nich/do nich. Koncepcje obiektowe, typu listener czy inny obserwator albo właśnie te sloty i sygnały są wygodniejsze w użyciu, potencjalnie bezpieczniejsze...ale są obiektowe ;) Nie dadzą się zastosować wszędzie, a przynajmniej nie w łatwy sposób.

0

@kq:

Jak znasz C++ to siłą rzeczy i tak będziesz musiał znać C jeśli mowa o jakikolwiek sensownym poziomie kompetencji

dlaczego ? Przecież C++ jest "nowszą" wersją C

1

Nie, to dwa różne języki. C++ jest na C oparty, ale to nie to samo.
Natomiast:
A. z uwagi na zależny od implementacji name mangling w C++, C jest typowym językiem do pisania interfejsów bibliotecznych.
B. systemy udostępniają z reguły API w C. Dostępne z C++, ale to wciąż C. Nowsze standardy (tak C jak C++) to zmieniają, ale jeśli potrzebujesz porozumieć się z systemem i tak możesz być na C skazany.

0

@alagner:
Czy język C pozwala też w pewnym stopniu zrozumieć asm ? Co bardzo kiedyś chciałbym umieć - ale wydaje mi się za ciężki jak na razie

I dodatkowe pytanie:
dlaczego wszyscy tak gloryfikują "pythona" ? A z wypowiedzi @alagner daje się odczuć jakby go odradzał

cyt @alagner

nie liczyłbym Pythona jako typowego języka skryptowego. Tzn. on jest skrytpowy niewątpliwie i można go używać jako basha na sterydach

więc na czym najlepiej się skupić ?

3
zkubinski napisał(a):

@alagner:

Czy język C pozwala też w pewnym stopniu zrozumieć asm ? Co bardzo kiedyś chciałbym umieć - ale wydaje mi się za ciężki jak na razie

Jak dla ciebie to zacznij od nauki czytania ze zrozumieniem to pomoże nie we wszystkim, bo "... z wypowiedzi @alagner daje się odczuć jakby go odradzał ..." wynika że czytanie ze zrozumieniem jest nadal dla ciebie czarną magią a z tego powodu nic nie rozumiesz z dokumentacji.

zkubinski napisał(a):

więc na czym najlepiej się skupić ?

Pytasz ogólnie czy na twoją miarkę? Bo to są różne pytania.

1
zkubinski napisał(a):

@kq:

Jak znasz C++ to siłą rzeczy i tak będziesz musiał znać C jeśli mowa o jakikolwiek sensownym poziomie kompetencji

dlaczego ? Przecież C++ jest "nowszą" wersją C

Jest jego (prawie) nadzbiorem. T.j. prawie każdy program w C jest poprawnym programem w C++, chociaż są rzeczy, na które C pozwala, a C++ nie (chociażby nazwanie zmiennej class). Da się pisać aplikacje w czystym C++, ale to C jest lingua franca programowania, więc jeśli kiedykolwiek chcesz użyć jakiejś nie-C++ biblioteki (np. api systemowego) to musisz choć trochę C ogarniać.

0

czy LEPIEJ pisać funkcje zwrotne ? Czy sygnały i sloty ?

W temacie pytania - wg mnie zależy od zastosowania. Zakładając, że projekt to Qt/C++:

  1. Funkcje zwrotne (callback)
  • używałbym pewnie z jakimiś libkami, które wystawiają interfejs wymagający callbacków
  1. sygnały/sloty:
  • zakładam, że nie chodzi dokładnie o kod jak przedstawiony w pytaniu, bo dla takiego sygnały/sloty nie będzie działać, ponieważ nie ma pętli komunikatów
  • jeden sygnał może odpalić więcej niż jeden slot, wiele sygnałów może odpalić ten sam slot
  • wbudowana "obsługa" sygnalizacji między wątkami

1 użytkowników online, w tym zalogowanych: 0, gości: 1