On 2011-02-01, R. P. <r...@w...pl> wrote:
> W dniu 2011-02-01 16:50, Stachu 'Dozzie' K. pisze:
>> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>>>>> Wieksosc neisczesc spowodowana jest tym ze "programy systemowe"
>>>>>> napisane sa w C z "chytrymi rzutami"
>>>>>
>>>>> Zgadza się. Są źródłem błędów. Ale dzięki nim pisane oprogramowanie może
>>>>> też być bardzo wydajne... O tym nie wspominasz.
>>>>
>>>> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
>>>> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
>>>> (asymptotycznej).
>>>>
>>>> Tak, w jądrze systemu operacyjnego też.
>>>>
>>>
>>> Gadasz jak typowy teoretyk.
>>
>> Gadasz jak typowy pożal-się-Boże-praktyk bez przygotowania
>> teoretycznego.
>
> Kulturą wypowiedzi to ty nie grzeszysz. Nie wiesz kim jestem i jakie mam
> przygotowanie teoretyczne. A ja nie mam obowiązku tobie się z tego tłuaczyć.

Ktoś tu mnie najpierw próbował wyzywać od "typowych teoretyków". Trochę
nie na miejscu jest wytykanie mi przez ciebie takich zwrotów.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Feb 1, 10:50 pm, Marek Borowski <m...@b...com> wrote:

> Operacje bliskie
> hardware najwygodniej sie robi w C.

Jeszcze tego nie pokazałeś.

> Jak np w innych jezykach wysokiego
> poziomu deklarujesz wywolanie funkcji z pod konkretnego adresu he ?
>
> W C prosze bardzo:
>
> void (*fun)(void) = (void (*)(void))0xFC00;

W Adzie:

procedure Fun;
for Fun'Address use 16#FC00;

> Jak po odebraniu pakietu dobierzesz sie do jego pol, bez dodatkowych
> narzutow ?

Robiąc rzut wskaźnika albo overlay - to drugie jest ciekawsze, bo w
ogóle nie potrzeba żadnego wskaźnika.

> W C jest to trywialne:

Trywialne to jest np. w Adzie, bo w ogóle nie potrzeba wskaźnika.

> Proste i wygodne.

Oczywiście. Ale nadal nie pokazałeś, co takiego "systemowego" da się
zrobić w C a czego nie da się zrobić np. w Adzie. Ironicznie,
przykłady, które pokazałeś do tej pory, można by użyć akurat do tego,
żeby C skrytykować.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

W dniu 2011-02-02 10:09, Stachu 'Dozzie' K. pisze:
> On 2011-02-01, R. P.<r...@w...pl> wrote:
>> W dniu 2011-02-01 16:50, Stachu 'Dozzie' K. pisze:
>>> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>>>>>> Wieksosc neisczesc spowodowana jest tym ze "programy systemowe"
>>>>>>> napisane sa w C z "chytrymi rzutami"
>>>>>>
>>>>>> Zgadza się. Są źródłem błędów. Ale dzięki nim pisane oprogramowanie może
>>>>>> też być bardzo wydajne... O tym nie wspominasz.
>>>>>
>>>>> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
>>>>> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
>>>>> (asymptotycznej).
>>>>>
>>>>> Tak, w jądrze systemu operacyjnego też.
>>>>>
>>>>
>>>> Gadasz jak typowy teoretyk.
>>>
>>> Gadasz jak typowy pożal-się-Boże-praktyk bez przygotowania
>>> teoretycznego.
>>
>> Kulturą wypowiedzi to ty nie grzeszysz. Nie wiesz kim jestem i jakie mam
>> przygotowanie teoretyczne. A ja nie mam obowiązku tobie się z tego tłuaczyć.
>
> Ktoś tu mnie najpierw próbował wyzywać od "typowych teoretyków". Trochę
> nie na miejscu jest wytykanie mi przez ciebie takich zwrotów.

A pisanie ciebie/ty z malej litery o czym swiadczy? Zauwazylem, ze
robisz to nie tylko do mnie...

do góry

