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.

do góry

On 22/05/2023 15:17, io wrote:
>> Oczekują. MS pododawał masę ficzerów, takich jak np. kompleny system
>> firewalla/antywirusa, bo tego oczekiwali tumaniści.
> Użytkownika interesuje firwall? Co Ty gadasz.

Oczywiście. Nie dalej niż tydzień temu na sasiedniej grupie była
pogadanka o tym, że antywirusy są ważne, bo migają diodą dysku i używają
CPU. A wiec są bardzo ważne, choć nie wiadomo dokładnie co robią. Do
tego stopnia są ważne, że ludzie do dzisiaja instalują ten blatware
nawet, jeśli wymaga to płacenia. I że wyskakuje to ostrzeżenie czasami,
że coś jest, ale niekoniecznie, niebezpieczne. To bardzo ważne tworzenie
poczucia pato-bezpieczeństwa. Ludzie chcą, aby raz na jakiśczas system
dał im znać, że zatrzymał straszliwy atak albańskich hackerów. To im
pomaga być profesjonalistami.

Można oczywiscie napisać lepszy system operacyjny, ale komu by się chciało.

>> Dodał ogromny subsystem DirecX bo tego oczekiwali gracze.
> Co gracza obchodzi jakiś subsystem?

Obchodzi producenta OSa. Jesli MS nie ustandaryzował by subsystemu do
grania to:
1) gracze mieli by do wyboru naście implementacji, niekompatybilnych ze
sobą (już było: glide, opengl, wing)
2) ich system nie nadawał by się do "profesjonalnych zastosowań" czyli
do strzelania komuś w łeb w CS. To nie mój argument. Pamiętam rechot
pececiarzy w latach 80/90, którzy śmiali się że na Amidzę są gry, bo
jest blitter i spritey, a na pececie profesjonalne kopiowanie plików z
lewa na prawo w nortonie. Teraz wyszło, że wieszość domowych pecetów na
świecie używanych jest jako konsola do grania.

> Gracze
> w ogóle nie widzą potrzeby istnienia systemu operacyjnego choćby ten
> system w jakimś małym stopniu miał sens.

Widzą. Bezustannie muszą OS upgradeować aby im chodziły najnowsze
gierki. I nie maja ochoty rozwiązywać problemów "jaki sterowanik do gfx
dla gierki x". Ich obchodzi, aby ktoś to za nich zrobił. MS zrobił i to
jako tako działa. Na tyle, że od kilku lat nie muszę się interesować
jaki sterowanik gfx ściągnąć. Sam się ściąga i wszystko działa.

Sterowanik do płynnego strzelania komuś w łeb w CS nie jest może
niezbednyą częscią OSa, ale jest przez jego userów oczekiwany.

>> Dodał kilkanaście równległych wersji engines .NET bo tego oczekiwali
>> niedzielni programatorzy.
> Programiści nie pasują?

MS musiał wsadzić w windowsa różne wersje .NETa ponieważ nie potrafił
rozwizać problemu kompatybilności wstecznej API/ABI .NETa. Ten
workaround był tani dla MS ale drogi dla dysków userów. Sam naliczyłem
swego czasu 6 wersji .NETa na dysku. To nie były kilobajty.

Najzwyczajniej, jak się nie pomyślało zawczasu o sensownej metodzie
uprade API/ABI, to po kilku latach można tylko stosować durne workaroundy.

> Biblioteki rozwijają się aż ktoś mówi stop kompatybilności i sobie taka
> wersja zostaje.

Istnieją inne metody niż zamrażanie API/ABI i dostarczanie userom
kolejnych gigabajtów tych samych algorytmów. Tylko że wybrana przez MS
jest najzwyczajniej najtańsza (dla MS).

>> Dodał nowe sposoby aktualizacji oprogramowania, bo może tym razem
>> zadziała.
> Jakie?

Sklep. Też nie działa. Czekamy na nastepny. Coś w końcu wymyślą. To
wynika z prawdopodobieństwa.

>> Windows jest obecnie jak odkurzacz, wsysa do OSa wiele rzeczy,
>> niektóre potrzebne a niektóre to tylko artefakty debilnego planowania
>> MS. A notatnik jest tak samo gówniany, jak był. Pewne rzeczy, dobrze
>> wiedzieć, są niezmienne.
> No tak, na całym świecie są ludzie, którzy uważają że umieją to zrobić
> lepiej.

I robią. Zerknij na maki. Kultura projektowania tego systmu jest
wyraźnie większa niż MSowe "to spierdolimy to tak, a potem się zobaczy".

Nie, żeby maki były idealne.

