🚀 go-pugleaf

W dniu wtorek, 28 stycznia 2020 22:37:38 UTC+1 użytkownik heby napisał:

> >> Biliard. W sumie bez znaczenia. U mnie to i tak jeden #include.
> > A o ile wydłuża czas kompilacji?
> 
> Dopadła Cie reglamentacja czasu kompilacji? Masz ograniczenie na 
> produkcje promieniowania termicznego w procesach kompilacji wynikające z 
> troski o polską energetykę? Kompilujesz całosć za każdym razem? Widzisz 
> różnicę pomiedzy 10ms vs 20ms?

Wolę po prostu nie dokładać niepotrzebnych zależności.
Nie wiem, co w tym dziwnego.

> > że Ty sobie używasz jakiejś technologii, i ja sobie używam innej technologii
> 
> Kilka kiepskich makr cieżko nazwać technologią.

Język C to jest technologia, i język C++ to jest inna technologia.

> >, i wygląda na to, że z jakichś względów Tobie strasznie przeszkadza to, że nie używam tej technologii, której Ty używasz.
> 
> Mi nie przeszkadza bo nie używam popsutych makr które rozwiązują jakiś 
> problem generujac inny problem. Przestrzegam innych.

Chyba trochę przeszkadza, skoro atakujesz mnie z tego powodu.

> > Czasem, kiedy w odpowiedzi na moje różne krytyki C++ pojawiają się gorliwi wyznawcy, którzy przekonują mnie, że "chuja się znam", odsyłam ich do tej listy problemów.
> 
> Całość tego blogowego wpisu była C++ vs inne języki. A tu rozmawiamy C++ 
> vs C. Musiałem wiec przegapić tą "listę" która ma odniesienie do naszej 
> dyskusji.

C też jest innym językiem, niż C++.

> Nikt tutaj nie przekna Cie do pisania w C++ bo wcale nie musisz. Skoro 
> piszesz programy używając muzealnych technik zamiast wspaniałego 
> scheme/lispa to możesz miec "jakieś powody". Ja tylko zwracam uwagę że 
> zamiana technologii na C++ i pisanie dalej w C z małymi wstawkami w C++ 
> nikomu dupy nie urwało choć nie jednego pewnie zmusiło do spowiedzi i 
> pokuty w lokalnej grupie wyznaniowej.

Po pierwsze, C i C++ są niekompatybilne. A jeżeli używam rozszerzeń GNU C, to jest już w ogóle niekompatybilne, i zamiana jednego kodu na drugi jest nietrywialna. Po drugie, mi się dużo przyjemniej pisze w GNU C, niż w C++.
Jeżeli nie potrafisz sobie z tym poradzić, to może idź do terapeuty.

> > W każdym razie żaden jeszcze nie zaproponował jakiegokolwiek rozwiązania któregokolwiek z tych problemów.
> 
> Zabawne bo ja własnie zaproponowałem. Zmień na C++, użyj 
> boost::coroutine. Potem dorzuciłeś że to arm i przerwania. Skoro tak to: 
> nie uzywaj coroutines, użyj FreeRTOSa

Dokładnie tak. Zaproponowałeś wiele rozwiązań, zupełnie nie rozumiejąc uwarunkowań problemu. I to zaproponowałeś, mimo że nikt Cię o to nie prosił.
Dzięki temu straciłeś czas zarówno swój, jak i mój.

> > Ja w swoim życiu widziałem projekty, które grzęzły tylko od tego, że ktoś na początku podjął decyzję o użyciu tego właśnie języka.
> > (Nota bene, widziałem je właśnie w tej firmie, w której pracujesz)
> 
> To musiała być inna firma. Nic się nie zgadza.

Tam pomiędzy Ikeą a lotniskiem.

> > I jeżeli Ty masz ochotę dostrajać się do tempa pracy komitetu standaryzacyjnego C++, to to jest Twoja sprawa. Ja mam inne pomysły na korzystanie ze swojego życia, i wolę korzystać z rozwiązań, które rozumiem, i które działają już teraz.
> 
> Ale one nie działają. Dostarczyłeś popsutą bibliotekę do coroutines 
> która ma rozwiązywać problemy które rozwiązuje się inaczej.

Cały czas nie wiesz, jaki problem chcę rozwiązać, ani jakie są jego uwarunkowania. A mimo tego cały czas gadasz, jakbyś wiedział lepiej.

> >>> Żeby móc sobie pisać wątki na przerwaniach.
> >> OK, oczywisćie sprawdziłeś overheat przełaczanai stosów i zapisywania
> >> kontekstu rejestrów?
> > Jakiego przełączania stosów?
> 
> Tak działają coroutines w C/C++ bo w tym języku stos jest elementem 
> kontekstu wykonywania kodu.

W C jako takim nie ma czegoś takiego, jak "coroutines", więc nie można powiedzieć, że "tak działają".

> I dlatego nie masz tak naprawdę coroutines. Masz popsutą bibliotekę do 
> rozwiązywania absurdalnie nikłego zakresu problemów w porównaniu do 
> prawdziwych coroutines. Nie wykluczam że wystarczającą do "przerwania w 
> ARMie" aczkolwiek dalej jestem zaszokowany ile się w tym przerwaniu musi 
> dziać że aż trzeba na pomoc wołać preprocesor ...

Uuu, "aż wołać preprocesor".
<grzmoty i pioruny>

> >> Zaryzykuje: a sprawdziłeś co oferuje FreeRTOS?
> > Oczywiście. Mam dobre powody, dla których stosuję właśnie to rozwiązanie, które stosuję.
> 
> Masz dobre powody aby nie używać C++ i FreeRTOSa. Poza religią nie znam 
> sensownych, "blog" nie pomógł w ich identyfikacji. Co robić...

To nie moja wina, że brakuje Ci wyobraźni.

> >> W zasadzie tak: przerwania, jak to przerwania, powinny być szybkie.
> >> Korutyn bym tam nie wsadzał. Szczególnei takich z okolic "workaround
> >> przez zmienne statyczne".
> > Jaki "workaround"?
> 
> Niemożność używania stosu. To ogranicza zastosowanie do marginalnej 
> ilosci przypadków, w dodatku prawdopodobnie rozwiązywalnych ładniej 
> switch/case.

No dobrze, to może pokaż, czego nie możesz zrobić bez stosu, a co mógłbyć zrobić, gdybyś miał korutyny ze stosem.

> >> Oczywiscie że odpowiedź zależy od zabyt dużej liczby czynników aby miała
> >> sens. Ale ponieważ mam pod ręką fusy: masz problem z przekazywaniem
> >> wartości pomiędzy wywołaniami i sugerujesz zmienne statyczne i pracujesz
> >> z przerwaniami. Co może pójść źle?
> > A w czym to przeszkadza?
> 
> W niczym. Przy bardzo dużej uwadze, wyszarpaniu sobie żył i głebokiej 
> modlitwie masz szansę napisać cały program na side effectach przez 
> zmienne globalne i może nawet cudem zadziała. W końcu jakoś te programy 
> w BASICu na 8-bit pisali.

Rozumiem. Czyli tak sobie gadasz.

> >Jeżeli chcę się komunikować z przerwania z innymi komponentami systemu, to muszę użyć zmiennej globalnej.
> 
> To inny przypadek.

A czym się różni?

> > Zmienna statyczna to to samo, tyle że komunikuję się jedynie z innymi fragmentami korutyny.
> 
> Ale prawdziwe korutyny *NIE* ograniczają używania stosu. Używasz i 
> działa tak jak się spodziewasz.

> PS. Podpowiem Ci: Twój pomysł da się rozwiązać kilkoma makrami i 
> ukrytymi w nich "switch/case" bez używania magicznych ficzerów 
> kompilatora.

No to dajesz. Pokaż te kilka makr.

On 28/01/2020 23:30, Mateusz Viste wrote:
> C++ to mocno skomplikowana kobyła

Tak.

> , która ulega regularnym zmianom

Nie. Ulega ewolucji z zachowaniem *prawie* wszystkiego. Helloworldy w C 
działają tak samo a jak nie działają to często "trudno się dziwić".

> ... nie
> każdemu to odpowiada. 

Wolność wyboru.
>> Lutownicą też się da wbijać gwoździe w papę, dziadek tak robił.
> Być może szybciej wbijać lutownicą którą się ma w ręku, niż młotkiem
> który leży pod drabiną? Tak tylko gdybam.

Nie, tutaj mamy  do czynienia z przypadkiem gdzie młotek trzymasz już 
prawie w ręce (gcc->g++) ale dalej preferujesz lutownicę po dziadku bo 
"masz swoje powody".

>> Bo przerwania, bywa, przychodzą za szybko. Szczególnie jak się w nich
>> robi zbędną algorytmikę. Bywa że przychodzą *za* szybko.
> Nie wiem jak to wygląda w ARMie, ale w x86 int handlery są
> domyślnie nieprzerywalne. ARM ma inaczej?

Chyba nie czaisz problemów w mikrokontrolerach.

Jest sobie SPI. Na tym SPI napierniczają bajty. DMA chowa je do bufora w 
pamieci. Bywa że ten bufor to jeden bajt. Wysyła przerwanie kiedy jest 
pełny. Ty robisz sobie swoje korutyny i fancy programowanie makr. 
Przepełnia się drugi bufor. Nie odebrałeś przerwania. Dupa. To czy 
przerwania są czy nie przerywalne nie ma znaczenia. Problemy są rózne. 
Być może w opisywanym przypadku nie występują. Tylko po h... wtedy te 
całe korutyny?

Oczywiście zaraz się okaże że ten cały ARM z przerwaniami to do migania 
diodą służy. Tak czy inaczej przerwania to wielowątkowość + restryckje 
RT. Miejsca na zabawę tam dużo nie ma.

> Obsługa przerwań w BASICu?

Porównianie było do "makrowych korutyn" w których użycie "int a" jest 
zabronione co redukuje w nich pisany algorytm do poziomu BASICa z lat 70 
gdzie wszystko było globalne. Lutownica, nawet rozpadająca się i pod 
napięciem ciągle lepiej wbija gwoździe niż młotek.

On 29/01/2020 08:31, Maciek Godek wrote:
> Wolę po prostu nie dokładać niepotrzebnych zależności.

Przecież własnie dołożyłeś niepotrzebną zależnośc of ficzera w kompilatorze.

> Język C to jest technologia, i język C++ to jest inna technologia.

Język C++ to rozwinięcie jęyka C. Jeśli tylko nie będziesz udawał 
czepialskiego profesora to okaże się że C jest podzbiorem C++ z 
nieistotnymi róznicami w detalach dla programisty (albo poprawialne albo 
głupie - tak czy inaczej do zmiany).

> Chyba trochę przeszkadza, skoro atakujesz mnie z tego powodu.

Tu Cie nikt nie atakuje.

Masz kiepski kod. Ten kod nazywasz "korutynami".

To nie są korutyny. W dodaku okazuje się że wymagają workaroundu aby być 
w ogóle użyteczne do normalnego programowania, inaczej to pistolecik na 
kapiszony. Z workaroundem to odbezpieczony granat w gaciach.

Jak się okazuje że ktoś pyta "po co" to nerwowo marudzisz o jakiś 
powodach. Nie ma ich. To tylko takie hackerstwo. Wylatuje na pierwszym z 
brzegu code review.

> C też jest innym językiem, niż C++.

Nie, jest podzbiorem C++.

> Po pierwsze, C i C++ są niekompatybilne.

Nikt tak nie twierdzi, ale śmiem twierdzić że w Twoim wypadku zmiana z 
gcc na g++ nic nie spowoduje a może nawet pomoże (warningi, nielegalne 
konstrukcje itd itp). Czyli są komatybilne w jedną stronę.

> A jeżeli używam rozszerzeń GNU C

Przecież nie chcesz dodatkowych zależności, prawda?

>, to jest już w ogóle niekompatybilne, i zamiana jednego kodu na drugi jest nietrywialna.

Jak się popsuło kod to trzeba refaktorować. To tylko zwykły dług 
technologiczny a bywa że i vendor lockin. Pierwszy raz programujesz że 
nie wiesz że używanie niszowych rozwiązań generuje dług?

> Po drugie, mi się dużo przyjemniej pisze w GNU C, niż w C++.

Ludzie maja rózne gusta. Nic na to nie poradzę.

> Jeżeli nie potrafisz sobie z tym poradzić, to może idź do terapeuty.

Ja sobie z tym radzę doskonale. Czyli używam właściwych narzędzi tam 
gdzie rozwiązują one prawidłowo problemy. Uzywam C tam gdzie nie mam 
wyjścia, używam C++ tam gdzie mi to pomaga, używam Prologa tam gdzie 
trzeba wyrwać lachona. Każdy język ma zastosowanie.

Problem w tym że "uzywam C bo nie mam wyjścia" sprowadza się zazwyczaj 
do jakiś absurdalnych przypadków 8051 z kompiltorem pisanym przez 
dyletantów. Tam nie mam wyjścia.

>>> W każdym razie żaden jeszcze nie zaproponował jakiegokolwiek rozwiązania któregokolwiek z tych problemów.
>> Zabawne bo ja własnie zaproponowałem. Zmień na C++, użyj
>> boost::coroutine. Potem dorzuciłeś że to arm i przerwania. Skoro tak to:
>> nie uzywaj coroutines, użyj FreeRTOSa
> Dokładnie tak. Zaproponowałeś wiele rozwiązań, zupełnie nie rozumiejąc uwarunkowań problemu.

a) nigdzie ich na poczatku nie było
b) jak się pojawiły to zaproponowałem lepsze rozwiązanie
c) rozwiązanie nie pasuje
d) prawdopodobnie go to b) aż wyjdzie na to że masz rację bo w 
specyfikacji napisali że kod ma mieć popsute korutyny na makrach w C. No 
to wtedy nic nie poradzę. Deadlock.

> I to zaproponowałeś, mimo że nikt Cię o to nie prosił.

Taka natura ludzka: jesli ktoś się przewróci to staram się mu pomóc.

> Dzięki temu straciłeś czas zarówno swój, jak i mój.

Mój nie jest nic wart więc nie ma czego żałować. Za Twój przepraszam.

>> To musiała być inna firma. Nic się nie zgadza.
> Tam pomiędzy Ikeą a lotniskiem.

Dalej się nic nie zgadza.

>> Ale one nie działają. Dostarczyłeś popsutą bibliotekę do coroutines
>> która ma rozwiązywać problemy które rozwiązuje się inaczej.
> Cały czas nie wiesz, jaki problem chcę rozwiązać