On 2011-02-02, R. P. <r...@w...pl> wrote:
> W dniu 2011-02-02 10:09, Stachu 'Dozzie' K. pisze:
>> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>> W dniu 2011-02-01 16:50, Stachu 'Dozzie' K. pisze:
>>>> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>>>>>>> Wieksosc neisczesc spowodowana jest tym ze "programy systemowe"
>>>>>>>> napisane sa w C z "chytrymi rzutami"
>>>>>>>
>>>>>>> Zgadza się. Są źródłem błędów. Ale dzięki nim pisane oprogramowanie może
>>>>>>> też być bardzo wydajne... O tym nie wspominasz.
>>>>>>
>>>>>> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
>>>>>> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
>>>>>> (asymptotycznej).
>>>>>>
>>>>>> Tak, w jądrze systemu operacyjnego też.
>>>>>>
>>>>>
>>>>> Gadasz jak typowy teoretyk.
>>>>
>>>> Gadasz jak typowy pożal-się-Boże-praktyk bez przygotowania
>>>> teoretycznego.
>>>
>>> Kulturą wypowiedzi to ty nie grzeszysz. Nie wiesz kim jestem i jakie mam
>>> przygotowanie teoretyczne. A ja nie mam obowiązku tobie się z tego tłuaczyć.
>>
>> Ktoś tu mnie najpierw próbował wyzywać od "typowych teoretyków". Trochę
>> nie na miejscu jest wytykanie mi przez ciebie takich zwrotów.
>
> A pisanie ciebie/ty z malej litery o czym swiadczy?

O nienadużywaniu formy grzecznościowej.

> Zauwazylem, ze
> robisz to nie tylko do mnie...

Pisanie zaimków osobowych drugiej osoby obu liczb wielką literą jest tak
zwaną formą grzecznościową i jest używane w korespondencji. Forów i grup
dyskusyjnych nie uważam za korespondencję. Gdybym napisał do ciebie
e-maila albo inną prywatną wiadomość (think of phpBB), to formy
grzecznościowej bym użył.

Czyżbyś był z tych, którzy uważają że w reklamie "Miejsce na Twój
banner" forma grzecznościowa zaimka jest użyta poprawnie?

--
Secunia non olet.
Stanislaw Klekot

do góry

On 02/02/2011 08:46 AM, Andrzej Jarzabek wrote:
> 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.

Możliwe, chociaż wydaje mi się, że akurat o paddingu standard C też nic
nie mówi. Więc tak czy inaczej jesteś w krainie konkretnego kompilatora.

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

Pewnie, że można, ale nie wiem, czy się robi, za to każdy kompilator C
ma te rozszerzenia. Co to za argument o wołaniu funkcji? W C++ nie
musisz wołać?

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

Jeśli czytam przy co 20 pakiecie, to prawdopodobnie znaczy to, że wyszło
mi z pierwszego rzutowania, że w danym pakiecie mam dodatkowe dane w
innym formacie, czyli robię kolejne rzutowanie i dopiero wtedy wołam
funkcję. Możemy się tak licytować do śmierci, bo nie działamy na
konkretnym przykładzie.

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

Prawdopodobny scenariusz, ale tak samo masz w C++ - jeżeli nagle masz
buga, którego "poprawiasz" w ten sposób, że zmieniasz interface klasy
(bo przecież kontrakt przed bugiem był taki, że wartość była zwracana
"as is", czyli jako big endian), to co za różnica? Dalej i tak ktoś
robił sobie ntohla na własną rękę, bo przecież wcześniej dostawał
network order a potrzebował "native order".

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

W tym momencie nie przekłada się. Przekłada się na poziomie całego
projektu. W TYM MOMENCIE, czyli dokładnie w tym, o którym mówimy,
grzebiesz po bajtach i musisz uważać w każdym języku. Nawet jak masz
język, w którym opisujesz pakiet w XMLu, możesz zapomnieć o tym, o czym
pisałeś wyżej, to znaczy nie uwzględnić, że dana jest w big endian.

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

Ogólnie się zgadzam, ale zwróć uwagę, że podany wyżej przykład jest
bardzo konkretny i bardzo statyczny - dotyczy TYLKO odczytania jakiegoś
bufora, a nie operacji na nim, w dodatku w przypadku, kiedy dane mają
bardzo dobrze określony format - dane wysyłane przez sprzęt zwykle nie
zmieniają się razem z widzimisię klienta. Zwykle.

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

Kompletnie nie rozumiem, co to ma wspólnego z tematem.

JD

do góry

On 02/02/2011 10:34 AM, Maciej Sobczak wrote:
> On Feb 1, 10:50 pm, Marek Borowski<m...@b...com> wrote:
>> Jak po odebraniu pakietu dobierzesz sie do jego pol, bez dodatkowych
>> narzutow ?
>
> Robiąc rzut wskaźnika albo overlay - to drugie jest ciekawsze, bo w
> ogóle nie potrzeba żadnego wskaźnika.

Brzmi dobrze. Jakiś przykład?

JD

do góry

On 02/02/2011 09:22 AM, Krzysiek Kowaliczek wrote:
> 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.

Ja bym zaczął porównywać Clang z GCC jak będą miały te same
funkcjonalności. Obecnie GCC pewnie z samych ifów do opcji w stylu zrzut
drzewa jest znacznie wolniejszy :)

