-
X-Received: by 10.182.33.4 with SMTP id n4mr14572obi.9.1390859055415; Mon, 27 Jan
2014 13:44:15 -0800 (PST)
X-Received: by 10.182.33.4 with SMTP id n4mr14572obi.9.1390859055415; Mon, 27 Jan
2014 13:44:15 -0800 (PST)
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.nask
.pl!news.nask.org.pl!news.unit0.net!feeder1.cambriumusenet.nl!feed.tweaknews.nl
!209.85.216.88.MISMATCH!f11no7628782qae.1!news-out.google.com!wo6ni13igb.0!nntp
.google.com!uq10no4569348igb.0!postnews.google.com!glegroupsg2000goo.googlegrou
ps.com!not-for-mail
Newsgroups: pl.misc.elektronika
Date: Mon, 27 Jan 2014 13:44:15 -0800 (PST)
In-Reply-To: <b...@g...com>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=156.17.86.7;
posting-account=xhXTtgoAAACKj4068GUBPvd_O6BzRe_o
NNTP-Posting-Host: 156.17.86.7
References: <b...@g...com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3...@g...com>
Subject: Re: Programowanie uC - Pascal, czy C ?
From: h...@m...uni.wroc.pl
Injection-Date: Mon, 27 Jan 2014 21:44:15 +0000
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Xref: news-archive.icm.edu.pl pl.misc.elektronika:658853
[ ukryj nagłówki ]W dniu niedziela, 26 stycznia 2014 18:36:17 UTC-5 użytkownik s...@g...com
napisał:
> 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??
>
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.
Następne wpisy z tego wątku
- 27.01.14 23:45 J.F
- 27.01.14 23:51 J.F
- 28.01.14 00:04 J.F
- 28.01.14 00:16 A.L.
- 28.01.14 00:20 RoMan Mandziejewicz
- 28.01.14 00:51 J.F
- 28.01.14 00:56 J.F
- 28.01.14 01:05 RoMan Mandziejewicz
- 28.01.14 01:36 A.L.
- 28.01.14 01:38 A.L.
- 28.01.14 01:45 A.L.
- 28.01.14 08:42 Zbych
- 28.01.14 08:54 Zbych
- 28.01.14 10:22 Piotr Gałka
- 28.01.14 10:38 Piotr Gałka
Najnowsze wątki z tej grupy
- karta parkingowa
- Wl/Wyl (On/Off) bialy/niebieski
- I3C
- Pytanie o transformator do dzwonka
- międzymordzie USB 3.2 jako 2.0
- elektronicy powinni pomysleć o karierze elektryka
- jak szybko plynie prad
- Płytki Milkv-Duo
- Światłowód między budynkami
- POtrzebny bufor 3.3<>5V, jedonkieruowy, trójstanowy, wąski
- retro
- Bezprzewodowe polączenie Windows z projektorem
- rozklejanie obudowy
- Prośba o identyfikację komponentu
- Smart gniazdko straciło na zasięgu wifi?
Najnowsze wątki
- 2024-11-14 Dobra zmiana
- 2024-11-14 Czy prezydent może ułaskawić od zadośćuczynienia? [A. Lepper odszkodowania]
- 2024-11-14 Gliwice => Network Systems Administrator (IT Expert) <=
- 2024-11-14 Gliwice => Administrator Systemów Sieciowych (Ekspert IT) <=
- 2024-11-13 Filtr do pompy ruskiej
- 2024-11-12 Gdzie kosz?
- 2024-11-13 elektrycznie
- 2024-11-12 Jebane kurwa, kurwy.
- 2024-11-13 karta parkingowa
- 2024-11-13 Wl/Wyl (On/Off) bialy/niebieski
- 2024-11-12 I3C
- 2024-11-13 Kraków => DevOps Engineer (Junior or Regular level) <=
- 2024-11-13 Łódź => Senior SAP HANA Developer <=
- 2024-11-13 Zabrze => Senior PHP Symfony Developer <=
- 2024-11-13 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=