Ted netuším, na kterou část reagujete.
Víceméně se implementace GCC a Clang neliší, nebo jen v nuancích. Clang mi přijde, že generuje o pár procent menší framy a optimálnější kód v řádu promile, než GCC. Clang umí rozbalit a optimalizovat různé konstrukce awaiterů, takže nakonec to co má několik desítek řádek kódu se smrskne na jednu instrukci. Přepínání framů umí lépe optimalizovat Clang, který mezi corutinama skáče instrukcí JMP. Zatímco GCC někdy nezvládne TCO a vytváří zbytečně zásobníkové framy, ale naštěstí se tak neděje při symetrickém transferu, o tom snad ještě napíšu.
Obecně třeba s výpočtem velikosti frame je problém, že jeho velikost se spočítá až po optimalizaci kódu, kdy už musí být všechny konstanty známy. Tohle číslo pak tedy pouze propadne do operátoru new pro alokaci jako "ne-konstanta" (není to constexpr)
GCC oproti tomu má několik ještě neopravených a nepochopitelných bugů, které se v clangu nijak neprojevují. Jako je dost znát, že to má dětské nemoci, protože jako Clang, tak GCC umí nevhodně napsaným kódem sestřelit na SIGSEGV
Jak to dělá Visual C++ netuším, neměl jsem tu čest.
V ostatních "problémech" - něco definuje norma, ale platí, že to co norma nedefinuje (například MT Safe u korutin), to je UB. Je třeba se vyhnout takové situaci - synchronizovat
Intenzivně se zabývám programováním zejména v jazyce C++. Vyvíjím vlastní knihovny, vzory, techniky, používám šablony, to vše proto, aby se mi usnadnil život při návrhu aplikací. Pracoval jsem jako programátor ve společnosti Seznam.cz. Nyní jsem se usadil v jednom startupu, kde vyvíjím serverové komponenty a informační systémy v C++
Přečteno 51 079×
Přečteno 23 949×
Přečteno 22 876×
Přečteno 20 965×
Přečteno 17 763×