W dniu 01.02.2011 23:30, Wojciech Jaczewski pisze:
> W przypadku sterowników urządzeń te magiczne dane można otrzymać z
> urządzenia. Urządzenie zwykle śle strumień bajtów, bez systemu typów.
>
Ten strumień bajtów to np pakiet, który po przeparsowaniu jak
najbardziej należy wpakować w coś z typem a nie operować na char* jak to
programiści urządzeń wbudowanych lubią.

--
Pozdrawiam
Michoo

do góry

R. P. <r...@w...pl> wrote:
> W dniu 2011-01-31 13:50, Slawek Kotynski pisze:
>> fir wrote:
>>> wczoraj rozmaiwajac z kolegą nie programistą pragnąc mu wyjasnic
>>> wsoje zainteresowanie i podejscie do jezykow programowania narysowalem
>>> mu maly wykresik ktory sam mnie lekko zastanowił: chodzilo
>>> o wyjasnienie że dzielę jezyki programowania na dwie grupy: przed
>>> c (i mw 78 rokiem) i te po c (na ktore zreszta c na tyle wplynal ze
>>> jak najbardziej mozna je nazwac jezykami post-c) - samo c nalezaloby do
>>> trzeciej grupy, i chodzilo tez o wyjasnienie jak do tego ma sie moj
>>> wlasny 'projekt' czyli c2 (c z moimi poprawkami)
>>>
>>>
>>> /--------c2
>>> algol \ / / c++ kobol \\ / // Objective-C
>>> simula // c \\ java
>>> fortran / \ c#
>
>> W twoim podziale wstawienie w środek C nie jest niczym uzasadnione.
>
> Jak najbardziej ma znaczenie. Język C przyniósł rewolucję, razem z
> UNIXem. To od niego zaczęła się nowa era programowania. Jest kluczową
> częścią pejzażu technologicznego końca XX wieku (mowa oczywiście o
> technologiach informatycznych). Do dziś kernele większości systemów
> operacyjnych (w tym i najważniejszych - Unix i Linux) pisze się w C. C
> jest centralnym, podstawowym językiem również we współczesnej informatyce.
... jaka rewolucje? Ten specyficzny makroasembler nic
specjalnie nie wniosl, jest tylko popularny;-) BTW, a gdzie
Modula, Rexx czy Perl - ie ma bo to nie jest c-podobne? Z powazaniem
Adam Przybyla

do góry

On Tue, 01 Feb 2011 23:30:25 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>Krzysiek Kowaliczek wrote:
>
>>> Magia typu void*. Nie ma co się rozpisywać. Jako programista
>>> unixowy/linuxowy doskonale wiesz co mam na myśli.
>>>
>>
>> Rozumiem że w programie dostajesz magiczne dane, ponieważ słaby
>> system typów nie uratował Cię od pomyłki?
>
>W przypadku sterowników urządzeń te magiczne dane można otrzymać z
>urządzenia. Urządzenie zwykle śle strumień bajtów, bez systemu typów.
Ba, ale nawet w Pascalu dało się to zrobić elegancko, bez używania
konstrukcji a'la szalony elektronik.

To co zarzuca C A.L. to, moim zdaniem, domyślne pozwolenie na
niskopoziomowe manewry i/lub upowszechnienie się takiego języka jako
języka ogólnego zastosowania. Zachęca to do zajmowania się
niskopoziomowymi szczegółami już na początku, zamiast na końcu, kiedy
to jest potrzebne. W efekcie istnieje presja na powszechne stosowanie
średnio bezpiecznych sztuczek, zamiast promowania, nazwijmy to,
ładnego kodu. Pod tym względem C jest regresem, gdyż dotychczas
większość języków wraz z czasem przechodzi do coraz bardziej
wysokopoziomowych/abstrakcyjnych konceptów, tylko języki rodziny C i
pochodnej idą trochę wbrew tym trendom.

Gdyby C i pochodne pozostały językiem pośrednim przetwarzania
programów z języków wyższego poziomu to tej dyskusji chyba by nie
było.
--
Grzegorz Krukowski

do góry

On 02/02/2011 01:01, Jędrzej Dudkiewicz wrote:
> On 02/02/2011 01:06 AM, Andrzej Jarzabek wrote:
>>
>> Naprawdę? Szkoda tylko, że jak piszesz tę strukturę, to musisz pilnować,
>> żeby wszystkie pola były na swoim miejscu i żeby Ci kompilator nie
>> namieszał paddingiem na przykład.
>
> __attribute__((packed)), pola struktury nie mogą być przekładane.

To nie jest zdaje się część standardowego języka C, tylko rozszerzenie,
które twórca implementacji dodał dlatego właśnie, że C się do tego
kiepsko nadaje.

