On 02/02/2011 02:52 PM, Andrzej Jarzabek wrote:
> 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.

W C++ to samo.

>> Więc tak czy inaczej jesteś w krainie konkretnego kompilatora.
>
> A w C++ możesz właśnie nie być.

Jak robisz ręczny, dokładny dostęp pole po polu, to pewnie, że może być.
W C też tak możesz napisać. Ba, w C++ możesz napisać tak, jak jest w C,
i też będzie pięknie.

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

Ta funkcja jest wołana w jednym miejscu. Wołanie funkcji w jednym
miejscu uważam za non-issue. To zupełnie inna skala problemu niż ręczne
wołanie odpowiednika destruktora.

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

Jak to jakieś inne pole w niekoniecznie innym formacie? Znaczy mam tę
samą strukturę, tylko z innym polem? To znaczy mam tę samą strukturę,
czy jednak nie?

>> czyli robię kolejne rzutowanie i dopiero wtedy wołam
>> funkcję.
>
> Jakie to proste i wygodne!

A w C++ co zrobisz? To samo. Skoro masz nagle dane, które masz inaczej
interpretować (bo nie wierzę, że jednak masz tę samą strukturę z innymi
polami - w głowie mi się taka mutacja nie mieści), to musisz ustalić,
jako co masz interpretować. Bierzesz bajt/zmienną identyfikującą dane w
binarnym buforze, wybierasz odpowiednią klasę i karmisz ją buforem.

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

No i to jest dokładnie to, co napisałem wcześniej. W C++ masz wszystko
ładnie zapakowane, ale zwykle w opakowaniu siedzi jakiś syf.

Może tak: ja uważam, że grzebanie się w bajtach i w bitach to jest
grzebanie w gnoju i niezależnie od tego, czy robisz to w kombinezonie
czy w kąpielówkach, pozostanie to grzebaniem w gnoju. Sprawę należy
załatwić szybko, powstały kod hermetycznie zamknąć w jakiejś klasie i o
całości zapomnieć. Dlatego uważam, że rzutowanie wskaźnika na bufor na
wskaźnik na strukturę jest równie dobrym rozwiązaniem jak każde inne. O
ile nie jest to powszechna technika.

JD

do góry

On 02/02/2011 02:45 PM, Maciej Sobczak wrote:
> 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
... zapewniające inny widok na ten sam obiekt. Przy
opisie overlay nie ma nic o obiekcie, z tego co rozumiem. W
szczególności możesz ten sam obiekt "przykryć większym widokiem", i nikt
Ci tego nie zabroni. Unia jak w pysk strzelił, nawet nie unia, tylko
rzutowanie adresu na wskaźnik na unię. Ale zgadzam się, że jako
narzędzie wyróżnione znacznie bezpieczniejsze i eleganckie.

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

Ładne.

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

Może ktoś inny, bo ja tej tezy nie broniłem.

JD

do góry

On 01.02.2011 17:03, Grzegorz Krukowski wrote:
>
>>
>> W kernelu ciągle znajodwane są jakieś dziury. We wszystkich popularnych
>> systemach. To jest niezaprzeczalny fakt. Nie bronię C. Pisałem tylko, ze
>> jest ważnym punktem w historii, bo stał się jezykiem niesamowicie
>> popularnym i napisano w nim zdecydowanie najwięcej linii kodu...
>
> Oczywiście, tylko dlaczego? Bo ówczesne zasobyk komputerów były
> malutkie i liczył się każdy bajt. Tyle że obecnie już nie musimy być
> tak oszczędni i wychwalanie C/C++ jako leku na całe zło jest już nieco
> bez sensu.

Z tego powodu nowoczesny program o takiej samej funkcjonalności jak ten
sprzed wielu lat zajmuje teraz 20 razy więcej pamięci.

