Fajna prezentacja. Też uważam, że budowanie software’u z setkami bibliotek jest nieskalowalne (i wręcz niebezpieczne). Duże firmy unikają jak ognia zewnętrznych zależności.
Nie do końca zgadzam się natomiast z argumentami odnośnie przewagi C nad C++:
- przeciążanie funkcji można zaimplementować wydajnie (chociażby na przykładzie Javy i C#),
- nie trzeba używać STLa (oni nawet tego nie sprawdzają!),
- C++ obsługuje anonimowe unie, większość kompilatorów wspiera anonimowe struktury,
- designated initializers zostały wprowadzone w C++20,
- struktury z indeksowanymi polami da się zaimplementować w C++ (chociaż przyznaję, że jest to bardziej skomplikowane niż odpowiednik w C).
Co do argumentu o niskim wykorzystaniu zasobów, ciekawe czy implementacja takiego blitowania na GPU (przy uzyciu bardzo prostych shaderów i w niskiej rozdzielczości / framerate) rzeczywiście skutkowałaby większym zużyciem energii od wersji software’owej.
Oczywiście wykluczyloby to platformy bez GPU, więc rozumiem wybór ręcznej rasteryzacji.Bawiłem się SDL3. Robiłem grafikę softwareowo. 4000 blitów 12x22px na klatkę za pomocą wbudowanej funkcji SDL_BlitSurfaceTiled z przeźroczystością za pomoca colorkey. Zajmowało to od 7 do 18 ms. Wydaje mi się, że gdybym napisał sam specjalizowane to byłoby wiele razy szybsze. Nie zrobiłem tak od początku bo się obawiałem różnych formatów bufora ramki.
Jaki render driver i wymiary docelowego recta?
Jeśli wypełniałeś po prostu jeden raz obszar o powierzchni 4000 kafelków, to spodziewałbym się lepszej wydajności.
W tym tygodniu komitet C++ zatwierdził mechanizm reflection w następnej wersji języka.
Teraz można użyć jeszcze bardziej skomplikowanej składni, żeby zaimplementować rozwiązanie Sosa. :-Dstruct S { unsigned i:2, j:6; }; consteval auto member_number(int n) { if (n == 0) return ^^S::i; else if (n == 1) return ^^S::j; } int main() { S s{0, 0}; s.[:member_number(1):] = 42; // Same as: s.j = 42; s.[:member_number(5):] = 0; // Error (member_number(5) is not a constant). }Zabawne jest też to, że najnowsze propozycje rozszerzeń w C++ dosłownie odtwarzają w przykładach popularne biblioteki rustowe i pythonowe. Widać, kto obecnie wyznacza trendy w tej dziedzinie, a kto próbuje gonić resztę świata.
Nie wiem po co to wtrącenie o dużych firmach? Czy to jest duża firma?
Każdy koduje jak mu wygodnie. Ja dalej nie rozumiem OOP. Nie umiem zaprojektować dobrej hierarchii klas wewnątrz aplikacji. Wydaje mi się, że to jest fajne do wystawiania popularnego API dla innych.
Byś musiał sprawdzić ile zużywają GPU i CPU. Ile razy dłużej CPU musi pracować by tyle samo zużyć. Czy rzeczywiście tyle pracuje przy blitowaniu.
Kiedyś z Lacky porównywaliśmy sprzętowe i softowe dekodowanie wideo. Sprzętowe brało więcej. Dane na podstawie czujników prądu w laptopie.
Jeśli chodzi o konstrukcje językowe to ostatnio myślałem nad czymś. Co jeśli “.” byłaby normalnym elementem nazwy tak jak “_”? W C mógłby istnieć skrót do nadawania nazw z przedrostkiem w stylu:
group costam. { int x = 0; int y = 1; }co byłoby równoznaczne:
int costam.x = 0; int costam.y = 0;Fajnie jakby przed “costam” można było wstawić “const” lub “static”, dla wszystkich elementów. Oczywiście zamiast “.” można użyć “_” lub nic i używać camelCase.
Tak wiem, pora deszczowa w pełni.
Ta składnia mi to trochę pascalowe
with.Problem z taką interpretacją kropki wystąpiłby przy zagnieżdżonych strukturach.
Jeśli dobrze rozumiem pomysł,foo.barbyłby w tym przypadku niepowiązany ze zmiennymifoo.bar.xifoo.bar.y.Ze struktur bym prawdopodobnie zrezygnował. Uznałbym, że zmienne to mapowanie pamięci. Wymyślenie lepszej dynamicznej pamięci zostawiam tobie. Ale wyobrażam sobie jakieś konteksty na wzór banków pamięci (aktywacje mapy?).
Do grupy można jeszcze dodać tablice.