>> Jak w C zapiszesz pole pakietu, które jest zaczyna się od ósmego bajta i
>> jest czterobajtową liczbą, powiedzmy bez znaku, zapisaną w formacie -
>> uwaga - big endian?
>
> Rozumiem, że chodzi o deklarację tego pola w strukturze? Otóż wstawię na
> początek pól na łączną wartość 7 bajtów, potem wstawię czterobajtową
> zmienną, a potem wywołam funkcję "preprocess_packet", która mi zawoła
> ntohl i pochodne na wskazanych polach, w tym na tej zmiennej.

Jeśli oprócz castowania należy jeszcze rozszerzyć język i do tego
jeszcze wołać funkcje, to w praktycznie każdym języku imperatywnym można
mieć równie "proste i wygodne" rozwiązanie, a w wielu można to zrobić
prościej, wygodniej i przenośnie.

>> W C++ za to możesz bez problemu wrapnąć bufor bajtowy w klasę, która
>> jako dane pole udotępnia ci dajmy na to 14 bajt bufora albo wartość
>> liczbową w natywnym formacie, zapisaną jako big endian na bajtach od 4
>> do 7.
>
> Jasne, ale w środku albo będziesz kopiował dane do oddzielnych pól, albo
> będziesz trzymał wskaźniki do nich i wołał ntohl przy dostępie, albo
> wstawisz powyższy syf. To trzecie ma najmniejszy narzut pamięciowy i
> obliczeniowy w czasie wykonania.

Nieprawda. Jeśli np. czytasz wartość tego pola tylko w co 20 pakiecie,
to mniejszy narzut ma konwertowanie przy dostępie.

Modyfikowanie bufora ma z kolei taki problem, że łatwo wprowadzić buga:
wyskakuje w testowaniu błąd, dopisujesz funkcję preprocess_packet, a
tymczasem inny programista napisał jakiś kawałek kodu,, który gdzieś
dalej korzysta z założenia, że pod tym wskaźnikiem znajduje się
poprawnie sformatowany pakiet.

> Tak czy owak, zaletą C++ jest to, że jakby co, to można tego rozwiązania
> użyć, ale znacznie ładniej zapakowanego.

Ale "ładiuej zapakowane" w tym momencie przekłada się właśnie na "nadaje
się do". Na przykład - bez żadnej straty wydajności - powoduje, że
trudniej wprowadzić błędy, w szczególności w zmianach dokonywanych wiele
miesięcy po napisaniu pierwotnego kodu. Albo że można to samo zrobić
przenośnie - co z kolei oznacza, że zamiast pisać kod do
obsługi/parsowania pakietów na swoją implementację, można skorzystać z
dobrze przetestowanej biblioteki third-party.

do góry

R. P. pisze:
>> Ten sam algorytm o złożoności O(n) napisany w C może być kilkukrotnie
>> przyspieszony, gdy przepisze się go w języku wyższego poziomu. Bo
>> użyjesz już gotowych i efektywnych struktur danych z języka wyższego
>> poziomu, zamiast paprać w C. I bo kompilator lepiej zoptymalizuje kod
>> pośredni niż ma to miejsce dla C.
>
> Taka np. klasa string w C++ na pewno właściwą strukturą nie jest, bo to
> samo napisane w interpretowanym awk (ten sam algorytm przetwarzania
> tekstu) potrafi zadziałać 3x szybciej... Podobnie wiele innych klas w
> std jest w c++ spapranych. Chociażby stream'y też są wydajnościowo
> skopane i w C zawsze wychodzi szybciej.
>

Bo do operacji na tekście przewidziano inne klasy niż string, to raz.
Kompilator, oraz opcje kompilacji też mają bardzo duże znaczenie - to
dwa.... W C może wyjść tak samo szybko jak w C++, zależy li tylko od
kompilatora, oraz umiejętności programisty.

--
Kaczus
http://kaczus.republika.pl

do góry

R. P. pisze:
> W dniu 2011-02-01 16:53, Andrzej Jarzabek pisze:
>> On Feb 1, 3:46 pm, "R. P."<r...@w...pl> wrote:
>>> W dniu 2011-02-01 16:44, Andrzej Jarzabek pisze:
>>>
>>>> Nieprawda. "Chytre rzuty" nie wnosz nic w kwestii wydajno ci.
>>>
>>> Pozawalaj np. omin tablic funkcji wirtualnych, kt ra daje narzut
>>> czasowy.
>>
>> Podasz może jakiś przykład, gdzie dzięki "chytrym rzutom" w C udaje
>> się napisać coś, co np. w C++ możnaby osiągnąć wyłącznie przy
>> dodatkowym narzucie ze strony tablicy funkcji wirtualnych?
>
> Z założenia C++ jest nadzbiorem C (choć nie do końca), więc to co
> zrobisz w C możesz również zrobić w C++. Po prostu w C++ robisz
> hierarchię klas (tak jest ładnie) a w C pojęcia klasy nie masz, odpada
> więc dziedziczenie itp. Nie ma więc w ogóle mowy o "robieniu tego
> samego" celem symulacji polimorficznych wywołań, bo inaczej projektuje
> się struktury.