Nie dowiem się już nigdy. Jestem przekonany że bez względu na to co nie 
wymyślisz i tak na koniec okaże się że to problem wyssany z palca.

>, ani jakie są jego uwarunkowania.

Poza pewnymi wąskimi dziedzinami inzynierii wysokiego ryzyka, kod pisze 
się pod narzędzami do tego przystosowanymi. Nie wiem czy korutyna za 
zmiennymi gobalnymi do czegokolwiek pasuje. Nie, nie pasuje.

> A mimo tego cały czas gadasz, jakbyś wiedział lepiej.

Być może to doświadczenie. Ale przypuszczalnie tylko złudzenie.

>> Tak działają coroutines w C/C++ bo w tym języku stos jest elementem
>> kontekstu wykonywania kodu.
> W C jako takim nie ma czegoś takiego, jak "coroutines", więc nie można powiedzieć, że "tak działają".

W C masz stos jako integralną częśc jezyka. Wiec aby coroutines działały 
w C musisz w nich *jakoś* obsługiwać stos. Teraz lepiej?

> Uuu, "aż wołać preprocesor".
> <grzmoty i pioruny>

Nie, nie grzmoty i piuruny tylko wyrzucenie z review. Przyznaje, efekty 
mniej spektakularne.

>> Masz dobre powody aby nie używać C++ i FreeRTOSa. Poza religią nie znam
>> sensownych, "blog" nie pomógł w ich identyfikacji. Co robić...
> To nie moja wina, że brakuje Ci wyobraźni.

Cały czas chcesz by Ci czytać w myślach. To nie jest możliwe.

>> Niemożność używania stosu. To ogranicza zastosowanie do marginalnej
>> ilosci przypadków, w dodatku prawdopodobnie rozwiązywalnych ładniej
>> switch/case.
> No dobrze, to może pokaż, czego nie możesz zrobić bez stosu, a co mógłbyć zrobić, gdybyś miał korutyny ze stosem.

[...]
yeld( 42 );
for( i = 6 ; i < 10 ; ++i )
    [...]
    yeld( i );
    [...]

W zasadzie napisanie dowolnego nieco bardziej skomplikowanego generatora 
wymaga natychmiast użycia workaroundu ze zmiennymi statycznymi.

PS. Zmienne statyczne tez nie są potrzebne. Wystarczy dowolny obiekt 
trzymający stan korutyny. Zaznaczam że jest to tylko niewiele lepsze 
rozwiązanie bo ten obiekt też musi być śledzony jeśli nie daj Panie 
korutyny będą się przeplatać. Tak czy owak d...z tyłu.

>>> Jeżeli chcę się komunikować z przerwania z innymi komponentami systemu, to muszę użyć zmiennej globalnej.
>> To inny przypadek.
> A czym się różni?

Tym że do tego systemy operacyjne wynalazły różne metody IPC ponieważ 
jest nieuniknione.

W Twoim wypadku używanie zmiennych globalnych nie jest nieuniknione 
tylko wynika z kiepskiej implementacji.

>> PS. Podpowiem Ci: Twój pomysł da się rozwiązać kilkoma makrami i
>> ukrytymi w nich "switch/case" bez używania magicznych ficzerów
>> kompilatora.
> No to dajesz. Pokaż te kilka makr.

Może coś narzeźbię w wolnej chwili. Uzywałem tego przez jakiś czas z 
miernym skutkiem i raczej nie znajduje powodów do powrotu.

On 29/01/2020 08:31, Maciek Godek wrote:
>> PS. Podpowiem Ci: Twój pomysł da się rozwiązać kilkoma makrami i
>> ukrytymi w nich "switch/case" bez używania magicznych ficzerów
>> kompilatora.
> No to dajesz. Pokaż te kilka makr.

Proszę, wersja z ifami jest nawet wygodniejsza w użyciu:

#define BEGIN_BAD_COROUTINE( _coroutineState )				     \
     int& coroutineState = _coroutineState.m_coroutineState;        \
     if ( coroutineState == 0 )									 \
     {

#define BAD_YIELD( _result )             \
		coroutineState = __LINE__;                 \
         return _result;                 \
     }             \
	else if ( coroutineState == __LINE__ )   \
     {

#define BAD_END_COROUTINE()                 \
     }

struct SimpleState
{
	int m_coroutineState = 0;
};

int
coroutine1()
{
	static SimpleState state;

	BEGIN_BAD_COROUTINE(state);

	BAD_YIELD(1);

	BAD_YIELD(2);

	BAD_YIELD(3);

	BAD_END_COROUTINE()

	return 4;
}

int
coroutine2()
{
	static SimpleState state;

	BEGIN_BAD_COROUTINE(state);

	BAD_YIELD(10);

	BAD_YIELD(11);

	BAD_YIELD(12);

	BAD_END_COROUTINE()

	return 13;
}

int main()
{
	for (int i = 0; i < 4; ++i)
	{
		std::cout << coroutine1() << std::endl;
		std::cout << coroutine2() << std::endl;
	}
}

Wynik:

1
10
2
11
3
12
4
13

On 29/01/2020 18:19, heby wrote:
> yeld( 42 );

yield oczywiście, dla czepialskich.

W dniu środa, 29 stycznia 2020 18:19:27 UTC+1 użytkownik heby napisał:
> On 29/01/2020 08:31, Maciek Godek wrote:
> > Wolę po prostu nie dokładać niepotrzebnych zależności.
> 
> Przecież własnie dołożyłeś niepotrzebną zależnośc of ficzera w kompilatorze.

Kod i tak już jest zależny od GCC, więc to bez różnicy.

> > Język C to jest technologia, i język C++ to jest inna technologia.
> 
> Język C++ to rozwinięcie jęyka C.

Nie jest, i to już od dawna.
Ze standardu C nie zadziała ci chociażby designated initializers struktur.
(I w C++20 też nie zadziała)

> Masz kiepski kod. Ten kod nazywasz "korutynami".
> 
> To nie są korutyny. W dodaku okazuje się że wymagają workaroundu aby być 
> w ogóle użyteczne do normalnego programowania, inaczej to pistolecik na 
> kapiszony. Z workaroundem to odbezpieczony granat w gaciach.

Witaj w świecie programowania w C/C++.

> > Po pierwsze, C i C++ są niekompatybilne.
> 
> Nikt tak nie twierdzi, ale śmiem twierdzić że w Twoim wypadku zmiana z 
> gcc na g++ nic nie spowoduje a może nawet pomoże (warningi, nielegalne 
> konstrukcje itd itp). Czyli są komatybilne w jedną stronę.

No wiem. Zauważyłem już, że "śmiesz twierdzić" wiele rzeczy, o których nie masz bladego pojęcia.
Ale zobaczmy.

x.c <<EOF
#include <stdio.h>

int main(int argc, const char *argv[]) {
  struct {
    int x;
    char c;
  } s = {
    .c = 'a',
    .x = 7
  };
  printf("%c%d\n", s.c, s.x);
  return 0;
}
EOF

# gcc x.c
# ./a.out
a7
# g++ x.c
x.c: In function ‘int main(int, char**)’:
x.c:10:3: sorry, unimplemented: non-trivial designated initializers not supported
   };
   ^
x.c:10:3: sorry, unimplemented: non-trivial designated initializers not supported

> > A jeżeli używam rozszerzeń GNU C
> 
> Przecież nie chcesz dodatkowych zależności, prawda?

Nie ma dodatkowych zależności. Jak pisałem, z GCC korzystam tak czy siak.

> >> nie uzywaj coroutines, użyj FreeRTOSa
> > Dokładnie tak. Zaproponowałeś wiele rozwiązań, zupełnie nie rozumiejąc uwarunkowań problemu.
> 
> a) nigdzie ich na poczatku nie było

Bo i problemu nie przedstawiałem.
Przedstawiałem pewne rozwiązanie, które jest stosowalne również poza kontekstem, w którym je sformułowałem.
Rozwiązanie oczywiście można zasadnie krytykować, ale odświeżanie starego flamewara "C vs. C++" ma umiarkowany sens.

> >> Masz dobre powody aby nie używać C++ i FreeRTOSa. Poza religią nie znam
> >> sensownych, "blog" nie pomógł w ich identyfikacji. Co robić...
> > To nie moja wina, że brakuje Ci wyobraźni.
> 
> Cały czas chcesz by Ci czytać w myślach. To nie jest możliwe.

Wystarczy, że nie będziesz proponował rozwiązań od czapy.

> >> Niemożność używania stosu. To ogranicza zastosowanie do marginalnej
> >> ilosci przypadków, w dodatku prawdopodobnie rozwiązywalnych ładniej
> >> switch/case.
> > No dobrze, to może pokaż, czego nie możesz zrobić bez stosu, a co mógłbyć zrobić, gdybyś miał korutyny ze stosem.
> 
> [...]
> yeld( 42 );
> for( i = 6 ; i < 10 ; ++i )
>     [...]
>     yeld( i );
>     [...]

Czas start.

int f(void) {
  COROUTINE_START();
  static int i;
  COROUTINE_YIELD(42);
  for (i = 6; i < 10; ++i ) {
      COROUTINE_YIELD(i);
  }
}

Hmm. Chyba wygląda dość tak samo.

> W zasadzie napisanie dowolnego nieco bardziej skomplikowanego generatora 
> wymaga natychmiast użycia workaroundu ze zmiennymi statycznymi.
> 
> PS. Zmienne statyczne tez nie są potrzebne. Wystarczy dowolny obiekt 
> trzymający stan korutyny. Zaznaczam że jest to tylko niewiele lepsze 
> rozwiązanie bo ten obiekt też musi być śledzony jeśli nie daj Panie 
> korutyny będą się przeplatać. Tak czy owak d...z tyłu.

Nadal nie podałeś żadnego przykładu.

> >>> Jeżeli chcę się komunikować z przerwania z innymi komponentami systemu, to muszę użyć zmiennej globalnej.
> >> To inny przypadek.
> > A czym się różni?
> 
> Tym że do tego systemy operacyjne wynalazły różne metody IPC ponieważ 
> jest nieuniknione.
> 
> W Twoim wypadku używanie zmiennych globalnych nie jest nieuniknione 
> tylko wynika z kiepskiej implementacji.

To pokaż mi jak przekazać informację z przerwania do procesu bez zmiennej globalnej.

> >> PS. Podpowiem Ci: Twój pomysł da się rozwiązać kilkoma makrami i
> >> ukrytymi w nich "switch/case" bez używania magicznych ficzerów
> >> kompilatora.
> > No to dajesz. Pokaż te kilka makr.
> 
> Może coś narzeźbię w wolnej chwili. Uzywałem tego przez jakiś czas z 
> miernym skutkiem i raczej nie znajduje powodów do powrotu.

Nie ma potrzeby. Już zrobiłem:

#define CO_START()                              \
  static int continuation = 0;                  \
  switch(continuation) {                        \
  case 0:

#define CO_YIELD(value)                         \
  continuation = __LINE__;                      \
  return value;                                 \
  case __LINE__:

#define CO_END() default: continuation = 0; }

On 29/01/2020 21:41, Maciek Godek wrote:
>> Przecież własnie dołożyłeś niepotrzebną zależnośc of ficzera w kompilatorze.
> Kod i tak już jest zależny od GCC, więc to bez różnicy.

Skoro tak to zmiana na g++ też jest bez różnicy.

>>> Język C to jest technologia, i język C++ to jest inna technologia.
>> Język C++ to rozwinięcie jęyka C.
> Nie jest, i to już od dawna.
> Ze standardu C nie zadziała ci chociażby designated initializers struktur.
> (I w C++20 też nie zadziała)

Czyli jednak spierasz się jak czepialski profesor. Trudno. Wdepnąłeś w 
niszowy mechanizm języka który ma odpowiednik w C++. Dług. Do spłaty 
albo do kreatywnej księgowości. Ewentualnie jak to zwykle bywa zejdzie 
wraz z kodem na śmietnik historii.

>> Masz kiepski kod. Ten kod nazywasz "korutynami".
>> To nie są korutyny. W dodaku okazuje się że wymagają workaroundu aby być
>> w ogóle użyteczne do normalnego programowania, inaczej to pistolecik na
>> kapiszony. Z workaroundem to odbezpieczony granat w gaciach.
> Witaj w świecie programowania w C/C++.

Nie nie nie, to raczej świat kwadratowych kół. Nieustannie wymyślanych 
przez programistów C.

>> Nikt tak nie twierdzi, ale śmiem twierdzić że w Twoim wypadku zmiana z
>> gcc na g++ nic nie spowoduje a może nawet pomoże (warningi, nielegalne
>> konstrukcje itd itp). Czyli są komatybilne w jedną stronę.
> No wiem. Zauważyłem już, że "śmiesz twierdzić" wiele rzeczy, o których nie masz bladego pojęcia.

Z tym pojęciem to nie masz pojęcia.

> Ale zobaczmy.

I zobaczyliśmy kod który w C++ piszę się troszkę inaczej. Spór akademicki.

>>> A jeżeli używam rozszerzeń GNU C
>> Przecież nie chcesz dodatkowych zależności, prawda?
> Nie ma dodatkowych zależności. Jak pisałem, z GCC korzystam tak czy siak.

Czli masz g++ za darmo.

>>>> nie uzywaj coroutines, użyj FreeRTOSa
>>> Dokładnie tak. Zaproponowałeś wiele rozwiązań, zupełnie nie rozumiejąc uwarunkowań problemu.
>> a) nigdzie ich na poczatku nie było
> Bo i problemu nie przedstawiałem.

Bo go pewnie nie ma.

> Przedstawiałem pewne rozwiązanie, które jest stosowalne również poza kontekstem, w którym je sformułowałem.

Strach się bać ile jeszcze problemów wymaga równie popsutych rozwiązań.

> Rozwiązanie oczywiście można zasadnie krytykować, ale odświeżanie starego flamewara "C vs. C++" ma umiarkowany sens.

Nie przypominam sobie abym go odświeżał. Stwierdziłem tylko że kod jest 
fundamentalnie niebezpieczny oraz że można znaleźc gotowe rozwiązanie w 
booscie. I nadepnąłem na odcisk. Cała reszta to tylko trolling 
wynikający ze strachu przed lekarstwem.

>> Cały czas chcesz by Ci czytać w myślach. To nie jest możliwe.
> Wystarczy, że nie będziesz proponował rozwiązań od czapy.

Chcesz mi powiedzieć że można proponować rozwiązania nie z czapy bez 
znajomości prawdziwego problemu? No, to niestety wymaga szklanej kuli.

Po drugie to popruste coroutines są z czapy bez względu na to co niby 
rozwiązują.

