46.2 C++26 és későbbi irányok ellenőrzött státusszal

Ez a szakasz tudatosan nem ismétli meg a fő kurzus anyagát (lásd C++23 összefoglaló és migrációs táblázat (46.1)), és nem állítja, hogy bármelyik alábbi képesség elérhető. Célja egy státusz-ellenőrzési keretrendszer és egy elsődleges forrásokhoz vezető térkép adása, amelyet a generálás, illetve az olvasás napján aktuális WG21- és compiler-/library-forrásokból kell kitölteni. A C++26 egészének státuszát a forrásjegyzék [C++26] tétele rögzíti (2026-10-25: technikailag lezárt, DIS-szavazáson, ISO-kiadás nem igazolt), az egyes könyvtári képességekét pedig a C++26 könyvtári és konkurencia-kitekintés táblázata. Az itt szereplő, C++26 utáni irányok konkrét státusza viszont nem ellenőrzött, kitöltendő mező, nem pedig tényállítás; a lenti sablon ennek kitöltésére szolgál.

46.2.1 A „státusz” négy szintje

A C++ ökoszisztémában egy új képesség élete több, egymástól szigorúan megkülönböztetendő állapoton halad át, és a gyakorlati döntéseknél a négy szintet nem szabad összemosni.

1. Javaslat (proposal) – P-számú WG21-dolgozat. Lehet elvetett, aktív revízión eső, vagy plenáris szavazással elfogadott egy következő szabványba. Az elfogadás ténye a working draftba kerüléshez vezet, de önmagában nem tesz egy képességet „szabványossá”.
2. Working draft – az N-számú munkapiszkozat (például az N4950 a C++23 esetében). Ez a szabvány előkészítő szövege; a nyilvános draft hivatkozási alap, de nem az ISO által kiadott, jogilag közzétett szabvány. A draft és a megjelent ISO szöveg között eltérések lehetnek (szavazási javítások, szerkesztői pontosítások).
3. Közzétett ISO szabvány – a nemzeti testületek szavazásával jóváhagyott, az ISO által kiadott szöveg. A hivatalos jelölés és a végleges tartalom ehhez a szinthez kötődik; a fizetős ISO kiadvány és a working draft nem azonos.
4. Implementációs támogatás – az, amit a választott compiler- és standard library-verzió ténylegesen fordítani és futtatni képes. Ezt feature-test makrók (__cpp_lib_*, __cpp_*) és compiler-státuszoldalak alapján kell ellenőrizni, nem a javaslat szövege alapján.

Ezért a helyes kérdés sosem az, hogy „benne van-e C++26-ban?”, hanem az, hogy melyik szinten áll, melyik revízión, melyik konkrét compiler/library párosítással, és mikor ellenőriztük.

46.2.2 A forrás és a dátum rögzítése

A státuszt csak forrással és dátummal szabad megjelölni. A szakaszhoz használható táblázatsablon a következő; az első három oszlopot a tanulónak kell kitöltenie elsődleges forrásból, a negyedik az, amit a szöveg megenged.

A „szint” oszlopban csak a fenti négy kategória egyike állhat; a forrásokhoz elsődleges anyagot (WG21 papers, working draft, compiler-/stdlib-dokumentáció, ABI-specifikáció) kell használni, nem blogbejegyzést vagy összefoglalót. A tarisznyába kerülő source_id-k helyére itt a konkrét P-/N-jelölést és a megtalálás dátumát kell írni.

46.2.3 Reflection és compile-time code generation

A reflection (tükrözés) célja, hogy a program a saját típusait és tagjait compile time enumerálhatóvá tegye, és erre építve generikus szerializációt, ORM-et, teszteket lehessen írni kézi felsorolás nélkül. A C++20-as alap ezt makrókkal és sablonmanipulációval utánozza.

// serialize_cxx20.cpp — C++20 baseline: kézi felsorolás
#include <cstdio>

struct Point { int x; int y; };

// A mezőket kézzel kell megismételni: ez az a terület,
// amit a reflection a jövőben kiválthat.
void dump(const Point& p) {
    std::printf("{x=%d, y=%d}\n", p.x, p.y);
}

int main() {
    Point p{1, 2};
    dump(p);
    return 0;
}

# Fordítási parancs (a tanuló laborjában ellenőrizendő):
g++ -std=c++20 -O2 -Wall -Wextra serialize_cxx20.cpp -o serialize_cxx20

Ez a kód a C++20 alapszabályok szerint állítja össze a kimenetet; a reflection-javaslat megjelenési formája (API-nevek, metaobjektum-típus, iteráció módja) revíziónként változhat, ezért nem tanácsos előre rögzített szintaxist feltételezni. Ha a szakaszhoz később reflection-példát illesztünk, a -std=c++26 kapcsoló és a hozzá tartozó compiler-státusz ellenőrzése csak a working draft szintjén értelmezhető; ezt tilos verziófüggetlen garanciaként olvasni.

46.2.4 Contracts