W C też możesz pisac obiektowo i mieć dziedziczenie - ba tak nawet pisać
możesz w asemblerze...

--
Kaczus
http://kaczus.republika.pl

do góry

Użytkownik Marek Borowski napisał:
> On 01-02-2011 14:34, Krzysiek Kowaliczek wrote:
>> To właśnie w programowaniu systemowym powinno się kłaść *maksymalny*
>> nacisk na bezpieczeństwo!
>>
> Cos mam wrazenie ze mylicie systemy z systemami. Operacje bliskie
> hardware najwygodniej sie robi w C. Jak np w innych jezykach wysokiego
> poziomu deklarujesz wywolanie funkcji z pod konkretnego adresu he ?

Nic mi się nie pomyliło. Nie wiem czemu jak ludzie słyszą hasło
system operacyjny to od razu im się zapala kontrolka dostęp do
sprzętu. Zarządca procesów, pamięci, praw dostępu, biblioteki
systemowe, itd. tam nie chcę mieć tego całego syfu związanego
z słabym systemem typów. A co do dostępu do sprzętu to silny
system typów nie wyklucza przecież tego. Można wyobrazić przecież
sobie np. deklarację bloku kodu z atrybutem "unsafe" albo ohydnie
wyglądające operatory konwersji jak w C++ reinterpret_cast.
Takie konstrukcje mają kłuć w oczy, po to aby programista świadomie
i z rozwagą ich używał.

Pozdrawiam
KK

do góry

Użytkownik R. P. napisał:

> Gadasz jak typowy teoretyk. Ten sam algorytm o złożoności np. O(n)
> napisany w języku wysokiego poziomu (np. w C++) może być kilkukrotnie
> przyspieszony, gdy się go przepisze na C. W C++ dochodzą dodatkowe
> narzuty (np. na funkcje wirtualne), to przecież oczywiste. Dlaczego
> algorytm o czasie asymptotycznym O(n) w C może być kilkukrotnie szybszy
> niż ten sam w C++? Wszystko rozbija się o tę magiczną stałą k. O(2n) =
> O(5n) = O(kn).

Tak i dlatego kompilator Clang napisany w całości C++ jest kilka
razy szybszy od GCC.

Pozdrawiam
KK

do góry

Użytkownik Wojciech Jaczewski napisał:
> Stachu 'Dozzie' K. wrote:
>
>> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
>> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
>> (asymptotycznej).
>
> To są takie rozważania teoretyczne, ale jak popatrzeć czasem na dyskusje na
> LKML, to tam jednak czasami przejmują się pojedynczymi instukcjami. Sądzę,
> że ma to sens - w końcu oni mają w tym doświadczenie.
>

W pewnych przypadkach ma to sens, zresztą sam pisałeś czasami się
przejmują. W rozliczeniu całościowym Dozzie ma rację. Zresztą jaki
to ma związek z systemem typów. Jedno nie wyklucza drugiego.
R.P. się coś pozajączkowało ponieważ twierdzi, że silny
system typów=mniejsza wydajność.

Pozdrawiam
KK

do góry

On 2011-02-01, R. P. <r...@w...pl> wrote:
> W dniu 2011-02-01 16:54, Stachu 'Dozzie' K. pisze:
>> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>>>> Chciałem jedynie wykazać, że jest ważnym punktem w historii informatyki.
>>>>> Bardzo ważnym.
>>>>
>>>> A potem wtrąciłeś, że jest potężnym i wysokopoziomowym językiem. Przy
>>>> czym ani tego że jest potężnym językiem, ani że wysokopoziomowym, nie
>>>> raczyłeś uzasadnić.
>>>
>>> Wysokopoziomowym strukturalnym. A to drobna różnica.
>>
>> W argumentacji? Żadna. Wysokopoziomowym strukturalnym jest Matlab.
>>
>
> Słuzy do konkretnych zastosowań.

I po prawdzie właśnie dlatego jest wysokopoziomowy.

> Zlinkujesz go z C w trybie jądra?

A co to ma do rzekomej wysokopoziomowości C?

--
Secunia non olet.
Stanislaw Klekot

do góry