Vlákno názorů k článku
Mělo by se jádro předělat z C do C++?
od cc - Já myslím, že to hodně lidí nepochopilo. O...
-
Já myslím, že to hodně lidí nepochopilo. O žádný přepis nejde. Idea je taková, že C++ umí některé věci, které jsou dobré a ten jazyk je blíž C než Rust. Takže třeba type-safe šablony pro kontejnery, kde se teď všechno castuje, tam by to bylo lepší, ale nikdo nemluvil o tom dělat nějaké šílené OOO.
Podle mě to nemá šanci, ale vzhledem k tomu, že tam už je Rust, tak to asi stojí o diskuzi, případně nástřel toho, co by se v C++ mohlo používat a co ne. Exceptions, RTTI, a komplet std bude určitě zakázané, takže rozhodně nejde o nějaké "moderní C++ v kernelu", ať už si pod tím představí kdo chce co chce...
Ještě bych dodal, že třeba fuchsia má taky jádro v "restricted" C++ - dnes je to celkem běžná věc.
12. 1. 2024, 19:41 editováno autorem komentáře
-
Tak celkem rozumna typova bezpecnost je u dulezitych veci implementovana pomoci sparse a maker/inline funkci, takze nejaky extra posun pri pouziti sablon nevidim.
Uz druhe desetileti se zivim vyvojem a portovanim Linuxu na ruzne architektury (hlavne telekomunikacni systemy) a predstava, kdy resim nefungujici kod vygenerovany C++ prekladacem na obskurnim HW, kde je znacna sance, ze muze byt spatne jak ten kod, tak prekladac, tak i HW, me desi.
-
Treba prohlizet kod vznikly specializaci sablon asi nebude uplne zuzo, obzvlast jakmile se sablony zacnou zanorovat. Kdyz k tomu pridame to, ze by se ztratila rozsirena typova kontrola, kterou dela sparse (pokud by ho nekdo nerozsiril o sablony), tak mi to proste prijde kontraproduktivni. A to, ze gcc pouzije spatne typy neni tak neobvykle, uz jsem objevil chybu, kdy ztratilo volatile kvalifikator z elementu struktury ve strukture a kdy pro rozdil dvou ukazatelu bylo pouzito signed odcitani.
-
Vec<> bohuzel neni moc dobry priklad, protoze uvnitr kernelu se proste nespolehas na jinou, nez svou vlastni implementaci, protoze potrebujes presne vedet, co ten kod dela. Pridej k tomu specializace pro ruzne typy a uz z toho mas binec, ve kterem se nikdo nevyzna. Dobry priklad je treba nasledujici:
Pokud v C pridam pro vektory typu bool bitove pole, namisto puvodniho unsigned char pole, tak ho nazvu jinak a kdyz ho nekdo bude chtit pouzit, pak bude muset prepsat svuj kod a prejit na novou implementaci.
Pokud udelas specializaci sablony v C++ pro vektor typu bool, ze je bitove pole a ne char pole, tak v momente, kdy nekdo takove pole pouziva o takove zmene vubec nemusi vedet a pravdepodobne to bude fungovat dobre, ale v pripade, ze se bude spolehat na puvodni velikost, tak ma problem.
Tohle lze samozrejme ale vyresit ze zavedes standardni postupy, taky nemenis velikosti struktur a drzis API/ABI atd., ale jako priklad je to dobre.Navic cela std knihovna je nepouzitelna taky ze stejneho duvodu, jako je nepouzitelna C standard library.
-
Divej, že má C++ posraný std::vector<bool> víme všichni a nevim proč by toto měl být nějaký argument k této diskuzi, když víme, že std se do kernelu nikdy nedostane, protože exceptions...
Kernel taky alokuje paměť a má na to vlastní alokátor, tak by Vec<> použil ten... V tomto konkrétně nevidím problém. To co implementovali v kernelu v C není problém implementovat v C++.
-
Nebud tak haklivy, neni to pripad std::vector<bool>. Zamerujes se na jeden konkretni problem, ale muj priklad byl spise o tom, ze pokud mas nejaky kontejner, tak proste potrebujes vedet, jak presne funguje a nesmi se to rozbit. Coz se nejspis stane, kdyz nekdo pro dany typ dat udela specializaci. Myslel jsem to hodne obecne. V praxi by se to samozrejme resilo vlastni implementaci v kernelu.
-
Takze navrhujete udelat dalsi sablonu, ktera by definovala, jaky alokator a s jakymi flagy se pouzije + jeste rozsirit API, aby se dal zmenit alokator za behu pro pouziti, kdy se cast alokuje pri startu pred inicializaci slabu a cast az potom. To uz se trochu zacina blizit tomu sablonovemu peklu, ktere jsem popisoval jako duvod, proc C++ nepouzivat.
Dalsi otazka je, jestli bychom timto zpusobem neprisli o optimalizaci, ktera vybere cilovou slab cache uz v dobe prekladu, pokud alokovana velikost je compile time constant. Vlastne neprisli, protoze tu velikost bychom prece taky mohli dat do parametru sablony...
-
Nějak nerozumím. Ten alokátor je typ s jednoduchým rozhraním pro alokaci a dealokaci. Vec ani vector to víc řešit nepotřebují. A celý alokátor se tomu vektoru předá při konstrukci.
Jestli ta alokace potřebuje nějaké flagy či něco podobného, tak to může být schované uvnitř toho alokátoru. Žádné rozšiřování šablon není potřeba.
Různé alokátory pro různá použití je naprosto běžný use case. -
Prave ze nemuze, v Linuxu pri alokaci pouzivate ruzne flagy, urcujici treba jestli alokator muze blokovat. Napr. B+ strom nema ty flagy ulozene nekde v instanci, ale jsou parametrem insertu. Vizte https://elixir.bootlin.com/linux/latest/source/include/linux/btree.h#L110
Implementace stromu nemuze vedet, z jakeho kontextu je volana. To, ze se u jedne instance nejake genericke struktury pouzivaji rozdilne flagy pri alokaci je naprosto bezne, protoze se proste pouziva ze dvou rozdilnych kontextu. Vpodstate cele STD API je kvuli tomu nepouzitelne. -
> Treba prohlizet kod vznikly specializaci sablon asi nebude uplne zuzo
Prosím reálnou situaci, kdy to potřebuješ? Jako myslíš si prohlížet kód v C++?
Já třeba si prohlížím výsledek v asembleru a kolikrát několikrát vnořená šablona vede na deset instrukcí kódu. A jsou i situace, kdy ta šablona nevede na žádný kód díky optimalizaci na takovou úroveň, že se vše udělá v rámci jiné věci a výsledky se jen reusnou. Takové rekurzivní volání v šabloně mnohdy překladač rozbalí do několika instrukcí za sebou.
Při tomhle prohlížení mne ale spíš zajímá, jestli překladač někde zbytečně nezahazuje nějakou optimalizaci, nikdy by mě nenapadlo to kontrolovat z hlediska funkčnosti. Pokud ta věc je jazykově správně napsaná, pak musí fungovat aniž bych to musel prohlížet a kontrolovat.
-
Tak já se s tím setkal jednou asi po 10 letech a to v důsledku použití nových featur (korutin) v gcc-11. A nebylo to v šablonách. Tam ale asi má smysl kontrolovat disassembler, než se probírat cestami dané šablony.
Nevím co používáte za překladače nebo HW, že jste tak často obětí chyb. V drtivá většina chyb vzniklá třeba po zapnutí optimalizací byla chyba na mé straně (přístup ke zničené proměnné typicky jako reference na temporary)
