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
inny punkt siedzenia...
Guest
Guest
Mon Jan 27, 2014 7:21 pm
no pochwal się w czym piszą globalnowiochowe platformowe ci...y?
JDX
Guest
Guest
Mon Jan 27, 2014 7:31 pm
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
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 .
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):
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?
Irokez
Guest
Guest
Mon Jan 27, 2014 8:23 pm
W dniu 2014-01-27 07:50, Grzegorz Kurczyk pisze:
Quote:
ale z czasem nie dziwi mnie zapis typu Sum+=*BuffPtr++ i jest dla mnie
czytelny od pierwszego rzutu okiem.
czytelny od pierwszego rzutu okiem.
o kurr.. co to robi?
Fakt, z C jestem cienki, kiedyś na studiach pisałem na i386 w C
koder/dekoder teletransmisyjny z automatyczną korekcją błędów, ale pół
roku wcześniej pisaliśmy w Pascalu więc jak zobaczyliśmy te krzaki... ja
wymęczyłem to jakoś a kumpel wkurzony zaczął od maina i potem poszedł
asemblerem do samego końca.
Fakt, nie wyobrażam sobie bez C pisania konkretnego softu. Jakoś
zabrakło mi motywacji bo to tylko hobbistycznie a język ST jest bliższy
Pascalowi. Na '51 wolałem napisać program w assemblerze.
--
Irokez
Grzegorz Niemirowski
Guest
Guest
Mon Jan 27, 2014 8:39 pm
Irokez <no.email@wp.pl> napisał(a):
Quote:
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?
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.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 12 days, 18 hours, 53 minutes and 20 seconds
Irokez
Guest
Guest
Mon Jan 27, 2014 8:47 pm
W dniu 2014-01-27 20:39, Grzegorz Niemirowski pisze:
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.
Wierzę na słowo
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.
Wierzę na słowo
Na szybko tak szukam ANSI C i coś o tablicach i jest to jednak
czytelniej pokazywane.
No ale skracamy ile się da, nawet ksiądz się wita "pochwa"
ajt
Guest
Guest
Mon Jan 27, 2014 8:52 pm
W dniu 2014-01-27 20:23, Irokez pisze:
Quote:
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?
ale z czasem nie dziwi mnie zapis typu Sum+=*BuffPtr++ i jest dla mnie
czytelny od pierwszego rzutu okiem.
o kurr.. co to robi?
Pobiera wartość wskazywaną przez BuffPtr i dodaje ją do zmiennej sum.
Przy okazji zwiększa wartość BufPtr tak, by wskazywał na kolejny element
Dla mnie ten zapis jest również bardzo czytelny i oczywisty od
pierwszego spojrzenia. Po prostu jeden z bardzo typowych i często
używanych zapisów :)
Quote:
Fakt, z C jestem cienki, kiedyś na studiach pisałem na i386 w C
koder/dekoder teletransmisyjny z automatyczną korekcją błędów, ale pół
roku wcześniej pisaliśmy w Pascalu więc jak zobaczyliśmy te krzaki... ja
wymęczyłem to jakoś a kumpel wkurzony zaczął od maina i potem poszedł
asemblerem do samego końca.
Bardzo lubię(właściwie lubiłem) pisać w C, potem C++; Teraz to bardziej
w stronę php się przesunęło
Ćwiczenia z C wyglądały ciekawie. Świętej pamięci pan Jan Bielecki
polecał zakupić właście co wydaną kolejną książkę i zrobić erratę.
Znawcy jego twórczości zapewne pamiętają, że bardzo lubił popisywać się
znajomością niuansów języka, zamieszczając często w książkach dość
pokręcone przykłady, najeżone znaczkami jak wyżej, więc przeanalizowanie
ich, w celu wykrycia ewentualnych niezgodności z opisem, było niezłą
szkołą :)
--
Pozdrawiam
Andrzej
www.symbiostock.info
JarosĹaw SokoĹowski
Guest
Guest
Mon Jan 27, 2014 8:59 pm
Pan Marek napisał:
Quote:
Kiedyś na uczelni (koniec lat 90) zaproponowałem wykładowcy, że
przeniosę jego kod do symulacji lini pol w silniku do innego
środowiska. Kod napisany w fortranie pod DOS i uruchamiany na pentium
1 ~160MHz.
Przy podstawowych parametrach wejściowych kod pod DOSem potrzebował
ok 30s na obliczenia i narysowanie linii na przekroju silnika.
Przeniosłem to na linuxa, kod fortrana potraktowałem f2c, dodałem
interfejs w Lesstifie. Uruchamiałem to na podobnej maszynce, z tym że
robiła ona za serwer aplikacji X z xdm, z którego korzystało kilka
osób. Jak już wszystko ruszyło i pokazywałem wykładowcy efekt
działania, to był dość zaskoczony, bo z 30 sekund obliczeń na DOS
zrobiło się około 3-4. Wyraził uznanie, że faktycznie to szybciej
działa, ja mu na to, wskazując na kolegę siedzącego na stanowisku
obok i grającego w Quake'a - Wie Pan, może udało by się jeszcze
szybciej ale kolega ma właśnie misję do skończenia i gra też na tej
maszynie, więc prosił aby tą nasza symulację odpalać z mniejszym
nice'em, bo mu trochę gra korbi - mina wykładowcy bezcenna
przeniosę jego kod do symulacji lini pol w silniku do innego
środowiska. Kod napisany w fortranie pod DOS i uruchamiany na pentium
1 ~160MHz.
Przy podstawowych parametrach wejściowych kod pod DOSem potrzebował
ok 30s na obliczenia i narysowanie linii na przekroju silnika.
Przeniosłem to na linuxa, kod fortrana potraktowałem f2c, dodałem
interfejs w Lesstifie. Uruchamiałem to na podobnej maszynce, z tym że
robiła ona za serwer aplikacji X z xdm, z którego korzystało kilka
osób. Jak już wszystko ruszyło i pokazywałem wykładowcy efekt
działania, to był dość zaskoczony, bo z 30 sekund obliczeń na DOS
zrobiło się około 3-4. Wyraził uznanie, że faktycznie to szybciej
działa, ja mu na to, wskazując na kolegę siedzącego na stanowisku
obok i grającego w Quake'a - Wie Pan, może udało by się jeszcze
szybciej ale kolega ma właśnie misję do skończenia i gra też na tej
maszynie, więc prosił aby tą nasza symulację odpalać z mniejszym
nice'em, bo mu trochę gra korbi - mina wykładowcy bezcenna
FORTRAN pod DOS-em działał jakoś wyjątkowo marnie. Sądzę, że został
sklecony naprędce z potrzeby chwili, bo przecież wśród użytkowników
DOS-a była olbrzymia grupa przesiedleńców z mainframe'ów, którym bez
FORTRANu było jakoś tak nijak. Sam używałem mało, ale miałem kolegę
nałogowca, który jakieś symulacyjki w tym wciąż łupał. Gdzieś tak na
przełomie wieków też chciał cos łupność, ale się okazało, że na swoim
laptopie z W98 nie ma kompilatora, za to na moim z linuksem da się
FORTRAN odpalić. Wnioski były podobne -- czas obliczeń o rząd wielkości
krótszy.
--
Jarek
JarosĹaw SokoĹowski
Guest
Guest
Mon Jan 27, 2014 9:00 pm
Pan J.F napisał:
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.
Takie np odwrocenie tablicy zespolonej rownie elegancko jak w
Fortranie daje sie zapisac i rownie szybko idzie ?
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?
--
Jarek
Grzegorz Niemirowski
Guest
Guest
Mon Jan 27, 2014 9:02 pm
Irokez <no.email@wp.pl> napisał(a):
Quote:
W dniu 2014-01-27 20:39, Grzegorz Niemirowski pisze:
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.
Wierzę na słowo
Na szybko tak szukam ANSI C i coś o tablicach i jest to jednak czytelniej
pokazywane.
No ale skracamy ile się da, nawet ksiądz się wita "pochwa"
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.
Wierzę na słowo
Na szybko tak szukam ANSI C i coś o tablicach i jest to jednak czytelniej
pokazywane.
No ale skracamy ile się da, nawet ksiądz się wita "pochwa"
Tutaj odwołanie jest przez wskaźnik, dlatego nie widzisz kwadratowych
nawiasów. Wskaźnik pokazuje na jakiś element bufora. Gwiazdką pobieramy
sobie wskazywany element, a operatorem inkrementującym ++ przesuwamy
wskaźnik na kolejny element. Wartość, którą pobraliśmy, dodajemy do zmiennej
Sum. Ta linijka generalnie pracuje sobie w jakiejś pętli. Jeśli tablica
nazywa się Buff i mamy zmienną indeksową i, wówczas możemy zapisać to tak:
Sum+=Buff[i++];
I akurat tutaj nie jest to kwestia skracania, oba zapisy są podobnie długie.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 12 days, 19 hours, 6 minutes and 53 seconds
Grzegorz Kurczyk
Guest
Guest
Mon Jan 27, 2014 9:29 pm
W dniu 27.01.2014 21:02, Grzegorz Niemirowski pisze:
Quote:
Tutaj odwołanie jest przez wskaźnik, dlatego nie widzisz kwadratowych
nawiasów. Wskaźnik pokazuje na jakiś element bufora. Gwiazdką pobieramy
sobie wskazywany element, a operatorem inkrementującym ++ przesuwamy
wskaźnik na kolejny element. Wartość, którą pobraliśmy, dodajemy do
zmiennej Sum. Ta linijka generalnie pracuje sobie w jakiejś pętli. Jeśli
tablica nazywa się Buff i mamy zmienną indeksową i, wówczas możemy
zapisać to tak:
Sum+=Buff[i++];
I akurat tutaj nie jest to kwestia skracania, oba zapisy są podobnie
długie.
nawiasów. Wskaźnik pokazuje na jakiś element bufora. Gwiazdką pobieramy
sobie wskazywany element, a operatorem inkrementującym ++ przesuwamy
wskaźnik na kolejny element. Wartość, którą pobraliśmy, dodajemy do
zmiennej Sum. Ta linijka generalnie pracuje sobie w jakiejś pętli. Jeśli
tablica nazywa się Buff i mamy zmienną indeksową i, wówczas możemy
zapisać to tak:
Sum+=Buff[i++];
I akurat tutaj nie jest to kwestia skracania, oba zapisy są podobnie
długie.
Zapis ze wskaźnikiem stosowałem w związku z optymalniejszym kodem
wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego elementu
tablicy. Czyli gdy np elementami tablicy Buff były zmienne typu long, to
w pętli za każdym przejściem było liczone wskaźnik do elementu wg wzoru
ptr = adres_bazowy_tablicy_Buff + i * 4; Przy zastosowaniu wskaźnika był
on ustawiany na adres początku tablicy tylko raz przed pętlą, a potem
wewnątrz pętli inkrementację wskaźnika załatwiał jeden rozkaz procesora
ADIW Z, 4
Pozdrawiam
Grzegorz
Grzegorz Niemirowski
Guest
Guest
Mon Jan 27, 2014 9:55 pm
Grzegorz Kurczyk <grzegorz.usun.to@control.slupsk.pl> napisał(a):
Quote:
Zapis ze wskaźnikiem stosowałem w związku z optymalniejszym kodem
wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego elementu
tablicy. Czyli gdy np elementami tablicy Buff były zmienne typu long, to w
pętli za każdym przejściem było liczone wskaźnik do elementu wg wzoru ptr
= adres_bazowy_tablicy_Buff + i * 4; Przy zastosowaniu wskaźnika był on
ustawiany na adres początku tablicy tylko raz przed pętlą, a potem
wewnątrz pętli inkrementację wskaźnika załatwiał jeden rozkaz procesora
ADIW Z, 4
Pozdrawiam
Grzegorz
wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego elementu
tablicy. Czyli gdy np elementami tablicy Buff były zmienne typu long, to w
pętli za każdym przejściem było liczone wskaźnik do elementu wg wzoru ptr
= adres_bazowy_tablicy_Buff + i * 4; Przy zastosowaniu wskaźnika był on
ustawiany na adres początku tablicy tylko raz przed pętlą, a potem
wewnątrz pętli inkrementację wskaźnika załatwiał jeden rozkaz procesora
ADIW Z, 4
Pozdrawiam
Grzegorz
Hm, to ciekawe. Może to przypadłość konkretnej wersji avr-gcc lub kwestia
ustawień kompilacji. Z tego co wiem, współczesne kompilatory na tyle radzą
sobie z optymalizacją, że potrafią wygenerować tak samo szybki kod dla
dostępu wskaźnikowego jak i tablicowego.
http://stackoverflow.com/questions/2305770/efficiency-arrays-vs-pointers
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 12 days, 20 hours, 7 minutes and 48 seconds
Grzegorz Kurczyk
Guest
Guest
Mon Jan 27, 2014 10:11 pm
W dniu 27.01.2014 21:55, Grzegorz Niemirowski pisze:
Quote:
Grzegorz Kurczyk <grzegorz.usun.to@control.slupsk.pl> napisał(a):
Zapis ze wskaźnikiem stosowałem w związku z optymalniejszym kodem
wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego
elementu tablicy. Czyli gdy np elementami tablicy Buff były zmienne
typu long, to w pętli za każdym przejściem było liczone wskaźnik do
elementu wg wzoru ptr = adres_bazowy_tablicy_Buff + i * 4; Przy
zastosowaniu wskaźnika był on ustawiany na adres początku tablicy
tylko raz przed pętlą, a potem wewnątrz pętli inkrementację wskaźnika
załatwiał jeden rozkaz procesora ADIW Z, 4
Pozdrawiam
Grzegorz
Hm, to ciekawe. Może to przypadłość konkretnej wersji avr-gcc lub
kwestia ustawień kompilacji. Z tego co wiem, współczesne kompilatory na
tyle radzą sobie z optymalizacją, że potrafią wygenerować tak samo
szybki kod dla dostępu wskaźnikowego jak i tablicowego.
http://stackoverflow.com/questions/2305770/efficiency-arrays-vs-pointers
Zapis ze wskaźnikiem stosowałem w związku z optymalniejszym kodem
wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego
elementu tablicy. Czyli gdy np elementami tablicy Buff były zmienne
typu long, to w pętli za każdym przejściem było liczone wskaźnik do
elementu wg wzoru ptr = adres_bazowy_tablicy_Buff + i * 4; Przy
zastosowaniu wskaźnika był on ustawiany na adres początku tablicy
tylko raz przed pętlą, a potem wewnątrz pętli inkrementację wskaźnika
załatwiał jeden rozkaz procesora ADIW Z, 4
Pozdrawiam
Grzegorz
Hm, to ciekawe. Może to przypadłość konkretnej wersji avr-gcc lub
kwestia ustawień kompilacji. Z tego co wiem, współczesne kompilatory na
tyle radzą sobie z optymalizacją, że potrafią wygenerować tak samo
szybki kod dla dostępu wskaźnikowego jak i tablicowego.
http://stackoverflow.com/questions/2305770/efficiency-arrays-vs-pointers
To nie tylko kwestia kompilatora ale i możliwości procesora. Przykład,
który podałeś tyczy "dużych" procesorów posiadających rozbudowane tryby
adresowania (32bitowy procesor z rodziny 686). On potrafi sobie policzyć
wskaźnik do elementu tablicy w jednym rozkazie i tu faktycznie nie ma
różnicy. W małym AVR-ku już tak słodko nie ma
Wyliczenie wskaźnika
do elementu tablicy to już kilka rozkazów. A jak tablica ma elementy
typu rekordowego o "dziwnej" liczbie bajtów w rekordzie, to w
wyliczeniach wskaźnika pojawia się czasochłonne mnożenie.
Pozdrawiam
Grzegorz
Guest
Mon Jan 27, 2014 11:44 pm
W dniu niedziela, 26 stycznia 2014 18:36:17 UTC-5 użytkownik stch...@gmail.com napisał:
Quote:
Temat zupełnie luźny do dyskusji. Niee, ekspertem Pascala absolutnie nie jestem, ale zupełnie nieźle poruszam się w tym środowisku programistycznym.
Kto i po jaką cholerę wymiślił C? W zasadzie pisze się programy bardzo
podobnie jak w Pascalu. Ino, że imho jest to zdecydowanie mniej czytelne
niż w Pascalu.
A ileż się nasłuchałem, że w C da się zrobić to, czego w Pascalu się nie da.
I w "sieci" też się o tym naczytałem.. Ino CZEGO DO PANI NĘDZY SIĘ nie da??
Kto i po jaką cholerę wymiślił C? W zasadzie pisze się programy bardzo
podobnie jak w Pascalu. Ino, że imho jest to zdecydowanie mniej czytelne
niż w Pascalu.
A ileż się nasłuchałem, że w C da się zrobić to, czego w Pascalu się nie da.
I w "sieci" też się o tym naczytałem.. Ino CZEGO DO PANI NĘDZY SIĘ nie da??
Wycięłem twoje przykłady bo bardziej wskazują na Twoją niewiedzię niż na
braki C. Narzekasz na najmiej istotne róznice, gdzie spora część
programistów uważa że rozwiązanie z C jest lepsze. Tzn. '{' i '}'
są tak samo czytelne jak 'begin' i 'end' ale krótsze. Pętla 'for'
w C jest bardzo wygodna w użyciu, a jak się do niej przyzwyczaisz
to będzie logiczna. W angielskim '&' jest używany jako skrót słowa
'and' więc jego użycie w iloczynie logicznym jest jak najbardziej
logiczne.
Pytasz się dlaczego wymyślono C. Proste, był potrzebny język
z nastepującymi własnościami:
- ma się dać kompilować głupim kompiltorem (pierwsza maszyna na której
chodziło C mała w porównaniu z innymi uwczesnymi maszynami)
- ma pozwalać na zwięzły i czytelny zapis programu
- ma pozwalać na otrzymanie w miarę wydajnego kodu wynikowego
- ma dawać kontrolę nad maszyną
Z tego punktu widzenia najważniejsze w C są:
- operator rzutowania (cast), bo pozwala na różne niskopoziomowe
sztuczki
- arytmetyka adresowa i konwersja tablic do wskaźników bo pozwala
jawnie zapisać manipulacje potrzebne przy dostępie do tablic
i w ten sposób uniknąć wstawiania przez kompilator potencjalnie
powolnego niejawnego kodu
- orientacja na wyrażenia: np. podstawienia w C są wyrażeniami i
mogą być użyte jako części innych wyrażeń co pozwala na zwięzły
zapis
- '++', '--' i ogólniej operatory modyfikacji jak np. '+=', są zwięzłe
i łatwo dla nich generować wydajny kod
- operatory i pola bitowe, pomagają przy programowaniu sprzętu.
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.
Jak komplator optymalizujący (wtedy niedostępny) dałby kod o
czasie wykonania 1 to badziewiaty kompilator C dawał czas
wykonania np. 1.5 a badziewiaty kompilator Frotranu np. 4 i
szła fama że "C jest szybkie". W efekcie C zdobyło sobie
popularność. Dziś większą rolę odgrywa rozpęd: C jest popularne
więc autorzy kompilatorów (i innych narzędzi) się starają.
Ludzie używają C bo są dobre narzędzia.
C ma parę wad w porównaniu z Pascalem. Najważniejsze jest
luźniejsze sprawdzanie typów, kompilator C względnie łatwo
przepuszcza który w Pascalu sygnalizuje bład typu. W efekcie
można się namęczyć z szukaniem błędu który w Pascalu byłby
usunięty przed pierwszym uruchomieniem programu. W bardziej
trywialnych rzeczy ':=' jako podstawienie i '=' jako porównanie
jest niezwykle tródno pomylić, zaś w C napisanie '=' zamiast
'==' jest jednym z częstszych błędów. Nowoczesne kompilatory
C ostrzegają o wielu konstukcjach które choć legalne to
prawdopodobnie są błędem, ale ciągle to mniej niż może
zrobić kompilator Pascala. Inną wadą w podobnym duchu
jest trudność sprawdzania czy indeksy tablic mieszczą się
w zadanym zakresie. 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.
Kompilator C widzi wskaźnik i nie jest jasne jakie są granice
obszaru zawierającego wskazywany element. To powoduje że
automatyczne sprawdzanie zakresu indeksów jest znacznie
trudniejsze (nie znam "normalnego" kompilatora C który by
to robił).
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;
jest normalnym kodem w C który wstawia wartość do rejestru
WDTCTL (sterowanie watchdoga w MSP430). Dokładniej,
w MSP430 rejestry urządzeń pojawiają się pod magicznymi
adresami pamięci. C ma preprocesor który czyta pliki
nagłówkowe i rozwija makrodefinicje. Plik nagłówkowy dla MSP430
definuje WDTCTL jako makrodeniicję, tak że główna cześć kompilatora
widzi coś w stylu:
*(volatile uint8_t *) 0xsss = 0xzzz | 0xwww;
gdzie '0xsss ' jest magicznym adresem zaś '0xzzz' i '0xwww'
są stałymi. W efekcie kod jest z zasadzie tak samo wydajny
jak kod assemblerowy bezpośrednio piszący do rejestrów
procesora, a czytelność jest znacznie lepsza (można by
chcieć lepszą nazwę niż WDTCT, ale akurat WDTCTL jest
w dokumentacji procesora...). W Pascalu podobna rzecz
wymaga rozszerzeń, najprawdopodobniej manipulacji
na wskaźnikach w stylu C + preprocesor albo 'properties'
w stylu Delphi. Jest spora szansa że jak weźmiesz
współczesny kompilator Pascala to będzie miał jakieś
rozszerzenie pozwalające to zrobić, ale problemem
może być znalezienie choć jednego kompilatora na
daną platformę. Do tego kompilator na inną platformę
może mieć na tyle różne rozszerzenia że będziesz miał
trochę roboty gdybyś chciał przeportować kod.
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.
J.F
Guest
Guest
Mon Jan 27, 2014 11:45 pm
Użytkownik napisał w wiadomości grup
dyskusyjnych:3a3cc0cf-7519-4efc-b7a1-c307d18b9f33@googlegroups.com...
Quote:
Wycięłem twoje przykłady bo bardziej wskazują na Twoją niewiedzię niż
na
braki C. Narzekasz na najmiej istotne róznice, gdzie spora część
na
braki C. Narzekasz na najmiej istotne róznice, gdzie spora część
Tu racje ma A.L. - najpierw nauczyc sie w miare dobrze C, potem
narzekac :-)
Trzeba przyznac ze skladnia C jest "bledogenna" - nawet doswiadczony
programista moze sie latwo pomylic.
Wystarczy ze napisze a=b zamiast a==b i nieszczescie gotowe.
Ale lint lub ostrzezenia kompilatora pozwalaja sporo z nich wykryc.
Quote:
Pytasz się dlaczego wymyślono C. Proste, był potrzebny język
z nastepującymi własnościami:
- ma się dać kompilować głupim kompiltorem (pierwsza maszyna na
której
chodziło C mała w porównaniu z innymi uwczesnymi maszynami)
z nastepującymi własnościami:
- ma się dać kompilować głupim kompiltorem (pierwsza maszyna na
której
chodziło C mała w porównaniu z innymi uwczesnymi maszynami)
No, C i Pascal to mniej wiecej te same lata, a tych kombinacji w C
tyle, ze kompilator Pascala chyba znacznie prostszy.
Quote:
- ma pozwalać na zwięzły i czytelny zapis programu
Juz chyba nie bylo co oszczedzac pojedynczych znakow, a i tak
najwiecej sie na wciecia tracilo
Brak instrukcji "with" w C troche utrudnia zwiezlosc.
Quote:
- ma pozwalać na otrzymanie w miarę wydajnego kodu wynikowego
Tego i Pascal nie wyklucza, no moze z wyjatkiem sprawdzania zakresow
tablic.
Quote:
- ma dawać kontrolę nad maszyną
Pare rozszerzen made in Borland i oba dawaly taka sama.
Quote:
Z tego punktu widzenia najważniejsze w C są:
- operator rzutowania (cast), bo pozwala na różne niskopoziomowe
sztuczki
- operator rzutowania (cast), bo pozwala na różne niskopoziomowe
sztuczki
Wirth by sie obrazil, ale to mozna i do Pascala wprowadzic.
Poza tym nie calkiem jest w C okreslone kiedy rzutujesz, a kiedy jest
konwersja.
Quote:
- arytmetyka adresowa i konwersja tablic do wskaźników bo pozwala
jawnie zapisać manipulacje potrzebne przy dostępie do tablic
i w ten sposób uniknąć wstawiania przez kompilator potencjalnie
powolnego niejawnego kodu
jawnie zapisać manipulacje potrzebne przy dostępie do tablic
i w ten sposób uniknąć wstawiania przez kompilator potencjalnie
powolnego niejawnego kodu
No, na tej arytmetyce mozna lekko osiwiec :-)
Quote:
- orientacja na wyrażenia: np. podstawienia w C są wyrażeniami i
mogą być użyte jako części innych wyrażeń co pozwala na zwięzły
zapis
mogą być użyte jako części innych wyrażeń co pozwala na zwięzły
zapis
Akurat tego bym nie gloryfikowal, malo uzyteczne.
Quote:
- '++', '--' i ogólniej operatory modyfikacji jak np. '+=', są
zwięzłe
i łatwo dla nich generować wydajny kod
zwięzłe
i łatwo dla nich generować wydajny kod
No, roznie z tym bywalo. Kolega kiedys w Pascalu z uwielbieniem pisal
np a+a, az kiedys spojrzal w kod i sie okazalo ze 2*a jest szybsze.
Fakt ze czesto ulatwia zapis.
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.
Jak komplator optymalizujący (wtedy niedostępny) dałby kod o
czasie wykonania 1 to badziewiaty kompilator C dawał czas
wykonania np. 1.5 a badziewiaty kompilator Frotranu np. 4 i
szła fama że "C jest szybkie".
nie doceniać możliwici użycia prostego kompilatora. Ale w pierwszych
latach C kompilatory dla mini i mikrokomuterów były badziewiate.
Jak komplator optymalizujący (wtedy niedostępny) dałby kod o
czasie wykonania 1 to badziewiaty kompilator C dawał czas
wykonania np. 1.5 a badziewiaty kompilator Frotranu np. 4 i
szła fama że "C jest szybkie".
No nie, Fortran jak pisalem potrafil dac dobry kod.
Tylko ze on sie nadawal do obliczen, takiej "kontroli nad sprzetem"
jak C absolutnie nie mial.
Quote:
W efekcie C zdobyło sobie
popularność. Dziś większą rolę odgrywa rozpęd: C jest popularne
więc autorzy kompilatorów (i innych narzędzi) się starają.
Ludzie używają C bo są dobre narzędzia.
Inną wadą w podobnym duchu
jest trudność sprawdzania czy indeksy tablic mieszczą się
w zadanym zakresie. 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.
popularność. Dziś większą rolę odgrywa rozpęd: C jest popularne
więc autorzy kompilatorów (i innych narzędzi) się starają.
Ludzie używają C bo są dobre narzędzia.
Inną wadą w podobnym duchu
jest trudność sprawdzania czy indeksy tablic mieszczą się
w zadanym zakresie. 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.
Ale to akurat umiarkowana zaleta. To ze program sam sprawdzi indeks i
sie wysypie z bledem jest w gotowym programie niedopuszczalne. Program
nie ma sie wysypywac.
A jak programista doda wlasne sprawdzenie ... to mu to od kompilatora
zupelnie niepotrzebne.
Quote:
Kompilator C widzi wskaźnik i nie jest jasne jakie są granice
obszaru zawierającego wskazywany element.
obszaru zawierającego wskazywany element.
No, obsluga tablic wielowymiarowych jest w C cokolwiek komiczna :-)
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;
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.
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.
Biblioteki C w zasadzie mozna by i w Pascalu wykorzystac.
J.
J.F
Guest
Guest
Mon Jan 27, 2014 11:51 pm
Użytkownik "Jarosław Sokołowski" napisał w
Pan J.F napisał:
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.
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?
juz
sobie dobrze radzi z liczbami zespolonymi ?
Bo Fortran raczej nie ma z tym klopotu, ale dawniej kod z C++
daleki
byl od doskonalosci.
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?
No wiesz ... numerycy mieli swojego Fortrana i nie prosili o nic
wiecej, inni nie tykali sie numeryki i tez nie prosili i tak sie to
jakos ustalilo :-)
J.
elektroda NewsGroups Forum Index - Elektronika Polska - Pascal kontra C: Czy naprawdę C przewyższa czytelnością i wygodą w programowaniu?