Sicherheit ist ein wichtiges Thema in C++26, und Contracts sind wahrscheinlich das größte Feature für die Sicherheit. Aber C++26 hat noch viel mehr zu bieten.

Heute möchte ich drei kleine, aber wichtige Verbesserungen in C++26 vorstellen, die typische Sicherheitsprobleme in C++ lösen.

Binden einer zurückgegebenen Referenz an eine temporäre Variable

Ein Sicherheitsproblem kann schwer zu finden sein. Dieser Codeausschnitt stammt aus dem Proposal P2748R5, auf den ich in diesem Abschnitt immer wieder Bezug nehme. Ich habe ihn in ein minimales, ausführbares Programm umgewandelt.

// bindReferenceToTemporary.cpp

#include 
#include 
#include 

const std::string_view& getString() {
    static std::string s = "Hallo Welt!";
    return s;
}

int main() {
    std::cout << getString() << '\n';
}   

Der GCC-Compiler gibt bereits eine aussagekräftige Fehlermeldung aus:

Hier kommt ein weiteres Beispiel mit einem Fehler im Code:

struct X {
    const std::map<:string int=""> d_map;
    const std::pair<:string int="">& d_first;

    
X(const std::map<:string int="">& map)
        : d_map(map), d_first(*d_map.begin()) {}
};

Wer den Code geschrieben hat, hat übersehen, dass das erste Element des Paares, das als Schlüssel bezeichnet wird, konstant ist. Dadurch wird eine temporäre Variable erstellt. Infolgedessen ist d_first nicht mehr gültig.

Das bringt uns zur nächsten Sicherheitsverbesserung.

Fehlerhaftes Verhalten bei nicht initialisierten Lesevorgängen

Ich beziehe mich auf den Proposal P2795r5.

Zunächst einmal gilt es für Objekte mit automatischer Speicherdauer und temporäre Objekte. Deren Besonderheit ist, dass sie auf einen beliebigen Wert initialisiert werden. Das bedeutet, dass das Programm ein undefiniertes Verhalten aufweist.

Damit bleibt noch eine Frage offen: Was bedeutet automatische Speicherdauer? Die folgenden Variablen haben eine automatische Speicherdauer:

• Variablen, die einen Blockbereich haben und nicht explizit als static, thread_local oder extern deklariert wurden. Der Speicher dieser Variablen bleibt nur so lange gültig, bis der Block abgeschlossen ist.
• Variablen, die zu einem Parameterbereich gehören, beispielsweise einer Funktion. Sie werden automatisch zerstört, wenn der Parameterbereich aufgelöst wird.

Zwei Beispiele aus dem Proposal sollen diese Begriffe verdeutlichen:

extern void f(int);

int main() {
  int x;     // default-initialized, value of x is indeterminate
  f(x);      // glvalue-to-prvalue conversion has undefined behaviour
}   

void f(T&);
void g(bool);

void h() {
  T* p;    // uninitialized, has erroneous value (e.g. null)
  bool b;  // uninitialized, erroneous value may not be valid bool

  f(*p);   // dereferencing has undefined behaviour
  g(b);    // undefined behaviour if b is invalid
}

Um es auf den Punkt zu bringen: Der Proposal verwandelt nicht initialisierte Lesevorgänge, die in C++23 ein undefiniertes Verhalten darstellten, in fehlerhafte Programme in C++26.

Natürlich kann die vollständige Initialisierung automatischer Variablen ein relativ aufwendiger Vorgang sein. Daher gibt es einen Opt-out-Mechanismus:

Das Attribut [[indeterminate]] repräsentiert den Opt-out-Mechanismus. Dieses Feature ist nur für Experten gedacht. Das Attribut ermöglicht es, Variablen mit automatischer Speicherung, die nicht initialisiert wurden, zu lesen, ohne dass das Programm fehlerhaft ist. Das folgende vereinfachte Beispiel stammt aus dem Proposal:

int x [[indeterminate]];
std::cin >> x;