>> yeld( 42 );
>> for( i = 6 ; i < 10 ; ++i )
>>      [...]
>>      yeld( i );
>>      [...]
> Czas start.
> int f(void) {
>    COROUTINE_START();
>    static int i;

Jeb. Właśnie użyłeś zmiennej globalnej. Ojej. 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ć.

Łomatko, o co Ci chodzi? Zmienne statyczne w funkcjach są 
problematyczne. Twoje korutyny są problematyczne z tego powodu. To że 
się da nie oznacza że ktokolwiek przy zdrowych zmysłach tak by robił w 
kodzie produkcyjnym.

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

>> PS. Zmienne statyczne tez nie są potrzebne. Wystarczy dowolny obiekt
>> trzymający stan korutyny. Zaznaczam że jest to tylko niewiele lepsze
>> rozwiązanie bo ten obiekt też musi być śledzony jeśli nie daj Panie
>> korutyny będą się przeplatać. Tak czy owak d...z tyłu.
> Nadal nie podałeś żadnego przykładu.

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.

>> Tym że do tego systemy operacyjne wynalazły różne metody IPC ponieważ
>> jest nieuniknione.
>> W Twoim wypadku używanie zmiennych globalnych nie jest nieuniknione
>> tylko wynika z kiepskiej implementacji.
> To pokaż mi jak przekazać informację z przerwania do procesu bez zmiennej globalnej.

Nigdzie nie napisałem że robi się to bez zmiennej globalnej. Napisałem 
że OSy dają interfejsy IPC bo jest to nieuniknione.

Masz do tego rózne IPC. Od cli/sei, przez mutexy po rury. Do koloru do 
wyboru. W gruncie rzeczy one używają stanów globalnych. Tylko że 
programista jest zwolniony od tego aby to obrabiać na jakimś poziomie. 
Albo robi to samodzielnie cli/sei, albo oddaje częśc abstrakcji 
systemowi jak w muteksowaniu, albo całkiem zdaje się na OS.

Jest to nieuniknione wiec ten problem OSy jakoś starają się generycznie 
rozwiazać.

U Ciebie można tego uniknąć, ale to wymaga napisania czegoś więcej niż 
kilku prostych sztuczek z makrami. I ktoś to już napisał. Ba, napisał to 
w conajmniej kilku biblitekach.

Z resztą dlaczego mam się produkowaćw kółko?

https://en.wikipedia.org/wiki/Coroutine

"In order to implement general-purpose coroutines, a second call stack 
must be obtained, which is a feature not directly supported by the C 
language.[...]"

Jest nawet coś o Twoich wypocinach:

"[...]"As far as I know, this is the worst piece of C hackery ever seen 
in serious production code." The main shortcomings of this approximation 
are that, in not maintaining a separate stack frame for each coroutine, 
local variables are not preserved across yields from the function, it is 
not possible to have multiple entries to the function, and control can 
only be yielded from the top-level routine. "

Ale spokojnie, Oni też są tylko głupi i trolują.

>    case __LINE__:

Na marginesie: to, o ile mnie pamiec nie myli, nie zadziała z Visualem. 
Ale to naprawdę na marginesie, przecież nie chcesz generować dodatkowych 
zależności.

On Wed, 29 Jan 2020 18:19:23 +0100, heby wrote:

> do jakiś absurdalnych przypadków 8051 z kompiltorem pisanym przez 

jaki? jaki'ś
jakich? jakich'ś

Uprzedzając zarzut o nazizm gramatyczny:

>> I to zaproponowałeś, mimo że nikt Cię o to nie prosił.
> 
> Taka natura ludzka: jesli ktoś się przewróci to staram się mu pomóc.

Popieram ;-)


-- 
pozdrawiam
Roman Tyczka

W dniu środa, 29 stycznia 2020 22:25:33 UTC+1 użytkownik heby napisał:
> >> yeld( 42 );
> >> for( i = 6 ; i < 10 ; ++i )
> >>      [...]
> >>      yeld( i );
> >>      [...]
> > Czas start.
> > int f(void) {
> >    COROUTINE_START();
> >    static int i;
> 
> Jeb. Właśnie użyłeś zmiennej globalnej. Ojej. Co się 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".

> >> PS. Zmienne statyczne tez nie są potrzebne. Wystarczy dowolny obiekt
> >> trzymający stan korutyny. Zaznaczam że jest to tylko niewiele lepsze
> >> rozwiązanie bo ten obiekt też musi być śledzony jeśli nie daj Panie
> >> korutyny będą się przeplatać. Tak czy owak d...z tyłu.
> > Nadal nie podałeś żadnego przykładu.
> 
> 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.

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

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

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ące w 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ę:
https://pl.wikipedia.org/wiki/Funkcja

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

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.

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.

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ę:
> https://pl.wikipedia.org/wiki/Funkcja

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.

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.

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óry z 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ą.

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

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() i z 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:
https://www.quora.com/What-is-functional-programming/answer/Panicz-Godek

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

On 30/01/2020 00:54, Maciek Godek wrote:
>> 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()?

1 i 2. W zależności od numeru wywołania. Gdzie tu wycieka jakiś stan 
wewnetrzny? Napisałeś generator. Generator generuje. Dostałeś co 
chciałeś. W czym problem?

>> Własnie odkryłeś że funkcje pure mogą mieć mutowalne, prywatne zmienne w
>> środku i dalej być pure.
> Mylisz "funkcje pure" z hermetyzacją.

Nie, nie mylę.

Pure function [...] Its evaluation has no side effects (no mutation of 
local static variables, non-local variables, mutable reference arguments 
or I/O streams).

Nic to nie piszą o tym że nie wolno mutować lokalnych zmiennych. Ale 
spokojnie, to tylko internet, na pewno kłamią.

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

Korutyna może być pure gdy nie mutuje świata poza nią. Ale nie jest 
fukcją tylko generatorem. Czyli ma *wiele* wyjśc a nie jedno. Ot i cała 
tajemnica.

Twoje rozwiązanie ze zmiennymi statycznymi powoduje że nie jest pure. To 
nie powoduje że nie działa. To powoduje tylko tyle że jest mało 
użyteczne w świecie gdzie "pure" jest preferowane ... czyli prawie wszędzie.

> Funkcji nie da "się zatrzymać", bo ona "się nie wykonuje".
> Ona odwzorowuje wejście w wyjście,

Korutyne da się zatrzymać. Taka jej istota. Da się ją w tym stanie 
przeplatać z innymi korutynami, ba nawet tymi samymi ale pracującymi z 
innym kontekstem (w normalnych implementacjach: stosem).

I korutyna może ale nie musi zwracać nic, jedną lub wiele wartości.

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

Radze poczytać internety w kwesti co to jest pure.

Korutyna to nie jest funkcja w rozumieniu "pure function" ale moze byc 
"pure coroutine".

Twoje nie są z powodu fundamentalnego błedu implementacyjengo w jump 
oriented programming. Moje z boosta mogą, ale nie muszą być "pure". Mam 
wybór.

>> To zabawne, bo moje korutyny też nie mają. Robią yield() i z 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.

Zaś kolor niebieski jest niebieski.

> Tutaj masz, proszę, poczytaj sobie:
> https://www.quora.com/What-is-functional-programming/answer/Panicz-Godek

Mam kilka książek, niektóre nawet czytałem. Dziękuję.

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

Widzisz, problem jest w tym że jesteś czepialski i nie rozumiesz metafor.

Nie, korutyna nie jest funkcją ani nie ma obowiązku być pure.

To o co chdozi w tej dyskusji to fakt że:
a) moje korutyny mogą być bez side effectów i znimi, mam wybór
b) Twoje, z powodu dziadowskiej implementacji, mogą mieć tylko side 
effecty lub wymagają dodatkowego kodu do zarządzania ich stanem, pzoa 
tym posiadają masę wad, wszystkie wymienione na wiki.

> Pierdolić potrafi każdy.

Dlatego masz pełne prawo pisać na usenecie dowolnie bezuzyteczne kawałki 
kodu, ale musisz pamietać że reszta świata może i ma prawo a nawet 
obowiązek popukać się w czoło.

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

Napisałeś kod nazywając to "korutynami" który nie ma z nimi wiele 
wspólnego. Zostałeś nawet z tego powodu wyśmiany, jak setki przed tobą 
piszących ten sam kod, na głupiej wikipedii.

I mówisz że to co mówie nie ma sensu.

Nie miewasz przypadkiem czasem wrażenia że cały świat jest przeciwko Tobie?

> Określenie, żeby "odpalać naprzemiennie tę samą korutynę" jest całkowitą bzdurą.

Oczywiście. Dalej nie pojmujesz że istnieje coś takiego jak "kod" i 
"kontekst wywołania".

W przypadku C tym konteksem jest stos.

Nic dziwnego że tego nie widzisz, twoje korutyny to kod i kontekst 
zmielone razem w zmiennych statycznych.

> Naprzemiennie możesz odpalać dwie różne rzeczy

Widziałeś kiedyś dwa wątki pracujace na tych samych instrukcjach 
maszynowych w tej samej pamieci, RÓWNOLEGLE?

To teraz użyj wyobraźni aby sobie wyobrazić że ta sama korutyna może 
pracować na dwóch róznych kontekstach wywołania, naprzemiennie, nie 
zakłucając się. boost to potrafi. Bo używa kontekstu stosu a nie 
zmiennych statycznych.

> , a nie "dwie te same rzeczy", bo "dwie te same rzeczy" to jest jedna i ta sama rzecz.

Zgubiłem biedaku kontekst wywołania kodu i stąd te problem w pojmowaniu 
dlaczego Twoje korutyny są tylko pośmiewiskiem na wikipedii.

W dniu czwartek, 30 stycznia 2020 23:11:51 UTC+1 użytkownik heby napisał:
> On 30/01/2020 00:54, Maciek Godek wrote:
> >> 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()?
> 
> 1 i 2. W zależności od numeru wywołania. Gdzie tu wycieka jakiś stan 
> wewnetrzny?

Miejsce zatrzymania jest stanem wewnętrznym.

> Napisałeś generator. Generator generuje. Dostałeś co 
> chciałeś. W czym problem?

Udostępniłem stan wewnętrzny konsumentowi.
Nie ma problemu. Tylko to nie jest "pure function".

> >> Własnie odkryłeś że funkcje pure mogą mieć mutowalne, prywatne zmienne w
> >> środku i dalej być pure.
> > Mylisz "funkcje pure" z hermetyzacją.
> 
> Nie, nie mylę.
> 
> Pure function [...] Its evaluation has no side effects (no mutation of 
> local static variables, non-local variables, mutable reference arguments 
> or I/O streams).
> 
> Nic to nie piszą o tym że nie wolno mutować lokalnych zmiennych. Ale 
> spokojnie, to tylko internet, na pewno kłamią.

Jasne, możesz sobie robić co chcesz, jeżeli stan nie jest widoczny z zewnątrz.
A w przypadku powyższej korutyny stan jest widoczny z zewnątrz, bo albo jesteś w takim stanie, że dostaniesz 1, albo w takim, że dostaniesz 2.

> >>> 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.
> 
> Korutyna może być pure gdy nie mutuje świata poza nią. Ale nie jest 
> fukcją tylko generatorem. Czyli ma *wiele* wyjśc a nie jedno. Ot i cała 
> tajemnica.

?

Gdzie tak piszą?

> Twoje rozwiązanie ze zmiennymi statycznymi powoduje że nie jest pure. To 
> nie powoduje że nie działa. To powoduje tylko tyle że jest mało 
> użyteczne w świecie gdzie "pure" jest preferowane ... czyli prawie wszędzie.

Gdzie "pure" co jest preferowane?
"Pure mineral water"?

> > Funkcji nie da "się zatrzymać", bo ona "się nie wykonuje".
> > Ona odwzorowuje wejście w wyjście,
> 
> Korutyne da się zatrzymać. Taka jej istota. Da się ją w tym stanie 
> przeplatać z innymi korutynami, ba nawet tymi samymi ale pracującymi z 
> innym kontekstem (w normalnych implementacjach: stosem).

Dlatego nie jest "czysta" w takim sensie, w jakim "czysta funkcja" jest "czysta".

> I korutyna może ale nie musi zwracać nic, jedną lub wiele wartości.

A czysta funkcja musi zwrócić wartość.

> >> 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ć.
> 
> Radze poczytać internety w kwesti co to jest pure.

No to dajesz linki do tych swoich internetów.

> Korutyna to nie jest funkcja w rozumieniu "pure function" ale moze byc 
> "pure coroutine".

Łooo!
I pewnie może też być "pure fun".

> >> 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ę.
> 
> Widzisz, problem jest w tym że jesteś czepialski i nie rozumiesz metafor.
> 
> Nie, korutyna nie jest funkcją ani nie ma obowiązku być pure.
> 
> To o co chdozi w tej dyskusji to fakt że:
> a) moje korutyny mogą być bez side effectów i znimi, mam wybór

Nie mogą, bo yield jest side effectem. Chyba że nie jest, to wtedy nie są korutynami, tylko funkcjami.

> Nie miewasz przypadkiem czasem wrażenia że cały świat jest przeciwko Tobie?

Raczej nie.

> > Naprzemiennie możesz odpalać dwie różne rzeczy
> 
> Widziałeś kiedyś dwa wątki pracujace na tych samych instrukcjach 
> maszynowych w tej samej pamieci, RÓWNOLEGLE?
> 
> To teraz użyj wyobraźni aby sobie wyobrazić że ta sama korutyna może 
> pracować na dwóch róznych kontekstach wywołania, naprzemiennie, nie 
> zakłucając się. boost to potrafi. Bo używa kontekstu stosu a nie 
> zmiennych statycznych.

Boost potrafi. Moje rozwiązanie nie potrafi (chyba że ktoś by chciał generować ten sam kod funkcji wielokrotnie z makra, ale to średni pomysł).
Dlatego problem, że "dwie te same korutyny będą sobie nawzajem nadpisywać stan", nie może wystąpić.

On 30/01/2020 23:58, Maciek Godek wrote:
> Boost potrafi. Moje rozwiązanie nie potrafi (chyba że ktoś by chciał generować ten sam kod funkcji wielokrotnie z makra, ale to średni pomysł).
> Dlatego problem, że "dwie te same korutyny będą sobie nawzajem nadpisywać stan", nie może wystąpić.

Wiadomo, można zawsze z buga zrobić feature.

"Dzięki temu że nie działa nam w kalulatorze dodawanie masz zaletę że 
nie wiesz ile wisisz urzędowi skarbowemu".

Powodzenia!