A contracts célja: előfeltétel, utófeltétel és invariáns deklaratív rögzítése úgy, hogy a diagnosztikai és runtime-szemantikát a szabvány definiálja, ne az adott assert-implementáció. A C++20-as alap: assert, [[likely]], std::abort, illetve saját invariant-ellenőrző makrók. A contracts szövegében a semantics (mikor értékelődik a predikátum, mi történik megsértés esetén, hogyan viszonyul a noexcept-hoz) a kritikus pont, mert ez határozza meg, hogy a kód viselkedése hogyan módosul debug- és release-profilban. A pontos megfogalmazás a working draftból ellenőrizendő, és az implementációs támogatás compilerenként eltér.

46.2.5 std::execution sender/receiver

A sender/receiver modell az asszinkron végrehajtást egy kompozicionálható pipeline-nyá teszi: a munka leírása (sender) elkülönül a futtatástól (scheduler), és a hibakezelés, megszakítás, több erőforrás-típus egyetlen típusrendszerbe kerül. A C++20-as alap a std::future/std::async és kézi szálkezelés, amelyek a pipeline-szemantikát csak egyedi megoldásokkal közelítik. A szakaszhoz ezért a C++20-as mintát mutatjuk meg, a sender/receiver formát csak a working draft alapján, jelöléssel.

// baseline_async.cpp — C++20: std::future, mint a sender/receiver előtti alap
#include <future>
#include <cstdio>

int compute() { return 42; }

int main() {
    std::future<int> f = std::async(std::launch::async, compute);
    std::printf("%d\n", f.get());
    return 0;
}

g++ -std=c++20 -O2 -Wall -Wextra -pthread baseline_async.cpp -o baseline_async

A példa a meglévő alapot mutatja. A sender/receiver bevezetése ezt a felületet nem helyettesíti azonnal; a library implementáció és a standard library-ben elérhető komponensek köre külön ellenőrizendő. A konkurens élettartam és reclamation kérdései a shared ownership, reclamation és konkurens review (34.6) szakaszra épülnek, ahol az ownership-szerződés pontosabb.

46.2.6 Hazard pointer / RCU és reclamation library

A lock-free adatszerkezetekben a legnehezebb kérdés nem a mutáció, hanem a biztonságos visszanyerés (reclamation): mikor szabad egy csomópontot felszabadítani, ha egy olvasó még mutat rá. A C++20-ban erre a std::shared_ptr az egyetlen szabványos, de atomi referenciaszámítás miatt költséges válasz. A hazard pointer és az RCU ennél olcsóbb alternatívák; a hozzájuk tartozó library-eszközök státusza a working draftban és az implementációkban külön ellenőrizendő. A választás nem helyettesíthető: a shared_ptr továbbra is a helyes alap, ha az ownership megosztott, és a reclamation-költség nem kritikus.

46.2.7 SIMD, linear algebra és könyvtári térkép

A SIMD (single instruction, multiple data) típusok célja, hogy a vektoros hardveres párhuzamosságot hordozhatóan, típusosan lehessen kihasználni, a kézi intrinsics és az __m128-család helyett. A linear algebra (mátrix-, vektor-műveletek) célja, hogy a numerikus kód standard könyvtári alapot kapjon, és a BLAS/LAPACK-függést hordozható réteg váltsa fel. A két terület státusza eltér: a SIMD típusok nyelvi magas szintű leírása és a linear algebra library-felülete külön P-/N-anyagokban követhető, és mindkettő implementációs támogatása külön ellenőrizendő. A jelen szakasz csak a térképet adja: a részletes könyvtári választást a Standard könyvtári lefedettség és ökoszisztéma-térkép (46.4) tárgyalja.

46.2.8 Papers és working draft nem közzétett ISO szabvány

A legfontosabb félreértés, hogy egy P-számú dolgozat vagy egy N-számú working draft azonos a kiadott szabványos szöveggel. A különbség nem formális: az ISO-szavazás szerkesztheti a szöveget, a nemzeti adaptáció eltérhet, és a working draft egy adott pillanat pillanatképe, amelybe későbbi javaslatok már bekerülhettek, illetve korábbiak kikerülhettek. Ezért a „C++26-ban van” állítás csak a keletkezés dátumával és a hivatkozott konkrét N-/ISO-számmal együtt érvényes. Ha a kurzus bármely fejezetében egy képességre hivatkozunk, a hivatkozást a keletkezés dátumához és a konkrét draft-kiadáshoz kell kötni.

46.2.9 Tipikus hibák

• Szint-összemosás: elfogadott javaslatot „szabványosnak” nevezni, vagy a working draftot az ISO-kiadással azonosítani.
• Támogatás igazolása a javaslat szövegével: a P-dolgozat nem bizonyítja, hogy a fordító támogatja; ehhez feature-test makró és compiler-státuszoldal kell.
• Dátum nélküli hivatkozás: a C++26 státusz gyorsan változik; dátum nélkül a hivatkozás nem reprodukálható.
• shared_ptr „kiváltása”: a hazard pointer/RCU a megosztott tulajdonlás alternatívája csak ott, ahol a reclamation-költség kritikus és az ownership-szerződés ezt megengedi.
• Előre rögzített szintaxis: a reflection- és sender/receiver-API revíziónként változhat; a szakasz példáiban ezért a C++20-as alapot és a jelölést kell követni.

46.2.10 Összefoglaló

A C++26 és későbbi irányok tárgyalásakor a kérdés nem az, hogy „benne van-e a szabványban”, hanem az, hogy melyik szinten (proposal / working draft / ISO / implementált), melyik revízión, melyik forrásból és melyik dátummal ellenőriztük. A fejezet öt területe (reflection, contracts, sender/receiver, hazard pointer/RCU, SIMD és linear algebra) mindegyike a working draft és a compiler-/library-státusz együttes vizsgálatát igényli; egyik sem helyettesíti a fő kurzus C++20-as alapját, és egyik sem garantálható verziófüggetlenül. A státuszkategóriák és a táblázatsablon biztosítják, hogy a későbbi átdolgozások a konkrét forráshoz és dátumhoz köthetők legyenek.

46.2.11 Feladatok

46.2.11.1 1. feladat (magyarázó)

Egy kollégád azt állítja: „a contracts támogatott C++26-ban, tehát a g++ -std=c++26 lefordítja”. Fogalmazd meg, milyen szint- és bizonyítékhiányt tartalmaz ez az állítás, és sorolj fel legalább három ellenőrzési lépést.

46.2.11.2 2. feladat (kódolási)

Egészítsd ki a serialize_cxx20.cpp példát úgy, hogy a dump függvény egy Point tömböt is kezeljen, és a buildparancsot add meg. A kód a C++20 alapszabályok szerint forduljon.

46.2.11.3 3. feladat (diagnosztikai)

Válaszd ki a fejezet öt területe közül a std::execution-t, és készíts egy táblázatsort a „forrás és dátum” sablon szerint. Add meg, hogy mely feature-test makrót (__cpp_lib_*) fogsz ellenőrizni, és miért nem elegendő a P-dolgozat hivatkozása.

46.2.12 Megoldások

46.2.12.1 1. megoldás

Az állítás két szintet mos össze: az „elfogadva C++26-ra” a working draft szintjét érinti, nem a közzétett ISO szabvány szintjét, és nem bizonyítja az implementációs támogatást. A -std=c++26 kapcsoló léte sem garancia arra, hogy a contracts szemantikája a választott compilerben megfelel a draftnak. Ellenőrzési lépések: (a) keresd meg a contracts-javaslat pontos P-számát és azt, hogy melyik working draft-kiadásba került be, dátum megjelölésével; (b) ellenőrizd, hogy a választott compiler státuszoldala a képességet „implemented”-nek jelöli-e, és melyik verziótól; (c) ellenőrizd a feature-test makrót a szabványkönyvtárban, és hogy a dokumentált szemantika (runtime/diagnosztika) egyezik-e a working draft szövegével. Csak a három lépés együttes eredménye után állítható bármi a gyakorlati használhatóságról.

46.2.12.2 2. megoldás

// serialize_cxx20_tomb.cpp — kiegészített C++20 baseline
#include <cstdio>
#include <cstddef>

struct Point { int x; int y; };

void dump(const Point& p) {
    std::printf("{x=%d, y=%d}\n", p.x, p.y);
}

void dump_array(const Point* a, std::size_t n) {
    std::printf("[");
    for (std::size_t i = 0; i < n; ++i) {
        if (i) std::printf(", ");
        dump(a[i]);
    }
    std::printf("]\n");
}

int main() {
    Point ps[3] = {{1,2}, {3,4}, {5,6}};
    dump_array(ps, 3);
    return 0;
}

g++ -std=c++20 -O2 -Wall -Wextra serialize_cxx20_tomb.cpp -o serialize_cxx20_tomb

Ellenőrzési feltétel: a fordítás -Wall -Wextra mellett figyelmeztetés nélkül menjen át; a kimenet [{x=1, y=2}, {x=3, y=4}, {x=5, y=6}] legyen. A példa a C++20 alapszabályok szerint fordítható; a futtatás a tanuló laborjában ellenőrizendő, nem tesztelt eredményként kezelendő.

46.2.12.3 3. megoldás

A táblázatsor:

A feature-test makrót (__cpp_lib_execution vagy a sender/receiver-hez tartozó, a választott standard library dokumentációjában megnevezett makró) a fordítóval kell kiértékeltetni. A P-dolgozat hivatkozása azért nem elegendő, mert az a javaslat szövegét rögzíti, nem a standard library tényleges implementációját; a makró és a library release note együtt adja a gyakorlati támogatás bizonyítékát. A shared_ptr-alapú összehasonlításhoz lásd shared ownership, reclamation és konkurens review (34.6).