NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Pascal kontra C: Czy naprawdę C przewyższa czytelnością i wygodą w programowaniu?
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
J.F
Guest
Guest
Tue Jan 28, 2014 12:04 am
Użytkownik "JDX" napisał w wiadomości grup
On 2014-01-27 18:34, J.F wrote:
Quote:
A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++
juz
sobie dobrze radzi z liczbami zespolonymi ?
Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++
daleki byl
od doskonalosci.
Podejrzewam (bo nie porównywałem), że C++ obecnie radzi sobie z
liczbami
zespolonymi tak samo dobrze jak Fortran. W każdym razie w bibliotece
standardowej ma wsparcie dla tych liczb:
http://en.cppreference.com/w/cpp/numeric/complex .
juz
sobie dobrze radzi z liczbami zespolonymi ?
Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++
daleki byl
od doskonalosci.
Podejrzewam (bo nie porównywałem), że C++ obecnie radzi sobie z
liczbami
zespolonymi tak samo dobrze jak Fortran. W każdym razie w bibliotece
standardowej ma wsparcie dla tych liczb:
http://en.cppreference.com/w/cpp/numeric/complex .
Wlasnie o to chodzi - w Fortranie napiszesz a+b, to wygeneruje kilka
instrukcji dla koprocesora dodajacy odpowiednie rejestry, a tu to
nawet nie wiem - jest inline, czy wywola funkcje ?
Funkcja w Fortranie jak ma zwrocic zespolony wynik, to zwraca w dwoch
rejestrach, a w C++ chyba to wykracza poza typy podstawowe, wiec
trzeba obiekt, pamiec na niego alokowac, potem zwalniac ... i operacja
a+b moze sie zrobic powaznym programem.
Quote:
Takie np odwrocenie tablicy zespolonej rownie elegancko jak w
Fortranie
daje sie zapisac i rownie szybko idzie ?
Elegancko macierze to się odwraca w Matlabie (i klonach):
http://www.mathworks.com/help/matlab/ref/inv.html.
A jak to się robi w Fortranie?
Fortranie
daje sie zapisac i rownie szybko idzie ?
Elegancko macierze to się odwraca w Matlabie (i klonach):
http://www.mathworks.com/help/matlab/ref/inv.html.
A jak to się robi w Fortranie?
Elegancko sie uzywa funkcji z biblikoteki numerycznej. Ale ja o tym
jak taka funkcje samemu napisac :-)
J.
A.L.
Guest
Guest
Tue Jan 28, 2014 12:16 am
On Mon, 27 Jan 2014 21:00:00 +0100, Jaros?aw Soko?owski
<jaros@lasek.waw.pl> wrote:
Quote:
Pan J.F napisał:
A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++ juz
sobie dobrze radzi z liczbami zespolonymi ?
Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++ daleki
byl od doskonalosci.
Takie np odwrocenie tablicy zespolonej rownie elegancko jak w
Fortranie daje sie zapisac i rownie szybko idzie ?
To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
następcy jeśli już, to dopiero po dopisaniu do nich jakichś bibliotek.
Edisony jakieś te wszystkie języki pisały, czy co?
A z drugiej strony - uzyles f2c, wiec ominales problem ... ale C++ juz
sobie dobrze radzi z liczbami zespolonymi ?
Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++ daleki
byl od doskonalosci.
Takie np odwrocenie tablicy zespolonej rownie elegancko jak w
Fortranie daje sie zapisac i rownie szybko idzie ?
To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
następcy jeśli już, to dopiero po dopisaniu do nich jakichś bibliotek.
Edisony jakieś te wszystkie języki pisały, czy co?
Fortran wie ze a + (b + c) != (a + b) + c, a inne jezyki nie wiedza
A.L.
RoMan Mandziejewicz
Guest
Guest
Tue Jan 28, 2014 12:20 am
Hello Hebisch,
Monday, January 27, 2014, 10:44:15 PM, you wrote:
[...]
Quote:
- ma pozwalać na zwięzły i czytelny zapis programu
Oksymoron. W ogóle pisanie w kontekście C o czytelnym kodzie to kpina.
[...]
--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)
J.F
Guest
Guest
Tue Jan 28, 2014 12:51 am
Użytkownik "RoMan Mandziejewicz" napisał w wiadomości
Hello Hebisch,
[...]
Quote:
- ma pozwalać na zwięzły i czytelny zapis programu
Oksymoron. W ogóle pisanie w kontekście C o czytelnym kodzie to
kpina.
Oksymoron. W ogóle pisanie w kontekście C o czytelnym kodzie to
kpina.
Alez skad. Sa konstrukcje ... ale nie musisz ich uzywac.
Nie podoba sie Sum+=*Bufptr++, to napisz
Sum=Sum+ Buf[i] ;
i=i+1 ;
J.
J.F
Guest
Guest
Tue Jan 28, 2014 12:56 am
Użytkownik "A.L." napisał w wiadomości
On Mon, 27 Jan 2014 21:00:00 +0100, Jaros?aw Soko?owski
Quote:
To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
następcy jeśli już, to dopiero po dopisaniu do nich jakichś
bibliotek.
Edisony jakieś te wszystkie języki pisały, czy co?
Fortran wie ze a + (b + c) != (a + b) + c, a inne jezyki nie wiedza
na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
następcy jeśli już, to dopiero po dopisaniu do nich jakichś
bibliotek.
Edisony jakieś te wszystkie języki pisały, czy co?
Fortran wie ze a + (b + c) != (a + b) + c, a inne jezyki nie wiedza
My tu o liczbach zespolonych a nie zerowych :-)
W C wprowadzili "unary plus"
Piszesz a+ (+(b+c)) i liczy tak jak zapisane, a nie w dowolnej
kolejnosci.
J.
RoMan Mandziejewicz
Guest
Guest
Tue Jan 28, 2014 1:05 am
Hello J.F,
Tuesday, January 28, 2014, 12:51:19 AM, you wrote:
Quote:
- ma pozwalać na zwięzły i czytelny zapis programu
Oksymoron. W ogóle pisanie w kontekcie C o czytelnym kodzie to
kpina.
Alez skad. Sa konstrukcje ... ale nie musisz ich uzywac.
Oksymoron. W ogóle pisanie w kontekcie C o czytelnym kodzie to
kpina.
Alez skad. Sa konstrukcje ... ale nie musisz ich uzywac.
Jasne. Tylko czasem analizować działanie cudzego programu trzeba. I
zaczynajš się wytryski fantazji programistycznej...
Quote:
Nie podoba sie Sum+=*Bufptr++, to napisz
Sum=Sum+ Buf[i] ;
i=i+1 ;
Sum=Sum+ Buf[i] ;
i=i+1 ;
Ależ ja wiem, co to wskaniki. Nawet w Pascalu dało się nimi operować
- trochę to kulawe było ale było. Tyle, że takie podejcie uzależnia
od fizycznej struktury danych w pamięci. O ile w przypadku drobnych
programów w ľC jeszcze to ujdzie, to już w dużych programach, z
założenia przenonych, wišzanie się z fizycznš strukturš danych może
być kulš u nogi.
--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)
A.L.
Guest
Guest
Tue Jan 28, 2014 1:36 am
On Mon, 27 Jan 2014 13:44:15 -0800 (PST), hebisch@math.uni.wroc.pl
wrote:
Quote:
Dziś kompilatory optymalizujące dla C są łatwo dostępne, więc można
nie doceniać możliwici użycia prostego kompilatora. Ale w pierwszych
latach C kompilatory dla mini i mikrokomuterów były badziewiate.
nie doceniać możliwici użycia prostego kompilatora. Ale w pierwszych
latach C kompilatory dla mini i mikrokomuterów były badziewiate.
Nie byly badziewne. Pierwsze kompilatory C byly doskonale, na dlugo
zanim pojawily sie pecety. W C byl i jest pisany UNIX. Gdy Pecety sie
pojawily, kompilatory C bazowaly na technice kompilacji kompilatorow
Unixowych i byly naprawde doskonale. Zas kompilatory Pascala bazowaly
na p-kodzie i maszynie wirtualnej
Jak idzie o optymalizacje, to optymalizacja nei jest specjalnie
krytyczna
Quote:
Kompilator Pascala wie kiedy ma do czynienia
z tablią i zwykle (z wyjątkiem niekiedy dodawanyc konstrukcji
w stylu C) zna rozmiar tablicy więc może automatycznie wstawić
instrukcje sprawdzające czy indeks mieści się w granicach.
No i wlasnei dlatego program w Pascalu jest wolniejszy niz w C
Quote:
W sumie: jak masz dobry kompilator Pascala to może on
mieć zalety w porównaniu z C. Ale jest spora szansa
że C wygra ze względu na większą dostępność narzędzi
i bibliotek.
mieć zalety w porównaniu z C. Ale jest spora szansa
że C wygra ze względu na większą dostępność narzędzi
i bibliotek.
Nei nalezy porownywac pomarancz z jablkami. Pascal to silnie typowany
jezyk wysokiego poziomu, C to "strukturalizowany asembler" dla
zastosowan gdzie neisbedny jest bliski kontakt z "metalem"
NA dodatek, Pascal ma pewne cechy ktore powoduja ze musi wykonywac sie
wolniej niz C. Oprocz indeksow tablic (patzr wyzej) sa "zanurzone
procedury" (nested procedures) ktore wymahaja aby dostep do pewnych
elementow byl okreslany w czasie wykonania programu.
Dodatkowe problemy sa historyczne. Pascal zrobil sie populatny gdy
pojawil sie kompilator Ammana bazuajcy na p-kodzie, ktory umozliwial
latwe przenoszenie na inne maszyny. Kopmilatory Pascala albo
poprzestawaly na p-kodzie i jego interpretacji, albo kompilowaly p-kod
do kodu maszyny. Niektore (kompilator dla ICL1900, czylo Odry 1305)
generowaly nierelokowalny kod maszynowy zamiast generacji p-kodu.
Oczywiscie, to wszystko plus prostota rekursywnych parserow LL(1)
powodowala ze generowany kod nei byl piorunujacej jakosci.
Optymalizacja zas nei zawsze jest pozadana. Wiadomo ze a + (b+c) nei
rowna sie czasami (a+b)+c, a optymalizujacy kompilator usunie nawiasy
jako pierwsza czynnosc. No, chyba ze to jest kompilator Fortranu...
A.L.
P.S> A przyczyna zwiezlosci C jest prosta: gdy uzywa sie {} zamiast
begion/end, krazek tasmy papierowej jest znacznie mniejszy...
A.L.
Guest
Guest
Tue Jan 28, 2014 1:38 am
On Tue, 28 Jan 2014 01:05:33 +0100, RoMan Mandziejewicz
<roman@pik-net.pl.invalid> wrote:
Quote:
Hello J.F,
Tuesday, January 28, 2014, 12:51:19 AM, you wrote:
- ma pozwalać na zwięzły i czytelny zapis programu
Oksymoron. W ogóle pisanie w kontekście C o czytelnym kodzie to
kpina.
Alez skad. Sa konstrukcje ... ale nie musisz ich uzywac.
Jasne. Tylko czasem analizować działanie cudzego programu trzeba. I
zaczynają się wytryski fantazji programistycznej...
Nie podoba sie Sum+=*Bufptr++, to napisz
Sum=Sum+ Buf[i] ;
i=i+1 ;
Ależ ja wiem, co to wskaźniki. Nawet w Pascalu dało się nimi operować
- trochę to kulawe było ale było. Tyle, że takie podejście uzależnia
od fizycznej struktury danych w pamięci.
Tuesday, January 28, 2014, 12:51:19 AM, you wrote:
- ma pozwalać na zwięzły i czytelny zapis programu
Oksymoron. W ogóle pisanie w kontekście C o czytelnym kodzie to
kpina.
Alez skad. Sa konstrukcje ... ale nie musisz ich uzywac.
Jasne. Tylko czasem analizować działanie cudzego programu trzeba. I
zaczynają się wytryski fantazji programistycznej...
Nie podoba sie Sum+=*Bufptr++, to napisz
Sum=Sum+ Buf[i] ;
i=i+1 ;
Ależ ja wiem, co to wskaźniki. Nawet w Pascalu dało się nimi operować
- trochę to kulawe było ale było. Tyle, że takie podejście uzależnia
od fizycznej struktury danych w pamięci.
Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem
A.L.
A.L.
Guest
Guest
Tue Jan 28, 2014 1:45 am
On Tue, 28 Jan 2014 00:56:27 +0100, "J.F"
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Użytkownik "A.L." napisał w wiadomości
On Mon, 27 Jan 2014 21:00:00 +0100, Jaros?aw Soko?owski
To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
następcy jeśli już, to dopiero po dopisaniu do nich jakichś
bibliotek.
Edisony jakieś te wszystkie języki pisały, czy co?
Fortran wie ze a + (b + c) != (a + b) + c, a inne jezyki nie wiedza
My tu o liczbach zespolonych a nie zerowych :-)
W C wprowadzili "unary plus"
Piszesz a+ (+(b+c)) i liczy tak jak zapisane, a nie w dowolnej
kolejnosci.
On Mon, 27 Jan 2014 21:00:00 +0100, Jaros?aw Soko?owski
To mnie zawsze wprawiało w pewną zadumę. Fortran od dziecka rachował
na liczbach zespolonych jak na każdych innych. Zaś jego bezpośredni
następcy jeśli już, to dopiero po dopisaniu do nich jakichś
bibliotek.
Edisony jakieś te wszystkie języki pisały, czy co?
Fortran wie ze a + (b + c) != (a + b) + c, a inne jezyki nie wiedza
My tu o liczbach zespolonych a nie zerowych :-)
W C wprowadzili "unary plus"
Piszesz a+ (+(b+c)) i liczy tak jak zapisane, a nie w dowolnej
kolejnosci.
Nie jestem pewien. Link do standardu?...
A.L.
Zbych
Guest
Guest
Tue Jan 28, 2014 8:42 am
W dniu 2014-01-27 23:45, J.F pisze:
Quote:
Pascal w zasadzie potrafi to samo co C, choć program może być
nieco dłuższy jeśli skróty w C trzeba wyekspandować (program
w Pascalu może też być krótszy). Ale w C jest de facto standard
pozwalający zrobić sporo niskopoziomowych rzeczy. Np:
/* Diable watchdog timer */
WDTCTL = WDTPW | WDTHOLD;
Akurat tu .. Pascala latwo rozszerzyc o operacje bitowe, zas C nie
gwarantuje jednolitej kompilacji powyzszego.
W obliczu roznych mozliwosci procesora i sprzetowych rejestrow nie
wiadomo jak C to skompiluje.
nieco dłuższy jeśli skróty w C trzeba wyekspandować (program
w Pascalu może też być krótszy). Ale w C jest de facto standard
pozwalający zrobić sporo niskopoziomowych rzeczy. Np:
/* Diable watchdog timer */
WDTCTL = WDTPW | WDTHOLD;
Akurat tu .. Pascala latwo rozszerzyc o operacje bitowe, zas C nie
gwarantuje jednolitej kompilacji powyzszego.
W obliczu roznych mozliwosci procesora i sprzetowych rejestrow nie
wiadomo jak C to skompiluje.
Akurat w tym przykładzie kompilator nie ma zbyt dużego wyboru i poza
zmianą sposobu adresacji rejestru nie może nic fikuśnego wygenerować.
Gorzej z konstrukcjami typu:
rejestr |= stała
rejestr &= stała
rejestr ^= stała
rejestr.bit = stała
Bo może się okazać że taka modyfikacja rejestru wcale nie jest atomowa.
Zbych
Guest
Guest
Tue Jan 28, 2014 8:54 am
W dniu 2014-01-28 08:42, Zbych pisze:
Quote:
W dniu 2014-01-27 23:45, J.F pisze:
Pascal w zasadzie potrafi to samo co C, choć program może być
nieco dłuższy jeśli skróty w C trzeba wyekspandować (program
w Pascalu może też być krótszy). Ale w C jest de facto standard
pozwalający zrobić sporo niskopoziomowych rzeczy. Np:
/* Diable watchdog timer */
WDTCTL = WDTPW | WDTHOLD;
Akurat tu .. Pascala latwo rozszerzyc o operacje bitowe, zas C nie
gwarantuje jednolitej kompilacji powyzszego.
W obliczu roznych mozliwosci procesora i sprzetowych rejestrow nie
wiadomo jak C to skompiluje.
Akurat w tym przykładzie kompilator nie ma zbyt dużego wyboru i poza
zmianą sposobu adresacji rejestru nie może nic fikuśnego wygenerować.
Pascal w zasadzie potrafi to samo co C, choć program może być
nieco dłuższy jeśli skróty w C trzeba wyekspandować (program
w Pascalu może też być krótszy). Ale w C jest de facto standard
pozwalający zrobić sporo niskopoziomowych rzeczy. Np:
/* Diable watchdog timer */
WDTCTL = WDTPW | WDTHOLD;
Akurat tu .. Pascala latwo rozszerzyc o operacje bitowe, zas C nie
gwarantuje jednolitej kompilacji powyzszego.
W obliczu roznych mozliwosci procesora i sprzetowych rejestrow nie
wiadomo jak C to skompiluje.
Akurat w tym przykładzie kompilator nie ma zbyt dużego wyboru i poza
zmianą sposobu adresacji rejestru nie może nic fikuśnego wygenerować.
Chociaż jak rejestr jest odpowiednio długi, to też jest miejsce na
fantazję kompilatora (i problemy).
Piotr Gałka
Guest
Guest
Tue Jan 28, 2014 10:22 am
Użytkownik "Grzegorz Niemirowski" <gnthexfiles@poczta.onet.pl> napisał w
wiadomości news:lc6clu$eb3$1@node2.news.atman.pl...
Quote:
Irokez <no.email@wp.pl> napisał(a):
W dniu 2014-01-27 07:50, Grzegorz Kurczyk pisze:
ale z czasem nie dziwi mnie zapis typu Sum+=*BuffPtr++ i jest dla mnie
czytelny od pierwszego rzutu okiem.
o kurr.. co to robi?
Sumuje elementy tablicy. Potwierdzam, to jest czytelne.
Programuję w C od dawna, ale tylko z tydzień w roku.
W dniu 2014-01-27 07:50, Grzegorz Kurczyk pisze:
ale z czasem nie dziwi mnie zapis typu Sum+=*BuffPtr++ i jest dla mnie
czytelny od pierwszego rzutu okiem.
o kurr.. co to robi?
Sumuje elementy tablicy. Potwierdzam, to jest czytelne.
Programuję w C od dawna, ale tylko z tydzień w roku.
Widząc taki zapis mam wątpliwość, czy postinkremetacja dotyczy wskaźnika
(bardziej prawdopodobne), czy wskazywanej wartości (mniej prawdopodobne).
Wolę wstawić nawias, aby jak zajrzę tu za kilka lat nie zastanawiać się na
nowo.
P.G.
Piotr Gałka
Guest
Guest
Tue Jan 28, 2014 10:38 am
Użytkownik "A.L." <alewando@aol.com> napisał w wiadomości
news:4uude9ps6nbgorfb7mqrknafrqkbi7b6no@4ax.com...
Quote:
Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem
Czasem brakuje mi w C dostępu do bitu przeniesienia.
A może jest tylko ja nie wiem ?
P.G.
JDX
Guest
Guest
Tue Jan 28, 2014 10:40 am
On 2014-01-28 10:22, Piotr Gałka wrote:
Quote:
Użytkownik "Grzegorz Niemirowski" <gnthexfiles@poczta.onet.pl
napisał w wiadomości news:lc6clu$eb3$1@node2.news.atman.pl...
Irokez <no.email@wp.pl> napisał(a):
W dniu 2014-01-27 07:50, Grzegorz Kurczyk pisze:
ale z czasem nie dziwi mnie zapis typu Sum+=*BuffPtr++ i jest
dla mnie czytelny od pierwszego rzutu okiem.
o kurr.. co to robi?
Sumuje elementy tablicy. Potwierdzam, to jest czytelne.
Programuję w C od dawna, ale tylko z tydzień w roku. Widząc taki
zapis mam wątpliwość, czy postinkremetacja dotyczy wskaźnika
(bardziej prawdopodobne), czy wskazywanej wartości (mniej
prawdopodobne).
No właśnie, ten zapis jest przykład typowego, niechlujnie napisanego
kodu w imię tzw. "zwięzłości". :-D
Quote:
Wolę wstawić nawias, aby jak zajrzę tu za kilka lat nie zastanawiać
się na nowo.
No pewnie. A w ramach czytelności warto też wstawić spacje po obu
się na nowo.
No pewnie. A w ramach czytelności warto też wstawić spacje po obu
stronach operatora +=. Nawet pomimo tego, że to takie rozrzutne.
J.F
Guest
Guest
Tue Jan 28, 2014 6:01 pm
Użytkownik "Piotr Gałka" napisał w wiadomości
Quote:
Użytkownik "A.L." <alewando@aol.com> napisał w wiadomości
Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem
Czasem brakuje mi w C dostępu do bitu przeniesienia.
A może jest tylko ja nie wiem ?
Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem
Czasem brakuje mi w C dostępu do bitu przeniesienia.
A może jest tylko ja nie wiem ?
Nie ma, bo to wbrew pozorom nie assembler.
No, sa wstawki assemblerowe, da sie to zrobic, ale to juz trzeba
wiecej instrukcji napisac, bo inaczej nie wiadomo jak sie wczesniejsze
skompilowalo.
J.
elektroda NewsGroups Forum Index - Elektronika Polska - Pascal kontra C: Czy naprawdę C przewyższa czytelnością i wygodą w programowaniu?