W dziedzinie OSów dysponujemy głównie porażkami projektowymi będącymi
standardem rynkowym. Jak każdy standard, z grubsza.

do góry

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.

do góry

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.

do góry

On Mon, 22 May 2023 18:29:29 +0200, heby wrote:
> 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?

A może chcę zapisać na dysk?

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

Ale programy wymagają UTF-8.
To sobie klase zdefiniuje ... taki u8string :-)

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

W C/C++

A to moze być np program do komunikacji z czytnikiem kart bankowych.


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

Przeciez w C tez są zdefiniowane przez standard.
Tylko trochę słabo.
Albo lepiej niz w C++, bo brak wartosci nieokreślonych :-)

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

Oby.
Bo jak bedzie dobrze zaciemniony ... to przejdzie ?


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

Ja sie rozumiem z zespołem :-)

>> Którzy dbają o swoje pensje ? :-)
> Dużo nie zrobią hackując zamiast programować.

Zaraz tam hackować ...

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

Jest i w C++. Tylko nie moge znależć dokumentacji MS.

Taki tam mały przykład
https://www.functionx.com/vccli/controls/dgv.htm

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

oj, ja bym tam sprawdził kto komu rozwiązania narzuca :-)
Bo może Mazda to juz nie Mazda.
Choc akurat związki z Fordem ma juz dosc stare.

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

Nie o to chodzi.
Sorry za zmiane z c++ na .net/c#, ale masz klase DataGridView,
która jest taką tabelką na ekranie,
https://learn.microsoft.com/en-us/dotnet/api/system.
windows.forms.datagridview?view=windowsdesktop-7.0

i zawiera obiekt( właściwość?) Rows, któwy jest kolekcją wierszy,
zawierających dane. Wiersze typu DataGridViewRow

Ale mozesz też podłączyc inne źródło danych
https://learn.microsoft.com/en-us/dotnet/api/system.
windows.forms.datagridview.datasource?view=windowsde
sktop-7.0#system-windows-forms-datagridview-datasour
ce

np typ DataTable, która zawiera DataRow.

I sie teraz nie interesuj jak to jest zrobione, tylko powiedz
czy np mogę kolor komórki zmienić?
Albo co się stanie, jak wpiszę nową wartość w komórkę?

Albo np chcę jakąs funkcje wywołać po kolei dla dla wszystkich
wierszy, czy dla zakresu wierszy ... szybka sprawa, bo kolekcja
Rows juz sie składa z pojedynczych wierszy, czy taki pojedynczy
wiersz trzeba będzie dopiero zbudować?

Nie bez powodu doświadczeni programiści zarabiają dużo, a juniorzy
mało :-)

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

Być moze te wrappery obchodzą problemy, ale ... Fortran potrafi
operowac na liczbach zespolonych, bo to jego natywny typ.
W c++ to typ skonstruowany z innych. Jako, że było za wolno,
to nawrzucano inline.
Ale nadal, jak gdzies jest zwracana wartosc zespolona, to fortran
używał dwóch rejestrów, a c++ ... nie musi budować obiektu?

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

Nie tylko, wszystko robią, żebym sie jak d* zachowywał :-)

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

No fakt, sort w c++ szybki ... zrobili
wieloprocesorowo/wielordzeniowo?

> Nie zliczę ile widziałem hash map napisanych w C. Każda
> inna. I każda nieuniwersalna, nieprzetestowana inaczej jak na produkcji.

owszem ... ale czy nie wynika to z tego, ze różne wymagania, czy różne
optymalizacje mogą być?

a ta z c++ dobra na wszystko? I wydajna?

> C to taki język, gdzie wszystko można. I niestety to powoduje radosną
> twórczość i walenie kijem w pieniek.

J.

do góry

On 22/05/2023 21:30, J.F wrote:
>>> Ale rozmiar w elementach, czy w bajtach? :-P
>> Rozmiar tablicy.
>> Co kogo obchodzi jej rozmiar w bajtach, poza allokatorami?
> A może chcę zapisać na dysk?

To musi napisać serializator. Prawdopodobnie będzie miał w środku
std::size() aby zserializować każde pole osobno. Nie chcesz przeciez
zapisywać śmieci z paddingu pamięci, prawda? Albo, o zgrozo, gołych
pointerów, co w naszym wypadku zrzutu tablicy stringów miało by miejsce.

>>>> 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.
> Ale programy wymagają UTF-8.