Czepiam się tylko przykładu, bo nie wątpię, że w C++ można pisać szybsze
programy niż w C.

JD

do góry

On 02/02/2011 12:07 PM, Jędrzej Dudkiewicz wrote:
> On 02/02/2011 10:34 AM, Maciej Sobczak wrote:
>> On Feb 1, 10:50 pm, Marek Borowski<m...@b...com> wrote:
>>> Jak po odebraniu pakietu dobierzesz sie do jego pol, bez dodatkowych
>>> narzutow ?
>>
>> Robiąc rzut wskaźnika albo overlay - to drugie jest ciekawsze, bo w
>> ogóle nie potrzeba żadnego wskaźnika.
>
> Brzmi dobrze. Jakiś przykład?

Patrzyłem tutaj:

http://en.wikibooks.org/wiki/Ada_Programming/Types#O
verlays

Wygląda na to, że to taka unia unii i struktury i rzutowania wskaźnika,
tylko ma fajniejszą nazwę.

JD

do góry

On Feb 2, 1:00 pm, Jędrzej Dudkiewicz <jedrzej.dudkiew...@nospam-
gmail.com> wrote:

> >> Robi c rzut wska nika albo overlay - to drugie jest ciekawsze, bo w
> >> og le nie potrzeba adnego wska nika.
>
> > Brzmi dobrze. Jaki przyk ad?
>
> Patrzy em tutaj:
>
> http://en.wikibooks.org/wiki/Ada_Programming/Types#O
verlays
>
> Wygl da na to, e to taka unia unii i struktury i rzutowania wska nika,
> tylko ma fajniejsz nazw .

Nie chodzi tylko o nazwę. Chodzi o to, że w ten sposób bardziej
bezpośrednio wyraża się intencje programisty - chcę mieć inny widok na
ten sam obiekt. Po cholerę mi tu jakieś unie albo wskaźniki? Unie to
struktury danych a wskaźniki służą do odwołań pośrednich - ani jedno
ani drugie nie pasuje naturalnie do zamierzeń programisty.

W C++ jest lepiej, bo można zadeklarować referencję i zainicjalizować
ją przez reinterpret_cast - w sumie o to samo chodzi, ale nadal ciężko
uznać, że coś jest trywialne. Trywialne jest w Adzie - chcę
zadeklarować obiekt w miejscu innego obiektu. Proste.

A teraz coś lepszego:

type My_Int is new Integer;
for My_Int'Alignment use 16;

Mam nadzieję, że nie trzeba tłumaczyć co to robi. Poproszę o wersję w
*standardowym* C, który ponoć jest najlepiej predysponowany do
"programowania systemowego" (cokolwiek to znaczy).

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Feb 2, 11:06 am, Jędrzej Dudkiewicz <jedrzej.dudkiew...@nospam-
gmail.com> wrote:
> On 02/02/2011 08:46 AM, Andrzej Jarzabek wrote:
>
> >> __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.
>
> Możliwe, chociaż wydaje mi się, że akurat o paddingu standard C też nic
> nie mówi.

Mówi, że może być i ogólniej, że konkretny binarny layout struktury
jest zależny od implementacji.

> Więc tak czy inaczej jesteś w krainie konkretnego kompilatora.

A w C++ możesz właśnie nie być.

> > 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.
>
> Pewnie, że można, ale nie wiem, czy się robi, za to każdy kompilator C
> ma te rozszerzenia.

NIe każdy, przynajmniej nie w takiej postaci.

> Co to za argument o wołaniu funkcji? W C++ nie
> musisz wołać?

Nie musisz, znaczy możesz napisać tak, żeby się sama wołała.


> > Nieprawda. Jeśli np. czytasz wartość tego pola tylko w co 20 pakiecie,
> > to mniejszy narzut ma konwertowanie przy dostępie.
>
> Jeśli czytam przy co 20 pakiecie, to prawdopodobnie znaczy to, że wyszło
> mi z pierwszego rzutowania, że w danym pakiecie mam dodatkowe dane w
> innym formacie,

Wyszło powiedzmy tyle, że w danym pakiecie masz jakieś inne pola,
niekoniecznie w innym formacie.

> czyli robię kolejne rzutowanie i dopiero wtedy wołam
> funkcję.

Jakie to proste i wygodne!

> Możemy się tak licytować do śmierci, bo nie działamy na
> konkretnym przykładzie.

Przykład jest wystarczająco konkretny. W C++ w każdej takiej sytuacji
możesz stworzyć klase opakowującą bez żadnych narzutów, a decyzje o
tym, kiedy konwetować, czy za każdym dostępie, czy na miejscu, czy
trzymać wynik zcache'owany osobno zostawić implementacji.

do góry