A. L. wrote:

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

Jest to jak najbardziej szczegół implementacyjny. Projekt można dzielić na
obiekty, a można też np. na osobne procesy w systemie operacyjnym i pomiędzy
nimi interfejs w stylu zupełnie nie-obiektowym - np. prosty protokół
tekstowy. Jakby sobie to rozrysowywać w pajęczynkę powiązań między
poszczególnymi modułami, przy jednym i drugim wykonaniu wyjdzie mniej-więcej
to samo. Czyli ogólna wizja jest taka sama. Wykonanie natomiast różni się
szczegółami implementacyjnymi. Hierarchia obiektów to już szczegół
implementacyjny - projektowanie niżej-poziomowe niż ogólna wizja.

do góry

On 02/02/2011 14:19, Jędrzej Dudkiewicz wrote:
> On 02/02/2011 02:52 PM, Andrzej Jarzabek wrote:
>>
>> Mówi, że może być i ogólniej, że konkretny binarny layout struktury
>> jest zależny od implementacji.
>
> W C++ to samo.

Ale w C++ można to lepiej rozwiązać inaczej, niż rzutując na strukturę.

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

Wcale nie będzie pięknie: będzie kaszaniasto.

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

Funkcja wołana jest w jednym miejscu, być może. Ale takich funkcji masz
np. 87, dla 163 różnych formatów komunikatów: dla jednych wołasz na
początku, dla innych nie, dla innych wołasz, jak chcesz uzyskać dostęp
dla jakiegoś konkretnego pola. Prawdopodobieństwo wprowadzenia błędu
przy takim projekcie i nie wywołania w pewnym miejscu którejś z tych
funkcji, albo wywołania nie tej, co trzeba, jest wysokie.

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

Elementarne drogi Watsonie. Jeśli struktura ma więcej niż jedno pole, to
oprócz tego, że ma jakieś określone, to ma również inne. Ta sama struktura.

>>> czyli robię kolejne rzutowanie i dopiero wtedy wołam
>>> funkcję.
>>
>> Jakie to proste i wygodne!
>
> A w C++ co zrobisz? To samo.

Np. napiszę klasę wrapującą bufor bajtowy z funkcjami dostępu. Jeśli np.
na wejściu będę sądził, że dane pole jest czytane w jenym miejscu, to
zrobię konwersję przy odczycie. Jeśli okaże się, że to założenie się nie
sprawdziło, że program wykonuje za dużo konwersji i powoduje to
niedopuszczalną utratę performance'u, to sobie np. zcache'uję wynik.
Zachowując jednocześnie 100% kompatybilności z kodem klienckim.

Dodatkowo jeśli chcę modyfikować bufor w klasie, to mogę wskaźnik na
niego schować w klasie, w ten sposób mając wysoką dozę
prawdopodobieństwa, że dalszy kod przetwarzający nie będzie miał do
niego dostępu.

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

I daję taką klasę do dalszego przetwarzania, przez co nie ma możliwości,
żeby obsługujący kod przez pomyłkę wywołał funkcję przeznaczoną dla
innej struktury, albo ie wywołał jakiejś funkcji, którą powinien wywołać
przy odczycie jakiegoś pola.

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

OK, ja tylko nie zgadzam się z tezą, że C jakoś szczególnie dobrze się
do tego nadaje - bo już C++ nadaje się lepiej.

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

Właśnie nie jest równie dobre, choćby dlatego, że nie daje hermetycznego
zapakowania.

do góry

On 02/02/2011 14:41, b...@n...pl wrote:
> On 01.02.2011 17:03, Grzegorz Krukowski wrote:
>>
>> 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.

Nawet jeśli, to co za problem? 20 razy więcej pamięci jest 20 razy
tańsze niż 20 razy mniej pamięci przed wieloma laty.

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

A teraz program o _takiej samej_ funkcjonalności zajmuje ile? Uwaga,
program o jakiejkolwiek funkcjonalności, której brakowało w Calamusie
się nie liczy.

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

E tam. Vim u mnie zajmuje 2 mega bez GUI i 3 mega z. A to jest bardzo
rozbudowany edytorek tekstu.

Z drugiej strony, że Emacs zajmuje całe osiem megabajtów i że wolno
chodzi to ludzie marudzili na długo przed Calamusem. Dzisiaj nikt nie
narzeka.

do góry

On Tue, 01 Feb 2011 18:13:37 +0100
Michoo <m...@v...pl> wrote:


> Tak, na przykład umieszcza się w klasie jako pierwszy bajt wskaźnik na
> strukturę zawierającą wskaźniki na funkcje.


Jednobajtowy wskaznik? Na jakim sprzecie z jednobajtowymi wskaznikami
zaimplementowany jest c++?

do góry

W dniu 06.02.2011 00:51, Michal pisze:
> On Tue, 01 Feb 2011 18:13:37 +0100
> Michoo<m...@v...pl> wrote:
>
>
>> Tak, na przykład umieszcza się w klasie jako pierwszy bajt wskaźnik na
>> strukturę zawierającą wskaźniki na funkcje.
>
>
> Jednobajtowy wskaznik? Na jakim sprzecie z jednobajtowymi wskaznikami
zaimplementowany jest c++?
s/pierwszy bajt/pierwsze bajty/

Zdanie zmutowało mi się z 2 - widziałem kod gdzie "dla oszczędności
miejsca" był jeden bajt - indeks który pozwalał wybrać z globalnej
tablicy właściwy wskaźnik (kto będzie miał więcej niż 255 klas? ;) ).
Ale, to już patologia a nie standardowe rozwiązanie w C, więc w końcu o
nim nie napisałem w tamtym poście.

--
Pozdrawiam
Michoo

do góry