[[indeterminate]] int a, b[10], c[10][10];
compute_values(&a, b, c, 10);

// This class benefits from avoiding determinate-storage initialization guards.
struct SelfStorage {
  std::byte data_[512];
  void f();   // uses data_ as scratch space
};

SelfStorage s [[indeterminate]];   // documentation suggested this

void g([[indeterminate]] SelfStorage s = SelfStorage());   // same; unusual, but plausible

Die letzte Sicherheitsfunktion betrifft unvollständige Typen.

Unzulässiges Löschen eines Zeigers auf einen unvollständigen Typ

Ein unvollständiger Typ ist ein Datentyp, für den nur die Deklaration, aber keine Definition existiert. Ein Zeiger oder eine Referenz auf einen unvollständigen Typ ist völlig in Ordnung. Operationen, die die Größe, das Layout oder die Mitgliedsfunktionen dieses Datentyps erfordern, sind jedoch fehlerhaft.

Die neue Funktion ist etwas spezifischer: Das Löschen eines Zeigers auf einen unvollständigen Klassentyp ist fehlerhaft, es sei denn, dieser Klassentyp verfügt über einen trivialen Destruktor und keine klassenspezifische Deallokations-Funktion. Das bedeutet, dass der Compiler den Destruktor der Klasse erstellt hat und operator delete in der Klasse nicht überladen wurde.

Der Proposal liefert ein gutes Beispiel, um den feinen Unterschied zwischen einem trivialen Destruktor und einem nicht-trivialen Destruktor zu veranschaulichen:

Triviale Destruktoren:

// trivialDestructor.cpp
    
namespace xyz {
  struct Widget; // forward decl
  Widget *new_widget();
} // namespace xyz

int main() {
  xyz::Widget *p = xyz::new_widget();
  delete p;
}

namespace xyz {
struct Widget {
  const char *d_name;
  int         d_data;
  // (implicit) trivial destructor
  // This is the only difference.
}; 

Widget *new_widget() { 
    return new Widget(); 
}
} // namespace xyz

Nicht-trivialer Destruktor:

// nontrivialDestructor.cpp

namespace xyz {
  struct Widget; // forward decl
  Widget *new_widget();
} // namespace xyz

int main() {
  xyz::Widget *p = xyz::new_widget();
  delete p;
}
namespace xyz {
struct Widget {
  const char *d_name;
  int         d_data;
  ~Widget() {} // nontrivial dtor
  // This is the only difference.
};

Widget *new_widget() { 
    return new Widget(); 
}
} // namespace xyz

Das zweite Beispiel enthält einen nicht-trivialen Destruktor. Entsprechend dem Proposal bricht die Kompilierung mit einer Fehlermeldung ab:

Wie geht es weiter?

In meinem nächsten Artikel werde ich mich mit einigen kleineren Verbesserungen rund um Templates befassen. Diese Verbesserungen dienen in erster Linie dazu, inkonsistentes Verhalten in C++ zu beseitigen.

(rme)

Large Language Models (LLMs) wie GPT, LLaMA oder Claude prägen die aktuelle Diskussion rund um Künstliche Intelligenz. Sie schreiben Texte, beantworten Fragen, übersetzen Inhalte und lösen scheinbar komplexe Aufgaben. Ihr Auftreten wirkt oft fast menschlich, weshalb viele Menschen ihnen ein Verständnis oder gar eine Form von Intelligenz zuschreiben.

In Wirklichkeit sind LLMs jedoch keine denkenden Systeme, sondern extrem leistungsfähige statistische Modelle, die Wahrscheinlichkeiten für Wortfolgen berechnen. Ihr Erfolg beruht auf drei Faktoren: enormen Datenmengen, gigantischen Modellgrößen und der Transformer-Architektur.

Dieser Beitrag erklärt, was LLMs sind, wie sie trainiert werden und warum sie wirken, als könnten sie „denken“.

Was ein Large Language Model ist