PS. Twój kod też to może w ograniczonej formie potrafić. Dodaj kontekst 
do makr. Nie, to dalej będzie do dupy, ale zatrzyma się tylko na 
okrężnicy a nie dwunastnicy. Zawsze jakiś postęp.

W dniu piątek, 31 stycznia 2020 00:11:44 UTC+1 użytkownik heby napisał:
> On 30/01/2020 23:58, Maciek Godek wrote:
> > Boost potrafi. Moje rozwiązanie nie potrafi (chyba że ktoś by chciał generować ten sam kod funkcji wielokrotnie z makra, ale to średni pomysł).
> > Dlatego problem, że "dwie te same korutyny będą sobie nawzajem nadpisywać stan", nie może wystąpić.
> 
> Wiadomo, można zawsze z buga zrobić feature.
> 
> "Dzięki temu że nie działa nam w kalulatorze dodawanie masz zaletę że 
> nie wiesz ile wisisz urzędowi skarbowemu".
> 
> Powodzenia!
> 
> PS. Twój kod też to może w ograniczonej formie potrafić. Dodaj kontekst 
> do makr. Nie, to dalej będzie do dupy, ale zatrzyma się tylko na 
> okrężnicy a nie dwunastnicy. Zawsze jakiś postęp.

Zapomniałeś wkleić linki wyjaśniające, czym są "pure coroutines".

On 2020-03-08 22:03, heby wrote:
> On 08/03/2020 21:29, JDX wrote:
>>> Co to za argument że architektura jest "znana"? Od 40 lat
>>> większość software jest pisana w językach wysokiego poziomu.
>>> Jakim cudem argument "znamy '51" ma jakikolwiek związek z
>>> podejmowaniem decyzji współcześnie?
>> Bo zdarzają się jeszcze nieźle sprzedające się produkty na 51,
>> które zostały zaprojektowane w czasach, gdy ten rdzeń nie był
>> jeszcze przestarzały.
> 
> Czyli jakie unikatowe cechy rdzenia '51 lub peryferiów nie występują
> w ByleCzym?
No banki rejestrów i wydzielony stos raczej nie występują we
współczesnym byle czym. :-D

> Nie, to już nie jest utrzymywanie. To prosta droga do katastrofy.
Dlaczego zaraz katastrofy? Firma ma nowy produkt na nowym, zupełnie
innym MCU, ale stary produkt na 51 też (się) sprzedaje.

> Problemem nie jest pieniądź.
Ooo, na podstawie mojego doświadczenia jako klepacza kodu w tzw.
biznesie myślę, że problemem jest przede wszystkim pieniądz. Trudno mi
sobie wyobrazić użycie 51 w nowym projekcie, ale kto wie, może jakaś
firma chciałaby lekko zmodyfikować sprzęt i zrobić 51 w ASICu (+ jakiś
dodatkowy stuff) i wykorzystać istniejące oprogramowanie. Właśnie w celu
zaoszczędzenia, najprawdopodobniej krótkoterminowego.

> Od 40 lat słyszę jakie to szerokie i głębokie zalety posiada '51, ale
> jakoś bez detalicznego enumerowania tychże. O kasie nikt nie
> wspomina. Tam bez wątpienia jest jakiś inny powód, po tych wszystkich
> rozmowach dochodzę do wniosu że jest tylko jeden: religia.
Na pewno ode mnie czegoś takiego nie słyszałeś. Od dawna uważam, że 51
to padlina. Tak z 15+ lat temu na p.m.e lobbowałem za MCU na ARM. To
były czasy, gdy rodzina LPC2000 Philipsa na ARM7TDMI wchodziła pod
strzechy. Chociaż tak BTW to większy sentyment mam do H8/300H i H8S –
fajne ortogonalne CISCi.

> I potem się dziwie że na C++ w embedded przeciętny Pan Zdzisław od
> 40 lat robiący sterowiki zegarów szkolnych reaguje alergicznie. Skoro
> się nie da użyć w "najszybszym procesorze świata" to najlepiej nie
> używać wcale i nigdzie.
Na ja np. chciałbym użyć, ale nie tylko gołego C++, ale też kontenerów z
STL-a. Ale jak ich użyć, skoro nie wiem jak działają, albo może i wiem,
ale mi się to nie podoba – chodzi mi o alokację i realokację pamięci na
stercie. Rust pod tym względem jest fajny, bo specjalnie z myślą o
rzeźbiących w embedded dostarcza dwie wersje kontenerów – z pamięcią
alokowaną dynamicznie na stercie i z pamięcią alokowaną statycznie.
Oczywiście ze względu na te alokacje są pewne niuanse w ich użyciu, ale
można z tym żyć. No i wtedy jest fajnie – piszesz sobie kernel czy
drajwer bez martwienia się o alokacje, tak jakbyś pisał coś na desktopa.
A w C++ nie wiadomo jak to łatwo zrobić. Tzn. ja nie wiem. W każdym
razie jeśli już mamy być postępowi, to nie C++ tylko Rust. :-)

On 09/03/2020 02:03, JDX wrote:
>> Czyli jakie unikatowe cechy rdzenia '51 lub peryferiów nie występują
>> w ByleCzym?
> No banki rejestrów

Zerknij na FIQ na ARM.

> i wydzielony stos raczej nie występują we
> współczesnym byle czym. :-D

Bo współczesne byle co właśnie nie musi mieć sprzętowego stosu. To jest 
zaleta, że nie ma.

>> Nie, to już nie jest utrzymywanie. To prosta droga do katastrofy.
> Dlaczego zaraz katastrofy? Firma ma nowy produkt na nowym, zupełnie
> innym MCU, ale stary produkt na 51 też (się) sprzedaje.

W sensie jaka nowa technologia, projektowana na nowym ASICu ma mieć 
stary kod pisany pod '51? Bo taki target jest tego wynalazku z Bytomia.

>> Problemem nie jest pieniądź.
> Ooo, na podstawie mojego doświadczenia jako klepacza kodu w tzw.
> biznesie myślę, że problemem jest przede wszystkim pieniądz. Trudno mi
> sobie wyobrazić użycie 51 w nowym projekcie, ale kto wie, może jakaś
> firma chciałaby lekko zmodyfikować sprzęt i zrobić 51 w ASICu (+ jakiś
> dodatkowy stuff) i wykorzystać istniejące oprogramowanie. Właśnie w celu
> zaoszczędzenia, najprawdopodobniej krótkoterminowego.

A czyli w sensie zrobić taki workaround? A tak, to do tego tak. Tylko że 
w takich projetkach juz nie ma C++ z definicji. Nie zapomina że to wątek 
o C++ i w tym kontekscie się tutaj wypowiadam. '51 nie ma sensu w ogóle 
poza jakimiś iditycznymi przypadkami z okolic zapchajdziury na rynku. 
Nikt tam nie będzie narzekał na kompilator a często nie będzie narzekał 
na cokolwiek bo ma tylko wsad binarny a główny programista od 20 lat 
leży pod brzozą.

Nawet Microsoft ostatnio naprawia bugi w starym office na poziomie 
asemblera bo, prawdopodobnie, zgubili kod źródłowy. SourceSafe, hehehe.

>> I potem się dziwie że na C++ w embedded przeciętny Pan Zdzisław od
>> 40 lat robiący sterowiki zegarów szkolnych reaguje alergicznie. Skoro
>> się nie da użyć w "najszybszym procesorze świata" to najlepiej nie
>> używać wcale i nigdzie.
> Na ja np. chciałbym użyć, ale nie tylko gołego C++, ale też kontenerów z
> STL-a.

Kontenery STL -> allokacje. To zaczyan mieć sens od ARM7 a i tam nikły. 
Ja nie masz MMU/wirtualną to allokowanie jest proszeniem się o kłopoty. 
Jak masz MMU to jest proszeniem się o kłopoty tylko później. C++ w 
embedded to nie powinien być kontenerowy STL chyba że ktoś naprawdę wie 
co robi.

> A w C++ nie wiadomo jak to łatwo zrobić.

Nie robić jeśli nie jest to konieczne. Każda allokacja w embedded 
oznacza potencjalne problemy w runtime.

> razie jeśli już mamy być postępowi, to nie C++ tylko Rust. :-)

A tymczasem na całym świecie brodate inzyniery po 60tce napierniczają 
kod na '51 w popsutych kopilatorach C i gołym kodzie maszynowym 
nazywając to "stabilną platformą z doskonale znanymi narzędziami". 
Jeszcze 10 lat temu jeden student mówił że był w firmie gdzie dev na '51 
robili na MSDOSie. Tylko odlatego że jeden z "Zygmuntów" nie potrafił 
używać niczego poza CP/M, o pardon, MS-DOS. Ponoć dlatego że miał tam 
wszystko pod kontrolą. Ile w tym prawdy nie wiem, ale spotykam do 
dzisiaj dinozaury które potrafią pisać aktywnie w Delphi 1 więc się 
wcale nie zdziwie jeśli to była prawda.

W dniu poniedziałek, 9 marca 2020 19:48:34 UTC+1 użytkownik heby napisał:

> Kontenery STL -> allokacje. To zaczyan mieć sens od ARM7 a i tam nikły. 
> Ja nie masz MMU/wirtualną to allokowanie jest proszeniem się o kłopoty. 
> Jak masz MMU to jest proszeniem się o kłopoty tylko później. C++ w 
> embedded to nie powinien być kontenerowy STL chyba że ktoś naprawdę wie 
> co robi.
> 
> > A w C++ nie wiadomo jak to łatwo zrobić.
> 
> Nie robić jeśli nie jest to konieczne. Każda allokacja w embedded 
> oznacza potencjalne problemy w runtime.

A użycie boost::coroutines dokonuje alokacji, czy nie?

On 09/03/2020 21:20, Maciek Godek wrote:
> A użycie boost::coroutines dokonuje alokacji, czy nie?

Nie musi. Czy dokonuje nie wiem, pewnie tak. Ale nie ma takiego 
obowiązku, w końcu stos korutyny możesz mieć statyczny gdzieś obok, 
albo, wzorem apliakcji embedded, możesz mieć pool allokatora na te stosy 
i znany rozmiar. Więc możesz sobie napisać godek::coroutine i tam może 
nie być allokacji ale stos, czemu nie.

W dniu poniedziałek, 9 marca 2020 22:00:49 UTC+1 użytkownik heby napisał:
> On 09/03/2020 21:20, Maciek Godek wrote:
> > A użycie boost::coroutines dokonuje alokacji, czy nie?
> 
> Nie musi. Czy dokonuje nie wiem, pewnie tak.

I nadal uważasz, że unikanie C++ na rzecz C jest kwestią religii?

Sam widzisz, że - nawet jeśli mechanizmy, które oferuje C++ byłyby wygodne
(a nie są), to tworzą one barierę dla zrozumienia systemu. Model operacji C jest stosunkowo prosty, i każdy kompetentny programista powinien go rozumieć.
Natomiast model C++a jest skomplikowany, i ta komplikacja ma w dużej mierze przypadkowy charakter.

Zadaję Ci proste, fundamentalne pytanie: czy boost::coroutines, do użycia którego niedawno mnie zachęcałeś, dokonuje alokacji. Ty nie dość, że nie znasz odpowiedzi, to jeszcze nie potrafisz tego łatwo znaleźć w dokumentacji.

Wcale mnie to nie dziwi. Jeżeli uważasz, że całościowe rozumienie systemu, który się rozwija, jest "kwestią religii", niech będzie i tak. Moim zdaniem jest to raczej kwestia rozsądku i pragmatyzmu.

> Ale nie ma takiego 
> obowiązku, w końcu stos korutyny możesz mieć statyczny gdzieś obok, 
> albo, wzorem apliakcji embedded, możesz mieć pool allokatora na te stosy 
> i znany rozmiar.

Każda STLowa kolekcja daje Ci możliwość dostarczenia Twojego własnego alokatora.
Dlatego rozumując po Twojemu, powinieneś raczej zachęcać embedowców do tego, żeby grzęzli w bagnie debugowania ich własnych customowych alokatorów i hulali sobie z wesołymi alokacjami STLowych kolekcji.

> Więc możesz sobie napisać godek::coroutine i tam może 
> nie być allokacji ale stos, czemu nie.

Te Twoje rady są coraz lepsze. To, skoro "mogę sobie napisać" (bo to takie łatwe?), może pokaż mi, jak taka implementacja mogłaby wyglądać.

Chętnie się dowiem.

On 10/03/2020 09:22, Maciek Godek wrote:
>> On 09/03/2020 21:20, Maciek Godek wrote:
>>> A użycie boost::coroutines dokonuje alokacji, czy nie?
>> Nie musi. Czy dokonuje nie wiem, pewnie tak.
> I nadal uważasz, że unikanie C++ na rzecz C jest kwestią religii?

Tak. Coroutines wymagaja stosu, chyba że ktoś wymyślił taki pistolet na 
wodę jak Ty. Tak czy siak musisz ten stos dostarczyć. Czy to C++ czy C 
jest drugorzędne. To czy przez allokacje czy przez statyczny zbiór 
bajtów też jest drugorzędne. Problemem Twoich coroutines jest to że nie 
mają stosu, bo są h..owe. Zrób żeby miały i okaże się że dyskusja o C++ 
nie ma z nimi związku.

Więc jeszcze raz dla wyjaśnienia:

a) masz h.ową implementację coroutines i nie ma to związku z językiem

b) przypadkiem pojawił się temat czy C++ czy C który nie ma sensu do 
analizy na tle corountines

c) "masz swoje powody" których do dzisiaj nie poznaliśmy.

> Sam widzisz, że - nawet jeśli mechanizmy, które oferuje C++ byłyby wygodne
> (a nie są), to tworzą one barierę dla zrozumienia systemu.

Nie. Uzywasz wysokopoziomowego boost::coroutine, który nie dość że jest 
jest w C++ to jeszcze używa ficzerów OS niedostepnych na 
mikrokontorlerach. Dyskutujesz w złym branchu wątku. Widać masz jakiś 
kłopot w udowanianiu swoich racji skoro wyskoczyłeś nagle w środku 
marudzenia o PICach.

> Model operacji C jest stosunkowo prosty, i każdy kompetentny programista powinien go rozumieć.

Więc jesteś dzieciakiem wyznającym zasadę że najlepszą abstrakcją jest 
brak abstrakcji i napierniczanie w asm. Tak widać wszystko i łatwo 
zrozumieć. Tylko czy na pewno o to chodzi w programowaniu czeoś więcej 
niż hello worldy.

> Natomiast model C++a jest skomplikowany, i ta komplikacja ma w dużej mierze przypadkowy charakter.

