M.M. <m...@g...pl> napisał(a):

> <f...@g...pl> napisał(a):
>
> > M.M. <m...@g...pl> napisał(a):
> >
> > > fir <f...@g...pl> napisał(a):
> > >
> > > > czy wystepuja jezyki z definiowaniem
> > > > operatorow (inne niz c++, gdzie zresztą
> > > > to definiowanie jest bardzo ograniczone -
> > > > mozna sobie wyobrazic jezyk ze tak swobodnym
> > > > definiowaniem operatorow jak funkcji, moze
> > > > to skrociloby listingi choc trudno powiedziec)
> > >
> > > Czy ja wiem, czy to może istotnie skrócić listingi?
> > > W moim odczuciu, poza nielicznymi wyjątkami, przeładowanie
> > > operatorów tylko utrudnia parsowanie kodu w oczach. Wyjątki o
> > > których mowa to np. zdefiniowanie operatora w standardowej/popularnej
> > > bibliotece co powoduje że oczy każdego programisty dobrze
> > > przywykły do ich używania.
> > >
> >
> > trudno powiedziec, w sumie taki operator (jak z przykladow
> > wczesniej) to tylko troche inny sposob wywolania funkcji
> W Javie nie ma (chyba że jakoś niedawno dodali i nie zdążyłem
> uzupełnić informacji) i nie powoduje to problemów. Wątpię
> aby w językach ogólnego(!) przeznaczenia był jakikolwiek
> sens intensywnego zastępowania wywołań funkcji operatorami,
> nie wspominając nawet o własnym definiowaniu. W językach

trudno powiedziec na ile to by bylo uzyteczne, ale jest to
w syntaktycznym sensie ogolniejsze nic wywolania funkcji i
daje pewne nowe mozliwosci i o tyle jestem w pewnym stopniu za

niesie tez problemy, dla mnie glowny jaki widze polega na tym
ze takie operatorowe pisanie odziela w jakims stopniu od
fizycznej warstwy c, (mniej 'widac' te poszczegolne wywolania,
np jakos latwo napisac przy pomocy operatorow to co w normalnej
wersji by bylo odrzucone np

z = a cat b cat c cat d cat e;
(vel
z = a + b + c + d + e; )


dla scalanis stringow (normalnie jakos takich rzeczy nie
pisze bo pisze to wogole jakos inaczej (na nizszym poziomie)
(i w sumie zapewne lepiej - choc ten przyklad moze jest nieco
fikcyjny)


o samym jezyku w jego przeswitujacej na asma wersji w wydaniu
operatorowym gorzej by sie pewnie myslalo; pewnie tez czesciej
by sie popelnialo bledy np nazwy operatorow i zmiennych nie
moglyby kolidowac itd

zdaje sie jednak ze moglyby byc jednak jakies bonusy, poza
mniejsza liczba nawiasow np 'generyczny' sposob traktowania
funkcji (operator mozna nazwac funkcja) np moznaoczekiwac
ze takie operatory jak init draw print itp bedą traktowane
bardziej generycznie i bedzie np oczekiwane ze dla wszystkich
encjo zdolnych do narysowania sie draw bedzie dostarczone
i tak dalej (to w sumie zachacza o moj stary pomysc 'nctx'
z wieloczlonowymi nazwami jak

draw (Costam* c) at (int x, int y)
{

}

bo to jedno i to samo mniej wiecej z tym ze tu draw at
jest traktowane jako trojargumentowy dwuskładnikowy operator




> specjalistycznych oczywiście jest inaczej, warto konstrukcjom
> używanym najczęściej zaprojektować zwartą syntaktykę - czyli
> nie tylko operatory.
>
> > - jest to oszczedniejsze w znaki w stosunku do wywolan funkcji
> > ale tez o ilestam trudniejsze w czytaniu - z tym ze c w pewnym
> > sensie jest pomyslane dla zaawansowanych, ludzi ktorzy nawykli,
> Niby racja. Ale np. ja co nabiorę wprawy w dziwolągach
> danego języka a potem przez kilka miesięcy nie mam okazji ani
> zawodowo ani hobbystycznie używać/trenować to zapominam. Czas
> który poświęcam na naukę/przypomnienie składni mógłbym lepiej
> spożytkować.
>
> Zadajmy w prośbie o szczerą odpowiedź choćby takie pytanie:
> Ile osób mówiących o sobie że zna dobrze C++ była świadoma
> problemu operatora >> (przesunięcie bitowe) przy szablonach?
>
>
> Pozdrawiam
>
>


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/