I dlatego możesz wybrać Qt, które używa natywnie UTF-16 i potrafi, jesli
potrzebujesz, policzyć ile jest tam *znaków* jak również przemieszczać
się między UTF-8. Tylko że od razu mówię, że policzenie ilosci znaków w
UTF to zagadnienie na habilitację. Nie bez powodu jest skomplikowane a
zdaje się że w kilku wypadkach (bodaj Koreański) mocno mętne.
QTextBoundaryFinder.

Innymi słowy, jeśli masz zagadnienia związane z tekstem UTF, to masz
zagadnienia związane z jego wyświetlaniem, a to jest cecha biblitek
graificznych, nie C++. C++ nie posiada w standardzie nic [G]UIowego.

> To sobie klase zdefiniuje ... taki u8string :-)

Już to zrobiono i to znacznie lepiej niz tylko u8. QString.

>> U mnie true i false są zdefiniowane przez standard.
> W C/C++
> A to moze być np program do komunikacji z czytnikiem kart bankowych.

Wtedy masz połaczenie z hardware i wtedy piszesz translator z
hardwarowego true na softwareowy true.

Reszta algorytmini nie powinna nic wiedzieć o jakims hardware, a
prawidłowo napisana powinna dać się uruchmić i przetestować bez hardware.

>> Patrz, jeszcze jeden powód żeby porzucić guano C.
> Przeciez w C tez są zdefiniowane przez standard.
> Tylko trochę słabo.

C nie wspiera typu bool. Różne OSy różnie definiują TRUE/FALSE.
Napisanie w tym bałaganie generycznego/przenośnego algorytmu jest
utrudnione.

Prawie każda przenośna bibliteka, z korzeniami w C, redefiniuje wszstko.
To świadczy o tym, jak kiepski to język, skoro nawet podstawowe typy nie
mają sensownie okreśonych sizeof i trzeba to łatać ręcznie.

> Albo lepiej niz w C++, bo brak wartosci nieokreślonych :-)

A są jakieś nieokreslone wartości bool?

Jak chcesz świadomie, to w boost jest tribool. On ma trzecią wartość,
niezdefiniowaną.

Jest też boost::optional<bool> który może służyć za to samo.

>>> obfuscate jednak cieszy sie popularnoscią ... tzn jako ciekawostka,
>>> niekoniecznie w praktyczny użytku.
>> Nie przejdzie przez review.
> Oby.
> Bo jak bedzie dobrze zaciemniony ... to przejdzie ?

Zakładasz corner case.

Tak, czasmi trafia się cieżki kod na review. Ale nie na tyle cieżki, aby
ktoś przerzucił przez niego sabotaż. Kod obiektowy jest relatywnie
czytelny. Schowanie tam jakiejś niegrzecznej logiki jest trudne jeśli
review przegląda doświadczony programista.

Jeszcze raz: jeśli masz w zespole sabotażystę, to nie tylko wylatuje on
z automatu z teamu, jego wrzuty też się przegląda i wycofuje/naprawia.

>>>> 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.
> Ja sie rozumiem z zespołem :-)

Nie zawsze tak jest. Część ludzi z którymi pracowałem zwalniała się z
poprzednich firm z powodu toksycznej atomsfery, intryg, czy zwykłego
bullying. Rózne były opowieści, ale zazwyczaj po czyms, co amerykanie
nazywają "red flags" ludzie się zwalniają. Są firmy i korpo, gdzie red
flags jest widoczne na wejściu a są też takie, że pojawiają się po
tygodniach pracy.

>>> Którzy dbają o swoje pensje ? :-)
>> Dużo nie zrobią hackując zamiast programować.
> Zaraz tam hackować ...

Hackowanie to pisanie kodu w sposób, który jest czytelny tylko dla
piszącego, albo powodujący rózne problemy w teamie, w przyszłych
refactoringach itd itp.

Na przykład wykorzystywanie, nielegalnie, pamięci poza zakresem
allokacji, bo "tam przecież jest padding", co powoduje milion błedów
valgrinda, choć aplikacja działa. To jest hacking. Można zrobić to
normalnie i poprawnie, ale można też pokazać że jest się samcem omega,
wprowadzajac fikuśne rozwiązania mające na celu zdenerowwanie wszystkich
na około.

>>>> 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.
> Jest i w C++. Tylko nie moge znależć dokumentacji MS.

Ale co jest?

> Taki tam mały przykład
> https://www.functionx.com/vccli/controls/dgv.htm

To jest Managed C. Nie ma nic wspólnego z C++.

> I sie teraz nie interesuj jak to jest zrobione, tylko powiedz
> czy np mogę kolor komórki zmienić?

Zazwyczaj odpowiada za to, w typowym GUI, Delegat. Poszukaj możliwosci
nadania delegata, którego zadanime jest rysowanie zawartości komórki.