Model coroutines jest boosta. Napisz sobie inny model, nazwij go, wystaw 
na githubie i tyle. Moze znajdziesz go za 30 lat w standardzie C60 gdzie 
uratuje życie ludziom mrugającym dwoma diodami na raz.

> Zadaję Ci proste, fundamentalne pytanie: czy boost::coroutines, do użycia którego niedawno mnie zachęcałeś, dokonuje alokacji. Ty nie dość, że nie znasz odpowiedzi, to jeszcze nie potrafisz tego łatwo znaleźć w dokumentacji.

Ale ja tego nie muszę wiedzieć. Na tym polega, misiaczku złoty, 
abstrakcja. NIE musisz znać detali implementacyjnych jesli interfejs 
jest zdefiniowany. I po drugie: możesz sobie te detale podmienić jak Ci 
nie pasują. Chcesz coroutines bez allokacji. To sobie napisz. Interfejs 
do nich jest prosty i przejrzysty, implementację możesz napisać na 
makrach, h.. to kogo obchodzi.

> Wcale mnie to nie dziwi. Jeżeli uważasz, że całościowe rozumienie systemu, który się rozwija, jest "kwestią religii", niech będzie i tak. Moim zdaniem jest to raczej kwestia rozsądku i pragmatyzmu.

Wiadomo. Pisz wszystko w asm. Tam nie ma miejsca na nierozumienie. Co 
bardziej zaawansowani potrafią nawet migać diodą.

>> Ale nie ma takiego
>> obowiązku, w końcu stos korutyny możesz mieć statyczny gdzieś obok,
>> albo, wzorem apliakcji embedded, możesz mieć pool allokatora na te stosy
>> i znany rozmiar.
> Każda STLowa kolekcja daje Ci możliwość dostarczenia Twojego własnego alokatora.

Myslisz że zmiana allokatora z malloc na swój zmienia jakoś zasadniczo 
problem fragmentacji pamięci? Programy w embedded często nie allokują 
wcale. Ale to nie przeszkadza mieć porządnie zrobionych coroutines ze 
stosem zamiast pistoleciku na wodę z makrami i switch case.

> Dlatego rozumując po Twojemu, powinieneś raczej zachęcać embedowców do tego, żeby grzęzli w bagnie debugowania ich własnych customowych alokatorów i hulali sobie z wesołymi alokacjami STLowych kolekcji.

Wręcz odwrotnie, namawiam embedowców aby używali C++ ale NIE używali 
STL. Od samego początku. Problemem nie jest *swój* allkokator. Problemem 
jest allokator w ogóle.

>> Więc możesz sobie napisać godek::coroutine i tam może
>> nie być allokacji ale stos, czemu nie.
> Te Twoje rady są coraz lepsze. To, skoro "mogę sobie napisać" (bo to takie łatwe?), może pokaż mi, jak taka implementacja mogłaby wyglądać.

Ile płacisz?

> Chętnie się dowiem.

Istnieją inne drogi poznania niż trolowanie.

W dniu wtorek, 10 marca 2020 20:28:55 UTC+1 użytkownik heby napisał:

> > Model operacji C jest stosunkowo prosty, i każdy kompetentny programista powinien go rozumieć.
> 
> Więc jesteś dzieciakiem wyznającym zasadę że najlepszą abstrakcją jest 
> brak abstrakcji i napierniczanie w asm.

?
Gdzie napisałem, żeby "napierniczać w asm"?
Abstrakcje w C są dobrze dobrane do zadań, do których używa się C.

Może niektóre rzeczy na niektórych architekturach są zrypane (np. konwencja wywołań na x86), ale to nie ma większego związku z językiem.

Natomiast abstrakcje w C++ są równie złe do programowania niskopoziomowego, jak i wysokopoziomowego.

> > Zadaję Ci proste, fundamentalne pytanie: czy boost::coroutines, do użycia którego niedawno mnie zachęcałeś, dokonuje alokacji. Ty nie dość, że nie znasz odpowiedzi, to jeszcze nie potrafisz tego łatwo znaleźć w dokumentacji.
> 
> Ale ja tego nie muszę wiedzieć. Na tym polega, misiaczku złoty, 
> abstrakcja.

Jeżeli chcesz tego użyć na systemie embedded, to musisz.
Na tym polega, misiaczku złoty, życie.

> > Wcale mnie to nie dziwi. Jeżeli uważasz, że całościowe rozumienie systemu, który się rozwija, jest "kwestią religii", niech będzie i tak. Moim zdaniem jest to raczej kwestia rozsądku i pragmatyzmu.
> 
> Wiadomo. Pisz wszystko w asm. Tam nie ma miejsca na nierozumienie. Co 
> bardziej zaawansowani potrafią nawet migać diodą.

Nie wiem skąd Ci strzelił ten asm.
Asembler jest złą abstrakcją, bo mocno utrudnia przenośność programów pomiędzy procesorami.

> > Dlatego rozumując po Twojemu, powinieneś raczej zachęcać embedowców do tego, żeby grzęzli w bagnie debugowania ich własnych customowych alokatorów i hulali sobie z wesołymi alokacjami STLowych kolekcji.
> 
> Wręcz odwrotnie, namawiam embedowców aby używali C++ ale NIE używali 
> STL.

Czyli, namawiasz żeby używali C++, ale żeby nie używali C++?

On 10/03/2020 22:59, Maciek Godek wrote:
> Abstrakcje w C są dobrze dobrane do zadań, do których używa się C.

C nie ma abstrakcji poza void*. I każdy język o silnych typach będzie od 
C lepszy. Nawet głupi Pascal. Nic tam nie jest do niczego dobrane, C to 
taki jezyk ktory miał zastąpić BCPL. I nagle różne Maćki dorabiają do 
tego filozofie, że niby coś zaprojektowane albo że dobranie. Nie. To 
tylko jezyk zastępujący BCPL.

> Może niektóre rzeczy na niektórych architekturach są zrypane (np. konwencja wywołań na x86), ale to nie ma większego związku z językiem.
> Natomiast abstrakcje w C++ są równie złe do programowania niskopoziomowego, jak i wysokopoziomowego.

To twierdzenie jest o tyle głupie że C++ ma takie same abstrakcjie jak 
duże języki (klasy, obiekty, interfejsy) i jednoczesnie kontrole 
niskopopziomową z C. Połaczono zalety pisania niskopoziomowego z 
abstrakcją w jednym jezyku. Niczego istotnego z C nie zabrano, więc jest 
równie dobry jak C + dodatkowe zalety.

>> Ale ja tego nie muszę wiedzieć. Na tym polega, misiaczku złoty,
>> abstrakcja.
> Jeżeli chcesz tego użyć na systemie embedded, to musisz.

Nikt, potwórzę, nikt nie pisał nic w tym wątku o używaniu coroutines w 
systemie embedded. Złapałeś się tej możliwosci jak brzytwy bo udowania 
tezę że gówniany kawałek kodu może być przydatny bo i hardware jest 
gówniany. No, tak bywa, zapytaj jakieś gówno piszą chłopaki od '51, u 
nich kod wygląda często jak zawartość szamba.

> Na tym polega, misiaczku złoty, życie.

Nie, na tym polega usilnie szukanie zastosowań Twójego gównianego 
kawałka kodu który jest gówniany z definicji, wliczając w to rechot 
rezty świata na wiki.

> Nie wiem skąd Ci strzelił ten asm.

Bo C to taki abstrakcyjny asembler.

> Asembler jest złą abstrakcją, bo mocno utrudnia przenośność programów pomiędzy procesorami.

No dostrzegasz ironii?

>> Wręcz odwrotnie, namawiam embedowców aby używali C++ ale NIE używali
>> STL.
> Czyli, namawiasz żeby używali C++, ale żeby nie używali C++?

Masz problem w pojmowaniu że C++ to kilka róznych koncepcji i nie ma 
obowiązku używać wszystkich. Cóż, trudno. Jak już pisałem na sali zawsze 
znajdzie się ktoś kto wypluje płuca krzycząc że trzeba robić new bo 
inaczej to nie C++. Nie, nie trzeba i dalej to jest C++. Jesteś 
niereformowalny, ale nie przejmuj się nie odstajesz w znacznym stopniu 
od hackerów poupychanych po firmach embedded. Im też się wydaje że od 
C++ krowy mleka nie dają.

W dniu środa, 11 marca 2020 07:12:26 UTC+1 użytkownik heby napisał:
> On 10/03/2020 22:59, Maciek Godek wrote:
> > Abstrakcje w C są dobrze dobrane do zadań, do których używa się C.
> 
> C nie ma abstrakcji poza void*.

Mechanizmy abstrakcji w C:
- funkcje
- makra
- typy uzytkownika (struktury, unie, wyliczenia)
- wskazniki na typy konkretne
- wskazniki na funkcje

> Nikt, potwórzę, nikt nie pisał nic w tym wątku o używaniu coroutines w 
> systemie embedded.

Ja pisałem o tym od początku.

> > Na tym polega, misiaczku złoty, życie.
> 
> Nie, na tym polega usilnie szukanie zastosowań Twójego gównianego 
> kawałka kodu który jest gówniany z definicji, wliczając w to rechot 
> rezty świata na wiki.

Tzn. na tym, że rozumiem, jak działa to, czego używam?

> > Nie wiem skąd Ci strzelił ten asm.
> 
> Bo C to taki abstrakcyjny asembler.

Argumentum ad sloganum?

> > Asembler jest złą abstrakcją, bo mocno utrudnia przenośność programów pomiędzy procesorami.
> 
> No dostrzegasz ironii?

?

> >> Wręcz odwrotnie, namawiam embedowców aby używali C++ ale NIE używali
> >> STL.
> > Czyli, namawiasz żeby używali C++, ale żeby nie używali C++?
> 
> Masz problem w pojmowaniu że C++ to kilka róznych koncepcji i nie ma 
> obowiązku używać wszystkich.

"Kilka" to lekkie niedoszacowanie.

Ale właśnie sęk w tym, że zawsze znajdzie się w internecie jakiś czesiek, który będzie udowadniał innym, że technologia, której używają, jest zacofana, bo nie jest technologią, której on używa.
A jak mu wykażą, że ta ich technologia jest adekwatna do problemów, które rozwiązują, to się zacznie gimnastykować, że jego technologia też tak potrafi, tylko nie można używać tego, śmego i owego.

W dniu środa, 11 marca 2020 07:12:26 UTC+1 użytkownik heby napisał:
> Nic tam nie jest do niczego dobrane, C to 
> taki jezyk ktory miał zastąpić BCPL. I nagle różne Maćki dorabiają do 
> tego filozofie, że niby coś zaprojektowane albo że dobranie. Nie. To 
> tylko jezyk zastępujący BCPL.

Tutaj jest bardzo piękna opowieść o tym, jak powstał język C, z samego źródła:
https://www.youtube.com/watch?v=EY6q5dv_B-o
(okolice 40-50 minuty)

Przede wszystkim C powstał jako język do napisania przenośnego UNIXa.
Ken Thompson otwarcie przyznaje, że nie był w stanie tego zrobić (choć trzykrotnie próbował), dopóki Dennis Ritchie nie dodał do języka B struktur.

I tyle z opowieści. Język C nie miał "nic zastępować", tylko miał służyć pewnemu konkretnemu celowi.

> To twierdzenie jest o tyle głupie że C++ ma takie same abstrakcjie jak 
> duże języki (klasy, obiekty, interfejsy) i jednoczesnie kontrole 
> niskopopziomową z C. Połaczono zalety pisania niskopoziomowego z 
> abstrakcją w jednym jezyku. Niczego istotnego z C nie zabrano, więc jest 
> równie dobry jak C + dodatkowe zalety.

Cóż, w moim doświadczeniu C++ łączy raczej wady pisania niskopoziomowego (segmentation fault i undefined behavior) z nieergonomicznymi interfejsami biblioteki standardowej i nadmiernie skomplikowaną składnią (template disambiguator for dependend names? naprawdę?) i semantyką (glvalue reference? prvalue reference? xvalue reference? poważnie?).

No, ale to tylko moje doświadczenie. Jak lubisz, to sobie używaj.

W dniu środa, 11 marca 2020 12:45:14 UTC+1 użytkownik Maciek Godek napisał:

> > To twierdzenie jest o tyle głupie że C++ ma takie same abstrakcjie jak 
> > duże języki (klasy, obiekty, interfejsy) i jednoczesnie kontrole 
> > niskopopziomową z C. Połaczono zalety pisania niskopoziomowego z 
> > abstrakcją w jednym jezyku. Niczego istotnego z C nie zabrano, więc jest 
> > równie dobry jak C + dodatkowe zalety.

Trochę też można to porównać do Ferrari, na siedzeniu którego leży gówno.
Rzeczywiście, Ferrari z gównem w środku ma takie same możliwości, jak Ferrari bez gówna + dodatkowe walory.

Jednak, jeżeli idzie o mnie, raczej bym wolał wariant bez gówna.

2020-03-11 o 04:45 -0700, Maciek Godek napisał:
> Jak lubisz, to sobie używaj.

I w zasadzie na tym możnaby zakończyć ten wątek. :)

My "wiemy", że C jest lepsze bo jest proste i przejrzyste bez żadnych
wodotrysków przez które człowiek gubi się w tym co tak naprawdę się
dzieje, a heby "wie" że C++ posiada trylion wynalazków których nie
potrzeba na nowo wymyślać i dlatego jest lepszy, a rozumieć jak co
działa nie ma potrzeby bo od tego są interfejsy by ukrywać detale
implementacji.

Oba obozy mogą się tak sprzeczać w nieskończoność... Tylko czy to ma
sens? Wszak o gustach się nie dyskutuje, a cała polemika "C vs C++"
rozbija się właśnie o gust (oraz poniekąd o sposób myślenia czy ogólniej
podejście do życia). Tak czy siak - nikt nikogo tu nie przekona.

Mateusz

On 11/03/2020 07:42, Maciek Godek wrote:
>>> Abstrakcje w C są dobrze dobrane do zadań, do których używa się C.
>> C nie ma abstrakcji poza void*.
> Mechanizmy abstrakcji w C:
> - funkcje

Są w C++.

> - makra

Są w C++.

> - typy uzytkownika (struktury, unie, wyliczenia)

Są w C++, tylko tam są na serio.

> - wskazniki na typy konkretne

Są w C++, tylko tam są na serio.

> - wskazniki na funkcje

Są w C++ tylko tam są na serio.

Natomaist C++ dodaje Ci masę innych rzeczy to tych pseudo abstrakcji. 
Między innymi dodaje prawdziwe abstrakcje takie jak szablony.