Był sobie taki program, nazywał się Calamus SL, z dodatkowymi modułami,
załadowanymi fontami dało się od biedy na nim pracować na 4MB RAM. A był
to program rozbudowany, do składu tekstu. Z własnym renderowaniem
wszystkiego, obsługa fontów wektorowych i to takiej jakości, że wiele
współczesnych systemów się chowa. Moduł obróbki grafiki, moduł
sprawdzania pisowni, tezaurus, dynamiczny kerning. Po prostu wszystko co
było potrzebne do składu tekstu. I mieścił się w 4MB pamięci, co prawda
na dokument zostawało jakieś 800KB, ale dało się. Obecnie 4MB to ma
prosty edytorek tekstu. Narzuty programistyczne typu: to użytkownik da
szybszy procesor, da więcej pamięci są zbyt duże.

--
wer <",,)~~
http://szumofob.eu

do góry

On 02/02/2011 02:45 PM, Maciej Sobczak wrote:

> A teraz coś lepszego:
>
> type My_Int is new Integer;
> for My_Int'Alignment use 16;

Swoją drogą ciekawe jakie są argumenty przemawiające za takim
traktowaniem, a nie za tworzeniem nowego typu. W zasadzie to
zastanawiające jest, jakie byłyby zalety i wady dodawania tego do typu.
Oprócz mnożenia bytów. Chociaż jak znam Adę (prawie nie znam), to pewnie
da się wyrównać również cały typ.

JD

do góry

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

> > A teraz coś lepszego:
>
> > type My_Int is new Integer;
> > for My_Int'Alignment use 16;
>
> Swoją drogą ciekawe jakie są argumenty przemawiające za takim
> traktowaniem, a nie za tworzeniem nowego typu.

To jest nowy typ.

> W zasadzie to
> zastanawiające jest, jakie byłyby zalety i wady dodawania tego do typu.
> Oprócz mnożenia bytów. Chociaż jak znam Adę (prawie nie znam), to pewnie
> da się wyrównać również cały typ.

To właśnie dotyczy całego typu. My_Int jest zupełnie nowym typem,
którego zbiór wartości i operacje są takie jak dla typu Integer, ale
jest to osobny typ.
Zmienne tego typu dopiero trzeba zadeklarować:

I : Integer := 7;
J : My_Int := 8; -- zmienna J jest wyrównana do 16 bajtów

Oczywiście, typu My_Int można też sobie użyć w strukturze, w tablicy,
na stercie, jako parametr szablonu, itd. - wszędzie będzie wlókł ze
sobą swoje własne parametry, jak wyrównanie czy rozmiar.

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

do góry

On 02/02/2011 05:26 PM, Maciej Sobczak wrote:
> On Feb 2, 4:02 pm, Jędrzej Dudkiewicz<jedrzej.dudkiew...@nospam-
> gmail.com> wrote:
>
>>> A teraz coś lepszego:
>>
>>> type My_Int is new Integer;
>>> for My_Int'Alignment use 16;
>>
>> Swoją drogą ciekawe jakie są argumenty przemawiające za takim
>> traktowaniem, a nie za tworzeniem nowego typu.
>
> To jest nowy typ.

No przecież!

>> W zasadzie to
>> zastanawiające jest, jakie byłyby zalety i wady dodawania tego do typu.
>> Oprócz mnożenia bytów. Chociaż jak znam Adę (prawie nie znam), to pewnie
>> da się wyrównać również cały typ.
>
> To właśnie dotyczy całego typu. My_Int jest zupełnie nowym typem,
> którego zbiór wartości i operacje są takie jak dla typu Integer, ale
> jest to osobny typ.
> Zmienne tego typu dopiero trzeba zadeklarować:
>
> I : Integer := 7;
> J : My_Int := 8; -- zmienna J jest wyrównana do 16 bajtów
>
> Oczywiście, typu My_Int można też sobie użyć w strukturze, w tablicy,
> na stercie, jako parametr szablonu, itd. - wszędzie będzie wlókł ze
> sobą swoje własne parametry, jak wyrównanie czy rozmiar.

Czyli tak jak bym się spodziewał. Bardzo śliczne. Co prawda wyklucza to,
możliwe w C++, indeksowanie pamięci stringami... czyż nie? :)

JD

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

Brawo, proponuję jeszcze udowodnić, że w ogóle nie ma żadnych
istotnych różnic między językami, bo jak posadzisz małpę przed
komputerem i nauczysz ją walić w klawisze, to w dowolnym języku
doprowadzi program do postaci, w której się nie kompiluje lub nie
uruchamia.