Zobacz na przykąłd w Qt:

https://doc.qt.io/qt-6/qstyleditemdelegate.html

Model danych nie zawiera i nie powinien zawierać nic, co ma związek z
reprezentacją graficzną. On ma dostarczać dane i niczym innym nie
powinien się zajmować.

> Albo co się stanie, jak wpiszę nową wartość w komórkę?

To masz zazwyczaj jakiś "Editor" podpięty pod View (zobacz delegata z
Qt). W różnych biblitekach GUI to może się róznie nazywać (np. Setter)
ale ogólnie to jest cecha niezwiązana z modelem, choć model będzie miał
możliwośc akceptacji wyniku tego wpisania.

To jest wielopoziomowo rozbite w taki sposób, aby zadowolić jakiś
wariant wzorca MVC. Jeśli zrobiono to poprawnie, to każdy z elementów
tego mechanizmu ma ściśle określone zadania.

> Albo np chcę jakąs funkcje wywołać po kolei dla dla wszystkich
> wierszy, czy dla zakresu wierszy ... szybka sprawa, bo kolekcja
> Rows juz sie składa z pojedynczych wierszy, czy taki pojedynczy
> wiersz trzeba będzie dopiero zbudować?

Dlaczego chcesz wywołać jakąś metodę chodząc po modelu tabelki, a nie po
danych wprost?

Jeśli chcesz chodzić po np. selekcji, to na 100% z selekcji możesz
wydłubać element modelu. Ponieważ to Ty kontrolujesz model, to masz
dostęp do tego, co tam trzymasz.

Detale są rózne w róznych implementacjach, ale prawdę mówiąc, czy to
Java Swing, C# Forms czy Qt, podobieństwa są znaczne w ogólnej
organizacji koncepcji MVC.

>> 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.
> Być moze te wrappery obchodzą problemy, ale ... Fortran potrafi
> operowac na liczbach zespolonych, bo to jego natywny typ.

I jak go reprezentuje w pamieci? W C++ reprezentacja to dwa
floaty/double, czyli sizeof(double)*2. Fortran dał radę magicznie zrobic
to lepiej?

> W c++ to typ skonstruowany z innych.

Nie. Natomiast jest to typ szablonowy. Możesz chcieś zamiast float mieć
double. Szablon jest bezkosztowy - wynikowy kod asm jest perfekcyjnie
dobrany do danego typu i nie generuje w runtime śladu narzutu.

> Jako, że było za wolno,
> to nawrzucano inline.

inline jest w gestii kompilatora. jak uz na, że to coś da, to wstawia.

> Ale nadal, jak gdzies jest zwracana wartosc zespolona, to fortran
> używał dwóch rejestrów, a c++ ... nie musi budować obiektu?

Nie.

Sposoby zwracania złożonych typów w C++ to osobny temat i jest to dość
skomplikowane jesli chcesz odpowiedzi na poziomie asm. To, co się stanie
w kodzie wynikowym, zależy od optymalizacji. Ogólnie dla x86, jak to
sprawdzałem wiele lat temu, skomplikowane funkcje zwracające dane
złożone były bardzo często optymalizowane tak, że nie było wywołań
funkcji i używane było wiele rejestrów (taki żart z x86). Wszystko
zależy od typu CPU i zakresu optymalizacji, w dodatku często podlega
wagowemu ocenianiu przez kompilator, biorący wiele pod uwagę (w tym
pipeline i out of order execution). Nie bez powodu poważniejsze
kompilatory akcpetują nawet konkretny typ achitektury CPu (np
SandyBridge) aby te wybory były trafniejsze.

I mała uwaga: współcześnie cache jest prawie tak samo szybki jak
rejestry. Na tyle, że mało kogo obchodzi czy dana jest w rejestrze czy
cache, przy pipeline w procesorze robiącym kilka instrukcji w cyklu te
detale nie mają większego znaczenia.

>> 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.
> No fakt, sort w c++ szybki ... zrobili
> wieloprocesorowo/wielordzeniowo?

Może po prostu ktoś wie jak poprawnie używać słowa const, std::move itp,
aby wyjaśnić kompilatorowi co chce, a nie jak w C jak to coś uzyskać.
C++, dzięki określaniu intencji, ma wiecej swobody w wyborze narzędzi do
jej uzyskania.

>> Nie zliczę ile widziałem hash map napisanych w C. Każda
>> inna. I każda nieuniwersalna, nieprzetestowana inaczej jak na produkcji.
> owszem ... ale czy nie wynika to z tego, ze różne wymagania, czy różne
> optymalizacje mogą być?

Może nalezy zacząc od tego, czy te funkcje są w ogóle poprawne. W C
bardzo cieżko testować unit testami, wiec nie dowiesz się tego łatwo.

> a ta z c++ dobra na wszystko? I wydajna?

std::unordered_set jest tak wydajny, jak dobrze rozumiesz jak działają
wysokopoziomowe elementy języka i jak dobry jesteś w pisaniu poprawnych
funkcji haszujacych. Więc, jeśli napiszesz funckję haszującą { return 1;
} to wydajny nie będzie, jeśli nie dostarczysz operatora && to wydajny
nie będzie, jeśli wstawisz za dużo std::shared_ptr trzymajacych inty to
wydajny nei będzie itd.

Dodatkowo standard nic nie mówi o implementacji. Implementacja jest
rózna w różncyh wersjach kompilatora, OSa itd itp. Kiedyś był na
przykład zewnętrzny zestaw, o nazwie STLPort. W niektórych przypadkach
lepszy (szybszy, mniejszy narzut) od dostaczonego przez MS. Obecnie jest
też alternatywny zestaw w boost.

Jeśli szukasz czegoś konkretnego, prawie na pewno ktoś to juz napisał:

https://www.boost.org/doc/libs/1_80_0/doc/html/conta
iner.html

do góry

On 22.05.2023 21:30, J.F wrote:
> On Mon, 22 May 2023 18:29:29 +0200, heby wrote:
>> On 22/05/2023 18:08, J.F wrote:
[...]
>>> 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.
>
> Być moze te wrappery obchodzą problemy, ale ... Fortran potrafi
> operowac na liczbach zespolonych, bo to jego natywny typ.
> W c++ to typ skonstruowany z innych. Jako, że było za wolno,
> to nawrzucano inline.
> Ale nadal, jak gdzies jest zwracana wartosc zespolona, to fortran
> używał dwóch rejestrów, a c++ ... nie musi budować obiektu?
Nie wiem tego, ale idę o zakład, że we współczesne C (od C99) i C++
(chyba od C++98), czyli tak mniej więcej od ćwierćwieku operują na
liczbach zespolonych nie gorzej niż Fortran. W C wprowadzono wtedy
słówko kluczowe _Complex, natomiast w C++ jest to zrobione na
templejtach. A strukturę w tych językach można przekazać/zwrócić do/z
funkcji w rejestrach ,,od zawsze", o ile się tam zmieści (AFAIR
kompilator robi to po prostu automatycznie, w papierach trzeba
sprawdzić), a jak nie, to przez stos. Z drugiej strony zastanawiam się,
jak program napisany w Fortranie uruchomiony np. na 32-bitowym Intelu
mógłby przez rejestry zwrócić kompleksa gdzie re i im są to 128-bitowe
floaty (albo 256-bitowe). Rejestrów zabraknie. :-)

do góry

On 22.05.2023 22:29, heby wrote:
[...]
> I dlatego możesz wybrać Qt, które używa natywnie UTF-16 i potrafi, jesli
> potrzebujesz, policzyć ile jest tam *znaków* jak również przemieszczać
> się między UTF-8. Tylko że od razu mówię, że policzenie ilosci znaków w
> UTF to zagadnienie na habilitację. Nie bez powodu jest skomplikowane a
> zdaje się że w kilku wypadkach (bodaj Koreański) mocno mętne.
> QTextBoundaryFinder.
No i zdaje się dlatego Qt pod spodem używa ICU:
https://en.wikipedia.org/wiki/International_Componen
ts_for_Unicode. A
przynajmniej kiedyś używało.

> C nie wspiera typu bool. Różne OSy różnie definiują TRUE/FALSE.
> Napisanie w tym bałaganie generycznego/przenośnego algorytmu jest
> utrudnione.
Śmiem się nie zgodzić. Już jakieś ćwierć wieku temu, w C99, wprowadzono
słówko kluczowe _Bool, a do tego plik stdbool.h z przydatnymi duperelami.

do góry

heby <h...@p...onet.pl> napisał(a):
> C nie wspiera typu bool.

Wspiera, <stdbool.h> się kłania.

> Różne OSy różnie definiują TRUE/FALSE.

OSy nie są od definiowania elementów języka.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 23/05/2023 15:27, JDX wrote:
>> C nie wspiera typu bool. Różne OSy różnie definiują TRUE/FALSE.
>> Napisanie w tym bałaganie generycznego/przenośnego algorytmu jest
>> utrudnione.
> Śmiem się nie zgodzić. Już jakieś ćwierć wieku temu, w C99

C99 leży w trumnie. Nie budzić.

do góry