Można oczywiście bredzić o tym że funkcja to taki rodzaj abstrakcji. W 
zasadzie za chwile dolecisz to debilnego wniosku że asembler jest 
abstrakcyjny bo ma rejestry i jsr. Daj se spokój.

>> Nikt, potwórzę, nikt nie pisał nic w tym wątku o używaniu coroutines w
>> systemie embedded.
> Ja pisałem o tym od początku.

Nie, Ty miałeś "swoje powody" których nie dało się wydobyć siłą i długo 
trwało zanim objawiłeś światu co ch... komu popsuty kod.

>> Nie, na tym polega usilnie szukanie zastosowań Twójego gównianego
>> kawałka kodu który jest gówniany z definicji, wliczając w to rechot
>> rezty świata na wiki.
> Tzn. na tym, że rozumiem, jak działa to, czego używam?

Ależ masz prawo używać. Jęsli migasz dwiema diodami to przyda się jak 
znalazł.

>>> Nie wiem skąd Ci strzelił ten asm.
>> Bo C to taki abstrakcyjny asembler.
> Argumentum ad sloganum?

Nie, tak wygladały początki Unixa. Mieli do dyspozycji albo assembler 
albo cokoliwek milimter wyżej. I po kilku próbach narodził się C. Jest 
milimetr wyżej. Główna róznica jest taka że ma inne (więcej) typy danych 
niż BCPL. Cała reszta to nieistotne duperele. C powstał po to aby pisać 
bardziej abstrakcyjnie jądra unixa. Nie interesował ich stowrzenie 
języka bezpiecznego, wygodnego, czytelnego. Chodziło o napierniczanie w 
czymś choć odrobinę lepszym niż asm. Cały jezyk C to takie popłuczyny po 
asm. To całe i++ wszak żywcem wyjęte z kilku architektur cpu.

>>> Asembler jest złą abstrakcją, bo mocno utrudnia przenośność programów pomiędzy procesorami.
>> No dostrzegasz ironii?
> ?

Nie dostrzegasz.

>>>> Wręcz odwrotnie, namawiam embedowców aby używali C++ ale NIE używali
>>>> STL.
>>> Czyli, namawiasz żeby używali C++, ale żeby nie używali C++?
>> Masz problem w pojmowaniu że C++ to kilka róznych koncepcji i nie ma
>> obowiązku używać wszystkich.
> "Kilka" to lekkie niedoszacowanie.

Kilka w zastosowaniach embedded. Silne typy, RAII, szablony. Na początek 
wystarczy.

> Ale właśnie sęk w tym, że zawsze znajdzie się w internecie jakiś czesiek

Sebastian.

>, który będzie udowadniał innym, że technologia, której używają, jest zacofana, bo nie jest technologią, której on używa.

Wiadomo, Twój punkt widzenia jest bardziej obiektywny bo jest bardziej 
subiektywny, najmojszy. Zrobisz karierę w polityce.

> A jak mu wykażą, że ta ich technologia jest adekwatna do problemów, które rozwiązują

Ale ty dopiero po solidnym pieprzenięciu w głowę argumentacją wymyśliłeś 
sobie że to ma zastosowanie w jakimś marginalnym, niszowym embedded w 
którym i tak pewnie tego nikt nie robi czegoś równie bez sensu nawet 
majac 60+. Co i tak do dzisiaj traktuje jako wymówkę.

Masz straszne parcie na udowodnienie światu że te dziadowskie korutyny 
mają sens. Sorry, nie mają, tak ogólnie. Jeśli pytałeś czy mozna za 
pomocą kilku mark migać didoami to tak, można. Jesli pytałeś czy te 
korutyny nadają się do czegkolwiek innego to nie, nie nadają się. bez 
względu na to czy napisałeś je w C czy C++. Są do dupy całkiem obiektywnie.

On 11/03/2020 12:45, Maciek Godek wrote:
> I tyle z opowieści. Język C nie miał "nic zastępować", tylko miał służyć pewnemu konkretnemu celowi.

Nie, nie masz chyba jednak pojęcia po co męczono się z BCPL, B i C. 
Męczono się bo pisanie kernela w asm przestało mieć sens.

https://en.wikipedia.org/wiki/C_(programming_language)

Ich jedynym zadaniem było przeportowanie kernela. W tym celu zrobili 
sobie lepszy asembler wysokiego poziomu bo inny asembler (BCPL) był 
idiotyczny z uwagi na absurdalne ograniczenia.

Moża dorabiać filozofie. Ale niestety, uzywasz narzędzia które powstało 
do zastapienia asm i tylko przypadkiem, z uwagi na bliskośc tego asm, 
napisano w nim te biliardy lini kodu, z niejasnej przyczyny. Prawie 
wszystko w informatyce nie ma sensu lub jest dziełem przypadku. Nie ma 
co dorabiać filozofii, C jerst rodzajem asemblera który automatyzuje 
pewne rzeczy ale daje bezpośredni dostęp do wszystkiego co asembler.

> Cóż, w moim doświadczeniu C++ łączy raczej wady pisania niskopoziomowego (segmentation fault i undefined behavior)

Których używasz w C.

> z nieergonomicznymi interfejsami biblioteki standardowej

Których nie musisz używać.

> i nadmiernie skomplikowaną składnią (template disambiguator for dependend names? naprawdę?)

Których nie musisz używac, ponadto jeśli Twój ostatni kompialtor C++ 
jest z zeszłego wieku to się trudno dziwić, dzisiaj komunikaty błedów sa 
czytelne całkiem do rzeczy.

> i semantyką (glvalue reference? prvalue reference? xvalue reference? poważnie?).

Widzisz, one wszystkie powstają po to aby udoskonalić jakość kodu, w tym 
usunąć castowanie wszystkeogo na void* które jest taką ukochaną 
abstrakcją wielu piszących w C. Możesz nie pojmować po co są jakieś 
konstrukcje w C++. Masz prawo nie rozumieć zamysłu twórców. Trudno. Nie 
każdy *powinien* pisać w C++. Rynek aplikacji migania dwoma diodami jest 
ciągle spory.

> No, ale to tylko moje doświadczenie.

Idę o zakłąd że nie masz nawet śladu doświadczenia z C++. Być może 
trafiłeś na zespół dyletantów i stąd fobie. Przeciwne twierdzenie za 
3...2...1...

> Jak lubisz, to sobie używaj.

Nie mam wyjścia. Jeśli mam bilardy lini kodu to wole je mieć w C++ niż w 
asm, pardon, C. Wolałbym mieć je w czym innym, ale to nie ode mnie już 
zależy.

On 11/03/2020 14:09, Maciek Godek wrote:
>>> To twierdzenie jest o tyle głupie że C++ ma takie same abstrakcjie jak
>>> duże języki (klasy, obiekty, interfejsy) i jednoczesnie kontrole
>>> niskopopziomową z C. Połaczono zalety pisania niskopoziomowego z
>>> abstrakcją w jednym jezyku. Niczego istotnego z C nie zabrano, więc jest
>>> równie dobry jak C + dodatkowe zalety.
> Trochę też można to porównać do Ferrari, na siedzeniu którego leży gówno.

Nie, to raczej porównanie do Malucha. C++ to taki Maluch opakowany w 
masę poduszek i domalowany na zewnątrz jak Ferrari. I co gorsza wygrywa 
niektóre wyścigi z prawdzimym Ferrari. Kierowcy normalnych Maluchów 
strzelają focha i regulują zaplon.

> Jednak, jeżeli idzie o mnie, raczej bym wolał wariant bez gówna.

Niezupełnie, Twój warian to własne gówno w postaci korutyn, bez stosu, 
na makrach. Prawda jest taka, drogi misiaczku, że NAWET doświadczony 
programista C pogonił by Cie za to kijem na code review. Wiem, bo 
pytałem. Nawet programiści C kreślą pewną granicę dziadostwa której nie 
przekraczają.

Masz hiper ważny powód aby obronić te makra. Ponieważ argumenty 
metrytoryczne się wyczerpały (z uwagi na ich niebycie) to teraz już 
tylko zwykły trolling. Masz ochotę na więcej czy zajmiesz się kwarantanną?

On 11/03/2020 15:00, Mateusz Viste wrote:
>Tak czy siak - nikt nikogo tu nie przekona.

Dyskusja o C++ to tylko taki wabik. Tak naprawdę Maćkowi chodzi o to aby 
ktoś w końcu te makra przytulił, pogłaskał i powiedział "już, już 
dobrze, Ci źli hejterzy się przyczepili tylko, jesteście śliczne". Nie 
widzę jednak za dużo obrońców, wiec moze niech się ktos zlituje to 
zakonczymy dyskutowanie.

W dniu środa, 11 marca 2020 18:37:11 UTC+1 użytkownik heby napisał:
> On 11/03/2020 07:42, Maciek Godek wrote:
> >>> Abstrakcje w C są dobrze dobrane do zadań, do których używa się C.
> >> C nie ma abstrakcji poza void*.
> > Mechanizmy abstrakcji w C:
[...]
> Natomaist C++ dodaje Ci masę innych rzeczy to tych pseudo abstrakcji. 
> Między innymi dodaje prawdziwe abstrakcje takie jak szablony.
> 
> Można oczywiście bredzić o tym że funkcja to taki rodzaj abstrakcji.

"Bredzić"?
Funkcja i abstrakcja to w zasadzie synonimy.
(Inna rzecz, że funkcje w C - i za nim C++ - są "koślawymi abstrakcjami", podobnie jak enumy i unie. Ale w C są koślawe z uzasadnieniem)

> >, który będzie udowadniał innym, że technologia, której używają, jest zacofana, bo nie jest technologią, której on używa.
> 
> Wiadomo, Twój punkt widzenia jest bardziej obiektywny bo jest bardziej 
> subiektywny, najmojszy.

Nie jest. To nie ja wyskakuję ze stwierdzeniami typu "po co używać C, jak jest C++" albo "używanie C w obliczu istnienia C++ może mieć wyłącznie podłoże religijne".

Jak mówię, jeśli lubisz, to sobie pisz w C++.
Ja zaprezentowałem coś tam dla języka C. To są różne języki.

> > A jak mu wykażą, że ta ich technologia jest adekwatna do problemów, które rozwiązują
> 
> Ale ty dopiero po solidnym pieprzenięciu w głowę argumentacją wymyśliłeś 
> sobie że to ma zastosowanie w jakimś marginalnym, niszowym embedded

?

Rozwiązanie wymyśliłem właśnie w kontekście systemu embedded, i problemu, jaki tam miałem. I w tamtym kontekście sprawdza się wystarczająco dobrze.


> Masz straszne parcie na udowodnienie światu że te dziadowskie korutyny 
> mają sens. Sorry, nie mają, tak ogólnie.

Nie mam żadnego parcia. W tym temacie powiedziałem wszystko, co miałem do powiedzenia. To Ty się na tym jakoś zafiksowałeś.

> > I tyle z opowieści. Język C nie miał "nic zastępować", tylko miał służyć pewnemu konkretnemu celowi.
> 
> Nie, nie masz chyba jednak pojęcia po co męczono się z BCPL, B i C. 
> Męczono się bo pisanie kernela w asm przestało mieć sens.
> 
> https://en.wikipedia.org/wiki/C_(programming_language)

Łał, umiesz wklejać linki do Wikipedii.

> Ich jedynym zadaniem było przeportowanie kernela. W tym celu zrobili 
> sobie lepszy asembler wysokiego poziomu bo inny asembler (BCPL) był 
> idiotyczny z uwagi na absurdalne ograniczenia.

?

Nie wiem, skąd sobie wyssałeś taką teorię.

> > Cóż, w moim doświadczeniu C++ łączy raczej wady pisania niskopoziomowego (segmentation fault i undefined behavior)
> 
> Których używasz w C.

Który przynajmniej nie udaje, że jest czymś więcej, niż jest.

> > z nieergonomicznymi interfejsami biblioteki standardowej
> 
> Których nie musisz używać.

Otóż to jest sedno wszystkiego. Nie muszę i nie używam.


> > i semantyką (glvalue reference? prvalue reference? xvalue reference? poważnie?).
> 
> Widzisz, one wszystkie powstają po to aby udoskonalić jakość kodu

One powstają dlatego, że czasem coś się komuś przywidzi, i będzie bił pianę dostatecznie energicznie, żeby weszło do standardu.

> > No, ale to tylko moje doświadczenie.
> 
> Idę o zakłąd że nie masz nawet śladu doświadczenia z C++.

Ktoś mnie kiedyś o to zapytał, i opisałem:
https://www.quora.com/What-is-your-experience-related-to-learning-C/answer/Panicz-Godek

(a Ty przegrałeś zakład)

> > Jak lubisz, to sobie używaj.
> 
> Nie mam wyjścia. Jeśli mam bilardy lini kodu to wole je mieć w C++ niż w 
> asm, pardon, C. Wolałbym mieć je w czym innym, ale to nie ode mnie już 
> zależy.

Dlaczego nie od Ciebie?

> >>> To twierdzenie jest o tyle głupie że C++ ma takie same abstrakcjie jak
> >>> duże języki (klasy, obiekty, interfejsy) i jednoczesnie kontrole
> >>> niskopopziomową z C. Połaczono zalety pisania niskopoziomowego z
> >>> abstrakcją w jednym jezyku. Niczego istotnego z C nie zabrano, więc jest
> >>> równie dobry jak C + dodatkowe zalety.
> > Trochę też można to porównać do Ferrari, na siedzeniu którego leży gówno.
> 
> Nie, to raczej porównanie do Malucha. C++ to taki Maluch opakowany w 
> masę poduszek i domalowany na zewnątrz jak Ferrari.

To nie miała być metafora, tylko analogia, która pokazuje, że rozumowanie postaci "Y ma wszystko to samo, co X plus coś jeszcze, więc jest co najmniej równie dobre jak X" jest wadliwe.

Jeżeli C albo C++ byłoby Maluchem, to nie wiem, czym miałoby być owo Ferrari.

> > Jednak, jeżeli idzie o mnie, raczej bym wolał wariant bez gówna.
> 
> Niezupełnie, Twój warian to własne gówno w postaci korutyn, bez stosu, 
> na makrach. Prawda jest taka, drogi misiaczku, że NAWET doświadczony 
> programista C pogonił by Cie za to kijem na code review. Wiem, bo 
> pytałem. Nawet programiści C kreślą pewną granicę dziadostwa której nie 
> przekraczają.

A ci programiści, których pytałeś, to jakie systemy zbudowali?

I jakie alternatywy proponowali dla rozwiązania tego problemu?