A różnica jest choćby taka, że jak masz wyspecyfikowany kontrakt,
mówie zwraca w formacie natywnym. Czy może nawet inaczej: różnica
polega na tym, że w ogóle można mówić o jakimś kontrakcie.

> Dalej i tak ktoś
> robił sobie ntohla na własną rękę, bo przecież wcześniej dostawał
> network order a potrzebował "native order".

Oprócz działania bez sensu, masz jednak kilka sensownych alternatyw,
których nie masz w C.

> >> Tak czy owak, zaletą C++ jest to, że jakby co, to można tego rozwiązania
> >> użyć, ale znacznie ładniej zapakowanego.
>
> > Ale "ładinej 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.

W tym momencie się właśnie przekłada. Bo "nadaje się do" nie sprowadza
się tylko do tego, że można napisać kawałek kodu, który zrobi to czy
owo, bo to niewątpliwie można w C zrobić, tylko jak potem ten kawałek
kodu funkcjonuje w kontekście całego projektu. To, jak to zrobisz ma
znaczenie dla tego, jak prawdopodobne jest to, że ktoś piszący kod
kliencki użyje tego, co zrobiłeś, nieprawidłowo, teraz lub kiedyś w
przyszłości - i tym kimś równie dobrze możesz być ty sam.

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

Oczywiście. Ale, dla przykładu, projektując taki XML możesz (w
zależności od tego, do czego będzie stosowany) założyć, że typ 'int32'
jest defaultowo big endian, niezależnie od architektury procesora,
albo że musisz endianness podać jawnie. W takiej sytuacji trudniej o
pomyłkę, w szczególności popełnioną przez programistę, który przez n
lat pisał systemy na architekturach big endian i przyzwyczaił się, że
można sobie po prostu rzutnąć inta 'bo działa'.

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

wiesz, nie ja ten przykłd wymyśliłem. Ale tutaj też masz zaletę C++:
jak programista dostanie strukturę, to może np. założyć, że
modyfikować bufor może przypisując wartości do pól struktury. Jak
dostanie obiekt z getterami ale bez setterów, to będzie musiał już się
trochę zastanowić.

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

Język, w którym można pisać re-usable i przenośne biblioteki przydatne
w jakichś zastosowaniach, lepiej się nadaje do tych zastosowań od
języka, w którym nie można.

do góry

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

> Czyli tak jak bym się spodziewał. Bardzo śliczne. Co prawda wyklucza to,
> możliwe w C++, indeksowanie pamięci stringami... czyż nie? :)

Nie. :-)

Pamiętaj, że nawet przy adresowaniu pamięci stringami musi istnieć
jakieś mapowanie tych adresów na liczby - chociażby po to, żeby można
było mieć ptrdiff_t, arytmetykę wskaźników, sizeof, itd. To wszystko
jest ze sobą powiązane.
W C++ istnieje też mniej lub bardziej zdefiniowany rzut wskaźnika na
int i z powrotem, więc związek wskaźników z liczbami jakiś jest.
Podobnie jest w Adzie, chociaż nie ma arytmetyki wskaźników.

W każdym razie zarówno C++ jak i Ada starają się tak rozmyć pojęcie
adresu, żeby niczego konkretnego nie sugerować. W praktyce i tak
wiadomo, co to oznacza na normalnym sprzęcie, ale nie zamyka się drzwi
dla różnych emulatorów czy innych maszyn wirtualnych, gdzie adres może
oznaczać coś innego.
Czyli w obu językach siła wyrazu jest podobna. Można swobodnie pisać w
nich systemy operacyjne, można też wyobrazić sobie adresowanie
stringami w emulatorze.