Ein LLM ist ein neuronales Netz – in der Regel ein Transformer-Decoder –, das auf die Vorhersage des nächsten Tokens in einer Zeichen- oder Wortfolge trainiert wird. Vereinfacht gesagt: Es lernt, welches Wort mit welcher Wahrscheinlichkeit folgt.

Ein Token kann dabei ein ganzes Wort, eine Silbe oder sogar nur ein Zeichen sein. Indem das Modell diese Wahrscheinlichkeiten Schritt für Schritt nutzt, kann es Texte generieren, die flüssig und plausibel wirken.

Die Bezeichnung „Large“ hat dabei zwei Dimensionen:

1. Modellgröße: Moderne LLMs besitzen Milliarden von Parametern.
2. Datenmenge: Sie werden auf gigantischen Textkorpora trainiert, die aus Büchern, Webseiten, Artikeln und Code bestehen.

Die Kombination aus Größe und Datenvielfalt erlaubt es den Modellen, extrem viele sprachliche Muster zu erfassen.

Training durch Vorhersage

Das Training eines LLM folgt einem simplen Prinzip, der „Next Token Prediction“: Das Modell sieht eine Sequenz von Token und soll das nächste Token vorhersagen. Diese Vorhersage wird mit der tatsächlichen Fortsetzung verglichen, der Fehler berechnet und die Modellgewichte werden per Gradientenverfahren angepasst.

Dieses Verfahren nennt man „Self-Supervised Learning“, da die Trainingsdaten automatisch Zielwerte liefern. Jeder Text bietet unzählige Trainingsbeispiele, ohne dass jemand manuell Labels erstellen muss.

Durch Milliarden von Trainingsschritten lernt das Modell:

• Grammatik und Syntax,
• typische Wortkombinationen und Redewendungen und
• implizite Strukturen wie Fakten, logische Muster oder sogar einfache Rechenregeln.

All das entsteht rein statistisch, ohne dass das Modell die Bedeutung der Wörter versteht.

Warum LLMs so kompetent wirken

Die Wirkung eines LLM beruht darauf, dass Sprache selbst ein enorm starkes Trägermedium für Wissen ist. Wer genügend Sprachmuster gesehen hat, kann in vielen Fällen den Anschein von Verständnis erzeugen.

Wenn Sie eine Frage stellen, produziert das Modell die wahrscheinlichste Wortfolge, die in seinem Trainingsuniversum auf diese Eingabe folgen könnte. Da menschliche Antworten auf Fragen oft konsistent sind, entsteht der Eindruck von Intelligenz.

Dieses Verhalten erklärt zugleich aber auch typische Schwächen:

• Halluzinationen: Modelle erfinden plausible, aber falsche Fakten, weil sie nicht prüfen können, ob etwas wahr ist.
• Mangel an echtem Verständnis: LLMs wissen nicht, was ihre Ausgaben bedeuten.
• Sensibilität für Formulierungen: Kleine Änderungen im Prompt können große Unterschiede in der Ausgabe bewirken.

LLMs sind also kompetente Sprachmustermaschinen, aber keine wissenden Systeme.

Der Einfluss von Feintuning und RLHF

Viele bekannte Modelle werden nach dem Grundtraining noch optimiert, zum Beispiel durch:

• Instruction Tuning: Das Modell lernt, Eingaben wie Anweisungen zu interpretieren und höflich zu antworten.
• RLHF (Reinforcement Learning from Human Feedback): Menschliche Bewertungen lenken das Modell in Richtung erwünschter Antworten.

Diese Schritte tragen stark dazu bei, dass ein LLM „hilfreich“ und „menschlich“ wirkt. Es spiegelt aber weiterhin nur Muster, die in Daten und Feedback enthalten sind.

Grenzen und Einsatzbereiche

LLMs sind mächtig, aber nicht universell:

• Sie können keine aktuellen Informationen ohne externe Anbindung bereitstellen.
• Sie besitzen kein Weltmodell und können keine logischen Schlüsse jenseits der gelernten Muster ziehen.
• Sie sind rechen- und datenintensiv, was den Einsatz in Unternehmen erschwert.

Trotzdem bilden sie die Grundlage vieler moderner KI-Anwendungen: Textgenerierung, Chatbots, Code Completion, semantische Suche oder Dokumentenzusammenfassungen.

Ausblick

Der nächste Teil dieser Serie wird sich der symbolischen KI und hybriden Ansätzen widmen. Er wird zeigen, warum klassische Wissensrepräsentationen wieder an Bedeutung gewinnen und wie sich statistische und symbolische Verfahren kombinieren lassen.

(rme)

Es ist ein Schritt in Richtung eigener Hardware samt App-Ökosystem. Meta bietet künftig ein Wearables Device Access Toolkit für Entwickler an. Das heißt, sie können damit Apps erstellen, die dann Metas Vision- und Audio-Fähigkeiten in den Brillen nutzen können.

„Angesichts des Erfolgs, den wir mit diesem Formfaktor erzielt haben, möchten wir eine Plattform bereitstellen, auf der Sie als Entwickler Erfahrungen entwickeln können, die die Funktionen von KI-Brillen für Nutzer Ihrer mobilen Anwendungen erweitern“, schreibt Meta im Blogbeitrag. Angesichts der Tatsache, dass sich Meta bisher mit seinen erfolgreichen Diensten Facebook, Instagram und WhatsApp auf die Vorgaben von Apple und Google einlassen musste, erscheint der Schritt für Meta wie eine Art Befreiungsschlag. Endlich ein eigenes Ökosystem und eigene Vorgaben für andere Anbieter. Freilich gibt es das auch bereits rund um die Quest, die trägt jedoch nicht zum wirtschaftlichen Erfolg bei, wie die Plattform-Dienste.

Das Meta Wearables Device Access Toolkit, wie es etwas sperrig heißt, wird zunächst gegen Ende des Jahres als Preview verfügbar sein. Auch wird mit ihm offenbar noch nicht der volle Funktionsumfang der smarten Brillen nutzbar sein. So heißt es im Blogbeitrag: „Unsere erste Version des Toolkits gibt Zugriff auf eine Reihe von Sensoren im Gerät, sodass Funktionen in mobilen Apps entwickelt werden können, die die Vorteile der Freisprechfunktion von KI-Brillen nutzen.“ Als Beispiel sagt Meta, könne man „POV-Erlebnisse“ entwerfen, für die die Kamera der Brille genutzt werden – POV steht für Point of Viiew und wird häufig als Zusatz in sozialen Netzwerken genutzt, wenn jemand etwas in Ich-Perspektive meint. Man kann also mit dem Toolkit künftig auf die Kamera zugreifen.

Auch soll „freihändige Informationsbeschaffung und Kommunikation“ möglich sein. Das bedeutet dann wohl Zugriff auf die Mikrofone und den Audioausgang.

Disney und Twitch testen bereits Metas Toolkit

Alles wird jedoch erstmal nur als Betaversion verfügbar sein – und damit auch nur in einer Testumgebung auszuprobieren. Meta entscheidet nach ausreichenden Tests, was welche Entwickler auch tatsächlich veröffentlichen dürfen. SDK, Dokumentation und Testumgebung stellt Meta bereit.

Schon vorab dürfen offenbar Twitch und Disney testen. So sollen Creator künftig via Meta-Brille live bei Twitch streamen können. Disney arbeitet an einem Prototyp, mit dem Besucher der Disneyparks über die KI-Brillen Informationen und Unterhaltung erhalten, heißt es in einem weiteren Blogbeitrag zur Connect-Virtual-Reality-Keynote. Schon vor zwei Jahren sprach Disneys-CEO Bob Chapek davon, Sehgewohnheiten von Disney+ dafür nutzen zu wollen, personalisierte Erlebnisse in dem Park anzubieten.

(emw)