W dniu 2013-10-11 23:19, Marek Borowski pisze:
> To jest wylacznie kwestia gustu. Ja tam wlasnie bardzo lubie C
> za mozliwosc bardzo zwiezlego zapisu. To jest wylacznie
> kwestia przyzwyczajenia.
>
> v++; v+=5; *p = v ? v : v+1; while(f); sa bardzo ok.
>
> zato niedobrze mi sie robi na mysl ze mialbym to zapisywac w postaci:
>
> let v := v + 1
>
> if v<>0 then
> begin
> derefrence p := v
> end
> else
> begin
> derefrence p := v + 1
> end
> endif
>

Masz rację, kwestia przyzwyczajenia. Zaczynałem od Pascala (uczono w
szkole) i niedobrze mi się robiło widząc C. Taki switch/case na przykład:
switch(c)
{
case 'a':fun1();
break;
case 'b':fun2();
break;
}

case pascal of
'a': proc1;
'b': fun1(7);
end;

i sporo innych dziwactw i pułapek C ( if(a=b) ). Ale przesiadłem się na
C i przyzwyczaiłem.




--
Michał

do góry

W dniu 2013-10-11 16:57, J.F pisze:
> Bo ja wiem czy taki wydumany ... robisz np sterownik silnika spalinowego.
> Albo windy, czy serwonapedu, albo plottera, UPS, ... czy np sterownik
> PLC (tzn nie uzyc gotowego, tylko robic wlasny).

Winda: główna logika działania stała, albo lepiej - odrębna, bo można
zmienić logikę bez zmiany sprzętu i odwrotnie. Maszyna stanów otrzymuje
sygnały typu wciśnięto przycisk n kasety, impuls z m czujnika położenia,
teraz ma załączyć bieg 1 silnika (czy podać napięcie na falownik),
wysłać do displeja/ów że jest na piętrze takim, porusza się góra/dół
itp. Może warto podzielić na kilka maszyn. Osobno mamy funkcję czytania
powiedzmy kasety windy - może każdy klawisz jest na osobnym kablu, może
jakiś RS485, CAN, czy inny - tym się zajmie zestaw funkcji, które będą
zależały od sprzętu. Program główny robi init urządzenia czytającego
przyciski, jakie by ono nie było. W ten sposób można zmienić logikę
działania już istniejącej windy zrealizowanej na innym (starszym) sprzęcie.
PLC? tak samo. Masz jakiś interpreter kodu programu, który nie zależy od
sprzętu. Masz I/O zależne od sprzętu więc te funkcje przerabiasz pod
konkretny uC.

> Ale dawniej ... trzeba sie bylo zmiescic w rynkowej cenie i
> znacznie mniejszym hardware. I na HAL nie bylo miejsca.

Zgadzam się w 100%. Tylko że wtedy (rok '90 +/- 4) nie było w
urządzeniach dotykowych wyświetlaczy lcd kolorowych, nie było ethernetu,
USB, kart SD. Wszystko było mocno ograniczone. Pewne zastosowania
wymagały żyłowania sprzętu, teraz byle nowszy procek za 15zł zrobi to
samo z użyciem 20% jego zasobów. Teraz każdy chce bezprzewodowo,
szyfrowane, kompatybilne z pozostałymi urządzeniami itd. Procesory się
zmieniają, są coraz lepsze, szybsze, tańsze i kto nie nadąży za tym
galopującym postępem zostanie w tyle, niezauważony.


--
Michał

do góry

W dniu 11.10.2013 17:28, Sebastian Biały pisze:
> On 2013-10-11 08:43, Zbych wrote:
>>>> Słaby przykład, w gcc można zrobić destruktor w C.
>>> I wtedy mamy jaki język?
>> Jeśli pijesz do tego, że nie jest to czyste C, to argument jest
>> chybiony. Przerwań też nie masz w C (ani w C++).
>
> Rozróżnij:
>
> a) implementacje funckjonalności od idiomu RAII.

A ty spróbuj rozróżnić krytykę przykładu, od krytyki idei.

> b) implementacje w C++ od impelmentacji w "czymś" nieprzenośnym.

To coś nieprzenośne ma taką samą przenośność jak gcc, czyli i tak sporą.

> ad a) Muszę wypełnić idiom RAII jakimś kodem, cli/sei nadawało się
> najlepiej.
>
> ad b) Pisanie w wynalazkach kończy się nieprzenosnym kodem, a na
> horyzoncie sprintem zapierd... clang.

Clang i tak powoli implementuje różne wynalazki z gcc, bo jest ciśnienie
na kompilowanie tym kernela, który nie stroni od różnych rzeczy
specyficznych dla gcc.

do góry

Użytkownik Sebastian Biały napisał:
> On 2013-10-11 17:43, Sylwester Łazar wrote:
>> No i dorzucił trochę koloru do Linuxa i zmieścił się w procku.
>> Teraz po naciśnięciu książki telefonicznej czeka tylko 100ms i już ma 10
>> pierwszych numerów z bazy danych na ekranie.
>> A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms
>
> Po 10 latach pisania kodu. Taki system operacyjny i GUI w asm nie
> istnieje *nigdzie* jako działający poważnie produkt. Nie dlatego że się
> nie da tylko dlatego że nie ma to żadnego sensu.

Sens jest, ale nakład pracy niewspółmierny zwłaszcza że są to obecnie
produkty na rok góra 2 a nie 10 jak dawniej. Widzę taki głupi trend w
komórkach że nawet poprawek się unika bo produkt przechodzi phase out
szybciej niż cykl wprowadzenia poprawki. A pamiętam sprzed bodaj 8 lat
SE T68i gdzie po zmianie parametrów sieci operatora (chyba era)
wypuszczono nowy soft i był wgrywany na koszt producenta mimo że model
już dawno był po gwarancji i nie produkowany.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

W dniu 2013-10-11 14:49, Sylwester Łazar pisze:
> W C przenosimy kod, mając nadzieję, że on się skompiluje po prostu innym
> kompilatorem i na dodatek będzie działał.

W przypadku kompilatorów asemblera jest dużo gorzej. Przynajmniej było
jak pisałem na '51 w asemblerze.

--
Michał

do góry