On Mon, 22 May 2023 16:05:38 +0200, heby wrote:
> On 22/05/2023 15:36, J.F wrote:
>>> std::size() jest znacznie bardziej przejrzysty, niż sizeof/sizeof i to
>> A zwraca wynik w bajtach, w elementach, czy to się po prostu wie? :-)
>
> Zwraca rozmiar.

Ale rozmiar w elementach, czy w bajtach? :-P

> Dla różnych typów zachowa się to jak zahardkodowana stała, zawołanie
> metody obiektu albo zostanie policzone na etapie kompilacji. Dzięki
> magii C++ wybór implementacji jest automatyczny.
>
> Ale to bez znaczenia, piszesz na poziomie na którym interesuje Cie
> *rozmiar* i już. Stringa, tablicy, wektora, listy. Rozmiar. Cokolwiek to
> oznacza.
> To jest właśnie wysokopoziomowe określenie potrzeby.

> W dodaku działa tak samo dobrze dla tablic i dla znacznie bardziej
> skomplikowanych kontenerów czy nawet głupich stringów.

stringa powiadasz ... bajtowego, unicode, utf-8 ? :-P

>>> wystarczy dla podniesienia jakosci i bezpieczeństwa. Takich konstrukcji
>>> jest wiele w C++ i nie operaja się one o jakieś trudne do ogarnięcia
>>> mechanizmy. Są wręcz trywialne.
>> Chyba, ze złośliwy programista przedefiniuje, bo może :-)
>
> To samo może i w C.
> Widziałem kod gdzie było:
> #define TRUE 0

> Zostawione w 1 pliku cpp na złość, przez niemiłego kodera-hackera.
> Gdybym nie miał tego pliku w historii to bym uznał to za jakas
> anegdotkę, a jednak kosztowało to kogoś dzień debugowania.

Możliwości jednak mniej, ale trzeba uważać :-)

No i ... jak to mieszane z innym systemem, to tam -1, tzn 0xff moze
oznaczać True ... albo i false

> Tak, trafiają
> się w tym zawodzie idioci, schizofrenicy, hackerzy, zarozumialcy,
> złośnicy. Mamy skuteczne metody ich eliminacji i utrudniania takich
> sabotaży.

obfuscate jednak cieszy sie popularnoscią ... tzn jako ciekawostka,
niekoniecznie w praktyczny użytku.

A takie np jQuery ... to juz nic nie trzeba zaciemniac :-)

>>> Nikt nie nakazuje używania skomplikowanego dziedziczenia czy operatorów.
>>> Nikt. To kwestia wyboru przez programistę. Mądry programita nie wybierze
>>> ich tylko dla beki. A na niemądrych jest lint i code review.
>> No nie wiem, czy zauważy, ze size() działa w danym obiekcie inaczej,
>> albo ze "+" oznacza teraz odejmowanie :-)
>
> Nie, ponieważ:
> a) programiści w zespołach nie są względem siebie złosliwi w normalej
> sytuacji. A jak są, drzwi otwarte.
> b) sami ustalają co można, a co nie, używać i z czym czują się komfortowo.

A jak to jest zespół złośliwych programistów?
Którzy dbają o swoje pensje ? :-)

> c) świadomośc tego jak coś działa w detalach jest przeciwieństwem
> współczesnego pisania wysoko abstrakcyjnego kodu
> d) są do tego unit testy, aby pilnować takich dupereli
> e) istotą size() jest to, aby działało w kazdym obiekcie/typie tak, jak
> tego się spodziewasz po słowie "rozmiar".
>
> Jedną z najtrudniejszych sztuczek jakie miałem w swojej karierze, jako
> osoba ucząca nowych członków zespołu, to była potrzeba wyplenienia z
> nich potrzeby wiedzy o tym jak coś działa w środku. Przestawienie
> programisty C z asemblera na myślenie abstrakcyjne jest nadludzkim
> wysiłkiem i nie w każdej sytuacji udało się.

Taa ... a ja potem sobie w "jeszcze lepszym" C#
deklaruję DataGridView, i się zastanawiam - ma to miejsce na dane, czy
nie ma?
A jak przypiszę w DGV DataTable, to użyje tego DT, przepisze na swoje
struktury, rozszerzy, czy jeszcze cos innego ...

> Wielu z nich nie potrafi
> inaczej myśleć niż pointerami, przez co współczesny kod C++ traktują
> dokładnie tak jak połowa ludzi w tym wątku - z wyparciem i urojeniami na
> temat jego wydajności.

A na macierzach zespolonych operuje już równie szybko jak Fortran,
czy nie bardzo ? :-P


Taa ... pisze sobie DataTable[i]["nr_klienta"] i myślę sobie ... jak
będą narzekać na wydajność, to będę myslał, nie teraz :-)

Albo czasem myslę "a ile może być tych rekordów w bazie ... milion?
To sobie wczytam wszystko do pamieci, a jak wyleci z błędem,
to sie dopisze "wymagane co najmniej 16GB RAM" :-(

J.