🚀 go-pugleaf

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