znaczacy > comp.lang.* > comp.lang.c

Maciek Godek (29.01.2020, 23:40)
W dniu ?roda, 29 stycznia 2020 22:25:33 UTC+1 u?ytkownik heby napisa?:
> Jeb. W?a?nie u?y?e? zmiennej globalnej. Ojej. Cosi? mo?e sta??


No. Co si? mo?e sta??

> Innymi s?owy jeste? krytykowany ?e twój kod wymaga zmiennych globalnych,
> pytasz "czego nie mo?esz zrobi? bez stosu, a co móg?by? zrobi?, gdyby?
> mia? korutyny ze stosem", podaje przyk?ad a ty dajesz przyk?ad korutyny
> bez stosu joko dowód ?e te? da si? zrobi?.


To, czy u?yjesz zmiennej automatycznej, czy statycznej, to tylko drobna ró?nica w implementacji. Funkcjonalnie ten kod jest identyczny.
A je?eli nie jest, to poka? mi prosz? ró?nic?..

> > Hmm. Chyba wygl?da do?? tak samo.

> Nie, jedno to pure function a druga to side effect. Fundamentalna
> ró?nica, ludzie po?wi?cili ?ycie aby wykaza? lepszosc jednych nad
> drugimi, tony prac naukowych napisali. Przykro mi ?e nie dostrzegasz
> tego "detalu".


Korutyna nie jest "pure function".
Poczytaj sobie mo?e troszk?, zanim zaczniesz u?ywa? terminologii.
Czyste funkcje w ogóle nie maj? czego? takiego, jak "przebieg sterowania".

> Nie musia?em, sam napisa?e? przed chwil? przyk?ad korutyny która jest
> nie reentrant, thradsafe, wahatever. Moja z boosta jest reentrant,
> threadsafe, whatever.


No to poka? mi ró?nic? behawioraln?. Poka?, jak jedna si? mo?e zepsu?, a druga nie mo?e, bo na razieto tak sobie gadasz.
heby (29.01.2020, 23:41)
On 29/01/2020 22:37, Roman Tyczka wrote:
>> do jaki? absurdalnych przypadków 8051 z kompiltorem pisanym przez

> jaki? jaki'?
> jakich? jakich'?
> Uprzedzaj?c zarzut o nazizm gramatyczny:


Nie padnie. Jestem zwyk?ym leniem gramatycznym i zbywam takie zaczepki
g??bokim ziewem. ;)
M.M. (29.01.2020, 23:48)
On Wednesday, January 29, 2020 at 8:26:51 PM UTC+1, heby wrote:
> On 29/01/2020 19:50, M.M. wrote:
> A jak im pewnego dnia podmienisz gcc na g++ to co si? stanie? A jak
> pewnego dnia dorzucisz im do kodu class scoped_interrupt_disable to co
> si? stanie? Wybuchnie im? Odmówi? pracy bo niekoszerne? Dospowiedzi pójd??


Nie wiem co si? stanie. Prosi?e? o przyk?ad, wi?c poda?em. Wszystko ma
swoje wady i zalety, nawet C++ ma wady wzgl?dem C, a jako nadzbiór nie
powinien mie? wad. Koszt przeszkolenia jest nie do przeskoczenia.

Dlatego ja si? nie dam nabra? wi?cej na nowe super technologie. Programowa?o
si? kiedy? na kartach perforowanych, potem w kodzie binarnym, potem w asemblerach
gorszych, potem w lepszych, potem w makroaseblerach, w ko?cu w gorszych
j?zykach wysokiego poziomu, w lepszych i w najlepszych... Nie zaprzeczam ?e
nast?pi? rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
wierz? ?e ten rozwój nie wpada? i nie wpada w ?lepe uliczki, a po drugie,
jest takie prawo w ekonomii którego nazwy ju? nie pami?tam, ale mówi ono o
tym, ?e od pewnego momentu trzeba niewspó?miernie du?o pracy w?o?y? w
udoskonalanie, aby uzyska? minimalnie lepsze efekty. Jak my?lisz,ile pracy
trzeba w?o?y?, ?eby przyspieszy? trabanta rozp?dzaj?cy, a ile, aby
przyspieszy? najszybszy samochód na ?wiecie i tym samym pobi? rekord pr?dko?ci?

Podobnie jest od jakiego? czasu z j?zykami programowania, j?zyki rozbudowane i
dopracowane o milion procent, daj? przyspieszenie procesu wytwarzania
oprogramowania o kilka procent. A nak?ad ?rodków na przeszkolenie personelu
lub samego siebie jest tym wi?kszy, im j?zyk bardziej rozbudowany.. Zmiana
technologii op?aca si? dopiero na d?u?? met?,do wi?kszych projektów.

> gcc:
>
> Kernel to problem bia?kowy. W zasadzie to problem jednego konkretnego
> zbioru moleku?, ale ludzie i tak robi? swoje:
>
> x-server nie wiem. Nie przypuszczam aby komukolawiek op?aca?o si? to
> przepisywa? dla idei, to raczej kod muzealny.
> Czyli mówisz o czym? innym ni? ja. Spieraj si? wi?c z kim? innym.


Spokojnie, ja jeszcze nie jestem pewny o co si? spieramy :)
Napisa?em o tym z jakim sposobami u?ywania okre?lenia 'programowanie w C++'
si? spotka?em, dlatego ?eby wiedzie? o czym rozmawiamy.

> >> W ogóle nie ma tutaj obiektowo?ci poza u?yciem jej w celu
> >> obs?ugi *ewentualnych* szablonów, bo tak to si? robi w C++.

> > Nie rozumiem.

> U?ycie sk?adni obiektowej (struct/class) nie oznacza ?e u?ywa si?
> obiektowo?ci.


Dlaczego?

> Sk?adnia ta bowiem przydaje si? w szablonach, jest wr?cz
> podstaw? pisania z u?yciem generycznych typów w C++. Nie maj?cych nic
> wspólnego z programowaniem obiektowym.


Chyba nadal nie rozumiem. A jakie wnioski z tego p?yn??

> Prawda.


> > Mnie bardzo dziwi taki sposób porównywania, dlaczego porównywa? do czego? co
> > powodowa?o (szczególnie u niedo?wiadczonych programistów) b??dy wykrywalne
> > po dwóch dniach debugowania?

> Mam buga który ukrywa? si? w void* przed ponad 10 lat. Przed oczami
> do?wiadczonych programistów. Jedyny powód ?e uda?o si? go znale?? to
> *przypadek*.


A ja zapewne mam niejeden taki b??d w szablonach.

> > Szablony maj? okropn? sk?adni? i podobno lepsza w
> > ogóle nie istnieje.

> Lepsza pewnie istnieje, ale te? sk?adnia nie jest okropna.


No dobrze, ja nie lubi?, ale kilku dyskutantów przed laty te? mówi?o ?e
nie lubi.

> Serio, uwa?asz ?e:
> traits< int >::max
> to jaka? okropna sk?adnia? Nie czerpiesz aby przypadkiem wiedzyo
> szablonach z jaki? grup anonimowych pisaczy w c?


Racja, takie proste przypadki s? bardzo przejrzyste. Mia?em na my?li sytuacje
gdy jeden szablon jest parametryzowany kilkoma innymi szablonami i jeszcze
dziedziczy z innego szablonu. Potem gdzie? w klasie jaka? statyczna tablica,
wszystko w kilku wersjach zale?ne od kompilacji warunkowej... Naprawd? w
takich sytuacjach mocno t?skni? za minimalistycznym C++ albo za Jav?, ale
có?, przyznaj?, ?e ani w Javie, ani w minimalistycznym C++ takiego efektu
nie uzyskam. Natomiast nie przyznam ?e szablony stanowi? eleganck? i
przejrzyst? sk?adni?, sprzyjaj?c? analizie kodu i sprzyjaj?c? pisaniu kodu
pozbawionego b??dów. Tak si? mówi ?e szablonystanowi? antidotum na b??dy, bo
porównuje si? je zwykle do najbardziej b??dogennych konstrukcji j?zyka, jak
wla?nie do makr, albo do rzutowania na void*.

> > Osobi?cie wcale nie pope?niam mniej b??dów w szablonach ni?
> > bez szablonów, w?a?ciwie to wielokrotne dziedziczenie z szablonów masakrycznie
> > komplikuje kod

> Ca?e szcz?scie wielokrotne dziedzidzenie szablonów wyst?puje g?ównie w
> bajkach i ksi?zeczkach dla niegrzecznych programistów c.


Wielokrotnie w sensie ?e jedna klasa (szablon) dziedziczy z bezpo?rednio z
kilku to owszem rzadko spotykana konstrukcja i niekoniecznie zalecana.
Ale po?rednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Y z Z, a Z
mo?e z kolejnych - to sytuacja cz?sta. Gdy ka?de jeszcze ma jakie? parametry i
typy - to naprawd? zazwyczaj dostawa?em oczopl?su gdy analizowa?em swój w?asny
kod po krótkim czasie. My?l? ?e ka?dy programista uzna?by za ?atwiejszy w
analizie kod np. Javy.

> >, debugowanie takiego kodu jest trudniejsze ni? zwyk?ego kodu.

> Robie to codziennie od kilkudziesi?ciu lat i cie?ko mi si?zgodzi?.


Mo?e zwykle u?ywasz szablonów po bo?emu, a nie do optymalizacji kodu? No i
szablony porównujesz to do makr i void* - czyli do czego? najbardziej
b??dogennego. Je?li u?ywam w pewien okre?lony sposób szablonów, to te?
nie mam z nimi problemów. Ale gdy np. ca?y algorytm genetyczny parametryzuj?
kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
edytor nie wie jakie metody b?d? mia? parametry.

[..]
> c) narz?dzia do lintowania wybijaja sobie z?by
> d) narz?dzia do statycznych analiz kodu s? zagubione
> e) code review nie przejdzie


To wszystko prawda, cho? z review to zale?y gdzie :-) Nie chcia?em
absolutnie powiedzie?, ?e macie ola? szablony i wróci? do void*.
Chcia?em powiedzie?, ?e je?li sobie radzono bez szablonów i system
operacyjny z GUI dzia?a? na 16MB RAM i pentium I 160MHz - to nie
ulegajmy z?udzeniu, ?e te szablony a? tak nies?ychanie du?o wnosz?.
Nigdy nie negowa?em szablonów, ale te? nigdy nie powiem, ?e brak
szablonów to strona czarna, a programowanie z szablonami to strona
bia?a.

> Ale oczywis?ie znam milion przyk?adów ?e mo?na mimo to. To "mo?na" to
> kwesia zwyk?ej higieny. Mo?na pisa? na void* tak samo jak mo?na mieszka?
> przy wysypisku i udawa? ?e to wiejskie zapachy.


Mam nadziej? ?e ju? jest zrozumia?e, i? nie namawiam nikogo do zrezygnowania z
szablonów, szczególnie u?ywanych po bo?emu, tylko zwracam uwag? na to, ?eby
nie traktowa? szablonów jako czego? dzi?ki czemu technologia wytwarzania
oprogramowania przyspieszy?a o kiladziesi?t procent, bo bez szablonów by?a
ju? ca?kiem szybkim samochodem, który trudo przyspiesza? w niesko?czono??.

> > Z
> > kolejnych wad szablonów, d?ugi czas kompilacji gdy w programie jest bardzo
> > du?o szablonów.

> Jeste? nastepnym developerem w tej dyskusji z Atari 65XE jako ci?g??
> integracj??


Nie, po prostu czasami mam w kodzie nasrana pe?no szablonów, jeden szablon
jest parametryzowany innymi, te inne te? s? parametryzowane jeszcze innymi, a
niektóre s? w kilku wersjach. Je?li zmieniam warunki kompilacji warunkowej to
musz? czeka? 30 sekund na pe?n? rekompilacj? (relatywnie) ma?ego programiku, a
test cz?sto te? trwa 30 sekund. Po prostu Ty u?ywasz szablonów inaczej ni? ja, i
odpisa?e? ze swojej perspektywy. Ja je?li si?gam po szablony to jest te?
jakie? prawdopodobie?stwo ?e chc? optymalizowa? kod, np. chc? wygenerowa?
skrojony sporawy kod na miar? konkretnego przypadku do rozwi?zania.

