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.

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. Czyli Twój kod
staje sie bardziej generyczny i łatwiejszy w analizie. Do tego stopnia,
że templateowa funkcja, w której jest std::size(), działa dla szerokiego
zakresu danych wejściowych.

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

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