Jest jednak pewna ciekawa różnica - w C++ nie ma osobnego pojęcia
adresu, to jest wplecione w pojęcie wskaźnika void* i istnieje
zastrzeżenie, że void* ma mieć taką samą reprezentację jak char*.
Czyli adresy i wskaźniki to w zasadzie to samo, nie rozdziela się tych
rzeczy.
Natomiast w Adzie czegoś takiego nie ma - adres to wartośc typu
System.Address, natomiast wskaźnik to tzw. "access value" i z adresem
nie ma żadnego związku poza tym, że istnieją osobne operacje do ich
wzajemnej konwersji. Nie ma wymagania na reprezentację, więc wskaźniki
mogą być tłuste, albo np. wskaźniki na stos mogą mieć zupełnie inny
format, niż wskaźniki na stertę (nawet na ten sam typ), itd. Czyli Ada
ma tu nawet większą swobodę implementacyjną, bez poświęcania
funkcjonalności.

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

do góry

Grzegorz Krukowski wrote:

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

Tak na prawdę, planując koncept na prawdę wysokopoziomowy, nie trzeba się
interesować językiem ani odrobinę. Często będąc zauroczonym programowaniem
obiektowym (przechodziłem ten etap - na szczęście szybko mi minął - w ciągu
jakichś 2-3 lat) pod pozorem projektowania wysokopoziomowego, projektowałem
tak na prawdę niskopoziomowo, bo zamiast zajmować się działaniem
programu/systemu jako całości (i tym, jak będzie on używany przez klientów),
zajmowałem się hierarchią obiektów, czyli szczegółem implementacyjnym, jakim
jest niewidoczna dla użytkownika struktura kodu źródłowego.

Nie ma nic złego w korzystaniu z abstrakcji, jakie dają języki wyższego niż
C poziomu. Ale zastanowienie się przez jakiś czas, jak mogłaby dana
funkcjonalność zostać zrealizowana w czystym C, albo nawet - w C na
mikrokontrolerze, powoduje że nieraz dochodzi się do rozwiązania nie tylko
znacząco wydajniejszego, ale też prostszego. Okazuje się, że ileś tam
przejściowych buforów, które tworzyło się w wysokopoziomowym projekcie, jest
całkowicie zbędnych. A program, który wykonuje rzeczy zbędne, zwykle nie
jest łatwy do zrozumienia dla programisty nie-autora, oglądającego ten kod.

do góry

On Wed, 02 Feb 2011 23:07:55 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>Grzegorz Krukowski wrote:
>
>> 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.
>
>Tak na prawdę, planując koncept na prawdę wysokopoziomowy, nie trzeba się
>interesować językiem ani odrobinę. Często będąc zauroczonym programowaniem
>obiektowym (przechodziłem ten etap - na szczęście szybko mi minął - w ciągu
>jakichś 2-3 lat) pod pozorem projektowania wysokopoziomowego, projektowałem
>tak na prawdę niskopoziomowo, bo zamiast zajmować się działaniem
>programu/systemu jako całości (i tym, jak będzie on używany przez klientów),
>zajmowałem się hierarchią obiektów, czyli szczegółem implementacyjnym, jakim
>jest niewidoczna dla użytkownika struktura kodu źródłowego.
>

H,m... Hierarchia obiektow to sczegol implementacyjny? Moze tak by
bylo warto pzrestudiowac sparwy obiektowe jeszcze raz i przemyslec
jaka jezt rola obiektowosci w modelowaniu?... I przemyslec "co ma
obiektowosc do ejzyka programwoania"?...

>Nie ma nic złego w korzystaniu z abstrakcji, jakie dają języki wyższego niż
>C poziomu. Ale zastanowienie się przez jakiś czas, jak mogłaby dana
>funkcjonalność zostać zrealizowana w czystym C, albo nawet - w C na
>mikrokontrolerze, powoduje że nieraz dochodzi się do rozwiązania nie tylko
>znacząco wydajniejszego, ale też prostszego. Okazuje się, że ileś tam
>przejściowych buforów, które tworzyło się w wysokopoziomowym projekcie, jest
>całkowicie zbędnych. A program, który wykonuje rzeczy zbędne, zwykle nie
>jest łatwy do zrozumienia dla programisty nie-autora, oglądającego ten kod.

Calkiem neidawno w Communications of the ACM byl artykul na temat
"szkodlowosci obiektowosci" - tak z grubsza. Zobacze czy jest
publiczna wersja...

A.L.

do góry