On Tuesday, December 8, 2015 at 5:12:10 PM UTC+1, Sebastian Biały wrote:
> On 2015-12-07 21:30, M.M. wrote:
> > Ale jeśli tak kategorycznie napiszesz, to dużo czytelników używających
> > prostszych mechanizmów pomyśli: ojeju, wszystkie moje programy działają
> > przez przypadek i zaraz padną.
>
> Pierdyliard programow padło po migracji na 64 bity.
Moje nie, może nie pamiętam jakiegoś małego wyjątku, ale raczej nie.


> Pierdyliard programów padło po migracji Win<->Lin.
Wielokrotnie przenosiłem z lin64 na win32, działały dość dobrze.

> Pierdyliar programow *własnie*
> pada bo ku zdzieiwieniu wielu programatorów na Win ich kompilator zaczął
> produkowac równolegle kod ARM.
Nie znam tego problemu.


> To że nie padł ci jakiś hello world nie oznacza że nie ma takich
> problemów w dużych aplikacjach.
Nie mam pojęcia co chcesz przez to powiedzieć. Nie chcę być złośliwy, ale
kolejność bajtów ani rozmiar typów prostych w moich programach nie
zmienia w zależności od ilości linii kodu.


> Są. Wiele osób na kierowniczych
> stanowiskach w wielu firmach podejmowalo decyzje bazujące na
> ignoranctwie, braku wyobraźni i pielegnowaniu dziadostwa.
Niekoniecznie takie decyzje wynikają z ignorancji. Była kiedyś tutaj
rozmowa, wszyscy zgodzili się, że wygra ten, kto dobrze przewidzi
rozwój projektu. Jeśli do małego programu użyje się metod ad-hoc i
potem ten program nie będzie rozwijany, to decyzja do wybrania metod
ad-hoc była bardzo słuszna. Wielokrotnie tak robię w małych programach i
nie żałuję tego. Natomiast jeśli program ma być potem rozwijany, to
oczywiście masz rację.



> > to myślę, że biblioteka do której linka podałeś, wymaga więcej świadomości
> > chociażby ze względu na to, że dużo dzieje się w destruktorach
>
> Nie.
>
> , a
> > klamerki nie są opcjonalne.
>
> Nie.
> > Programista zawsze powinien być świadomy
> > tego co robi.
>
> Słusznie. Świadomy nie wybierze zapisu raw nawet jesli ma napisać
> następny denny program do rozliczania faktur.
Nie wiem co wybierze. Jeśli jest świadomy i nie przewiduje rozwoju
tego dennego programu, to w ogóle nie zdziwię się, jeśli użyje
prymitywnych technik - wystarczą.



> > Ale nie przesadzałbym z całkowitym zakazem operowania na
> > binarnych formatach.
>
> Nie ma zakazu. Jest tylko armata z odpalony lontem wymierzona w stopę
> wyłacznie z powodu ignorancji.
Tak, jest taka armata, wielokrotnie już Ci przyznałem rację, ale tylko
wtedy gdy rozwój programu potoczy się w określonym kierunku. Jeśli
projekt sprzeda się w jednej sztuce i potem umrze, to gdzie ta armata?



> > Sorry, ale przyznając częściowo rację, nadal upieram się, ze foramty
> > binarne nadal mają się dobrze.
>
> Każdy format jest binarny.
Tak, ale użyłem tego określenia żeby odróżnić od formatu tekstowego.

> Problem nie lezy w tym jak zapisywać ale czy
> masz kontrolę nad tym jak się zapisuje.
Właśnie brak kontroli jest tutaj zaletą. Nie kontroluję, nie martwię się, nie
tracę czasu na szczegóły techniczne. Raz robię write, drugi raz robię
read i działa. Działa nawet jeśli zmienię ilość pól w strukturze. Tyle
że ma swoje ograniczenia, nie będzie kompatybilne ze starą wersją, ani
nie będzie łatwo zadbać o kompatybilność.

> Robiąc write na kawałki pamięci masz wiele niewiadomych.
Ja bym powiedział, że mam równanie z wieloma niewiadomymi, ale te
niewiadome skracają się do zera po obu stronach równania.

> Mam tutaj na tapecie przykład jak jakiś kretyn
> zapisywał do *xmla* liczbę i niespecjalnie przejmował się little/big
> endianess. Bo char* załatwia temat skuteczniej niż jakieś serializacje
> dla frajerów.
Nie rozumiem, to kolejny obcy dla mnie problem. Niedawno miałem kilka
giga xmli zaprojektowanych przez innego programistę. Gdy pracowałem nad
nimi, to ze wszystkim miałem problemy, ale nie z wczytaniem inta czy floata.


> To jak piszesz nawet drobne kawałki kodu niestety często oznacza rowniez
> jakie decyzje podejmujesz pisząc komercyjnie.
Że warto wypracowywać dobre nawyki, to się zgodzę, to jest dobry argument
za użyciem porządnej biblioteki do serializacji.


Pozdrawiam