> Pracuje na *zaje...e* ogromnej bazie kodu w C++. Kompilacja najd?u?szego
> i najbardziej popieprzonego pliku (zawiera g?ównie boost::spirit)
> napisanego z palca trwa co? pod 3 sek. Uwierz mi, to jest makabrycznie
> du?o zaawansowanego C++ i *tylko* 3 sekundy. Czy ju? umar?e? z nudów?


Ja przed chwil? doda?em do kompilacji -DOPCJA_X i czeka?em na pe?n?
kompilacj? z 30 sekund na dwóch rdzeniach. Jak jeszcze jest pomi?dzy
kompilacj? -fprofile-generate i -fprofile-use to czekam 2 minuty aby
zrobi? 30 sekundowy test.

> > Kolejna wada, trzeba udost?pni? kod ?ród?owy gdy si?
> > udost?pnia bibliotek? napisan? w postaci szablonów.

> Brednia.


To ch?tnie si? dowiem dlaczego, my?la?em ?e szablony to nag?ówki niezb?dne
do wygenerowania konkretnej wersji kodu, jak to udost?pni? w wersji
binarnej bez ?róde??

> > Nast?pna wada, kompilatory
> > czasami wskazuj? b??d daleko od jego wyst?pienia.

> Brednia w 99% wypadków.


U mnie w oko?o 30% przypadków jest to prawda.

> > Podsumowuj?c, kiedy? szablonów u?ywano rzadko albo w ogóle nie u?ywano

> Podobnie jak z papierem toaletowym.


Tylko ?e papier toaletowy nie ma nic wspólnego z programowaniem, a (nie)u?ywanie
szablonów ma sporo.

> Na patrz, a ja mia?em Amig? z 2MB pami?ci chip i na tej konfiguracji
> pogania?em SaSC w trybie C++ pisz?c obiektowe programy GUIowe. Mo?e to
> czary?


Mo?e czary, a mo?e to (w jakim? stopniu) dzi?ki void* ?

> > Jakby to
> > by?o napisane w 'C++ pe?n? g?b?', to nie wiem czy by dzia?a?o nawet 5 lat
> > pó?niej - ale na pewno jakby ju? zacz??o dzia?a? to by dzia?a?o lepiej i
> > szybciej by?oby rozwijane o nowe cechy.

> A po chwili si? budzisz i okazuje si? ?e ten sam program kompilowalny w
> C i C++ generuje dok?adnie taki sam kod asemblerowy.


Przecie? to jest oczywiste, ?e ka?da konkretyzacja szablonu oznacza nie
tylko ró?ny kod, ale nowy dodatkowy kod. Co nie znaczy, ?e nie mo?na
u?ywa? szablonów tak, aby ?atwo zrobi? kilka eksperymentów i wybra?
wariant generuj?cy najmniejszy kod.

> No, ale wiadomo, 100x wolniejszy bo to C++. Du?o NOPów si?wstawia na
> z?o?? tym wszystkim zaprza?com.


Hmmmm a to zaprza?cy ;-)

Pozdrawiam
heby (29.01.2020, 23:56)
On 29/01/2020 22:40, Maciek Godek wrote:
>> Jeb. W?a?nie u?y?e? zmiennej globalnej. Ojej. Co si? mo?e sta??

> No. Co si? mo?e sta??


Si? stan mo?e pomiesza? mi?dzy korutynami.

>> Innymi s?owy jeste? krytykowany ?e twój kod wymaga zmiennych globalnych,
>> pytasz "czego nie mo?esz zrobi? bez stosu, a co móg?by? zrobi?, gdyby?
>> mia? korutyny ze stosem", podaje przyk?ad a ty dajesz przyk?ad korutyny
>> bez stosu joko dowód ?e te? da si? zrobi?.

> To, czy u?yjesz zmiennej automatycznej, czy statycznej, to tylko drobna ró?nica w implementacji.


Nie, to ró?nica mi?dzy programowaniem funkcyjnym a tym drugim.

> Funkcjonalnie ten kod jest identyczny.


Nie. Bo zale?y to od reszty kodu którego nie wida?. Konkretnie kod *nie*
pure nie da si? oceni? patrz?c tylko w jedn? funkcj?.

> A je?eli nie jest, to poka? mi prosz? ró?nic?.


Dwie identyczne korutyny przeplataj?ce si? w jednym flow b?da si? zak?óca?.

Dwie identyczne korutyny nie przeplatajace si?, ale b?d?ce w ró?nych
w?tkach b?da si? zak?uca?.

Poprawnie napisana bibliteka do coroutines nie b?dzie mia?a tych wad
poniewa? zadba o *osobny* stos per wywo?anie. Tak robi ka?da znana mi
bibliteka do korutyn w jezykach imperatywnych. W tych innych pewnie te?.

>> Nie, jedno to pure function a druga to side effect. Fundamentalna
>> ró?nica, ludzie po?wi?cili ?ycie aby wykaza? lepszosc jednych nad
>> drugimi, tony prac naukowych napisali. Przykro mi ?e nie dostrzegasz
>> tego "detalu".

> Korutyna nie jest "pure function".


Nie ma przeszkód aby by?a. Przyk?adowo spora cz??c wzorca projektowego
"generator" jest pure i jest korutyn?. Iteratory s? korutyn? i s?
zazwyczaj pure. W ogóle, wiele rzeczy jest pure. Bez znaczenia czy to
korutyny czy zwyk?e funkcje.

Tylko nie u Ciebie. U Ciebie ka?de u?ycie zmiennej ko?czy si? byciem
"nie pure". Chyba ?e zastosujesz lokalny kontener na zmienne, ale wtedy
musisz zarz?dza? nim poza korutynami. I tak wynalaz?e? w?a?nie
cooperative multitasking, tylko kwadratowy.

> Poczytaj sobie mo?e troszk?, zanim zaczniesz u?ywa? terminologii.


O ba, Panie, ja to stosuje od dawna. Przeczyta?em to z jakie? 20 lat
temu, obecnie bazuje wy??cznie na w?asnej ignorancji.

> Czyste funkcje w ogóle nie maj? czego? takiego, jak "przebieg sterowania".


No i wychodzi na to ?e nie czaisz bazy. Moja *funkcja* jest pure. Twoja
nie. Obie s? korutynami.

Ja mog? napisa? "nie pure" funkcje jak chc? lub musz?.

Ty nie mo?esz napisa? pure poza duperelowatymi funkcyjkami bez stanu. Bo
mechanizm ma fundamentaln? wad?. Stan jest poza lokalnym stosem. Game over.

>> Nie musia?em, sam napisa?e? przed chwil? przyk?ad korutyny która jest
>> nie reentrant, thradsafe, wahatever. Moja z boosta jest reentrant,
>> threadsafe, whatever.

> No to poka? mi ró?nic? behawioraln?. Poka?, jak jedna si? mo?e zepsu?, a druga nie mo?e, bo na razie to tak sobie gadasz.


Och, pu?c t? sam? korutyn? 2x w jednym flow, na przemian.

Moja zadzia?a, twoja zapl?cze si? we wspólnym stanie.

Nie ma manipulacji stosem, nie ma korutyn. Jest tylko "jump oriented
programming".
Maciek Godek (29.01.2020, 23:58)
W dniu ?roda, 29 stycznia 2020 22:48:44 UTC+1 u?ytkownik M.M. napisa?:
> > > Szablony maj? okropn? sk?adni? i podobno lepsza w
> > > ogóle nie istnieje.

> > Lepsza pewnie istnieje, ale te? sk?adnia nie jest okropna.

> No dobrze, ja nie lubi?, ale kilku dyskutantów przed laty te? mówi?o ?e
> nie lubi.


Ja te? nie lubi?. Jest koszmarna. I niejednoznaczna. I nierozstrzygalna.
Maciek Godek (30.01.2020, 00:05)
W dniu ?roda, 29 stycznia 2020 22:56:31 UTC+1 u?ytkownik heby napisa?:
> On 29/01/2020 22:40, Maciek Godek wrote:
> >> Jeb. W?a?nie u?y?e? zmiennej globalnej. Ojej.Co si? mo?e sta??

> > No. Co si? mo?e sta??

> Si? stan mo?e pomiesza? mi?dzy korutynami.


Poka? przyk?ad.

> Dwie identyczne korutyny przeplataj?ce si? w jednym flow b?da si? zak?óca?.


Podaj przyk?ad.

> Dwie identyczne korutyny nie przeplatajace si?, ale b?d?cew ró?nych
> w?tkach b?da si? zak?uca?.


Semantyka korutyn w ró?nych w?tkach nie jest nawet dobrze okre?lona.
Nie wiadomo, jak si? powinno zachowywa?.

> >> Nie, jedno to pure function a druga to side effect. Fundamentalna
> >> ró?nica, ludzie po?wi?cili ?ycie aby wykaza? lepszosc jednych nad
> >> drugimi, tony prac naukowych napisali. Przykro mi ?e nie dostrzegasz
> >> tego "detalu".

> > Korutyna nie jest "pure function".

> Nie ma przeszkód aby by?a.


Jest zasadnicza. Korutyna ma swój stan wewn?trzny, który z definicji jest mutowalny.
A czysta funkcja robi tylko jedno: odwzorowuje wej?cie w wyj?cie.Zawsze dla tego samego wej?cia ma da? to samo wyj?cie. Nie ma stanu wewn?trznego.

I to jest do?? kolosalna przeszkoda.

> > Czyste funkcje w ogóle nie maj? czego? takiego, jak "przebieg sterowania".

> No i wychodzi na to ?e nie czaisz bazy. Moja *funkcja* jest pure. Twoja
> nie. Obie s? korutynami.


Korutyna to nie jest funkcja. Tutaj masz definicj?, prosz?:


> >> Nie musia?em, sam napisa?e? przed chwil? przyk?ad korutyny która jest
> >> nie reentrant, thradsafe, wahatever. Moja z boosta jest reentrant,
> >> threadsafe, whatever.

> > No to poka? mi ró?nic? behawioraln?. Poka?, jak jedna si? mo?e zepsu?, a druga nie mo?e, bo narazie to tak sobie gadasz.

> Och, pu?c t? sam? korutyn? 2x w jednym flow, na przemian.


Nie wiem o czym mówisz. Napisz kawa?ek kodu, to b?d? wiedzia?.
Problem jest taki, ?e okre?lenie "ta sama korutyna puszczona 2x wjednym flow" nie jest jednoznaczna, bo nie wiem, co masz na my?li mówi?c "ta sama korutyna". Kawa?ek kodu wszystko wyja?ni..
Maciek Godek (30.01.2020, 00:22)
W dniu ?roda, 29 stycznia 2020 22:56:31 UTC+1 u?ytkownik heby napisa?:

> Och, pu?c t? sam? korutyn? 2x w jednym flow, na przemian.


Postanowi?em spróbowa?. Zmiksowa?em ze sob? parzyste i nieparzyste wywo?ania tej samej korutyny w jednym flow:

void jeden_flow(void) {
ta_sama_korutyna(); // wywo?anie nieparzyste
ta_sama_korutyna(); // wywo?anie parzyste
ta_sama_korutyna(); // wywo?anie nieparzyste
ta_sama_korutyna(); // wywo?anie parzyste
}

dla porównania tutaj mam po prostu ci?g wywo?a? tej samej korutyny, bez przemieszania:

void bez_miksowania(void) {
ta_sama_korutyna(); // pierwsze wywo?anie
ta_sama_korutyna(); // drugie wywo?anie
ta_sama_korutyna(); // trzecie wywo?anie
ta_sama_korutyna(); // czwarte wywo?anie
}

Ku mojemu zdziwieniu, oba zachowa?y si? dok?adnie tak samo.
heby (30.01.2020, 00:41)
On 29/01/2020 22:48, M.M. wrote:
>> A jak im pewnego dnia podmienisz gcc na g++ to co si? stanie? A jak
>> pewnego dnia dorzucisz im do kodu class scoped_interrupt_disable to co
>> si? stanie? Wybuchnie im? Odmówi? pracy bo niekoszerne? Do spowiedzi pójd??

> Nie wiem co si? stanie. Prosi?e? o przyk?ad, wi?c poda?em.


Ten przyk?ad nie t?umaczy problemów w C++ tylko w bia?ku.

> Wszystko ma
> swoje wady i zalety, nawet C++ ma wady wzgl?dem C


W sensie ?e jest bardziej restrykcyjny? S?ysza?me kiedy? ?e to wada. Do
dzisiaj nie wiem dlaczego.

>, a jako nadzbiór nie
> powinien mie? wad. Koszt przeszkolenia jest nie do przeskoczenia.


Napisa?em Ci ?e nic nie musisz szkoli? poza "ch?opaki, od dzisiaj w
ka?dym przerwaniu na arma na pocz?tku ma sta? scoped_interrupt_disable
sid(); i h...". A jak który? podskoczy to w ?eb. Koniec szkolenia. Po
roku nie dadz? sobie tego si?a odebra?.

> nast?pi? rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
> wierz? ?e ten rozwój nie wpada? i nie wpada w ?lepe uliczki


Kiedy? ludzie uwa?ali BCPL za spe?enienie marze?. Sam si? kompiluje,
mo?na zrobi? bootstrap na dziwnym systemie, architektura wr?cz zdj?ta z
tablicy uczelni, *uproszczona* sk?adnia.

I wiesz co, trafi?em kiedy? przez zupe?ny przypadek na kolesia który nie
do?? ?e pisa? jeszcze ko?o 2000 roku w tym cudzie to jeszcze przez
nastepne 10 lat mia? do niego straszny sentyment.

Widzisz, to co piszesz to bia?ko.

Mam takie a takie do?wiadczenia, widzia?em to i tamto, wnioskuje z tego
to i owo.

A na koniec okazuje si? ?e programy w C++ nie do?? ?e s? czytelniejsze
od tych w C, to cz?sto s? szybsze, ?atwiejsze w analizie i refaktoringu.

Tylko ?e bia?ko. Bia?ko wie lepiej, szczególnie jak si? na czym? nie zna.

No wi?c dowiedzia?em si? ?e C to gówno. BCPL by? lepszy.

Bia?ko ...

>, a po drugie,
> jest takie prawo w ekonomii którego nazwy ju? nie pami?tam, ale mówi ono o
> tym, ?e od pewnego momentu trzeba niewspó?miernie du?o pracy w?o?y? w
> udoskonalanie, aby uzyska? minimalnie lepsze efekty. Jak my?lisz, ile pracy
> trzeba w?o?y?, ?eby przyspieszy? trabanta rozp?dzaj?cy, a ile, aby
> przyspieszy? najszybszy samochód na ?wiecie i tym samym pobi? rekord pr?dko?ci?


To teraz z tej analogi zrób casta na konkret.

To jaki j?zyk jest tym najszybszy na ?wiecie?

Rust chyba obecnie jest na karuzeli terndów?

I co to ma w ogóle do dyskusji o tym ?e zmiana z gcc na g++ dodaje od
razu za darmo mas? mo?liwosci które w C wymagaj? pisania kwadratowych kó??

>> Czyli mówisz o czym? innym ni? ja. Spieraj si? wi?c z kim? innym.

> Spokojnie, ja jeszcze nie jestem pewny o co si? spieramy :)


Podobno o wy?szo?? C++ nad C i odwrotnie.

Tylko ?e ja si? o to nie spieram. Ja tylko protestuje przeciwko
bredzeniu o tym ?e zmiana z gcc na g++ jest niemozliwa, bezsensowna i
korutyny nie musz? mie? stosu a programi?ci musz? si? szkoli? z u?ywania
prymitywnego RAII.

> Napisa?em o tym z jakim sposobami u?ywania okre?lenia 'programowanie w C++'


Wie? programowanie w C++ to programowanie z dowolnym ficzerem dost?pnym
w g++ a niedostepnym w gcc. Na przyk?d z u?yciem RAII, które to jest
swoj? drog? krytycznie potrzebne w embedded i jednoczesnie skandalicznie
olewane przez embedded. Bo kwadratowe ko?a ?atwiej si? produkuje ni?
kupuje okr?g?e.

>>>> W ogóle nie ma tutaj obiektowo?ci poza u?yciem jej w celu
>>>> obs?ugi *ewentualnych* szablonów, bo tak to si? robi w C++.
>>> Nie rozumiem.

>> U?ycie sk?adni obiektowej (struct/class) nie oznacza ?e u?ywa si?
>> obiektowo?ci.

> Dlaczego?


Bo obiektowo?c wymaga *OBIEKTÓW* a nie klas.

>> Sk?adnia ta bowiem przydaje si? w szablonach, jest wr?cz
>> podstaw? pisania z u?yciem generycznych typów w C++. Nie maj?cych nic
>> wspólnego z programowaniem obiektowym.

> Chyba nadal nie rozumiem. A jakie wnioski z tego p?yn??


?e traits< int >::max to nie jest programowanie obiektowe, natomiast to
jest programowanie w C++.

I tego faktu nie zmienia to ?e gdzie? w nag?ówku jest [...] class traits
[...].

"class" mog?o by si? nazywa? "type" i by? mo?e t? prost? sztuczk? ludzie
przestali by bredzi? ?e u?ywanie klas w C++ to pisanie obiektowe.

>> Mam buga który ukrywa? si? w void* przed ponad 10 lat. Przed oczami
>> do?wiadczonych programistów. Jedyny powód ?e uda?o si? go znale?? to
>> *przypadek*.

> A ja zapewne mam niejeden taki b??d w szablonach.


Nie, znalezienie b?adu w szablonach który ujawnia si? w runtime jest
naprawd? wy?sz? szko?a jazdy. Zrobienie b?edu w void* który ujawnia si?
w runtime to trywializm.

Szablony powoduj? ?e b?edy w runtime staj? si? sporadyczne. Przenoszone
s? na kompilacje.

Wiadomo, nie ka?dy potrafi czyta? komunikaty b??dów. Ale naprawd? od
kilkudziesi?ciu lat jest coraz lepiej z jako?ci? b?edów. Proponuje
zobaczy? co wy?wietla clang w przypadku b?edów kompilacji. Jest bardzo,
bardzo dobrze.

>> traits< int >::max
>> to jaka? okropna sk?adnia? Nie czerpiesz aby przypadkiem wiedzy o
>> szablonach z jaki? grup anonimowych pisaczy w c?

> Racja, takie proste przypadki s? bardzo przejrzyste.


I w tym momencie zamieniasz gcc na g++. Znalaz?e? jeden powód aby u?y?
C++ to go u?ywasz, jest za darmo.

> Mia?em na my?li sytuacje
> gdy jeden szablon jest parametryzowany kilkoma innymi szablonami


Poni?ej promila z promila zastosowa? szablonów wymaga takich wygibasów.

Dam przyk?ad: boost::spirit.

To jest bardzo skomplikowana bibliteka na bardzo pokr?coanych szblonach.

Ale dla user ko?cowego jest wr?cz bajecznie prosta.

Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
programistów C. Straszy si? ni? i jak wida? skutecznie.

> takich sytuacjach mocno t?skni? za minimalistycznym C++ albo za Jav?


Prawie ca?y boost to ukrycie skomplikowanych szablonów za bajecznie
prostymi interfejsami.

Pewnie, mo?esz zobaczy? boost::mpl czy fusion i pokaza? mi przyk?ady
gdzie jest cie?ko.

Ale oni naprawd? si? napracowali aby to ca?e mpl by?o *bajecznie* proste
po stronie usera mimo komplikacji w ?rodku.

Najwyczajniej, powtarzasz mity. C++ moze byc skomplikowany. Ale boost
pokaza? ?e ta komplikacja nie musi przecieka? do usera.

> pozbawionego b??dów. Tak si? mówi ?e szablony stanowi? antidotum na b??dy, bo
> porównuje si? je zwykle do najbardziej b??dogennych konstrukcji j?zyka, jak
> wla?nie do makr, albo do rzutowania na void*.


Stanowi? warstw? chroni?c? przed pewn? klas? problemów. Akurat tych
upierdliwych, bo w runtime.

Stanowi? jeszcze wiell innych rzeczy, ale void* nie jest alternatyw? dla
szablnów. Za void* nie ma ?adnych sensownych argumentów.

>> Ca?e szcz?scie wielokrotne dziedzidzenie szablonów wyst?puje g?ównie w
>> bajkach i ksi?zeczkach dla niegrzecznych programistów c.

> Wielokrotnie w sensie ?e jedna klasa (szablon) dziedziczy z bezpo?rednio z
> kilku to owszem rzadko spotykana konstrukcja i niekoniecznie zalecana.


My?le ?e 90% konstrukcji z boosta jest trywialna.

> Ale po?rednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Y z Z, a Z
> mo?e z kolejnych - to sytuacja cz?sta.


Prawie nie spotykana w kodzie usera. U?ywa si? jej w booscie czy stl,
ale mechanizmy widoczne jako API s? strywialziowane.

> Gdy ka?de jeszcze ma jakie? parametry i
> typy - to naprawd? zazwyczaj dostawa?em oczopl?su gdy analizowa?em swój w?asny
> kod po krótkim czasie. My?l? ?e ka?dy programista uzna?by za ?atwiejszy w
> analizie kod np. Javy.


Wi?c masz kiepskie do?wiadczenia wynikaj?ce z kiespkiego doboru przyk?adów.

>> Robie to codziennie od kilkudziesi?ciu lat i cie?ko mi si? zgodzi?.

> Mo?e zwykle u?ywasz szablonów po bo?emu, a nie do optymalizacji kodu?


U?ywam C++. W tym szablonów. Szablony s? od dziesi?tek lat coraz lepiej
wspierane przez kompialtory (komunikaty b?edów) i debuggery (pokazywanie
zawarto?ci). Nijak nie wiem czemu foo<int> mia?o by by? bardzie
skomplikowane do debugu. Jedyna przeszkoda to czasem d?u?sze nazwy
typów. Tylko ?e tam si? zagl?da raz na rok.

Znowu deminizujesz. Debug kodu z szblonami wyglada tsak samo jak w C. No
mo?e przesadzam: w C u?ywaj?c void* jeste? w d... od razu.

> nie mam z nimi problemów. Ale gdy np. ca?y algorytm genetyczny parametryzuj?
> kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
> edytor nie wie jakie metody b?d? mia? parametry.


Masz z?y edytor.

> To wszystko prawda, cho? z review to zale?y gdzie :-) Nie chcia?em
> absolutnie powiedzie?, ?e macie ola? szablony i wróci? do void*.
> Chcia?em powiedzie?, ?e je?li sobie radzono bez szablonów i system
> operacyjny z GUI dzia?a? na 16MB RAM i pentium I 160MHz - to nie
> ulegajmy z?udzeniu, ?e te szablony a? tak nies?ychanie du?o wnosz?.


Znowu to samo.

Mam m?otek, ale lepiej wbija? gwo?dzie lutownic?.

Mam szablony, ale przecie? void* to tylko kilka wad z którymi da sie ?y?.

Ja rozumiem jeszcze jak by za u?ywanie szblonów trzeba by?o p?aci?.

Ale s? za friko.

To PO CO ich nie uzywa??

> nie traktowa? szablonów jako czego? dzi?ki czemu technologia wytwarzania
> oprogramowania przyspieszy?a o kiladziesi?t procent, bo bez szablonów by?a
> ju? ca?kiem szybkim samochodem, który trudo przyspiesza? w niesko?czono??.


Szablony rozwiazuj? dobrze kre?lon? klas? problemów z jako?ci? kodu.

W C nie ma nic co mog?o by to zastapi? poza modlitw?.

>> Jeste? nastepnym developerem w tej dyskusji z Atari 65XE jako ci?g??
>> integracj??

> Nie, po prostu czasami mam w kodzie nasrana pe?no szablonów, jeden szablon
> jest parametryzowany innymi, te inne te? s? parametryzowane jeszcze innymi, a
> niektóre s? w kilku wersjach. Je?li zmieniam warunki kompilacji warunkowej to
> musz? czeka? 30 sekund na pe?n? rekompilacj?


Przyznam ?e "pe?na rekompilacja" to zjawisko niepotykane przy prawid?owo
opisanym projekcie.

Jeste? pewien ?e masz wszystko dobrze ?e masz potrzeb? pe?nej rekompilacji?

> Ja przed chwil? doda?em do kompilacji -DOPCJA_X i czeka?em na pe?n?
> kompilacj? z 30 sekund na dwóch rdzeniach. Jak jeszcze jest pomi?dzy
> kompilacj? -fprofile-generate i -fprofile-use to czekam 2 minuty aby
> zrobi? 30 sekundowy test.


Czyli to nie jest noramlna praca w programowanie. To wyj?tek, kiedy
robisz redefinicj?.

Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny ?e
nie powinien by? uwa?any za reprezentacyjny.

>>> Kolejna wada, trzeba udost?pni? kod ?ród?owy gdy si?
>>> udost?pnia bibliotek? napisan? w postaci szablonów.

>> Brednia.

> To ch?tnie si? dowiem dlaczego, my?la?em ?e szablony to nag?ówki niezb?dne
> do wygenerowania konkretnej wersji kodu, jak to udost?pni? w wersji
> binarnej bez ?róde??


usenet to za ma?o aby to opisa? bo zale?y od sytuacji.

Kod nie musi akceptowa? *dowonych* szablonów na przyk?ad. I biblioteka
udost?pnia impelemntcje dla tych kilku przypadków.

Mniej wiecej to to samo co biblioteka w C. Masz funckje przyjmuj?c? inty
i floaty. To samo w C++, mo?esz poda? szablon z intem i floatem.

To jeden z przyk?adów ?e *NIE* musisz *zawsze* udost?pnia? kodu
szablonowego.

>>> Nast?pna wada, kompilatory
>>> czasami wskazuj? b??d daleko od jego wyst?pienia.

>> Brednia w 99% wypadków.

> U mnie w oko?o 30% przypadków jest to prawda.


U?yj clanga.

>>> Podsumowuj?c, kiedy? szablonów u?ywano rzadko albo w ogóle nie u?ywano

>> Podobnie jak z papierem toaletowym.

> Tylko ?e papier toaletowy nie ma nic wspólnego z programowaniem, a (nie)u?ywanie
> szablonów ma sporo.


Z faktu ?e kto? kiedy? robi? kup? bez papieru nie wynika ?e papier jest
zb?dny obecnie.

Najzwyczajniej kiedy? go nie by?o.

Podobnie jak kiedy? nie by?o C++.

>> Na patrz, a ja mia?em Amig? z 2MB pami?ci chip i na tej konfiguracji
>> pogania?em SaSC w trybie C++ pisz?c obiektowe programy GUIowe. Mo?e to
>> czary?

> Mo?e czary, a mo?e to (w jakim? stopniu) dzi?ki void* ?


Nie, C++ z szablonami. SaSC mia? translator z C++ na generowany C.

Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
wyborem j?zyka C czy C++. Ma zwi?zek jedynie z kiepskimi programistami,
przyrostem danych i rozbudow? OSów.

>> A po chwili si? budzisz i okazuje si? ?e ten sam program kompilowalny w
>> C i C++ generuje dok?adnie taki sam kod asemblerowy.

> Przecie? to jest oczywiste


Nie jest. Dla znacznej cz?sci wyznawców C, bazuj?cych na opiniach z
facebooka ?wiat wygl?da tak ?e "C++ du?o zajmuje". Ta taka kolejna
teoria spiskowa obok antyszczepionkowców i niejedz?cych.

>, ?e ka?da konkretyzacja szablonu oznacza nie
> tylko ró?ny kod, ale nowy dodatkowy kod.


Nie. Tak. Zale?y.
heby (30.01.2020, 01:01)
On 29/01/2020 23:05, Maciek Godek wrote:
>> Si? stan mo?e pomiesza? mi?dzy korutynami.

> Poka? przyk?ad.


static int a = 1;
a = 2;

Ku naszemu zaskoczeniu a b?dzie równe 2.

>> Dwie identyczne korutyny przeplataj?ce si? w jednym flow b?da si? zak?óca?.

> Podaj przyk?ad.


Ten powy?je powinien wystarczy?.

>> Dwie identyczne korutyny nie przeplatajace si?, ale b?d?ce w ró?nych
>> w?tkach b?da si? zak?uca?.

> Semantyka korutyn w ró?nych w?tkach nie jest nawet dobrze okre?lona.


Jest okre?lona dok??dnie tak samo jak zwyk?ych funkcji. Pod warunkeim ?e
to korutyny a nie jump oriented programming.

> Nie wiadomo, jak si? powinno zachowywa?.


Dok?adnie wiadomo. Tak samo jak funkcje/procedury.

>>> Korutyna nie jest "pure function".

>> Nie ma przeszkód aby by?a.

> Jest zasadnicza. Korutyna ma swój stan wewn?trzny, który z definicji jest mutowalny.


Mo?e sobie mie?. Istotne jest ?e stan ten nie przecieka nigdzie poza ni?.

Tak samo pure funkcja mo?e mie? sobie w ?rodku mutowalne "int a".

I sobie mutuje.

I nie przecieka poza t? funkcj?.

W?asnie odkry?e? ?e funkcje pure mog? mie? mutowalne, prywatne zmienne w
?rodku i dalej by? pure.

> A czysta funkcja robi tylko jedno: odwzorowuje wej?cie w wyj?cie. Zawsze dla tego samego wej?cia ma da? to samo wyj?cie. Nie ma stanu wewn?trznego.


Ale? ma. Na ten przyk?ad :

foo() {
int a = 1;
a = 2
return a;
}

Je?li zatrzymasz ja w po?owie to ma stan wewn?trzny. Ale on nie jest
widoczny poza t? funkcj?, nie jest dost?pny równie? w korutynie poza ni?.

Bycie pure to nie jest nie posiadanie kompletnie ?adnego stanu. To jest
nie ingerowanie w stan poza t? funkcj?. W C/C++ do tego u?ywa si?
zazwyczaj stosu.

> I to jest do?? kolosalna przeszkoda.
>>> Czyste funkcje w ogóle nie maj? czego? takiego, jak "przebieg sterowania".


To zabawne, bo moje korutyny te? nie maj?. Robi? yield() i z ich puktu
widzenia nic si? nie sta?o, jad? dalej. yield() to takie puste wywo?anie
która nic ciekawego nie robi z ich puktu widzenia.

>> No i wychodzi na to ?e nie czaisz bazy. Moja *funkcja* jest pure. Twoja
>> nie. Obie s? korutynami.

> Korutyna to nie jest funkcja. Tutaj masz definicj?, prosz?:
>


Korutyna zachowuje si? jak funkcja z wieloma punktami wyj?cia i
hermetycznym stanem pomi?dzy.

Natomaist je?li chcesz sprowadzi? dyskusj? do poziomu upierdlowego
profesora to trudno. Sedno tkwi nawet nie w tym czy korutyna to funkcja
czy nie. Sedno jest w tym ?e masz gównian? impelemntacj? na któr? nawet
w g?upiej wikipedii wylali wiado pomyj bo tylko tyle mo?na o niej
powiedzie?.

>> Och, pu?c t? sam? korutyn? 2x w jednym flow, na przemian.

> Nie wiem o czym mówisz. Napisz kawa?ek kodu, to b?d? wiedzia?.
> Problem jest taki, ?e okre?lenie "ta sama korutyna puszczona 2x w jednym flow" nie jest jednoznaczna, bo nie wiem, co masz na my?li mówi?c "ta sama korutyna". Kawa?ek kodu wszystko wyja?ni.


Napisz w swoim kodzie flow w którym ta sama korutyna pracuje na przemian
na dwóch róznych danych wej?ciowych.

I odpal j? naprzemiennie.

I wiesz co, postanowi?em ?e kodu nie napisz?. To poni?ej godno?ci ?eby
udowania? komu? rzeczy oczywiste.
heby (30.01.2020, 01:04)
On 29/01/2020 23:22, Maciek Godek wrote:
> Ku mojemu zdziwieniu, oba zachowa?y si? dok?adnie tak samo.


Wi?c aby zach?ci? Ci? do dalszych eksperymentów pozwój ?e ka?da z tych
grup, czyli przysta i nieparzysta, dostanie inny zestaw danych
wej?ciowych i niech na nich popracuje.

Powiedzmy niech jedna liczy fibonacciego od 1 a druga, nietypowo, od 1000.

I naprzemiennie, a co. W ko?cu to korutyny.
Maciek Godek (30.01.2020, 01:54)
W dniu czwartek, 30 stycznia 2020 00:01:59 UTC+1 u?ytkownik heby napisa?:

> >>> Korutyna nie jest "pure function".
> >> Nie ma przeszkód aby by?a.

> > Jest zasadnicza. Korutyna ma swój stan wewn?trzny, któryz definicji jest mutowalny.

> Mo?e sobie mie?. Istotne jest ?e stan ten nie przecieka nigdzie poza ni?.


W korutynach w?a?nie przecieka.

Je?eli mam:

int c() {
while(1) {
yield(1);
yield(2);
}
}

to jaka b?dzie warto?? wyra?enia c()?

> Tak samo pure funkcja mo?e mie? sobie w ?rodku mutowalne "int a".
> I sobie mutuje.
> I nie przecieka poza t? funkcj?.
> W?asnie odkry?e? ?e funkcje pure mog? mie? mutowalne, prywatne zmienne w
> ?rodku i dalej by? pure.


Mylisz "funkcje pure" z hermetyzacj?.

> Ale? ma. Na ten przyk?ad :
> foo() {
> int a = 1;
> a = 2
> return a;
> }
> Je?li zatrzymasz ja w po?owie to ma stan wewn?trzny. Ale on nie jest
> widoczny poza t? funkcj?, nie jest dost?pny równie? w korutynie poza ni?.


Funkcji nie da "si? zatrzyma?", bo ona "si? nie wykonuje".
Ona odwzorowuje wej?cie w wyj?cie,

> Bycie pure to nie jest nie posiadanie kompletnie ?adnego stanu. To jest
> nie ingerowanie w stan poza t? funkcj?. W C/C++ do tego u?ywa si?
> zazwyczaj stosu.


Mo?e lepiej id? ju? spa?.

> > I to jest do?? kolosalna przeszkoda.
> >>> Czyste funkcje w ogóle nie maj? czego? takiego, jak "przebieg sterowania".

> To zabawne, bo moje korutyny te? nie maj?. Robi? yield() iz ich puktu
> widzenia nic si? nie sta?o, jad? dalej.


Je?eli "jad?", to maj? przebieg sterowania.
Przebieg sterowania to jest w?a?nie "jechanie".
I ono jest czym? istotnym dla korutyny.

Tutaj masz, prosz?, poczytaj sobie:


> Korutyna zachowuje si? jak funkcja z wieloma punktami wyj?cia i
> hermetycznym stanem pomi?dzy.


Funkcja nie ma czego? takiego jak "punkt wyj?cia". Funkcja odwzorowuje dziedzin? w przeciwdziedzin?.

> I wiesz co, postanowi?em ?e kodu nie napisz?. To poni?ej godno?ci ?eby
> udowania? komu? rzeczy oczywiste.


No ja wiem. Nie zaskakuje mnie to.
Pierdoli? potrafi ka?dy. Ilustrowa? swoje tezy przyk?adami ju? niekoniecznie.

Kodu nie napiszesz, ale nie dlatego, ?e to "poni?ej godno?ci", tylko dlatego, ?e to, co do tej pory mówi?e? o korutynach, nie mia?o sensu.

Okre?lenie, ?eby "odpala? naprzemiennie t? sam? korutyn?" jest ca?kowit? bzdur?.

Naprzemiennie mo?esz odpala? dwie ró?ne rzeczy, a nie "dwie te same rzeczy", bo "dwie te same rzeczy" to jest jedna i ta sama rzecz.
M.M. (30.01.2020, 05:40)
On Wednesday, January 29, 2020 at 11:41:53 PM UTC+1, heby wrote:
> On 29/01/2020 22:48, M.M. wrote:
> >> A jak im pewnego dnia podmienisz gcc na g++ to co si? stanie? A jak
> >> pewnego dnia dorzucisz im do kodu class scoped_interrupt_disable to co
> >> si? stanie? Wybuchnie im? Odmówi? pracy bo niekoszerne?Do spowiedzi pójd??

> > Nie wiem co si? stanie. Prosi?e? o przyk?ad, wi?c poda?em.

> Ten przyk?ad nie t?umaczy problemów w C++ tylko w bia?ku.


W jakim bia?ku?

> > Wszystko ma
> > swoje wady i zalety, nawet C++ ma wady wzgl?dem C

> W sensie ?e jest bardziej restrykcyjny? S?ysza?me kiedy? ?e to wada. Do
> dzisiaj nie wiem dlaczego.


Poda?em przyk?ad, ale Ty na to co? o jakim? bia?ku..

> >, a jako nadzbiór nie
> > powinien mie? wad. Koszt przeszkolenia jest nie do przeskoczenia.

> Napisa?em Ci ?e nic nie musisz szkoli? poza "ch?opaki, od dzisiaj w
> ka?dym przerwaniu na arma na pocz?tku ma sta? scoped_interrupt_disable
> sid(); i h...". A jak który? podskoczy to w ?eb. Koniec szkolenia. Po
> roku nie dadz? sobie tego si?a odebra?.


To faktycznie nie rozmawiamy o C++, tylko o czym? w rodzaju co napisa?e?
"wystarczy jeden ficzer z C++". Co dobrego z takiej rozmowy wyniknie?

> > nast?pi? rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
> > wierz? ?e ten rozwój nie wpada? i nie wpada w ?lepe uliczki

> Kiedy? ludzie uwa?ali BCPL za spe?enienie marze?. Samsi? kompiluje,
> mo?na zrobi? bootstrap na dziwnym systemie, architektura wr?cz zdj?ta z
> tablicy uczelni, *uproszczona* sk?adnia.


Niestety nie mia?em przyjemno?ci z BCPL.

> I wiesz co, trafi?em kiedy? przez zupe?ny przypadek na kolesia który nie
> do?? ?e pisa? jeszcze ko?o 2000 roku w tym cudzie to jeszcze przez
> nastepne 10 lat mia? do niego straszny sentyment.
> Widzisz, to co piszesz to bia?ko.


Nie wiem jak u?ywasz okre?lenia bia?ko.

> Mam takie a takie do?wiadczenia, widzia?em to i tamto, wnioskuje z tego
> to i owo.


Nie wiem w czym problem.

> A na koniec okazuje si? ?e programy w C++ nie do?? ?e s? czytelniejsze
> od tych w C, to cz?sto s? szybsze, ?atwiejsze w analizie irefaktoringu.


Sekund?. Programy w C++ mog? by? czytelniejsze od tych w C ito mog? by?
znacznie czytelniejsze, tak samo jak mog? by? ?atwiejsze w analizie i
refaktoringu. Ale je?li s? mocno zoptymalizowane pod k?tem szybko?ci
dzia?ania, to na pewno nie s? ani czytelne, ani ?atwe w analizie, a ju? w
ogóle s? fatalne w rozbudowie i refaktoringu.

> Tylko ?e bia?ko. Bia?ko wie lepiej, szczególnie jak si? na czym? nie zna.


Pierdolisz.

> No wi?c dowiedzia?em si? ?e C to gówno. BCPL by? lepszy.
> Bia?ko ...
> To teraz z tej analogi zrób casta na konkret.
> To jaki j?zyk jest tym najszybszy na ?wiecie?
> Rust chyba obecnie jest na karuzeli terndów?
> I co to ma w ogóle do dyskusji o tym ?e zmiana z gcc na g++ dodaje od
> razu za darmo mas? mo?liwosci które w C wymagaj? pisania kwadratowych kó??


Ju? pisa?em jaka jest analogia i nie przeczy?em mo?liwo?ciom C++. Nie mo?na
jednej technologii ulepsza? bez ko?ca, a ju? na pewno nie mo?na sta?ym
nak?adem kosztów/pracy ulepsza? o sta?? warto??, efekty staj? si? coraz
mniejsze, a j?zyki programowania s? ulepszane od dawna. Dopóki nie
b?dzie jakiego? prze?omu w technologiach wytwarzania oprogramowania, to
nie nale?y si? ju? spodziewa?, ?e taki czy inny zestaw nowych ficzerów
znacz?co udoskonali technologi?. W moim przypadku dobre biblioteki najbardziej
przyspieszaj? tworzenie oprogramowania. Bajeranckie cechy j?zyka.... to
nawet spowalniaj?, bo programista my?li czego lepiej u?y?. W Javie si?
szybciej programowa?o, ale efekt w C++ jest lepszy.

> >> Czyli mówisz o czym? innym ni? ja. Spieraj si? wi?c z kim? innym.

> > Spokojnie, ja jeszcze nie jestem pewny o co si? spieramy :)

> Podobno o wy?szo?? C++ nad C i odwrotnie.


Bez kontekstu nie wiem jak si? o to spiera?. Templates mo?na porównywa? do
b??dogennych makrodefinicji i void*. Templaty mo?na robi? po to, aby pomóc
kompilatorowi w wykrywaniu b??dów na etapie kompilacji. Ale te? templates
mo?na porównywa? do ?adnego kodu z metodami wirtualnymii templaty mo?na
pisa? w celu agresywnej optymalizacji kodu pod k?tem czasu wykonania. Niby
to samo, a za ka?dym razem zupe?nie inna sytuacja. A co dobrego ztej rozmowy,
to zupe?nie nie wiem... Kto? kto nie wie ?e templaty mog? pos?u?y? do
optymalizacji kodu, ale taki kod tylko w banalnych przypadkach jest
czytelny - to si? dowie. Ja na razie nic si? nie nauczy?em.

> Tylko ?e ja si? o to nie spieram. Ja tylko protestuje przeciwko
> bredzeniu o tym ?e zmiana z gcc na g++ jest niemozliwa, bezsensowna
> i
> korutyny nie musz? mie? stosu a programi?ci musz? si? szkoli? z u?ywania
> prymitywnego RAII.


Nie wiem, moje korutyny maj? stos i s? odporne na w?tki- chyba ?e to co
ja mam jeszcze nie nazywa si? korutyn?.

> > Napisa?em o tym z jakim sposobami u?ywania okre?lenia 'programowanie w C++'

> Wie? programowanie w C++ to programowanie z dowolnym ficzerem dost?pnym
> w g++ a niedostepnym w gcc. Na przyk?d z u?yciem RAII, które to jest
> swoj? drog? krytycznie potrzebne w embedded i jednoczesnie skandalicznie
> olewane przez embedded. Bo kwadratowe ko?a ?atwiej si? produkuje ni?
> kupuje okr?g?e.


A wy?ej napisa?e? ?e spieramy si? o wy?szo?? j?zyka C nad C++ lub odwrotnie.
J?zyk to nie jeden ficzer, a w praktyce nawet spór o ca?y j?zyk jest ja?owy, bo
co komu nawet z najlepszego j?zyka jak nie ma do niego narz?dzi?

> Bo obiektowo?c wymaga *OBIEKTÓW* a nie klas.


Nie wiem, a co z tego rozgraniczenia dobrego dla Ciebie i dla mnie?

> >> Sk?adnia ta bowiem przydaje si? w szablonach, jest wr?cz
> >> podstaw? pisania z u?yciem generycznych typów w C++. Nie maj?cych nic
> >> wspólnego z programowaniem obiektowym.

> > Chyba nadal nie rozumiem. A jakie wnioski z tego p?yn??

> ?e traits< int >::max to nie jest programowanie obiektowe, natomiastto
> jest programowanie w C++.


Te? nie wiem co z tego dobrego dla mnie i dla Ciebie.

> I tego faktu nie zmienia to ?e gdzie? w nag?ówku jest[...] class traits
> [...].
> "class" mog?o by si? nazywa? "type" i by? mo?e t? prost? sztuczk? ludzie
> przestali by bredzi? ?e u?ywanie klas w C++ to pisanie obiektowe.
> Nie, znalezienie b?adu w szablonach który ujawnia si? w runtime jest
> naprawd? wy?sz? szko?a jazdy. Zrobienie b?edu w void* który ujawnia si?
> w runtime to trywializm.


Programowa?em i z u?yciem szablonów i z void*. Tyle ?e szablonów zwykle u?ywam
do poprawy wydajno?ci. Swoj? osobist? statystyk? mam zdecydowanie na korzy??
void* - w sensie ?e mniej b??dów pope?nia?em.Ale powtarzam, ja czasami u?ywam
szablonów zupe?nie inaczej ni? 90% programistów.

> Szablony powoduj? ?e b?edy w runtime staj? si? sporadyczne. Przenoszone
> s? na kompilacje.
> Wiadomo, nie ka?dy potrafi czyta? komunikaty b??dów. Ale naprawd? od
> kilkudziesi?ciu lat jest coraz lepiej z jako?ci? b?edów. Proponuje
> zobaczy? co wy?wietla clang w przypadku b?edów kompilacji. Jest bardzo,
> bardzo dobrze.
> I w tym momencie zamieniasz gcc na g++. Znalaz?e? jeden powód aby u?y?
> C++ to go u?ywasz, jest za darmo.


Nie rozumiem w jakim momencie, gcc szablonów nie kompiluje, a rozmawiali?my w
tym akapicie o szablonach.

> > Mia?em na my?li sytuacje
> > gdy jeden szablon jest parametryzowany kilkoma innymi szablonami

> Poni?ej promila z promila zastosowa? szablonów wymaga takich wygibasów.


Je?li podajemy jawnie wydajno?? jako zalet? templates, to zwykle u?ywa
si? tego typu wygibasów.

> Dam przyk?ad: boost::spirit.
> To jest bardzo skomplikowana bibliteka na bardzo pokr?coanych szblonach.
> Ale dla user ko?cowego jest wr?cz bajecznie prosta.


Tak, o to w?a?nie chodzi. Moje mikro-biblioteki te? s? w jakim? stopniu proste,
ale s? wierzcho?kiem góry lodowej. Niewidoczna cz??? pod wod? stanowi
pierdylion eksperymentów z szablonami, makrami, opcjami kompilatora, z
oczekiwaniem na koniec pracy kompilatora, z uganianiem si? za syntax error w
innym pliku ni? pokaza? kompilator....

> Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
> programistów C. Straszy si? ni? i jak wida? skutecznie.


Nie wiem do czego nawi?zujesz.

> > takich sytuacjach mocno t?skni? za minimalistycznym C++ albo za Jav?

> Prawie ca?y boost to ukrycie skomplikowanych szablonów za bajecznie
> prostymi interfejsami.


Co nie znaczy ?e proces jego powstawiania (czytaj: technologia tworzenia
wysokiej jako?ci oprogramowania z u?yciem szablonów) by? tak samo
majestatyczny jak efekt ko?cowy dla ostatecznego u?ytkownika. Nawet to
s? ró?ne spojrzenia na to samo magiczne s?owo 'template'. Raz tworzymy
oprogramowanie korzystaj?c szablonów, drugi raz przygotowujemy szablony do
reu?ycia.

> Pewnie, mo?esz zobaczy? boost::mpl czy fusion i pokaza? miprzyk?ady
> gdzie jest cie?ko.
> Ale oni naprawd? si? napracowali aby to ca?e mpl by?o*bajecznie* proste
> po stronie usera mimo komplikacji w ?rodku.


I widzisz, mo?e zgadzamy si? co do wszystkiego. Dotarli?my w ko?cu do mojego
statystycznego punktu widzenia :D Te? si? kilka razy w ?yciuci??ko
napracowa?em, ?eby reu?ycie by?o bajecznie proste i jeszcze dawa?o wydajny
program. Z punktu widzenia osoby która si? napracowa?a,praca z szablonami
nie jest taka bajeczna, jak z punktu widzenia osoby u?ywaj?ce ich..

> Najwyczajniej, powtarzasz mity.


Nie powtarzam, nie rozumiemy si? po prostu. Niby i Ty, i ja piszemy o
szablonach. Ale na szablony mo?na patrzy? z kilku perspektyw, do mojej
chyba przed chwil? dotarli?my.

> C++ moze byc skomplikowany.


Zale?y jak porównywa?, np. wzgl?dem Javy jest koszmarnie skomplikowany.

> Ale boost pokaza? ?e ta komplikacja nie musi przecieka? dousera.


A no w?a?nie, to inne porównanie i zgadzam si? z Tob? ?e nie musi. A jakie
mi?e jest programowanie z u?yciem QT, naprawd? bardzo podobnie do Javy.

> > pozbawionego b??dów. Tak si? mówi ?e szablony stanowi? antidotum na b??dy, bo
> > porównuje si? je zwykle do najbardziej b??dogennych konstrukcji j?zyka, jak
> > wla?nie do makr, albo do rzutowania na void*.

> Stanowi? warstw? chroni?c? przed pewn? klas? problemów. Akurat tych
> upierdliwych, bo w runtime.


Mo?e tak naprawd? spieramy si? o to, ?e Ty uwa?asz i? szablony bardzo
usprawniaj? technologi? oprogramowania, a ja ?e usprawniaj? j? w mniejszym
stopniu? Nie zgadzam si? te?, ?e trudno pope?ni? b??d w runtime programuj?c z
wykorzystaniem szablonów.

> Stanowi? jeszcze wiell innych rzeczy, ale void* nie jest alternatyw? dla
> szablnów. Za void* nie ma ?adnych sensownych argumentów.


Nie wiem, trudno mi si? wypowiedzie?, bo od wielu lat void* zdarza mi
si? u?y? mo?e raz na rok. Mo?e z 15 lat temu u?ywa?em regularnie, te?
dawa?em rad?. I nie chc? powiedzie? po prostu ?e kiedy? bez papieru
dawali rad?, ale ?e jak dawali rad?, to ten papier toaletowynie jest a?
takim panaceum, tylko jakim? kolejnym ma?ym ulepszeniem.

> >> Ca?e szcz?scie wielokrotne dziedzidzenie szablonów wyst?puje g?ównie w
> >> bajkach i ksi?zeczkach dla niegrzecznych programistów c.

> > Wielokrotnie w sensie ?e jedna klasa (szablon) dziedziczy z bezpo?rednio z
> > kilku to owszem rzadko spotykana konstrukcja i niekoniecznie zalecana.

> My?le ?e 90% konstrukcji z boosta jest trywialna.


Pisa?e? te? ?e si? napracowali przy boo?cie, czy mia?e? na my?li ?e
napracowali si? przy pozosta?ych 10ciu procentach?

> > Ale po?rednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Yz Z, a Z
> > mo?e z kolejnych - to sytuacja cz?sta.

> Prawie nie spotykana w kodzie usera. U?ywa si? jej w booscie czy stl,
> ale mechanizmy widoczne jako API s? strywialziowane.


Ok, to ju? opisa?em wy?ej, nie rozumieli?my si?, bo pisa?em z punktu
widzenia kogo? kto takich konstrukcji u?ywa.

> > Gdy ka?de jeszcze ma jakie? parametry i
> > typy - to naprawd? zazwyczaj dostawa?em oczopl?su gdy analizowa?em swój w?asny
> > kod po krótkim czasie. My?l? ?e ka?dy programista uzna?by za ?atwiejszy w
> > analizie kod np. Javy.

> Wi?c masz kiepskie do?wiadczenia wynikaj?ce z kiespkiego doboru przyk?adów.


Czysta z?o?liwo?? czy kryje sie za tym co? konstruktywnego? Co to s?
kiepskie do?wiadczenia?

> U?ywam C++. W tym szablonów. Szablony s? od dziesi?tek lat coraz lepiej
> wspierane przez kompialtory (komunikaty b?edów) i debuggery (pokazywanie
> zawarto?ci). Nijak nie wiem czemu foo<int> mia?o by by? bardzie
> skomplikowane do debugu. Jedyna przeszkoda to czasem d?u?sze nazwy
> typów. Tylko ?e tam si? zagl?da raz na rok.


Na razie rozumiem, ?e dobre do?wiadczenia s? wtedy gdy si? tam zagl?da
raz na rok, a gdy kto? akurat nad tym pracuje, to nabiera kiepskich
do?wiadcze?.

> Znowu deminizujesz. Debug kodu z szblonami wyglada tsak samo jak w C. No
> mo?e przesadzam: w C u?ywaj?c void* jeste? w d... od razu.


Mia?em na my?l nie nie tylko ?ledzenie linia po linii wykonania kodu w
programie do debugowania, tyko generalnie usuwanie b??dów. Gdy ogl?dam
kod z 'wirtualnym typem' który dopiero w trakcie kompilacji b?dzie na
kilka sposobów konkretyzowany, to wcale nie jestem bardziej pewny jego
bezb??dno?ci, ni? gdy patrz? na kod zwyk?ej procedury. W zasadzie to
chyba mam odwrotnie, co do zwyk?ych procedur szybciej nabieram przekonania
?e s? poprawne. A swoj? drog? w programach do debugowania te? by?o
sporo b??dów i gorzej sobie radzi?y na szablonach.

> > nie mam z nimi problemów. Ale gdy np. ca?y algorytm genetyczny parametryzuj?
> > kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
> > edytor nie wie jakie metody b?d? mia? parametry.

> Masz z?y edytor.


Mo?e, a jaki Ty masz?

> Znowu to samo.
> Mam m?otek, ale lepiej wbija? gwo?dzie lutownic?.
> Mam szablony, ale przecie? void* to tylko kilka wad z którymi da sie ?y?.


Nie, nie to chcia?em powiedzie?. Mam szablony, u?ywam szablonów, ale jestem
?wiadomy ?e z void* te? dzia?a?o, wi?c te szablony to nie ?adne panaceum, ale
jakie? kolejne ulepszenie.

> Ja rozumiem jeszcze jak by za u?ywanie szblonów trzeba by?o p?aci?.


Bo trzeba, nic nie jest za darmo. T? op?at? by?a/jest:
- konieczno?? szkolenia personelu,
- konieczno?? nabrania do?wiadczenia przez personel,
- wiele lat implementacji w kompilatorach,
- problemy bo kompilatory ró?nie to wspiera?y,
- targi o to jak powinny wygl?da? w standardzie,
- próby ?amania standardu przez niektóre firmy,
- o wyd?u?onym czasie kompilacji, zwi?kszonym rozmiarze kodu i s?abym
pokazywaniu w?a?ciwej linii z syntax error - ju? pisa?em.
- o tym jak to wygl?da z punktu widzenia kogo? kto przygotowuje
wygodny szablon - te? ju? pisa?em.

> Ale s? za friko.
> To PO CO ich nie uzywa??


To nie do mnie pytanie, ja mówi? ?eby ich u?ywa?, tylko studz? emocje, bo
nie s?, nie by?y ca?kiem za friko, a w przypadku p?atnych bibliotek nigdy
nie b?d? za friko i nie s? a? takim wybawieniem skoro na void* te? dzia?a?o.

> > nie traktowa? szablonów jako czego? dzi?ki czemu technologia wytwarzania
> > oprogramowania przyspieszy?a o kiladziesi?t procent, bo bez szablonów by?a
> > ju? ca?kiem szybkim samochodem, który trudo przyspiesza? w niesko?czono??.

> Szablony rozwiazuj? dobrze kre?lon? klas? problemów z jako?ci? kodu.


Zgoda, ale wprowadzaj? te? inne problemy. Cho? podsumowanie dzi? wypada na
korzy?? szablonów, to po odj?ciu wad, to podsumowanie nie jest rewelacyjne.

> W C nie ma nic co mog?o by to zastapi? poza modlitw?.


Zewn?trzne programy narz?dziowe pe?ny rol? generyków, sam jeden wi?kszy
generator napisa?em do generowania sieci neuronowych. No i by? void* i
makra ;-)

> Przyznam ?e "pe?na rekompilacja" to zjawisko niepotykane przy prawid?owo
> opisanym projekcie.
> Jeste? pewien ?e masz wszystko dobrze ?e masz potrzeb? pe?nej rekompilacji?


Bym musia? napisa? (i potem pilnowa?) specjalne pliki make, które uwzgl?dniaj?
kompilacj? warunkow?. Nie wiem co gorsze, modli? si? czy nie mam b??du w
pliku make, czy czeka? te 30 sekund.

> Czyli to nie jest noramlna praca w programowanie. To wyj?tek, kiedy
> robisz redefinicj?.


Dla mnie to jest norma zawsze wtedy, gdy pracuj? pod wod? góry lodowej.
Poza tym owszem, to jest wyj?tek.

> Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny ?e
> nie powinien by? uwa?any za reprezentacyjny.


Nie wiem czy kiepski przypadek, sam przyzna?e? ?e ludzie od boosta
si? napracowali ci??ko...

> usenet to za ma?o aby to opisa? bo zale?y od sytuacji.
> Kod nie musi akceptowa? *dowonych* szablonów na przyk?ad. I biblioteka
> udost?pnia impelemntcje dla tych kilku przypadków.
> Mniej wiecej to to samo co biblioteka w C. Masz funckje przyjmuj?c? inty
> i floaty. To samo w C++, mo?esz poda? szablon z intem i floatem..
> To jeden z przyk?adów ?e *NIE* musisz *zawsze* udost?pnia? kodu
> szablonowego.


Nie rozumiem, ale ok, poszukam, poczytam, mo?e co? jest na

> >>> Nast?pna wada, kompilatory
> >>> czasami wskazuj? b??d daleko od jego wyst?pienia.
> >> Brednia w 99% wypadków.

> > U mnie w oko?o 30% przypadków jest to prawda.

> U?yj clanga.


Ostatnio u?ywam g++, ale wiem ?e powinienem spróbowa? iclanga.

> >>> Podsumowuj?c, kiedy? szablonów u?ywano rzadko albo w ogóle nie u?ywano
> >> Podobnie jak z papierem toaletowym.

> > Tylko ?e papier toaletowy nie ma nic wspólnego z programowaniem, a (nie)u?ywanie
> > szablonów ma sporo.

> Z faktu ?e kto? kiedy? robi? kup? bez papieru nie wynika ?e papier jest
> zb?dny obecnie.


No nie, mamy papier, ?yje si? troch? lepiej, ale musimy za niego zap?aci?,
go produkowa?, oczyszcza? w oczyszczalniach ?cieków, musimy i?? po niego
do sklepu, musimy go wypakowa? z paczki i powiesi? ko?o kibla, kto wie czy
nie ma jaki? ustaw prawny o papierze (na pewno jest, bo to mo?e rzutowa? na
stan zdrowia), a jak si? uzale?nimy od papieru i raz zapomnimy gokupi?, to
chodzimy z obsran? dup? do czasu u?ycia starej metody. Podobnie s? koszty
u?ycia szablonów, Ty to nazywasz kiepskim przypadkiem, a ja mam poczucie
pe?nego obrazu gdy te? te kiepskie przypadki wezm? pod uwag?, bo biblioteki
szablonów same nie powstaj? i nie zawsze s? darmowe.

> Najzwyczajniej kiedy? go nie by?o.
> Podobnie jak kiedy? nie by?o C++.
> Nie, C++ z szablonami. SaSC mia? translator z C++ na generowany C.


Tak. By?y generyki i w C, tylko na poziomie narz?dzi a nie j?zyka.

> Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
> wyborem j?zyka C czy C++. Ma zwi?zek jedynie z kiepskimi programistami,
> przyrostem danych i rozbudow? OSów.


Te? mi jest trudno si? wypowiedzie?, w sumie nie bior? udzia?u w
programach których kod wynikowy nie mie?ci si? na DVD. My?l? jednak
?e zdublowanie kodu ma najwi?kszy wp?yw.

> Nie jest. Dla znacznej cz?sci wyznawców C, bazuj?cych na opiniach z
> facebooka ?wiat wygl?da tak ?e "C++ du?o zajmuje". Tataka kolejna
> teoria spiskowa obok antyszczepionkowców i niejedz?cych.
> Nie. Tak. Zale?y.


Ok, chyba i tak, i tak nic po?ytecznego z tej rozmowy. Pewnie by?my
musieli wyprodukowa? jeszcze z 10 postów ?eby?my si? dobrze zrozumieli.
Jak do tego czasu nerwy by nikomu nie pu?ci?y, to mo?e potemby?aby jaka?
nauka ;-)

Pozdrawiam
Tomasz Kaczanowski (30.01.2020, 09:40)
W dniu 2020-01-29 o 18:24, heby pisze:
> On 29/01/2020 13:58, M.M. wrote:
>> No w?a?nie, s? pewne okoliczno?ci w których lepiej u?y? C, albo u?ycie
>> C++

> Poka? okoliczno?? kiedy lepiej u?y? kompilator C zamiast C++. Dowoln?
> rozs?dn?.


Dzi?ki swojej prostocie, ?atwiej jest przygotowa? kompilator C ni? C++
na eksperymentaln? platform?. Wi?c je?li nie masz gotowych narz?dzi
kompiluj?cej kod na dan? platform?, to przystosowanie nawet ju?
istniej?cego kompilatora jest po prostu prostsze, wi?c zajmuje mniej
czasu, a czasem mo?e mie? to znaczenie.
heby (30.01.2020, 23:45)
On 30/01/2020 04:40, M.M. wrote:
>> Ten przyk?ad nie t?umaczy problemów w C++ tylko w bia?ku.

> W jakim bia?ku?


Problemy z C++ to g?ównie problemy bia?kowe:
a) musz? u?ywa? new bo inaczej si? nie da
b) szwagra kumpla zi?cia ciotka to mia?a taki przypadek ?e zainkudowa?a
co? i exec zrobi? si? bilin razy wi?kszy
c) void* jest czytelniejsze ni? Foo*
d) po C++ krowy mleka nie daj?
e) ten sam asembler, ale jest wolniejszy bo szwagier sprawdza?
f) "mam swoje powody"

>> W sensie ?e jest bardziej restrykcyjny? S?ysza?me kiedy? ?e to wada. Do
>> dzisiaj nie wiem dlaczego.

> Poda?em przyk?ad, ale Ty na to co? o jakim? bia?ku.


Bo wszystkie problemy jakie pad?y w tym w?tku sa bia?kowe.

>> Napisa?em Ci ?e nic nie musisz szkoli? poza "ch?opaki, od dzisiaj w
>> ka?dym przerwaniu na arma na pocz?tku ma sta? scoped_interrupt_disable
>> sid(); i h...". A jak który? podskoczy to w ?eb. Koniec szkolenia. Po
>> roku nie dadz? sobie tego si?a odebra?.

> To faktycznie nie rozmawiamy o C++, tylko o czym? w rodzaju co napisa?e?
> "wystarczy jeden ficzer z C++". Co dobrego z takiej rozmowy wyniknie?


By? mo?e komu? uratuje dup? jak zampomni postawi? sei() przy returnie "w
przerwaniu ARMa".

Jeden ma?y ficzer ratuj?cy dup? wydaje si? by? ca?kiem sensowny jak za 0z?.

Ale nie, bo "mam swoje powody".

>> Kiedy? ludzie uwa?ali BCPL za spe?enienie marze?. Sam si? kompiluje,
>> mo?na zrobi? bootstrap na dziwnym systemie, architektura wr?cz zdj?ta z
>> tablicy uczelni, *uproszczona* sk?adnia.

> Niestety nie mia?em przyjemno?ci z BCPL.


?ladowe ilo?ci mo?na by?o odszuka?, najbli?ej, w Amidze; w okolicy
po?owy lat 80. DOSa mia?a napisanego w BCPLu. Skutkiem ubocznym
wszystkie pointery API DOSa wymaga?y arytmetyki >>2 <<2. H... wie po co :D

> Nie wiem jak u?ywasz okre?lenia bia?ko.


Jako decydowanie o technologii na podstawie pozaracjonalnych do?wiadcze?
przez ludzie sk?adaj?cych si? z bia?ka z domieszk? uprzedze?. Jedn? z
najbardziej zdumiewaj?cych rzeczy jakie zrozumia?em o porogramistach
jest to ?e to ludzie bardziej uprzedzeni do wszystkiego ni? przeci?tny
wyborca konserwatystów.

>> Mam takie a takie do?wiadczenia, widzia?em to i tamto, wnioskuje z tego
>> to i owo.

> Nie wiem w czym problem.


W tym ?e podej?cie racjonalne polega na czym? zgo?a odmiennym.

>> A na koniec okazuje si? ?e programy w C++ nie do?? ?e s? czytelniejsze
>> od tych w C, to cz?sto s? szybsze, ?atwiejsze w analizie i refaktoringu.

> Sekund?. Programy w C++ mog? by? czytelniejsze od tych w C i to mog? by?
> znacznie czytelniejsze, tak samo jak mog? by? ?atwiejsze w analizie i
> refaktoringu.


Nie, one *zazwyczaj* s?. Pozawalaj? wyrazi? algorytm bez pieprzenia si?
z pisaniem go w asemblerze, do którego w gruncie rzeczy sprowadza si? C,
a szczególnie taki poprzetykany void*.

> Ale je?li s? mocno zoptymalizowane pod k?tem szybko?ci
> dzia?ania, to na pewno nie s? ani czytelne, ani ?atwe w analizie, a ju? w
> ogóle s? fatalne w rozbudowie i refaktoringu.


Obawiam si? ?e w programowaniu wa?niejsza jest z?o?ono?? algorytmiczna
nad hackerskie optymalizacje kodu. Tym zajmuje si? kompilator.

I uwaga: wszystkie sztuczki z C++ z szablonami generuj? równie szybki i
równie hackerski kod co C. Tyle ?e ?atwiej to czyta?, rozumie? i
refaktorowa? ni? sieczk? kwadratowych kó? w C.

> Ju? pisa?em jaka jest analogia i nie przeczy?em mo?liwo?ciom C++. Nie mo?na
> jednej technologii ulepsza? bez ko?ca, a ju? na pewno nie mo?na sta?ym
> nak?adem kosztów/pracy ulepsza? o sta?? warto??, efekty staj? si? coraz
> mniejsze, a j?zyki programowania s? ulepszane od dawna. Dopóki nie
> b?dzie jakiego? prze?omu w technologiach wytwarzania oprogramowania, to
> nie nale?y si? ju? spodziewa?, ?e taki czy inny zestaw nowych ficzerów
> znacz?co udoskonali technologi?. W moim przypadku dobre biblioteki najbardziej
> przyspieszaj? tworzenie oprogramowania.


Na 99% masz do nich dost?p w C++. Nastepny pusty argument.

> Bajeranckie cechy j?zyka... to
> nawet spowalniaj?, bo programista my?li czego lepiej u?y?.


Odwrotnie. Programista nie my?li jak jest zbudowany std::container,
u?ywa move i ma najszybsz? z mo?liwych implementacj?. Pisanie w C++
opiera si? na pewnych obietnicach: napisz co chcesz a my zrobimy to tak
dobrze jak si? da, albo przynajmniej najlepiej jak potrafimy.

Bibliteki nie s? doskona?e. Ale s? coraz doskonalsze a lata 90 s?usznie
mine?y.

> Bez kontekstu nie wiem jak si? o to spiera?. Templates mo?na porównywa? do
> b??dogennych makrodefinicji i void*.


Nijak si? nie da. Templates nadaj? sens wska?nikom. void* odbiera ten
sens. To tak jak by? pisa? we wspomnianym BCPLu. Wszystko jest "wordem"
i sam se zgaduj co dosta?e? jako argument. No wiec masa programistów C
pisze w?a?nie w takim BCPLu. Wszystko jest void* i tylko cicha modlitwa
pozwala upewni? si? ?e to jest jednak Foo*.

> Nie wiem, moje korutyny maj? stos i s? odporne na w?tki - chyba ?e to co
> ja mam jeszcze nie nazywa si? korutyn?.


Korutyna ma mie? stos. Pisz? to w pierwszym zdaniu o korutynach na wiki.

Ale Maciek ma inny internet, inzynieri? i wszech?wiat. U nie go nie
musz?. St?d ca?a dyskusja, która tradycyjnie ju? odp?yne?a w kierunku
nastepnego nudnego flame starych dziadków. Przypuszcalnie za 30 lat
b?dziemy si? spiera? w sanatoriach wal?c si? laskami po ?bach.

>> Wie? programowanie w C++ to programowanie z dowolnym ficzerem dost?pnym
>> w g++ a niedostepnym w gcc. Na przyk?d z u?yciem RAII, które to jest
>> swoj? drog? krytycznie potrzebne w embedded i jednoczesnie skandalicznie
>> olewane przez embedded. Bo kwadratowe ko?a ?atwiej si? produkuje ni?
>> kupuje okr?g?e.

> A wy?ej napisa?e? ?e spieramy si? o wy?szo?? j?zyka C nad C++ lub odwrotnie.


Bo tak wysz?o. Pierowtny temat to napisanie kilku mark w celu emulacji
czego? czego autor nie pojmuje jak ma dzia?a?.

> J?zyk to nie jeden ficzer, a w praktyce nawet spór o ca?y j?zyk jest ja?owy, bo
> co komu nawet z najlepszego j?zyka jak nie ma do niego narz?dzi?


Do C++ jest ca?kiem sporo narz?dzi. Nie narzeka?bym.

>>>> U?ycie sk?adni obiektowej (struct/class) nie oznacza ?e u?ywa si?
>>>> obiektowo?ci.
>>> Dlaczego?

>> Bo obiektowo?c wymaga *OBIEKTÓW* a nie klas.

> Nie wiem, a co z tego rozgraniczenia dobrego dla Ciebie i dla mnie?


To do?c istotne przyci?cie powoduje ?e ludzie przestaj? widzie? C++ jako
"co? gdzie obowi?zkowo u?ywa si? new".

>> ?e traits< int >::max to nie jest programowanie obiektowe, natomiast to
>> jest programowanie w C++.

> Te? nie wiem co z tego dobrego dla mnie i dla Ciebie.


Dla innych mo?e wynika?. Na przyk?ad mog? w swoim zdumieniu zobaczy? ?e
powy?sza linijka nie kompiluje si? do milairda megabajtów. Ona si?
kompiluje do ... niczego.

Zazwyczaj programi?ci C w?a?nie tak widz? C++: du?o pisania wi?c
wolniej. Nie przychdozi im do g?owy ?e to pisanie jest po to aby
kompilator sprawdza? typy a nie generowa? kod.

> Programowa?em i z u?yciem szablonów i z void*. Tyle ?e szablonów zwykle u?ywam
> do poprawy wydajno?ci. Swoj? osobist? statystyk? mam zdecydowanie na korzy??
> void* - w sensie ?e mniej b??dów pope?nia?em. Ale powtarzam, ja czasami u?ywam
> szablonów zupe?nie inaczej ni? 90% programistów.


Mam do?wiadczenia dok?adnie odwrotne. W dodatku moje s? zbli?one do
obserwacji ludzi zajmujacych si? teori? programowania - silne typy s?
bezpieczniejsze ni? uniwersalne dane. U mnie liczy si? jako??, nie
wygoda pisania.

>> I w tym momencie zamieniasz gcc na g++. Znalaz?e? jeden powód aby u?y?
>> C++ to go u?ywasz, jest za darmo.

> Nie rozumiem w jakim momencie, gcc szablonów nie kompiluje, a rozmawiali?my w
> tym akapicie o szablonach.


"gcc" to tylko taki koncept kompilatora C. Jak si? uprzesz to oczywi?cie
za pomoc? gcc skopilujesz plik .cpp (z pewnymi detalami, ale pal sze??).
Tu chodzi o metafor?: zamie? swój kompilator z C na C++, to jest za darmo.

>>> gdy jeden szablon jest parametryzowany kilkoma innymi szablonami

>> Poni?ej promila z promila zastosowa? szablonów wymaga takich wygibasów.

> Je?li podajemy jawnie wydajno?? jako zalet? templates, to zwykle u?ywa
> si? tego typu wygibasów.


*W* ?rodku biblitek. U klienta? Nie, raczej nie. Tam si? to ko?czy
std::shared_ptr< Foo > a to ?e w ?rodku kto? sprawdza trywialnosc
konstruktora wielopoziomowymi szablonami to nie jest ani istotne ani
widoczne.

>> Ale dla user ko?cowego jest wr?cz bajecznie prosta.

> Tak, o to w?a?nie chodzi. Moje mikro-biblioteki te? s? w jakim? stopniu proste,
> ale s? wierzcho?kiem góry lodowej. Niewidoczna cz??? pod wod? stanowi
> pierdylion eksperymentów z szablonami, makrami, opcjami kompilatora, z
> oczekiwaniem na koniec pracy kompilatora, z uganianiem si? za syntax error w
> innym pliku ni? pokaza? kompilator....


Sprawd? co oferuje clang w kwesti przejrzysto?ci b?edów. gcc ju? od
dawna nie ma nic wspólnego z wygod? kompilowania. Da si?? Da.

>> Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
>> programistów C. Straszy si? ni? i jak wida? skutecznie.

> Nie wiem do czego nawi?zujesz.


Do bredzenia o tym ?e co?tam powi?ksza aplikacje o magabajty "bo trzeba
rozwija? szablony". ?omatko. Rozwijam szablony i raz mam 0 bajtów a raz
gigabajty. Na tego typu opinie nalezy natychmiast mówi? "Stop". Generuj?
tylko atmosere podobn? do antyszczepionkowców. Podobno u?ycie RAII
powoduje autyzm.

> Mo?e tak naprawd? spieramy si? o to, ?e Ty uwa?asz i? szablony bardzo
> usprawniaj? technologi? oprogramowania, a ja ?e usprawniaj? j? w mniejszym
> stopniu?


To zdajnie powy?ej to nawet nie do ko?ca si? do szablonów odnosi.
Bardziej do silnych typów. Tak silnych ?e dr? jap? na kompilacji, czego
void* nie potrafi.

> Nie zgadzam si? te?, ?e trudno pope?ni? b??d w runtime programuj?c z
> wykorzystaniem szablonów.


Kawestia oceny. Przypadki kiedy typ nie pasuje s? u mnie zredukowane do
prawie 0.