Zresztą programowanie jednak ma to do siebie, że jest mocno subiektywne, i różni ludzie mają różne style. Na przykład gość, który określił to rozwiązanie "worst piece of C hackery", sam zastosował je w swoim kodzie.

Bo najwidoczniej alternatywy były jeszcze gorsze.

> Masz hiper ważny powód aby obronić te makra.

Jaki niby mam powód?

> On 11/03/2020 15:00, Mateusz Viste wrote:
> >Tak czy siak - nikt nikogo tu nie przekona.
> 
> Dyskusja o C++ to tylko taki wabik. Tak naprawdę Maćkowi chodzi o to aby 
> ktoś w końcu te makra przytulił, pogłaskał i powiedział "już, już 
> dobrze, Ci źli hejterzy się przyczepili tylko, jesteście śliczne". 

Jest dokładnie przeciwnie. Rozwiązanie zostało już skrytykowane, nawet przeze mnie samego, i nie mam w tym temacie już nic więcej do dodania.

To Ty twierdzisz, że jeżeli ktoś preferuje C nad C++ to jego powody są natury religijnej. Ja tak nie uważam. Może w dużej mierze jest to kwestia osobistych preferencji - i pod tym względem zgadzam się z Mateuszem.
Tym niemniej, C++ jest obiektywnie bardziej skomplikowany niż C. Istnieją języki, które są mniej komplikowane od C++ i jednocześnie potężniejsze od niego (chociażby Scheme). Ale to nie znaczy, że do wszystkiego nadają się lepiej.

W każdym razie zgadzam się ze stwierdzeniem JDX, że jeżeli ktoś miałby brać bezpieczeństwo swojego kodu na serio, to raczej powinien się zastanowić nad Rustem, niż nad C++ (w którym można zrobić każdą tę samą głupotę, co w C, plus jeszcze sporo nowych głupot).

On Wednesday, March 11, 2020 at 9:35:43 PM UTC+1, Maciek Godek wrote:
(...)

Pozwolę sobie wtrącić swoje trzy grosze w tą ciekawa dyskusję, 
jako programista C a czasem C++ z przyuczenia :)

> > > Jednak, jeżeli idzie o mnie, raczej bym wolał wariant bez gówna.
> > 
> > Niezupełnie, Twój warian to własne gówno w postaci korutyn, bez stosu, 
> > na makrach. Prawda jest taka, drogi misiaczku, że NAWET doświadczony 
> > programista C pogonił by Cie za to kijem na code review. Wiem, bo 
> > pytałem. Nawet programiści C kreślą pewną granicę dziadostwa której nie 
> > przekraczają.
> 
> A ci programiści, których pytałeś, to jakie systemy zbudowali?
> 
> I jakie alternatywy proponowali dla rozwiązania tego problemu?
> 
> Zresztą programowanie jednak ma to do siebie, że jest mocno subiektywne, i różni ludzie mają różne style. Na przykład gość, który określił to rozwiązanie "worst piece of C hackery", sam zastosował je w swoim kodzie.
> 
> Bo najwidoczniej alternatywy były jeszcze gorsze.
> 
 IMHO dyskusja C vs C++ nie powinna abstrahować od platformy na jakiej
uruchamiany jest program. W tzw. embedded oryginalny problem rozwiązany jest przez OS-a a raczej RTOS-a z standardowym mechanizmem pracy współbieżnej tj.
IRQ -> ISR -> DSR -> Thread bez względu na to czy jest to C czy C++.

 Taką implementacje korutyn na preprocesorze natychmiast wyrzuciłbym do śmietnika natomiast propozycje użycia boosta na uC z 128 kB RAM-u tez wyrzuciłem do śmietnika. Na platformie, której używam (uC 128 kB RAM, 1MB Flash) RTOS + C jest całkowicie wystarczające i wygodne (zgodnie z radą programisty C++).
BTW. kernel i okolice używanego RTOS-a są napisane w C++.

On Friday, March 13, 2020 at 1:12:44 AM UTC+1, Maciek Godek wrote:
> W dniu czwartek, 12 marca 2020 20:17:25 UTC+1 użytkownik brak napisał:
> > > Bo najwidoczniej alternatywy były jeszcze gorsze.
> > > 
> >  IMHO dyskusja C vs C++ nie powinna abstrahować od platformy na jakiej
> > uruchamiany jest program.
> 
> Moim zdaniem dyskusja C vs C++ zawsze będzie raczej biciem piany, niż wymianą argumentów. Nie bez przyczyny zwykło się mawiać "de gustibus non est disputandum".
> 
> A mówiąc ogólniej, dyskusje techniczne nie powinny abstrahować od uwarunkowań problemu, dla którego szuka się rozwiązania.
Dokładnie tak. Dlatego dołączyłem się do wątku. Zamiast ciekawej dyskusji jak
rozwiązać problem powstała wirtualna przepychana.

 
> Jeżeli masz projekt, który już działa na RTOSie, to zgadzam się z Tobą jak najbardziej: zdecydowanie lepiej użyć wątku, niż jakiegoś wątłego mechanizm w rodzaju tego, który zaproponowałem.
Osobiście odmawiam pisania na uC bez RTOS-a. Aczkolwiek ;) czasem jest wymaganie typu 8-bitowy AVR z 128 bajtami RAM-u.

> 
> Jednak tutaj sytuacja była o tyle osobliwa, że ze wstępnej analizy wyszło mi, że dla tworzonej aplikacji RTOS nie będzie potrzebny. Założyłem, że jeżeli potrzeba użycia go się pojawi, to go dodam.
> 
> I w trakcie rozwoju projektu wymagania lekko się zmieniły: uznaliśmy, że być może będziemy mieli jedno peryferium, które być może będzie potrzebowało odrębnego wątku (który na dodatek będzie musiał pracować w trybie uśpienia).
> 
> W dalszym ciągu nie jest pewne, czy zastosujemy peryferium w ostatecznym produkcie. Przeportowanie aplikacji na RTOSa jest pewnym kosztem, który musielibyśmy ponieść, żeby móc skorzystać z prawdziwego wątku.
> 
> Tymczasem koszt dodania do projektu takiej korutyny jest dużo niższy od strony czasowej, zaś w moim wyobrażeniu elastyczność korzystania z trybów low-power jest większa, niż w przypadku RTOSa, który zawsze nakłada na system jakieś swoje ograniczenia (już chociażby to, że oprócz dokumentacji kontrolera musielibyśmy wertować dokumentację albo źródła tego czy innego RTOSa podniosłoby koszt czasowy projektu).
> 
> Tym bardziej, że - jak wspominałem - ten wątek może się ostatecznie okazać niepotrzebny.
Zgadzam się w 100%. To wymagania oraz racjonalność decydują o użytych "klockach" a nie dogmat prawie religijny.
Tryb low-power na RTOS-ie to koszmar a narzut na portowanie jest zwykle tak duży, że programowanie barmetal w C jest w pełni uzasadnione i rozsądne.

W dniu piątek, 13 marca 2020 13:26:07 UTC+1 użytkownik brak napisał:
> On Friday, March 13, 2020 at 1:12:44 AM UTC+1, Maciek Godek wrote:
> > W dniu czwartek, 12 marca 2020 20:17:25 UTC+1 użytkownik brak napisał:
> > > > Bo najwidoczniej alternatywy były jeszcze gorsze.
> > > > 
> > >  IMHO dyskusja C vs C++ nie powinna abstrahować od platformy na jakiej
> > > uruchamiany jest program.
> > 
> > Moim zdaniem dyskusja C vs C++ zawsze będzie raczej biciem piany, niż wymianą argumentów. Nie bez przyczyny zwykło się mawiać "de gustibus non est disputandum".
> > 
> > A mówiąc ogólniej, dyskusje techniczne nie powinny abstrahować od uwarunkowań problemu, dla którego szuka się rozwiązania.
> Dokładnie tak. Dlatego dołączyłem się do wątku. Zamiast ciekawej dyskusji jak
> rozwiązać problem powstała wirtualna przepychana.

No niestety, taki już urok panującej tutaj kultury dyskusji :)
 
> > Jeżeli masz projekt, który już działa na RTOSie, to zgadzam się z Tobą jak najbardziej: zdecydowanie lepiej użyć wątku, niż jakiegoś wątłego mechanizm w rodzaju tego, który zaproponowałem.
> Osobiście odmawiam pisania na uC bez RTOS-a. Aczkolwiek ;) czasem jest wymaganie typu 8-bitowy AVR z 128 bajtami RAM-u.

Moim zdaniem najlepiej używać RTOSa dopiero wtedy, kiedy rzeczywiście jest potrzebny. W kodzie składającym się z jednego maina raczej nie wystąpią problemy z synchronizacją, na które trzeba uważac, jak się zaprzęga RTOSa do pracy.

Poza tym jest jeszcze inny aspekt.

Dla mnie ważne jest, żeby kod, który działa na kontrolerze, dało się również uruchomić na PC. Aktualnie pracuję pod Windowsem, bo takie mamy firmowe wymagania, ale kompiluję w środowisku MSYS2, będącym lekką warstwą kompatybilności z systemami uniksowymi. W tej chwili nie skompilowałbym projektu na Linuksa, ale gdyby pojawiła się taka potrzeba, mógłbym dość szybko doprowadzić do takiego stanu.

Robiłem ewaluację FreeRTOSa dla naszego projektu. Podobało mi się to, że można go uruchomić zarówno pod Windowsem, jak i pod Linuksem, więc na moje potrzeby byłby OK. Jednak wówczas w większym stopniu przywiązałbym się do platformy, na której rozwijam system - port z Windowsa na Linuksa i jego utrzymanie byłyby kosztowniejsze.

Niby nie jest to nic wielkiego, ale zawsze, gdy nie muszę podejmować takich decyzji, wolę tego nie robić.

(Za to widziałem kiedyś projekt, który powinien był być robiony na RTOSie, ale zamiast tego był jakąś koszmarną maszyną stanów - i prawdopodobnie był to najgorszy kod, jaki widziałem w życiu)

On Friday, March 13, 2020 at 1:49:19 PM UTC+1, Maciek Godek wrote:
(...)
> No niestety, taki już urok panującej tutaj kultury dyskusji :)
IMHO zwykle dyskusje religijne kończyły się wojnami religijnymi.
Czasem nie warto rozmawiać.

(...)
> Dla mnie ważne jest, żeby kod, który działa na kontrolerze, dało się również uruchomić na PC. 
Absolutnie tak, zwłaszcza iż metod aby to osiągnąć jest całkiem sporo.
Np. RTOS-y oferują tryb symulatora - kompilacja i uruchomienie zwykle na Linux'ie
jako proces po przez emulatory typu QEMU, po emulatory dostarczane przez vendora z ichnim IDE itd.

> (Za to widziałem kiedyś projekt, który powinien był być robiony na RTOSie, ale zamiast tego był jakąś koszmarną maszyną stanów - i prawdopodobnie był to najgorszy kod, jaki widziałem w życiu)
A ja nawet musiałem nawet takiego potworka rozwijać.
 - Współzbieżność z priorytetyzacją rozwiązali cyklicznie wołając podzadania co
N-ty numer obrotu pętli głównej.
 - A koperacyjny model współbieżności oznaczał pomiar czasu w podzadaniach i jeśli został przekroczony limit, zapisanie stanu i zarejestrowanie callbacka
z parametrem czasowym. 
itd.

To jest według mnie ten obszar problemów gdzie język programowania nie dostarczy optymalnego rozwiązania.

W dniu piątek, 13 marca 2020 16:46:59 UTC+1 użytkownik brak napisał:
> On Friday, March 13, 2020 at 1:49:19 PM UTC+1, Maciek Godek wrote:
> (...)
> > No niestety, taki już urok panującej tutaj kultury dyskusji :)
> IMHO zwykle dyskusje religijne kończyły się wojnami religijnymi.
> Czasem nie warto rozmawiać.

Ja cały czas mam nadzieję, że o kwestiach technicznych można dyskutować merytorycznie i rzeczowo. Ale faktem jest, że w świecie technologii dużo jest przekonań i rozumowań o podłożu plemiennym (dyskusje w rodzaju "vim vs. emacs" albo właśnie "c vs. c++").

Pewnie to bardziej zagadnienie dla antropologów, niż dla programistów, ale w gruncie rzeczy ma to również swoje dobre strony (bo oprócz prowadzenia walk z innymi plemionami, ludzie też często wkładają pracę w to, żeby kultywować swoje wartości i wspierać się nawzajem w różnych celach)

Może też kwestia języka ma tutaj dość fundamentalne znaczenie, bo język chyba jest w dużej mierze źródłem naszej tożsamości - i wygląda na to, że języki programowania wcale się tak mocno pod tym względem nie różnią.

Oczywiście znam projekty embedowe, które są opracowane w C, które są kompletnymi gniotami (na przykład HAL od ST, by nie szukać daleko), oraz całkiem dobrze napisane projekty w C++ (choćby mbed, który jest moim zdaniem całkiem nieźle zrobiony). Generalnie jakość projektu programistycznego mocno zależy od tego, kto się za niego zabierze i co ów ktoś ma w głowie - na pewno mocniej, niż od samego języka programowania (choć oczywiście są języki lepsze i gorsze, i taki np. PHP4 jest doskonałym przykładem "języka gorszego", zaś PHP7 jest już całkiem niezły).

> > (Za to widziałem kiedyś projekt, który powinien był być robiony na RTOSie, ale zamiast tego był jakąś koszmarną maszyną stanów - i prawdopodobnie był to najgorszy kod, jaki widziałem w życiu)
> A ja nawet musiałem nawet takiego potworka rozwijać.
>  - Współzbieżność z priorytetyzacją rozwiązali cyklicznie wołając podzadania co
> N-ty numer obrotu pętli głównej.

To akurat jeszcze nie tak źle. Mogli rozwiązać dokładając więcej stanów.

> To jest według mnie ten obszar problemów gdzie język programowania nie dostarczy optymalnego rozwiązania.

Pełna zgoda.

