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. O ile w przypadku drobnych
programów w uC jeszcze to ujdzie, to już w dużych programach, z
założenia przenośnych, 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!)

do góry

On Mon, 27 Jan 2014 13:44:15 -0800 (PST), h...@m...uni.wroc.pl
wrote:

>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 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
>
> 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

>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.

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...

do góry

On Tue, 28 Jan 2014 01:05:33 +0100, RoMan Mandziejewicz
<r...@p...pl.invalid> wrote:

>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.

Do tego wlasnei sluzy C. C jest strukturalizowanym asemblerem

A.L.

do góry

On Tue, 28 Jan 2014 00:56:27 +0100, "J.F"
<j...@p...onet.pl> wrote:

>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.

Nie jestem pewien. Link do standardu?...

A.L.

do góry

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ć.

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.

do góry

W dniu 2014-01-28 08:42, Zbych pisze:
> 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ć.

Chociaż jak rejestr jest odpowiednio długi, to też jest miejsce na
fantazję kompilatora (i problemy).

do góry

Użytkownik "Grzegorz Niemirowski" <g...@p...onet.pl> napisał w
wiadomości news:lc6clu$eb3$1@node2.news.atman.pl...
> Irokez <n...@w...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).
Wolę wstawić nawias, aby jak zajrzę tu za kilka lat nie zastanawiać się na
nowo.
P.G.

do góry

Użytkownik "A.L." <a...@a...com> napisał w wiadomości
news:4uude9ps6nbgorfb7mqrknafrqkbi7b6no@4ax.com...

> 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.

do góry

On 2014-01-28 10:22, Piotr Gałka wrote:
>
> Użytkownik "Grzegorz Niemirowski" <g...@p...onet.pl>
> napisał w wiadomości news:lc6clu$eb3$1@node2.news.atman.pl...
>> Irokez <n...@w...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

> 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
stronach operatora +=. Nawet pomimo tego, że to takie rozrzutne. :-D

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości
>Użytkownik "A.L." <a...@a...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 ?

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.

do góry