> Nie wiem, trudno mi si? wypowiedzie?, bo od wielu lat void* zdarza mi
> si? u?y? mo?e raz na rok. Mo?e z 15 lat temu u?ywa?em regularnie, te?
> dawa?em rad?. I nie chc? powiedzie? po prostu ?e kiedy? bez papieru
> dawali rad?, ale ?e jak dawali rad?, to ten papier toaletowy nie jest a?
> takim panaceum, tylko jakim? kolejnym ma?ym ulepszeniem.


I jest za darmo. Znaczy nie papier tylko C++.

>> My?le ?e 90% konstrukcji z boosta jest trywialna.

> Pisa?e? te? ?e si? napracowali przy boo?cie, czy mia?e? na my?li ?e
> napracowali si? przy pozosta?ych 10ciu procentach?


Nie jest istotne kto si? naprawcowa? *przy* booscie. Istotne jest ile
napracuje si? klient tego API. No wi?c niewiele. O wiele mniej ni?
straszy si? m?odych studentów oferujac im w zamian ?upanie kamieni void*.

> Czysta z?o?liwo?? czy kryje sie za tym co? konstruktywnego? Co to s?
> kiepskie do?wiadczenia?


Kiepskie przyk?ad to na przyk?ad analiza closures w boost::spirit. Tam
jest cie?ko. I jestem pewny ?e je?li kto? chcia?by mi z?o?liwie wykaza?
?e boost jest trudny to wyjmie przyk??d z okolicy boost::spirit, mpl czy
fusion. To s? z?e do?wiadczenia. Przy uzywaniu takim jak na pocz?tku
watku, czyli "ma?ych kawa?eczków C++ usprawniajacych prac?" takie
kobylaste szablony nie tylko si? nie trafiaj? ale i sensu nie maj?.
Przyjdzie czas to kto? to doceni. Na razie wola?bym aby embedowcy
zauwa?yli ?e kto? w zesz?ym wieku wymy?li? RAII. To ju? by by?o naprawd?
mi?e.

> Na razie rozumiem, ?e dobre do?wiadczenia s? wtedy gdy si? tam zagl?da
> raz na rok, a gdy kto? akurat nad tym pracuje, to nabiera kiepskich
> do?wiadcze?.


Nie, to oznacza ?e k?opoty z debugiem kodu szablonowego praktycznie nie
wystepuj? w praktyce. Czasem si? tam zagl?da, w 50% przypadków brakuje
const albo mia? by? pointer a jest referencja. Ale to wida? od razu, bez
debugowania. Ostatni raz rozwija?em map? stl jakie? 2 lata temu szukaj?c
dlaczego nie dzia?a. Kodu biblitecznego stl/boost praktycznie sie nie
debuguje mimo ?e mój kod jest nimi przesi?kni?ty na wylot.

> Mia?em na my?l nie nie tylko ?ledzenie linia po linii wykonania kodu w
> programie do debugowania, tyko generalnie usuwanie b??dów. Gdy ogl?dam
> kod z 'wirtualnym typem' który dopiero w trakcie kompilacji b?dzie na
> kilka sposobów konkretyzowany, to wcale nie jestem bardziej pewny jego
> bezb??dno?ci, ni? gdy patrz? na kod zwyk?ej procedury. W zasadzie to
> chyba mam odwrotnie, co do zwyk?ych procedur szybciej nabieram przekonania
> ?e s? poprawne. A swoj? drog? w programach do debugowania te? by?o
> sporo b??dów i gorzej sobie radzi?y na szablonach.


Znowu chcia?em przypomnie? ?e lata 90 s?usznie mine?y.

>>> nie mam z nimi problemów. Ale gdy np. ca?y algorytm genetyczny parametryzuj?
>>> kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
>>> edytor nie wie jakie metody b?d? mia? parametry.

>> Masz z?y edytor.

> Mo?e, a jaki Ty masz?


Np. VS + Visual Assist. Visual assist poniek?d potrafi domy?la? si?
detali zwi?zanych z szablonami, i prawid?owo podpowiada?. I gubi si?
czasem, tak. Trudny j?zyk, ci??ko o dobry edytor, ale nie jest tak ?e
nie ma *nic*.

>> Mam m?otek, ale lepiej wbija? gwo?dzie lutownic?.
>> Mam szablony, ale przecie? void* to tylko kilka wad z którymi da sie ?y?.

> Nie, nie to chcia?em powiedzie?. Mam szablony, u?ywam szablonów, ale jestem
> ?wiadomy ?e z void* te? dzia?a?o, wi?c te szablony to nie ?adne panaceum, ale
> jakie? kolejne ulepszenie.


Tu jest zupe?nie inaczej. Silne typy s? lepsze ni? void*, mniej wi?cej
zawsze. Mimo to ludzie u?ywaj?cy void*, czasami wymieniaj?c ich wady,
dalej nie widz? sensu zmieny na silne typy. Problemem jest brak
logicznego argumentu dlaczego. W dodatku wielu reaguje skrajnie
alergicznie na pytanie "Dlaczego u?ywasz void* skoro silne typy s? za
darmo". To jest religia bia?kowa.

>> Ja rozumiem jeszcze jak by za u?ywanie szblonów trzeba by?o p?aci?.

> Bo trzeba, nic nie jest za darmo. T? op?at? by?a/jest:
> - konieczno?? szkolenia personelu,


U?ywaj? int, float. Nagle musz? u?y? Foo. To jaka? katastrofa?

> - konieczno?? nabrania do?wiadczenia przez personel,


Mieli na to ostatnie 40 lat.

> - wiele lat implementacji w kompilatorach,


Które od wielu lat je maj?.

> - problemy bo kompilatory ró?nie to wspiera?y,


Zaznaczam po raz kolejny ?e lata 90 s?usznie mine?y.

> - targi o to jak powinny wygl?da? w standardzie,


Zako?czone standardem.

> - próby ?amania standardu przez niektóre firmy,


Które nie wp?ywaj? na 99.9% kodu pisanego w C++ najmniejszym stopniu
oraz identyczne problemy wyst?puj? w ka?dym, dowlnym j?zyku i kompilatorze.

> - o wyd?u?onym czasie kompilacji, zwi?kszonym rozmiarze kodu i s?abym


Atari 65XE s?abo si? sprawdza jako ci?g?a integracja, podobnie klikanie
w "rebuild".

> pokazywaniu w?a?ciwej linii z syntax error - ju? pisa?em.


To dobrze, bo w clangu te? to zauwa?yli

> - o tym jak to wygl?da z punktu widzenia kogo? kto przygotowuje
> wygodny szablon - te? ju? pisa?em.


Ale to nikogo nie obchodzi po stronie klienta.

>> Szablony rozwiazuj? dobrze kre?lon? klas? problemów z jako?ci? kodu.

> Zgoda, ale wprowadzaj? te? inne problemy.


Nie. Ich naduzywanie mo?e generowa? problemy. Zastapienie void* silnym
typem nie tylko jest oczywistym rozwi?zaniem problemów z jakosci? kodu
ale wr?cz zmusza do poprawy jego jako?ci podczas pisania.

Perwsze s?ysz? aby silne typy mia? jakie? wady vs void*.

Na marginesie: void* to nie brak typu. To typ. Co? jak by pisa? w javie
kastujac wszystko do Object i spowrtoem za ka?dym razem. Po h.. ?

> Cho? podsumowanie dzi? wypada na
> korzy?? szablonów, to po odj?ciu wad, to podsumowanie nie jest rewelacyjne.


Stosujesz typow? metod? dyskutowania: b?d? wywa?ony, to b?d? brzmia?
m?drze. Tylko ?e te "nie jest rewelacyjne" jest troche smutne w
zderzeniu z faktem ?e szablony s? <division by zero exception> razy
lepsze od void*.

>> W C nie ma nic co mog?o by to zastapi? poza modlitw?.

> Zewn?trzne programy narz?dziowe pe?ny rol? generyków, sam jeden wi?kszy
> generator napisa?em do generowania sieci neuronowych. No i by? void* i
> makra ;-)


Kto komu broni generowa? kod z void*. Pisanie void* z palca jest pora?k?
a nie generowanie.

>> Jeste? pewien ?e masz wszystko dobrze ?e masz potrzeb? pe?nej rekompilacji?

> Bym musia? napisa? (i potem pilnowa?) specjalne pliki make, które uwzgl?dniaj?
> kompilacj? warunkow?.


I robisz to co 30 sekund? Czy mo?e robi to ci?g?a integracja?

> Nie wiem co gorsze, modli? si? czy nie mam b??du w
> pliku make, czy czeka? te 30 sekund.


To nie ty czekasz. To ci?g?a integracja czeka. Ty popijasz kaw?, albo
robisz co? innego.

>> Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny ?e
>> nie powinien by? uwa?any za reprezentacyjny.

> Nie wiem czy kiepski przypadek, sam przyzna?e? ?e ludzie od boosta
> si? napracowali ci??ko...


Nie widz? zwi?zku.

Zmieniasz globalnego define. Wymaga to rekompilacji wszystkiego.
Argument ?e wtedy jest wolno jest taki sam w C jak i w C++.

>> Z faktu ?e kto? kiedy? robi? kup? bez papieru nie wynika ?e papier jest
>> zb?dny obecnie.

> No nie, mamy papier, ?yje si? troch? lepiej, ale musimy za niego zap?aci?,
> go produkowa?, oczyszcza? [...]


Niekiedy daleko idace analogie s? b?edne.

C++ jest za friko.

Napisanie Foo* zamiast void* jest za friko.

RAII jest za friko.

W ogóle wszystko jest za friko.

Upierdiwy profesor powie ?e plik kompiluje si? 1.7ms d?u?ej. I b?dzie
mia? racj?. Ten 3-ci rodzaj racji. Co? jak uszcz?dzanie na plastikowych
s?omkach w prywatnych samolotach.

>>>> Na patrz, a ja mia?em Amig? z 2MB pami?ci chip i na tej konfiguracji
>>>> pogania?em SaSC w trybie C++ pisz?c obiektowe programy GUIowe. Mo?e to
>>>> czary?
>>> Mo?e czary, a mo?e to (w jakim? stopniu) dzi?ki void* ?

>> Nie, C++ z szablonami. SaSC mia? translator z C++ na generowany C.

> Tak. By?y generyki i w C, tylko na poziomie narz?dzi a nie j?zyka.


Nie rozumiesz. SasC to by? równie? normalny C++. To ?e w ?rodku
konwertowa? to na C i kompilowa?, to detal. Nieistotny. Niewidoczny.

Mia?em wi?c kompilator C++ na 2MB RAMu bez swapa i da?o si? w tym pisa?
obiektowe i okienkowe aplikacje o przyzwoitej wydajnosci. Ba, o
wydajno?ci zbli?onej do tej z C. Róznica by?a g?ównie w tym ?e ten
konwerter by? *bardzo* kiepski.

>> Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
>> wyborem j?zyka C czy C++. Ma zwi?zek jedynie z kiepskimi programistami,
>> przyrostem danych i rozbudow? OSów.

> Te? mi jest trudno si? wypowiedzie?, w sumie nie bior? udzia?u w
> programach których kod wynikowy nie mie?ci si? na DVD. My?l? jednak
> ?e zdublowanie kodu ma najwi?kszy wp?yw.


Ca?e szcz?scie C++ nie dubluje kodu sam z siebie jesli ludzie nie pisz?
byle jak.
heby (30.01.2020, 23:47)
On 30/01/2020 08:40, Tomasz Kaczanowski wrote:
>> Poka? okoliczno?? kiedy lepiej u?y? kompilator C zamiast C++. Dowoln?
>> rozs?dn?.

> Dzi?ki swojej prostocie, ?atwiej jest przygotowa? kompilator C ni? C++
> na eksperymentaln? platform?.


Przypomnij mi który obecnie u?ywany i popularny kompilator C/C++
generuje kod w asemblerze wprost z C/C++ bez warstwy po?redniej?

> Wi?c je?li nie masz gotowych narz?dzi
> kompiluj?cej kod na dan? platform?, to przystosowanie nawet ju?
> istniej?cego kompilatora jest po prostu prostsze, wi?c zajmuje mniej
> czasu, a czasem mo?e mie? to znaczenie.


Szczególnie jak odkrywasz ?e wspó?czesne kompilatory to jakie?
frontendy, backedy, kody po?rednie, maszyny wirtualne itd itp ...

Podobne wątki