W dniu wtorek, 10 marca 2020 09:22:58 UTC+1 użytkownik Maciek Godek napisał:
> W dniu poniedziałek, 9 marca 2020 22:00:49 UTC+1 użytkownik heby napisał:
> > On 09/03/2020 21:20, Maciek Godek wrote:
> > > A użycie boost::coroutines dokonuje alokacji, czy nie?
> > 
> > Nie musi. Czy dokonuje nie wiem, pewnie tak.
> 
> I nadal uważasz, że unikanie C++ na rzecz C jest kwestią religii?
> 
> Sam widzisz, że - nawet jeśli mechanizmy, które oferuje C++ byłyby wygodne
> (a nie są), to tworzą one barierę dla zrozumienia systemu. Model operacji C jest stosunkowo prosty, i każdy kompetentny programista powinien go rozumieć.
> Natomiast model C++a jest skomplikowany, i ta komplikacja ma w dużej mierze przypadkowy charakter.
> 
> Zadaję Ci proste, fundamentalne pytanie: czy boost::coroutines, do użycia którego niedawno mnie zachęcałeś, dokonuje alokacji. Ty nie dość, że nie znasz odpowiedzi, to jeszcze nie potrafisz tego łatwo znaleźć w dokumentacji.
> 


jest tak raczej dlatego ze ten user 
'heby' przypomina raczej nie kogos kto ma
glebokie zrozumienie tematu i jego datali tylko raczej malpe ktora po obieciu przypadkowego glupiego stanowiska zuca wybranymi wybranymi pseudoargumentami dookola niczym suszoną kupą - dlatego tez te wątki sa takie osobliwe [sam bym przy okazji tego nie komentowal gdyby nei bylo to jednak forsowaniem pewnego oglupienia
co nie jest za dobre, choc jest przynajmniej smieszne  ]


> Wcale mnie to nie dziwi. Jeżeli uważasz, że całościowe rozumienie systemu, który się rozwija, jest "kwestią religii", niech będzie i tak. Moim zdaniem jest to raczej kwestia rozsądku i pragmatyzmu.
> 
> > Ale nie ma takiego 
> > obowiązku, w końcu stos korutyny możesz mieć statyczny gdzieś obok, 
> > albo, wzorem apliakcji embedded, możesz mieć pool allokatora na te stosy 
> > i znany rozmiar.
> 
> Każda STLowa kolekcja daje Ci możliwość dostarczenia Twojego własnego alokatora.
> Dlatego rozumując po Twojemu, powinieneś raczej zachęcać embedowców do tego, żeby grzęzli w bagnie debugowania ich własnych customowych alokatorów i hulali sobie z wesołymi alokacjami STLowych kolekcji.
> 
> > Więc możesz sobie napisać godek::coroutine i tam może 
> > nie być allokacji ale stos, czemu nie.
> 
> Te Twoje rady są coraz lepsze. To, skoro "mogę sobie napisać" (bo to takie łatwe?), może pokaż mi, jak taka implementacja mogłaby wyglądać.
> 
> Chętnie się dowiem.

W dniu środa, 11 marca 2020 15:00:46 UTC+1 użytkownik Mateusz Viste napisał:
> 2020-03-11 o 04:45 -0700, Maciek Godek napisał:
> > Jak lubisz, to sobie używaj.
> 
> I w zasadzie na tym możnaby zakończyć ten wątek. :)
> 
> My "wiemy", że C jest lepsze bo jest proste i przejrzyste bez żadnych
> wodotrysków przez które człowiek gubi się w tym co tak naprawdę się
> dzieje, a heby "wie" że C++ posiada trylion wynalazków których nie
> potrzeba na nowo wymyślać i dlatego jest lepszy, a rozumieć jak co
> działa nie ma potrzeby bo od tego są interfejsy by ukrywać detale
> implementacji.
> 
> Oba obozy mogą się tak sprzeczać w nieskończoność... Tylko czy to ma
> sens? Wszak o gustach się nie dyskutuje, a cała polemika "C vs C++"
> rozbija się właśnie o gust (oraz poniekąd o sposób myślenia czy ogólniej
> podejście do życia). Tak czy siak - nikt nikogo tu nie przekona.
> 
nie jest tak poniewaz ten trylion wynalazkow c++ jest poprostu glupi i 'pozwala' pisac dosyc glupi kod - kod ktory w c mozna napisac duzo madrzej

same te 'wynalazki' c są dużo mądrzejsze
i robia nawet wlasnie imponujace mozna
pwoiedziec wrazenie (mz programowanie robi wrazenie samo w sobie, c po swojej stronie robi mozna powiedziec nawet osobne wrazenie jako sposob programowania), (choc i w c znalazly sie pewne flaws, (mysle np o wskaznikach na funkcje i na pewnych kwestiach zwiazanych ze wskaznikami w c w ogole) te flaws trudno mi ejdnak porownac do tych z c++ bo sa generalnie 'duzo trudniejsze' tj mz duzo trudniej jest powiedziec co dokladniej byloby dobre na ich miejsce)

W dniu piątek, 20 marca 2020 20:56:20 UTC+1 użytkownik (fir) napisał:
> W dniu środa, 11 marca 2020 15:00:46 UTC+1 użytkownik Mateusz Viste napisał:
> > 2020-03-11 o 04:45 -0700, Maciek Godek napisał:
> > > Jak lubisz, to sobie używaj.
> > 
> > I w zasadzie na tym możnaby zakończyć ten wątek. :)
> > 
> > My "wiemy", że C jest lepsze bo jest proste i przejrzyste bez żadnych
> > wodotrysków przez które człowiek gubi się w tym co tak naprawdę się
> > dzieje, a heby "wie" że C++ posiada trylion wynalazków których nie
> > potrzeba na nowo wymyślać i dlatego jest lepszy, a rozumieć jak co
> > działa nie ma potrzeby bo od tego są interfejsy by ukrywać detale
> > implementacji.
> > 
> > Oba obozy mogą się tak sprzeczać w nieskończoność... Tylko czy to ma
> > sens? Wszak o gustach się nie dyskutuje, a cała polemika "C vs C++"
> > rozbija się właśnie o gust (oraz poniekąd o sposób myślenia czy ogólniej
> > podejście do życia). Tak czy siak - nikt nikogo tu nie przekona.
> > 
> nie jest tak poniewaz ten trylion wynalazkow c++ jest poprostu glupi i 'pozwala' pisac dosyc glupi kod - kod ktory w c mozna napisac duzo madrzej
> 
> same te 'wynalazki' c są dużo mądrzejsze
> i robia nawet wlasnie imponujace mozna
> pwoiedziec wrazenie (mz programowanie robi wrazenie samo w sobie, c po swojej stronie robi mozna powiedziec nawet osobne wrazenie jako sposob programowania), (choc i w c znalazly sie pewne flaws, (mysle np o wskaznikach na funkcje i na pewnych kwestiach zwiazanych ze wskaznikami w c w ogole) te flaws trudno mi ejdnak porownac do tych z c++ bo sa generalnie 'duzo trudniejsze' tj mz duzo trudniej jest powiedziec co dokladniej byloby dobre na ich miejsce)

Co jest Twoim zdaniem nie tak ze wskaźnikami w C (i w szczególności ze wskaźnikami na funkcje)?

W dniu środa, 25 marca 2020 13:26:40 UTC+1 użytkownik (fir) napisał:
> W dniu wtorek, 24 marca 2020 21:31:01 UTC+1 użytkownik Maciek Godek napisał:
> > W dniu piątek, 20 marca 2020 20:56:20 UTC+1 użytkownik (fir) napisał:
> > > W dniu środa, 11 marca 2020 15:00:46 UTC+1 użytkownik Mateusz Viste napisał:
> > > > 2020-03-11 o 04:45 -0700, Maciek Godek napisał:
> > > > > Jak lubisz, to sobie używaj.
> > > > 
> > > > I w zasadzie na tym możnaby zakończyć ten wątek. :)
> > > > 
> > > > My "wiemy", że C jest lepsze bo jest proste i przejrzyste bez żadnych
> > > > wodotrysków przez które człowiek gubi się w tym co tak naprawdę się
> > > > dzieje, a heby "wie" że C++ posiada trylion wynalazków których nie
> > > > potrzeba na nowo wymyślać i dlatego jest lepszy, a rozumieć jak co
> > > > działa nie ma potrzeby bo od tego są interfejsy by ukrywać detale
> > > > implementacji.
> > > > 
> > > > Oba obozy mogą się tak sprzeczać w nieskończoność... Tylko czy to ma
> > > > sens? Wszak o gustach się nie dyskutuje, a cała polemika "C vs C++"
> > > > rozbija się właśnie o gust (oraz poniekąd o sposób myślenia czy ogólniej
> > > > podejście do życia). Tak czy siak - nikt nikogo tu nie przekona.
> > > > 
> > > nie jest tak poniewaz ten trylion wynalazkow c++ jest poprostu glupi i 'pozwala' pisac dosyc glupi kod - kod ktory w c mozna napisac duzo madrzej
> > > 
> > > same te 'wynalazki' c są dużo mądrzejsze
> > > i robia nawet wlasnie imponujace mozna
> > > pwoiedziec wrazenie (mz programowanie robi wrazenie samo w sobie, c po swojej stronie robi mozna powiedziec nawet osobne wrazenie jako sposob programowania), (choc i w c znalazly sie pewne flaws, (mysle np o wskaznikach na funkcje i na pewnych kwestiach zwiazanych ze wskaznikami w c w ogole) te flaws trudno mi ejdnak porownac do tych z c++ bo sa generalnie 'duzo trudniejsze' tj mz duzo trudniej jest powiedziec co dokladniej byloby dobre na ich miejsce)
> > 
> > Co jest Twoim zdaniem nie tak ze wskaźnikami w C (i w szczególności ze wskaźnikami na funkcje)?
> 
> sęk w tym ze trudo wlasnie jest dokladnie powiedziec co jest zle (jesli mowa o wskaznikach) ale moim zdaniem da sie zauwazyc ze cos tu jest zle
> 
> jedna z rzeczy ktore chyab moge wymienic 
> to prawdopodobnie takie rzeczy jak:
> 
> int*** x;
> 
> gdzie aby zapisac cos do do celowego inta piszesz ***x = 10;
> jest to prawdopodobnie zle, lepiej (prawodopodobnie) bylob by tym docelowym x'em bylo x
> 
> int*** x;
>  x = 10;
> (a te dodatkowe wskazniki byly by pewnie dostepne przez &x &&x i &&&x)
> 
> jednakowoz jest to trudny temat i troszke ciezki w romowie

Nie mam tego zbyt głęboko przemyślane, ale "z daleka" wygląda mi raczej na kwestię kosmetyczną. Thompson i Ritche zresztą raczej by zalecali styl deklaracji

int ***x;

który lepiej uwypukla symetrię pomiedzy deklaracją a użyciem (tzn. że ***x jest typu int).

Pominę kwestię, że w rzeczywistym kodzie rzadko kiedy korzystam z więcej niż dwóch poziomów przekierowania.

> co do tego co jest zle we wskaznikach na funkcje to jest nieco prostsze choc tez nie calkiem, jedna z rzeczy jest to ze takie wskazniki na funkcje jak w c (z takim pilnowaniem typu) sa dosyc malo uzyteczne, inna rzecz to ze np te nazywy typow uzywane w c sa po prostu zle (chyba  nawet zaloze watek na comp.lang.c z pytaniem/propozycja przemyslenia jak to poprawic, tak ze jak kolega zainteresowany mozna tam rzucic okiem czy cos z tego watku wyjdzie)

Rzuciłem okiem, ale nie mogę powiedzieć, żebym coś z tego zrozumiał :]

W moim odczuciu wskaźniki na funkcje są najbardziej użytecznym i elastycznym środkiem abstrakcji w języku C (no i też trudno sobie wyobrazić przenośnego UNIXa bez tego mechanizmu, gdzie deskryptor plików to - może w pewnym uproszczeniu - krotka wskaźników na funkcje (read, write, ioctl)).

Może pewnym kłopotem jest to, że składnia deklaracji faktycznie nie jest zachwycająco prosta - pod tym względem chyba najkorzystniej wypadają języki funkcyjne w rodzaju Haskella czy MLa (tylko że w ich przypadku to są "nie do końca wskaźniki").

Ale też nie jest to problem, z którym nie dałoby się poradzić (zwłaszcza jeżeli się umiejętnie korzysta z typedefów)

W dniu środa, 25 marca 2020 13:47:29 UTC+1 użytkownik Maciek Godek napisał:
> 
> W moim odczuciu wskaźniki na funkcje są najbardziej użytecznym i elastycznym środkiem abstrakcji w języku C (no i też trudno sobie wyobrazić przenośnego UNIXa bez tego mechanizmu, gdzie deskryptor plików to - może w pewnym uproszczeniu - krotka wskaźników na funkcje (read, write, ioctl)).
> 
> Może pewnym kłopotem jest to, że składnia deklaracji faktycznie nie jest zachwycająco prosta - pod tym względem chyba najkorzystniej wypadają języki funkcyjne w rodzaju Haskella czy MLa (tylko że w ich przypadku to są "nie do końca wskaźniki").
> 
> Ale też nie jest to problem, z którym nie dałoby się poradzić (zwłaszcza jeżeli się umiejętnie korzysta z typedefów)

no ja nie mowie ze wkazniki na funkcje nalezy skasowac w c tylko o ile pamietam 
to co mowie jest w kontekscie powiedzenia 
ze o ile c++ ma badziewiasto i glupio zrobione 'ficzery'/mechanizmy czy jak to nazwac (cechy jezyka) to c (mimo wlasnie dania tak poteznej 'abstrakcji') niektore rzeczy ma tez jakby blednie zrobione (tj w sensie c++ owym czyli w pozytywnym bo jezyk moze byc kiepski przez braki (-) i kiepski przez slaba jakosc ficzerow ktore ma wbudowane(+) c++ ma tych blednych plusow/bledow cala mase a c ma malo ale c tez ma tego cos, tyle ze malo)i te wskazniki an funkcje sa moimz daniem slaba strona c

(co pisze mocno niepracyzyjnie ale jestem zmeczony i nie che mi sie rozwijac tematu)

W dniu piątek, 13 marca 2020 22:52:35 UTC+1 użytkownik Maciek Godek napisał:
> W dniu piątek, 13 marca 2020 16:46:59 UTC+1 użytkownik brak napisał:
> > On Friday, March 13, 2020 at 1:49:19 PM UTC+1, Maciek Godek wrote:
> > (...)
> > > No niestety, taki już urok panującej tutaj kultury dyskusji :)
> > IMHO zwykle dyskusje religijne kończyły się wojnami religijnymi.
> > Czasem nie warto rozmawiać.
> 
> Ja cały czas mam nadzieję, że o kwestiach technicznych można dyskutować merytorycznie i rzeczowo. Ale faktem jest, że w świecie technologii dużo jest przekonań i rozumowań o podłożu plemiennym (dyskusje w rodzaju "vim vs. emacs" albo właśnie "c vs. c++").

Wpadłem dziś na bardzo ciekawą prezentację na ten temat:

https://www.youtube.com/watch?v=D7Sd8A6_fYU