eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingktóre języki 'historyczne' są ważne › Re: które języki 'historyczne' sš ważne
  • Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.PO
    STED!not-for-mail
    From: Jędrzej Dudkiewicz <j...@n...com>
    Newsgroups: pl.comp.programming
    Subject: Re: które języki 'historyczne' sš ważne
    Date: Wed, 02 Feb 2011 15:19:02 +0100
    Organization: http://onet.pl
    Lines: 81
    Message-ID: <iibp4m$p1q$1@news.onet.pl>
    References: <2...@n...onet.pl>
    <f...@t...askar.com.pl>
    <4d470681$0$2436$65785112@news.neostrada.pl>
    <r...@4...com>
    <4d47519c$0$2437$65785112@news.neostrada.pl> <ii8g1j$768$1@news.onet.pl>
    <4d47d675$0$2447$65785112@news.neostrada.pl> <ii8l0l$7j3$1@solani.org>
    <4d47fdf5$0$2456$65785112@news.neostrada.pl> <ii90a6$hdr$1@news.onet.pl>
    <4d480625$0$2456$65785112@news.neostrada.pl> <ii9256$prk$1@news.onet.pl>
    <ii9v6d$vi$1@news.onet.pl> <iia75c$f2o$1@inews.gazeta.pl>
    <iiaacp$8mk$1@news.onet.pl> <iib24t$5m2$1@inews.gazeta.pl>
    <iibdrm$7c6$1@news.onet.pl>
    <e...@n...googlegroups.com>
    NNTP-Posting-Host: 234-dzi-16.acn.waw.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    X-Trace: news.onet.pl 1296656343 25658 82.210.159.234 (2 Feb 2011 14:19:03 GMT)
    X-Complaints-To: n...@o...pl
    NNTP-Posting-Date: Wed, 2 Feb 2011 14:19:03 +0000 (UTC)
    User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209
    Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7
    In-Reply-To: <e...@n...googlegroups.com>
    Xref: news-archive.icm.edu.pl pl.comp.programming:188538
    [ ukryj nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: