Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #28118 > unrolled thread

Pakowanie struktur

Back to article view | Back to pl.comp.programming

Contents

  Pakowanie struktur Borneq <borneq@antyspam.hidden.pl> - 2015-12-02 17:02 +0100
    Re: Pakowanie struktur Wojciech Muła <wojtek.mula@gmail.com> - 2015-12-02 08:56 -0800
    Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-02 09:21 -0800
      Re: Pakowanie struktur JDX <jdx@onet.pl> - 2015-12-03 10:31 +0100
      Re: Pakowanie struktur Adam Klobukowski <adamklobukowski@gmail.com> - 2015-12-03 01:59 -0800
        Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 03:55 -0800
          Re: Pakowanie struktur Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-12-03 13:09 +0100
            Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 05:08 -0800
              Re: Pakowanie struktur Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-12-03 14:33 +0100
                Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 06:00 -0800
                  Re: Pakowanie struktur Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-12-03 15:05 +0100
                    Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 07:08 -0800
                      Re: Pakowanie struktur Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-12-04 09:43 +0100
      Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-03 09:21 -0600
        Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 07:23 -0800
          Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-03 10:45 -0600
            Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 09:02 -0800
              Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-03 11:37 -0600
            Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 09:15 -0800
              Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-03 11:40 -0600
                Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 09:57 -0800
    Re: Pakowanie struktur Maciej Sobczak <see.my.homepage@gmail.com> - 2015-12-03 06:20 -0800
      Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 07:19 -0800
        Re: Pakowanie struktur Maciej Sobczak <see.my.homepage@gmail.com> - 2015-12-03 08:29 -0800
          Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-03 08:56 -0800
            Re: Pakowanie struktur Maciej Sobczak <see.my.homepage@gmail.com> - 2015-12-04 05:18 -0800
              Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-04 12:26 -0800
                Re: Pakowanie struktur Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-12-07 10:14 +0100
                  Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-07 03:02 -0800
                    Re: Pakowanie struktur Maciej Sobczak <see.my.homepage@gmail.com> - 2015-12-07 06:12 -0800
                      Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-07 06:40 -0800
                        Re: Pakowanie struktur Sebastian Biały <heby@poczta.onet.pl> - 2015-12-07 19:03 +0100
                          Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-07 10:41 -0800
                          Re: Pakowanie struktur RW <bloody_rabbit@gazeta.pl> - 2015-12-08 05:10 -0600
                    Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-07 09:22 -0600
                      Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-07 08:05 -0800
                        Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-07 11:40 -0600
                          Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-07 10:29 -0800
                            Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-07 12:55 -0600
                              Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-07 11:06 -0800
                                Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-07 13:25 -0600
                                Re: Pakowanie struktur Sebastian Biały <heby@poczta.onet.pl> - 2015-12-07 20:34 +0100
                                  Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-07 12:30 -0800
                                    Re: Pakowanie struktur szemrany <szemrany@offline.off> - 2015-12-07 22:36 +0100
                                    Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-07 15:40 -0600
                                      Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 02:00 -0800
                                        Re: Pakowanie struktur witek <witek7205@gazeta.pl.invalid> - 2015-12-08 12:03 -0600
                                          Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 10:07 -0800
                                            Re: Pakowanie struktur Adam M <amorawski@magna-power.com> - 2015-12-08 10:18 -0800
                                              Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 10:32 -0800
                                      Re: Pakowanie struktur RW <bloody_rabbit@gazeta.pl> - 2015-12-08 05:09 -0600
                                    Re: Pakowanie struktur Maciej Sobczak <see.my.homepage@gmail.com> - 2015-12-08 04:20 -0800
                                    Re: Pakowanie struktur "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-12-08 13:16 +0000
                                      Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 05:50 -0800
                                        Re: Pakowanie struktur "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-12-08 14:40 +0000
                                          Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 07:07 -0800
                                            Re: Pakowanie struktur "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-12-08 15:59 +0000
                                              Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 08:47 -0800
                                                Re: Pakowanie struktur Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-12-09 10:19 +0100
                                    Re: Pakowanie struktur Sebastian Biały <heby@poczta.onet.pl> - 2015-12-08 17:11 +0100
                                      Re: Pakowanie struktur Adam M <amorawski@magna-power.com> - 2015-12-08 08:30 -0800
                                        Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 09:29 -0800
                                          Re: Pakowanie struktur Adam M <amorawski@magna-power.com> - 2015-12-08 09:31 -0800
                                            Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 09:47 -0800
                                      Re: Pakowanie struktur "M.M." <mmarszik@gmail.com> - 2015-12-08 09:20 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#28142

On Thursday, December 3, 2015 at 6:40:32 PM UTC+1, witek wrote:
> M.M. wrote:
> > On Thursday, December 3, 2015 at 5:45:16 PM UTC+1, witek wrote:
> >> zmienic algorytm.
> > Mam też pytanie. Powiedz mi: jeśli mam dane, które nie mieszczą się w
> > pamięci RAM, więc nie mogę ich do niej wczytać, to jak mam zmienić
> > algorytm, aby po tej zmianie się zmieściły?
> >
> > Pozdrawiam
> >
> 
> a po co sie uparles, ze musisz miec wszystkie dane w pamieci?
> Zmian algorytm na taki, ktory potrafi operować na części danych, takich, 
> ktore mieszczą się w pamięci, zamiast na całości.
> w ostatecznosci zwieksz ilosc dostepnej pamieci.
Dziękuję za dobre rady.

[toc] | [prev] | [next] | [standalone]

#28130

Piszę tutaj, ale problem dotyczy wszystkich postów w tym wątku.

Uwaga 1: endianie atakują.

Te tricki są do niczego i powinny być (i są) zakazane. W szczególności *wszystkie* pokazane do tej pory przykłady są zakazane przez przemysłowe standardy kodowania - właśnie dlatego, że działają tylko przypadkiem i to w ściśle określonych warunkach, których to warunków nie widać w kodzie.

Jak chcecie przepakowywać protokoły sieciowe, to ręcznie (uwaga 2: do operacji na bitach służą typy unsigned) a nie przez jakieś tam pragma packi czy inne pola bitowe. Dobrze napisany kod jest przenośny. I czytelny.

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

[toc] | [prev] | [next] | [standalone]

#28132

On Thursday, December 3, 2015 at 3:20:27 PM UTC+1, Maciej Sobczak wrote:
> Piszę tutaj, ale problem dotyczy wszystkich postów w tym wątku.
> 
> Uwaga 1: endianie atakują.
> 
> Te tricki są do niczego i powinny być (i są) zakazane. 
Jakie triki? W ogóle nie można rozpoznać na podstawie samych 
danych w jakim formacie są zakodowane. Rozmawiamy oczywiście o 
zgodnych formatach. Jeśli formaty są niezgodne, to trzeba napisać 
switch każdej pary (src,dst) formatów.


> W szczególności *wszystkie* pokazane do tej pory przykłady są zakazane 
> przez przemysłowe standardy kodowania - właśnie dlatego, że działają tylko
> przypadkiem i to w ściśle określonych warunkach, których to warunków nie 
> widać w kodzie.
Działają zawsze na zgodnych formatach.


> Jak chcecie przepakowywać protokoły sieciowe, to ręcznie (uwaga 2: do operacji na bitach służą typy unsigned) a nie przez jakieś tam pragma packi czy inne pola bitowe. Dobrze napisany kod jest przenośny. I czytelny.
Gdy są zgodne formaty, to nie trzeba niczego przepakowywać. Wystarczy
odczytać (w tej samej kolejności) i używać.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28135

> Jakie triki? W ogóle nie można rozpoznać na podstawie samych 
> danych w jakim formacie są zakodowane.

Przecież nikt nie każe rozpoznawać formatu na podstawie danych. O ile zrozumiałem nawiązanie do protokołów sieciowych, to format jest zwykle znany z góry.

> Rozmawiamy oczywiście o 
> zgodnych formatach.

Co to znaczy zgodnych formatach? Jest jeden format (zwykle znany) i trzeba go zdekodować na poszczególne pola (albo odwrotnie - spakować ze znanych wartości pól). Te triki z pragmą, polami bitowymi albo rzutowaniem wskaźników to są złe rozwiązania.

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

[toc] | [prev] | [next] | [standalone]

#28137

On Thursday, December 3, 2015 at 5:29:03 PM UTC+1, Maciej Sobczak wrote:
> > Jakie triki? W ogóle nie można rozpoznać na podstawie samych 
> > danych w jakim formacie są zakodowane.
> 
> Przecież nikt nie każe rozpoznawać formatu na podstawie danych. O ile zrozumiałem nawiązanie do protokołów sieciowych, to format jest zwykle znany z góry.
Jeśli przyszły dane w formacie znanym na podstawie protokołu, to trzeba
napisać konwersję zgodną z danym formatem. Rozmowa, w kontekście znanego
protokołu, zarówno o kopiowaniu bit po bicie, jak i o kopiowaniu z 
użyciem operatora konwersji (int), nie ma sensu. Rozmawialiśmy o 
szczególikach, typu:
1) można się przejechać na big/lit endian
2) najpierw memcpy, potem operator rzutowania
3) różny padding w strukturach
4) różny rozmiar inta na różnych platformach lub wersjach programu.


> > Rozmawiamy oczywiście o 
> > zgodnych formatach.
> 
> Co to znaczy zgodnych formatach? Jest jeden format (zwykle znany) i trzeba go zdekodować na poszczególne pola (albo odwrotnie - spakować ze znanych wartości pól). Te triki z pragmą, polami bitowymi albo rzutowaniem wskaźników to są złe rozwiązania.

Dlaczego złe? Jeśli ktoś wysyła tablicę struktur wyrównanych do 1 bajta, to
sytuacja ma się odwrotnie niż pisałeś: Jedynie przez przypadek odczyt 
zadziała na strukturach wyrównanych do 4 bajtów. Dlatego są złe, że nie
używa się przenośnych funkcji do wysłania i odebrania każdego pola? Owszem
to drobna wada. Ale wyobraź sobie, że ktoś pisze program tylko na windows i
tylko na x86, ma strutkurę z 20ma polami i zamiast napisać
write( &strukt , sizeof(strukt) , file )
pisze 20 razy:
write( unwersalny_format_int( strukt.pole1 ) , uniwersalny_rozmiar_int( strukt.pole1 ) , file );

Zgodzę się, że kod z memcpy jest ryzykowny, ale po pierwsze ryzyko to pojawia
się tylko w określonych sytuacjach, a aktywne unikanie tego ryzyka zajmuje
czas. Zobacz jak łatwo rypnąć się po poprawce pól w strukturze.


Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28145

> Rozmawialiśmy o 
> szczególikach, typu:
> 1) można się przejechać na big/lit endian
> 2) najpierw memcpy, potem operator rzutowania
> 3) różny padding w strukturach
> 4) różny rozmiar inta na różnych platformach lub wersjach programu.

Właśnie te szczególiki powodują, że te triki to złe rozwiązania.

> aktywne unikanie tego ryzyka zajmuje
> czas. Zobacz jak łatwo rypnąć się po poprawce pól w strukturze.

Jeśli problemem jest czas lub poprawki pól w strukturach (ale przecież protokół miał być znany?), to taki kod można wygenerować. Po to są standardy w rodzaju ASN.1 i jemu podobne. Albo nawet niestandardowe, ale poręczne wynalazki typu MessagePack.
Co do czasu - ogólnie, pisanie poprawnych programów może zająć więcej czasu, niż niepoprawnych. Ale akurat poprawna obsługa protokołu sieciowego to jest jedno z tych miejsc, gdzie oszczędność czasu na etapie kodowania się nie opłaca.

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

[toc] | [prev] | [next] | [standalone]

#28157

On Friday, December 4, 2015 at 2:18:45 PM UTC+1, Maciej Sobczak wrote:
> > Rozmawialiśmy o 
> > szczególikach, typu:
> > 1) można się przejechać na big/lit endian
> > 2) najpierw memcpy, potem operator rzutowania
> > 3) różny padding w strukturach
> > 4) różny rozmiar inta na różnych platformach lub wersjach programu.
> 
> Właśnie te szczególiki powodują, że te triki to złe rozwiązania.

Mają swoje zalety. Gdy mam dużą strukturę, którą będę modyfikował w
przyszłości i gdy użyję:
write( &struct , sizeof(struct) , 1 )
to:
1) w jednej linii kodu zapisuję/odczytuję całą strukturę.
2) strukturę mogę dowolnie modyfikować, a zapis i odczyt zawsze
   zadziała.


> > aktywne unikanie tego ryzyka zajmuje
> > czas. Zobacz jak łatwo rypnąć się po poprawce pól w strukturze.
> 
> Jeśli problemem jest czas lub poprawki pól w strukturach (ale przecież protokół miał być znany?), to taki kod można wygenerować. Po to są standardy w rodzaju ASN.1 i jemu podobne. Albo nawet niestandardowe, ale poręczne wynalazki typu MessagePack.
> Co do czasu - ogólnie, pisanie poprawnych programów może zająć więcej czasu, niż niepoprawnych. Ale akurat poprawna obsługa protokołu sieciowego to jest jedno z tych miejsc, gdzie oszczędność czasu na etapie kodowania się nie opłaca.

Zgodzę się z Tobą, ale tylko w przypadku bardzo dużych aplikacji. W mały i w
średnich programach to co proponujesz moim zdaniem jest przerostem 
formy nad treścią.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28179

W dniu 2015-12-04 21:26, M.M. pisze:
> On Friday, December 4, 2015 at 2:18:45 PM UTC+1, Maciej Sobczak wrote:
>>> Rozmawialiśmy o
>>> szczególikach, typu:
>>> 1) można się przejechać na big/lit endian
>>> 2) najpierw memcpy, potem operator rzutowania
>>> 3) różny padding w strukturach
>>> 4) różny rozmiar inta na różnych platformach lub wersjach programu.
>>
>> Właśnie te szczególiki powodują, że te triki to złe rozwiązania.
>
> Mają swoje zalety. Gdy mam dużą strukturę, którą będę modyfikował w
> przyszłości i gdy użyję:
> write(&struct , sizeof(struct) , 1 )
> to:
> 1) w jednej linii kodu zapisuję/odczytuję całą strukturę.
> 2) strukturę mogę dowolnie modyfikować, a zapis i odczyt zawsze
>     zadziała.

Zapis działa zawsze, odczyt - zależnie, czy odczytujemy ten co przed 
chwilą zapisaliśmy, czy może kompilowany wcześniej... Oczywiście ma 
swoje zalety i jest stosowany, ale jednak do stwierdzenia "zawsze 
działa" podchodziłbym jednak z pewną ostrożnością :)


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

[toc] | [prev] | [next] | [standalone]

#28181

On Monday, December 7, 2015 at 10:14:16 AM UTC+1, Tomasz Kaczanowski wrote:
> W dniu 2015-12-04 21:26, M.M. pisze:
> > On Friday, December 4, 2015 at 2:18:45 PM UTC+1, Maciej Sobczak wrote:
> >>> Rozmawialiśmy o
> >>> szczególikach, typu:
> >>> 1) można się przejechać na big/lit endian
> >>> 2) najpierw memcpy, potem operator rzutowania
> >>> 3) różny padding w strukturach
> >>> 4) różny rozmiar inta na różnych platformach lub wersjach programu.
> >>
> >> Właśnie te szczególiki powodują, że te triki to złe rozwiązania.
> >
> > Mają swoje zalety. Gdy mam dużą strukturę, którą będę modyfikował w
> > przyszłości i gdy użyję:
> > write(&struct , sizeof(struct) , 1 )
> > to:
> > 1) w jednej linii kodu zapisuję/odczytuję całą strukturę.
> > 2) strukturę mogę dowolnie modyfikować, a zapis i odczyt zawsze
> >     zadziała.
> 
> Zapis działa zawsze, odczyt - zależnie, czy odczytujemy ten co przed 
> chwilą zapisaliśmy, czy może kompilowany wcześniej... Oczywiście ma 
> swoje zalety i jest stosowany, ale jednak do stwierdzenia "zawsze 
> działa" podchodziłbym jednak z pewną ostrożnością :)

Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
write( &strukt , sizeof(strukt) , file );
Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28183

> Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
> write( &strukt , sizeof(strukt) , file );

Ale nie płacą nam za zapisy, tylko za odczyty (to było w dowcipie o backupach). :-)

U mnie też jest jeden wiersz:

serialize(&struct, file);

Nawet krócej. I wiem, że nie jestem zależny od pierdyliona rzeczy, nad którymi mogę nie mieć kontroli (endiany, opcje kompilatora, itd.).

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

[toc] | [prev] | [next] | [standalone]

#28184

On Monday, December 7, 2015 at 3:12:40 PM UTC+1, Maciej Sobczak wrote:
> > Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
> > write( &strukt , sizeof(strukt) , file );
> 
> Ale nie płacą nam za zapisy, tylko za odczyty (to było w dowcipie o backupach). :-)
Dobre :)



> U mnie też jest jeden wiersz:
> serialize(&struct, file);
> Nawet krócej. I wiem, że nie jestem zależny od pierdyliona rzeczy, nad którymi mogę nie mieć kontroli (endiany, opcje kompilatora, itd.).

Jeśli taki kod generuje jakiś automat, albo wspomaga jakiś język
programowania, to pewnie że masz rację. 

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28189

On 2015-12-07 15:40, M.M. wrote:
>> serialize(&struct, file);
>> Nawet krócej. I wiem, że nie jestem zależny od pierdyliona rzeczy, nad którymi mogę nie mieć kontroli (endiany, opcje kompilatora, itd.).
> Jeśli taki kod generuje jakiś automat

http://www.boost.org/doc/libs/1_59_0/libs/serialization/doc/index.html

[toc] | [prev] | [next] | [standalone]

#28191

On Monday, December 7, 2015 at 7:03:29 PM UTC+1, Sebastian Biały wrote:
> On 2015-12-07 15:40, M.M. wrote:
> >> serialize(&struct, file);
> >> Nawet krócej. I wiem, że nie jestem zależny od pierdyliona rzeczy, nad którymi mogę nie mieć kontroli (endiany, opcje kompilatora, itd.).
> > Jeśli taki kod generuje jakiś automat
> 
> http://www.boost.org/doc/libs/1_59_0/libs/serialization/doc/index.html

Eleganckie rozwiązanie.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28204

On Mon, 07 Dec 2015 19:03:00 +0100, Sebastian Biały wrote:

> On 2015-12-07 15:40, M.M. wrote:
>>> serialize(&struct, file);
>>> Nawet krócej. I wiem, że nie jestem zależny od pierdyliona rzeczy, nad
>>> którymi mogę nie mieć kontroli (endiany, opcje kompilatora, itd.).
>> Jeśli taki kod generuje jakiś automat
> 
> http://www.boost.org/doc/libs/1_59_0/libs/serialization/doc/index.html

Slyszalem rozne horror stories na temat czasow kompilacji bibliotek 
stosujacych serializacje z Boosta, ale to dawno temu bylo. Nadal jest tak 
zle?

RW

[toc] | [prev] | [next] | [standalone]

#28186

M.M. wrote:
> Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
> write( &strukt , sizeof(strukt) , file );

kazdy bełkot da sie zapisać.
Chodzi o to, żeby go potem ktoś umiał zrozumieć przy odczycie.
Zapisywanie całej stuktury w ten sposób to nie jest dobry pomysł.
Proponuję ci przy okazji małej zmiany dorzucić jakis wskaznik w strukturze.

[toc] | [prev] | [next] | [standalone]

#28187

On Monday, December 7, 2015 at 4:22:44 PM UTC+1, witek wrote:
> M.M. wrote:
> > Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
> > write( &strukt , sizeof(strukt) , file );
> 
> kazdy bełkot da sie zapisać.
To nie jest bełkot, tylko typowy zapis binarnych danych.

> Chodzi o to, żeby go potem ktoś umiał zrozumieć przy odczycie.
Bez dokumentacji to czasami protokół tekstowy ciężko zrozumieć.

> Zapisywanie całej stuktury w ten sposób to nie jest dobry pomysł.
Jest dobry, ale nie idealny, ma swoje zalety i wady.

> Proponuję ci przy okazji małej zmiany dorzucić jakis wskaznik w strukturze.
Jakby się uprzeć, to nawet by działało - wystarczy że wskaźnik będzie 
aktualny. Ale po co stosować takie rozwiązania? Przed chwilą na zwykłe 
write mówiłeś że to bełkot, a teraz chcesz do struktur zapisywanych w 
pliku wkładać wskaźniki???

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28188

M.M. wrote:
> On Monday, December 7, 2015 at 4:22:44 PM UTC+1, witek wrote:
>> M.M. wrote:
>>> Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
>>> write( &strukt , sizeof(strukt) , file );
>>
>> kazdy bełkot da sie zapisać.
> To nie jest bełkot, tylko typowy zapis binarnych danych.

tak,
ale tylko na pierwszym roku studiów.


>
>> Chodzi o to, żeby go potem ktoś umiał zrozumieć przy odczycie.
> Bez dokumentacji to czasami protokół tekstowy ciężko zrozumieć.

no i? ma to być dowód na co?

>
>> Zapisywanie całej stuktury w ten sposób to nie jest dobry pomysł.
> Jest dobry, ale nie idealny, ma swoje zalety i wady.

Jest fatalny i nikt takich rzeczy profesjonalnie nie robi.
Od tego jest serializacja.


>
>> Proponuję ci przy okazji małej zmiany dorzucić jakis wskaznik w strukturze.
> Jakby się uprzeć, to nawet by działało - wystarczy że wskaźnik będzie
> aktualny.

że co?



> Ale po co stosować takie rozwiązania? Przed chwilą na zwykłe
> write mówiłeś że to bełkot, a teraz chcesz do struktur zapisywanych w
> pliku wkładać wskaźniki???
>
aha, rozumiem, Stringi pakujemy w strukture.
Powodzenia w znalezieniu pracy.

[toc] | [prev] | [next] | [standalone]

#28190

On Monday, December 7, 2015 at 6:40:48 PM UTC+1, witek wrote:
> M.M. wrote:
> > On Monday, December 7, 2015 at 4:22:44 PM UTC+1, witek wrote:
> >> M.M. wrote:
> >>> Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
> >>> write( &strukt , sizeof(strukt) , file );
> >>
> >> kazdy bełkot da sie zapisać.
> > To nie jest bełkot, tylko typowy zapis binarnych danych.
> 
> tak,
> ale tylko na pierwszym roku studiów.
Działanie funkcji systemowych zmienia się wraz z rokiem studiów :D


> 
> 
> >
> >> Chodzi o to, żeby go potem ktoś umiał zrozumieć przy odczycie.
> > Bez dokumentacji to czasami protokół tekstowy ciężko zrozumieć.
> 
> no i? ma to być dowód na co?
Na to, że dla zrozumienia kluczowa jest dokumentacja a nie kryptografia.


> >> Zapisywanie całej stuktury w ten sposób to nie jest dobry pomysł.
> > Jest dobry, ale nie idealny, ma swoje zalety i wady.
> 
> Jest fatalny i nikt takich rzeczy profesjonalnie nie robi.
> Od tego jest serializacja.
Fatalny, a dobrze działa.

> 
> 
> >
> >> Proponuję ci przy okazji małej zmiany dorzucić jakis wskaznik w strukturze.
> > Jakby się uprzeć, to nawet by działało - wystarczy że wskaźnik będzie
> > aktualny.
> 
> że co?
Że będzie wskazywał na dane których się spodziewa program.


> > Ale po co stosować takie rozwiązania? Przed chwilą na zwykłe
> > write mówiłeś że to bełkot, a teraz chcesz do struktur zapisywanych w
> > pliku wkładać wskaźniki???
> >
> aha, rozumiem, Stringi pakujemy w strukture.
> Powodzenia w znalezieniu pracy.
Przypomnij sobie, to Ty zaproponowałeś w poście wyżej.


Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28192

M.M. wrote:
> On Monday, December 7, 2015 at 6:40:48 PM UTC+1, witek wrote:
>> M.M. wrote:
>>> On Monday, December 7, 2015 at 4:22:44 PM UTC+1, witek wrote:
>>>> M.M. wrote:
>>>>> Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
>>>>> write( &strukt , sizeof(strukt) , file );
>>>>
>>>> kazdy bełkot da sie zapisać.
>>> To nie jest bełkot, tylko typowy zapis binarnych danych.
>>
>> tak,
>> ale tylko na pierwszym roku studiów.
> Działanie funkcji systemowych zmienia się wraz z rokiem studiów :D
>
>
>>
>>
>>>
>>>> Chodzi o to, żeby go potem ktoś umiał zrozumieć przy odczycie.
>>> Bez dokumentacji to czasami protokół tekstowy ciężko zrozumieć.
>>
>> no i? ma to być dowód na co?
> Na to, że dla zrozumienia kluczowa jest dokumentacja a nie kryptografia.
>
>
>>>> Zapisywanie całej stuktury w ten sposób to nie jest dobry pomysł.
>>> Jest dobry, ale nie idealny, ma swoje zalety i wady.
>>
>> Jest fatalny i nikt takich rzeczy profesjonalnie nie robi.
>> Od tego jest serializacja.
> Fatalny, a dobrze działa.
>
>>
>>
>>>
>>>> Proponuję ci przy okazji małej zmiany dorzucić jakis wskaznik w strukturze.
>>> Jakby się uprzeć, to nawet by działało - wystarczy że wskaźnik będzie
>>> aktualny.
>>
>> że co?
> Że będzie wskazywał na dane których się spodziewa program.
>
>
>>> Ale po co stosować takie rozwiązania? Przed chwilą na zwykłe
>>> write mówiłeś że to bełkot, a teraz chcesz do struktur zapisywanych w
>>> pliku wkładać wskaźniki???
>>>
>> aha, rozumiem, Stringi pakujemy w strukture.
>> Powodzenia w znalezieniu pracy.
> Przypomnij sobie, to Ty zaproponowałeś w poście wyżej.
>
>
> Pozdrawiam
>

proponujesz rozwiązania implementowane przez najsłabszych studentów 
pierwszego roku.
Tragiczne w założeniach i jeszcze gorsze w niezawodności.

[toc] | [prev] | [next] | [standalone]

#28193

On Monday, December 7, 2015 at 7:55:10 PM UTC+1, witek wrote:
> M.M. wrote:
> > On Monday, December 7, 2015 at 6:40:48 PM UTC+1, witek wrote:
> >> M.M. wrote:
> >>> On Monday, December 7, 2015 at 4:22:44 PM UTC+1, witek wrote:
> >>>> M.M. wrote:
> >>>>> Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
> >>>>> write( &strukt , sizeof(strukt) , file );
> >>>>
> >>>> kazdy bełkot da sie zapisać.
> >>> To nie jest bełkot, tylko typowy zapis binarnych danych.
> >>
> >> tak,
> >> ale tylko na pierwszym roku studiów.
> > Działanie funkcji systemowych zmienia się wraz z rokiem studiów :D
> >
> >
> >>
> >>
> >>>
> >>>> Chodzi o to, żeby go potem ktoś umiał zrozumieć przy odczycie.
> >>> Bez dokumentacji to czasami protokół tekstowy ciężko zrozumieć.
> >>
> >> no i? ma to być dowód na co?
> > Na to, że dla zrozumienia kluczowa jest dokumentacja a nie kryptografia.
> >
> >
> >>>> Zapisywanie całej stuktury w ten sposób to nie jest dobry pomysł.
> >>> Jest dobry, ale nie idealny, ma swoje zalety i wady.
> >>
> >> Jest fatalny i nikt takich rzeczy profesjonalnie nie robi.
> >> Od tego jest serializacja.
> > Fatalny, a dobrze działa.
> >
> >>
> >>
> >>>
> >>>> Proponuję ci przy okazji małej zmiany dorzucić jakis wskaznik w strukturze.
> >>> Jakby się uprzeć, to nawet by działało - wystarczy że wskaźnik będzie
> >>> aktualny.
> >>
> >> że co?
> > Że będzie wskazywał na dane których się spodziewa program.
> >
> >
> >>> Ale po co stosować takie rozwiązania? Przed chwilą na zwykłe
> >>> write mówiłeś że to bełkot, a teraz chcesz do struktur zapisywanych w
> >>> pliku wkładać wskaźniki???
> >>>
> >> aha, rozumiem, Stringi pakujemy w strukture.
> >> Powodzenia w znalezieniu pracy.
> > Przypomnij sobie, to Ty zaproponowałeś w poście wyżej.
> >
> >
> > Pozdrawiam
> >
> 
> proponujesz rozwiązania implementowane przez najsłabszych studentów 
> pierwszego roku.
> Tragiczne w założeniach i jeszcze gorsze w niezawodności.

Ja mogę odpowiedzieć, że proponujesz strzelanie z armaty do komarów. 
Do czego taka rozmowa doprowadzi? Do niczego?

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | pl.comp.programming

csiph-web