On 22/05/2023 18:08, J.F wrote:
>>> A zwraca wynik w bajtach, w elementach, czy to się po prostu wie? :-)
>> Zwraca rozmiar.
> Ale rozmiar w elementach, czy w bajtach? :-P

Rozmiar tablicy.

Co kogo obchodzi jej rozmiar w bajtach, poza allokatorami?

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

C++ nie wspiera UTF-8. Nie wspiera też Mazovii ani ATASCI.

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

U mnie true i false są zdefiniowane przez standard.

Patrz, jeszcze jeden powód żeby porzucić guano C.

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

Nie przejdzie przez review.

>> 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?

To *ty* sie zwalniasz.

> Którzy dbają o swoje pensje ? :-)

Dużo nie zrobią hackując zamiast programować.
>> 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#

Teraz znowu eskalujesz do zupełnie innego języka. To nieuczciwe.

To że Fordy się psują nie oznacza, że nie powinieneś kupować Mazdy.

> deklaruję DataGridView, i się zastanawiam - ma to miejsce na dane, czy
> nie ma?

Pisanie obiektowe, szczególnie modelów danych, wymaga ogólnej orientacji
w temacie modelowania danych. Nie bez powodu płaci się tym ludziom
więcej niż wklepywaczom faktur.

> A jak przypiszę w DGV DataTable, to użyje tego DT, przepisze na swoje
> struktury, rozszerzy, czy jeszcze cos innego ...

Zazwyczaj masz określoną złożonośc operacji. Reszta, to detale
implementacyjne.

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

Wrappery na BLAS/LAPACK są bardzo cienkie. Nie wiem w jaki magiczny
sposób miały by liczyć coś wolniej, keidy 99.99% kodu to ten sam kod co
w Fortranie.

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

Ludzie piszący poważny soft myślą o tym. Przesadzasz w drugą stronę
starając się udowodnić koncept, że kod obiektowy jest wolniejszy, bo
programista dupa.

> 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" :-(

Myślę, że nie rozumiesz jakie problemy rozwiązuje się z użyciem C++. C
też magicznie nie wyczaruje więcej RAMu. Probem z algorytmiką i miejscem
jest dokładnie taki sam. Natomiast C++ oferuje gotowe, przetestowane
algorytmy operujące na tych danych. Co w przypadku C zazwyczaj oznacza
qsotr i tyle, reszta to kwadratowe koła wymyślane przez brodatych
60-latków z założeniem, że nikt inny nie wpadł na ich popsute
rozwiązanie. Nie zliczę ile widziałem hash map napisanych w C. Każda
inna. I każda nieuniwersalna, nieprzetestowana inaczej jak na produkcji.
C to taki język, gdzie wszystko można. I niestety to powoduje radosną
twórczość i walenie kijem w pieniek.