🚀 go-pugleaf

W dniu środa, 25 marca 2020 13:26:40 UTC+1 użytkownik (fir) napisał:
> W dniu wtorek, 24 marca 2020 21:31:01 UTC+1 użytkownik Maciek Godek napisał:
> > W dniu piątek, 20 marca 2020 20:56:20 UTC+1 użytkownik (fir) napisał:
> > > W dniu środa, 11 marca 2020 15:00:46 UTC+1 użytkownik Mateusz Viste napisał:
> > > > 2020-03-11 o 04:45 -0700, Maciek Godek napisał:
> > > > > Jak lubisz, to sobie używaj.
> > > > 
> > > > I w zasadzie na tym możnaby zakończyć ten wątek. :)
> > > > 
> > > > My "wiemy", że C jest lepsze bo jest proste i przejrzyste bez żadnych
> > > > wodotrysków przez które człowiek gubi się w tym co tak naprawdę się
> > > > dzieje, a heby "wie" że C++ posiada trylion wynalazków których nie
> > > > potrzeba na nowo wymyślać i dlatego jest lepszy, a rozumieć jak co
> > > > działa nie ma potrzeby bo od tego są interfejsy by ukrywać detale
> > > > implementacji.
> > > > 
> > > > Oba obozy mogą się tak sprzeczać w nieskończoność... Tylko czy to ma
> > > > sens? Wszak o gustach się nie dyskutuje, a cała polemika "C vs C++"
> > > > rozbija się właśnie o gust (oraz poniekąd o sposób myślenia czy ogólniej
> > > > podejście do życia). Tak czy siak - nikt nikogo tu nie przekona.
> > > > 
> > > nie jest tak poniewaz ten trylion wynalazkow c++ jest poprostu glupi i 'pozwala' pisac dosyc glupi kod - kod ktory w c mozna napisac duzo madrzej
> > > 
> > > same te 'wynalazki' c są dużo mądrzejsze
> > > i robia nawet wlasnie imponujace mozna
> > > pwoiedziec wrazenie (mz programowanie robi wrazenie samo w sobie, c po swojej stronie robi mozna powiedziec nawet osobne wrazenie jako sposob programowania), (choc i w c znalazly sie pewne flaws, (mysle np o wskaznikach na funkcje i na pewnych kwestiach zwiazanych ze wskaznikami w c w ogole) te flaws trudno mi ejdnak porownac do tych z c++ bo sa generalnie 'duzo trudniejsze' tj mz duzo trudniej jest powiedziec co dokladniej byloby dobre na ich miejsce)
> > 
> > Co jest Twoim zdaniem nie tak ze wskaźnikami w C (i w szczególności ze wskaźnikami na funkcje)?
> 
> sęk w tym ze trudo wlasnie jest dokladnie powiedziec co jest zle (jesli mowa o wskaznikach) ale moim zdaniem da sie zauwazyc ze cos tu jest zle
> 
> jedna z rzeczy ktore chyab moge wymienic 
> to prawdopodobnie takie rzeczy jak:
> 
> int*** x;
> 
> gdzie aby zapisac cos do do celowego inta piszesz ***x = 10;
> jest to prawdopodobnie zle, lepiej (prawodopodobnie) bylob by tym docelowym x'em bylo x
> 
> int*** x;
>  x = 10;
> (a te dodatkowe wskazniki byly by pewnie dostepne przez &x &&x i &&&x)
> 
> jednakowoz jest to trudny temat i troszke ciezki w romowie

Nie mam tego zbyt głęboko przemyślane, ale "z daleka" wygląda mi raczej na kwestię kosmetyczną. Thompson i Ritche zresztą raczej by zalecali styl deklaracji

int ***x;

który lepiej uwypukla symetrię pomiedzy deklaracją a użyciem (tzn. że ***x jest typu int).

Pominę kwestię, że w rzeczywistym kodzie rzadko kiedy korzystam z więcej niż dwóch poziomów przekierowania.

> co do tego co jest zle we wskaznikach na funkcje to jest nieco prostsze choc tez nie calkiem, jedna z rzeczy jest to ze takie wskazniki na funkcje jak w c (z takim pilnowaniem typu) sa dosyc malo uzyteczne, inna rzecz to ze np te nazywy typow uzywane w c sa po prostu zle (chyba  nawet zaloze watek na comp.lang.c z pytaniem/propozycja przemyslenia jak to poprawic, tak ze jak kolega zainteresowany mozna tam rzucic okiem czy cos z tego watku wyjdzie)

Rzuciłem okiem, ale nie mogę powiedzieć, żebym coś z tego zrozumiał :]

W moim odczuciu wskaźniki na funkcje są najbardziej użytecznym i elastycznym środkiem abstrakcji w języku C (no i też trudno sobie wyobrazić przenośnego UNIXa bez tego mechanizmu, gdzie deskryptor plików to - może w pewnym uproszczeniu - krotka wskaźników na funkcje (read, write, ioctl)).

Może pewnym kłopotem jest to, że składnia deklaracji faktycznie nie jest zachwycająco prosta - pod tym względem chyba najkorzystniej wypadają języki funkcyjne w rodzaju Haskella czy MLa (tylko że w ich przypadku to są "nie do końca wskaźniki").

Ale też nie jest to problem, z którym nie dałoby się poradzić (zwłaszcza jeżeli się umiejętnie korzysta z typedefów)