Connect with us

Entwicklung & Code

Von undefiniert zu definiert: Die Verwendung von std::launder in C++


Im heutigen Beitrag knüpfe ich an die übergreifenden Themen der letzten beiden Monate an. Heute geht es darum, wann und wo du std::launder aus C++17 einsetzen musst und worin der Unterschied zu reinterpret_cast oder std::start_lifetime_as besteht.

Weiterlesen nach der Anzeige


Portrait von Andreas Fertig

Portrait von Andreas Fertig

Andreas Fertig ist erfahrener C++-Trainer und Berater, der weltweit Präsenz- sowie Remote-Kurse anbietet. Er engagiert sich im C++-Standardisierungskomitee und spricht regelmäßig auf internationalen Konferenzen. Mit C++ Insights ( hat er ein international anerkanntes Tool entwickelt, das C++-Programmierenden hilft, C++ noch besser zu verstehen.

Die Bereiche, in denen man das heute Gelernte anwenden kann, sind vielfältig. Im Embedded-Bereich wird std::launder in der Regel verwendet, aber auch beim Schreiben von Bibliothekscode kommt „Laundering“ (zu Deutsch waschen und bügeln, gerne im Zusammenhang mit „Money“ als Geldwäsche) vor.

Wann es zu Problemen kommen kann

Ich verwende das Beispiel aus dem Paper P0532R0:


struct X {
  const int n;  // #A
  double    d;
};

X* p = new X{7, 8.8};  // #B

new(p) X{42, 9.9};  // #C

int  i = p->n;  // #D
auto d = p->d;  // #E


Hier stehen mehrere Teile, die zusammenpassen müssen. Beachte, dass das struct X das Datenfeld n als const deklariert.

Als Nächstes wird mithilfe von new in #B ein Objekt erstellt und der resultierende Zeiger in p gespeichert. So weit, so gut.

Weiterlesen nach der Anzeige

Der interessante Teil beginnt als Nächstes in #C mit dem Platzierungs-new. Wer das noch nie gemacht hat, muss den eigenen C++-Code vielleicht nicht waschen und glatt bügeln.

Das Platzierungs-new selbst ist auch in Ordnung. Das Problem tritt später in #D und #E auf. Hier wird auf die Werte des Zeigers p zugegriffen. Aber der Compiler darf davon ausgehen, dass nach #B der Inhalt von p unverändert ist, da p selbst nie dazu verwendet wurde, den Inhalt des Objekts zu ändern. Noch schlimmer: Eines der Datenelemente von X ist const. Das ist eine Freikarte für den Optimierer, zu Recht anzunehmen, dass sich der Wert von n nach der Konstruktion nie ändert.

Aber genau das habe ich in #C getan. Ich ändere einen const-Wert! Die Werte von i und d sind unbekannt. Das ist undefiniertes Verhalten.

Dieses lässt sich leicht vermeiden, sogar ohne std::launder, indem man den Zeiger aktualisiert und dem Compiler mitteilt, dass sich die Werte hinter p geändert haben:


X* p = new X{7, 8.8};  // #B

p = new(p) X{42, 9.9};  // #C

int  i = p->n;  // #D
auto d = p->d;  // #E


Die Frage ist also: Warum macht man das nicht einfach und vergisst std::launder? Nun, wann immer möglich, vergiss std::launder.

Leider gibt es Fälle, in denen das Aktualisieren des Zeigers wertvolle Ressourcen opfern würde.

Wenn es komplizierter wird

Angenommen, du implementierst einen benutzerdefinierten Allokator:


template
class Buffer {
  alignas(ALIGNMENT) std::byte mBuffer[SIZE];

public:
  template
  T* Construct(Ts... vals)
  {
    new(mBuffer) T{std::forward(vals)...};
    return reinterpret_cast(mBuffer);
  }

  template
  [[nodiscard]] T* Get()
  {
    return reinterpret_cast(mBuffer);
  }
};


Du siehst hier zwei Funktionen, die der Allokator bereitstellt: Construct und Get. Das Konzept von Buffer besteht darin, dass die gespeicherten Daten typunabhängig sind. Eine mögliche vereinfachte Verwendung könnte folgendermaßen aussehen:


struct Point {  // #A
  int x;
  int y;
};

struct Point3D {
  int x;
  int y;
  int z;
};

std::array, 2> storage{};  // #B

// #C
storage.at(0).Construct(2, 3);
storage.at(1).Construct(4, 5, 6);

// #D
storage.at(0).Get()->x = 7;


Die zwei Datentypen Point und Point3D in #A stehen als Beispiel für beliebige Typen. storage steht für den Stack-Speicher, der beliebige Daten speichern kann. Solange die Nutzer wissen, welcher Datentyp hinter einem Index steckt (und dieser Typ nicht zu groß ist), kann alles gespeichert werden.

Am ersten Element des Arrays #C konstruiere ich ein Point-Objekt, während ich am zweiten Element ein Point3D erstelle. Erst später im Programm #D werden die Objekte tatsächlich verwendet. Dennoch hat niemand aus gutem Grund einen Zeiger auf das frisch konstruierte Objekt gespeichert. Ein solcher Zeiger würde Speicherkapazität erfordern, und du weißt bereits, wohin dieser Zeiger zeigt.

Aus der Perspektive der abstrakten Maschine habe ich Löcher in das Typsystem gestochen. Der Compiler kann zu Recht davon ausgehen, dass sich die Daten hinter Get nicht ändern, es sei denn, er sieht etwa einen direkten Schreibzugriff #D. Ein solcher Zugriff bleibt vom Compiler unbemerkt (oder könnte es bleiben, da es sich um undefiniertes Verhalten handelt) im folgenden Code in #E, wenn ich an einer bestehenden Stelle ein neues Point-Objekt erstelle:


std::array, 2> storage{};  // #B

// #C
storage.at(0).Construct(2, 3);

// #D
storage.at(0).Get()->x = 7;

// #E
storage.at(0).Construct(8, 9);


Offensichtlich lässt sich das Problem hier am einfachsten vermeiden, indem man den von jedem Construct-Aufruf zurückgegebenen Zeiger speichert. Wenn das, wie hier, nicht machbar ist, besteht die richtige Vorgehensweise darin, den Zeiger mit std::launder zu „waschen“. Dieses spezielle Hilfsmittel fungiert als Devirtualisierungsbarriere, die Compiler-Optimierungen und -Annahmen verhindert.

std::launder zur Rettung

So lässt sich die Buffer-Implementierung auf sichere Weise aktualisieren. Zunächst zu Construct: Meine ursprüngliche Implementierung sah so aus:


template
T* Construct(Ts... vals)
{
  new(mBuffer) T{std::forward(vals)...};
  return reinterpret_cast(mBuffer);
}


Du kannst diesen Code auch ohne std::launder sicher machen, indem du den von new zurückgegebenen Zeiger zurückgibst:


template
T* Construct(Ts... vals)
{
  return new(mBuffer) T{std::forward(vals)...};
}


Die zweite Funktion, die du korrigieren musst, ist Get, dieses Mal durch Hinzufügen von std::launder:


template
[[nodiscard]] T* Get()
{
  return std::launder(reinterpret_cast(mBuffer));
}


Der Code geht nun davon aus, dass du Construct aufrufst, bevor du Get aufrufst. Dieser mBuffer enthält ein gültiges Objekt, das mit dem übereinstimmt, das mit Construct erstellt wurde.

Mit std::launder kannst du einen Zeiger aktualisieren, der auf ein bereits vorhandenes Objekt an dieser Speicheradresse verweist. Die Lebensdauer des Objekts an dieser Stelle hat also bereits begonnen.


(rme)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

KI-Portierung: Claude schreibt Bun-Codebasis in Rust neu


Bun ist einst angetreten, um Node.js als JavaScript-Server, NPM als Paketmanager und Bundler wie esbuild mit einer Software zu ersetzen. Ende 2025 übernahm die KI-Firma Anthropic das Open-Source-Projekt und das Bun-Entwicklerteam. Die Begründung: Anthropic nutzt Bun bereits für Claude Code und das Claude Agent SDK.

Weiterlesen nach der Anzeige

Jetzt wird klar, dass die Übernahme des Projekts durch die KI-Firma Anthropic nicht folgenlos bleibt: Ende April erschien ein Branch, in dem das Sprachmodell Claude auf Anweisung die gesamte Codebasis von Zig auf Rust umzieht. Noch am 5. Mai ordnete Jarred Sumner, Gründer von Bun, diese Entwicklung ein und versuchte damit, eine Diskussion zu beruhigen: „I work on Bun and this is my branch. This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.“

Doch es kam anders und die Ansätze wurden nicht verworfen: Am 14 Mai wurden die Änderungen vielmehr in den Main-Branch übernommen – 2188 Dateien geändert, eine Million Zeilen neu geschrieben, 4000 Zeilen gelöscht. Bun ist damit komplett in Rust geschrieben.

Dieses Vorgehen stößt nicht nur auf Begeisterung. Während Jarred Sumner auf GitHub ankündigt, Details im Blog veröffentlichen zu wollen, beginnt die Diskussion unter dem Beitrag. Kritisiert wird unter anderem, dass einige der alten Tests verändert wurden, damit die Rust-Version sie erfolgreich durchläuft. Auf Jarreds Aussage „We now have compiler-assisted tools for catching & preventing memory bugs“ reagieren Kommentatoren, dass das nur zutreffe, wenn man im Code nicht inflationär das Schlüsselwort unsafe verwende, wie Claude es getan habe.

Weiterlesen nach der Anzeige

Für das Bun-Team beginnt der größte Teil der Arbeit jetzt: In den GitHub-Issues sammeln sich bereits die ersten Probleme, die mit der Zig-Version nicht auftraten. Noch ist die Rust-Version nicht mit Versionsnummer veröffentlicht, doch das scheint nur eine Frage der Zeit zu sein. Wer Bun nutzt und zunächst abwarten möchte, sollte seine Version auf 1.3.14 festnageln. Das könnte die letzte Zig-Version bleiben.

Was kostet das?

Ein kompletter Umzug eines Projekts dieser Größe, komplett von einem LLM erledigt – das ist ein Novum in der Softwareentwicklung. Wie viele Token Bun dafür aufgewendet hat, verrät Jarred bisher nicht. Erst mit dieser Information könnte man errechnen, was ein solcher Umzug kosten würde, wenn man nicht gerade von Anthropic übernommen wurde.


(jam)



Source link

Weiterlesen

Entwicklung & Code

SAP investiert: n8n wird eines der wertvollsten deutschen KI-Startups


Deutschlands Softwareriese SAP investiert erneut in KI-Startups, diesmal in den Berliner Automatisierungsspezialisten n8n sowie in das KI-Kundenservice-Unternehmen Parloa. Konkrete Summen nennen die Beteiligten nicht. n8n teilt aber mit, dass die eigene Bewertung durch die Investition 5,2 Milliarden US-Dollar erreicht habe.

Weiterlesen nach der Anzeige

Das sei eine Verdopplung innerhalb weniger als eines Jahres und hebt n8n unter die am höchsten bewerteten KI-Startups in Deutschland. Spitzenreiter bleibt das Münchner KI-Drohnen-Startup Helsing, das laut jüngsten Berichten bald eine Bewertung von 18 Milliarden US-Dollar erreichen könnte.

Automatisierung und KI-Kundenservice

Die Produkte von n8n und Parloa passen gut in die Vision des autonomen Unternehmens, die SAP diese Woche bei der Hausmesse Sapphire vorgestellt hat. In einer autonomen Firma sollen KI-gestützte Assistenzen Hand in Hand mit menschlichem Personal arbeiten und Geschäftsabläufe vollständig übernehmen. n8ns Automatisierungswerkzeug soll laut Mitteilung in Kürze nativ innerhalb der Entwicklungsumgebung Joule Studio auf der SAP Business AI Platform verfügbar sein. Mit n8n lassen sich unter anderem KI-Workflows visuell erstellen und orchestrieren.

Auch bei Parloa geht es laut der Mitteilung nicht nur um eine strategische Investition, sondern um Produktintegration. Parloas KI-Agenten für Kundenservice über digitale Kanäle und Call-Center sollen sich mit Business-Daten und Prozessen aus der SAP Service Cloud verknüpfen können. Parloa verspricht dabei agentischen Kundenservice, der ein hohes Interaktionsvolumen bewältigen könne und sehr menschlich und markenkonform agiere. Parloas AI Agent Management Platform, die Agentenverwaltung von Design und Testing bis zu Deployment und Optimierung unterstützen soll, findet zudem Eingang in SAPs Geschäfts-App-Store.

SAP shoppt Start-ups

Laut Handelsregister steigt die Beteiligung SAPs an n8n auf fast 1,3 Prozent. Wie das Handelsblatt unter Berufung auf Insider schreibt, steckt SAP 60 Millionen in n8n; auch für Parloa soll ein zweistelliger Millionenbetrag geflossen sein.

Weiterlesen nach der Anzeige

Anfang Mai hat SAP das Freiburger KI-Startup Prior Labs übernommen, das sich auf Tabellarische Foundation Models konzentriert, und Pläne zur Übernahme der US-Datenplattform Dremio bekannt gemacht. Bereits im März ist bekannt geworden, dass SAP mit Reltio einen anderen Datenspezialisten aus den USA übernehmen will.


(axk)



Source link

Weiterlesen

Entwicklung & Code

Red Hat baut Ansible zur Steuerzentrale für KI-Agenten um


Red Hat wird die Ansible Automation Platform um viele neue Funktionen für KI-gestützte IT-Automatisierung erweitern. Im dritten Quartal soll eine neue Version erscheinen, in deren Mittelpunkt der Automation Orchestrator steht. Damit soll die Ansible-Plattform zur zentralen Ausführungsebene für KI-gestützte IT-Operationen werden. Der Orchestrator analysiert Signale von KI-Systemen oder Agenten, erkennt Zusammenhänge und schlägt Maßnahmen vor. Die eigentliche Umsetzung erfolgt über definierte Automatisierungsabläufe in Ansible. Red Hat nennt dieses Prinzip: „KI empfiehlt, Menschen genehmigen und die Automations-Plattform führt aus.“

Weiterlesen nach der Anzeige

Des Weiteren soll der Orchestrator unterschiedliche Quellen und Werkzeuge in einem gemeinsamen Ablauf verbinden. Beispielsweise können Alerts von IBM Instana, ServiceNow oder Splunk denselben Workflow starten, bei dem ein Ticket angelegt wird, eine KI den Vorfall analysiert und eine geeignete Maßnahme empfohlen wird. Anschließend muss eine Person diese Aktion freigeben, bevor Ansible das Problem automatisch beheben darf. Das heißt, der Orchestrator nutzt die vorhandenen Automatisierungen, statt diese zu ersetzen. Viele Unternehmen verfügen bereits über Skripte, Runbooks und Ansible-Playbooks, die der neue Orchestrator in KI-gestützte Prozesse einbindet.

Rechte begrenzen und kontrollieren

„KI-Agenten werden in der IT-Administration nur dann erfolgreich sein, wenn sie mit klar begrenzten Rechten innerhalb bewährter Leitplanken operieren“, sagt Sathish Balakrishnan, Vice President der Ansible Business Unit bei Red Hat. „KI kann Situationen analysieren und Maßnahmen empfehlen, doch die Ausführung muss immer über geprüfte Playbooks, Freigaben, Rollenmodelle und Audit-Trails erfolgen“, so Balakrishnan weiter.

Einen Schwerpunkt der neuen Version bilden Kontrollmechanismen. Dazu zählen rollenbasierte Zugriffe, Approval Gates, Auditing, Content Signing und Credential Management. Diese Kontrollmechanismen sollen unabhängig davon gelten, ob eine Automatisierung klassisch aufgabenbasiert, eventgetrieben oder KI-gestützt ausgelöst wird.

Ansible 2.7: Mehr Transparenz und MCP-Server

Parallel hat Red Hat die Ansible Automation Platform 2.7 angekündigt. Sie bringt unter anderem einen visuellen Editor für Execution Environments, einen Content-Katalog und Automation-Dashboards. Diese Dashboards sollen helfen, die Leistung und den wirtschaftlichen Nutzen der Automatisierung besser nachzuvollziehen.

Für AIOps wurde die Ansible-Plattform um einen MCP-Server (Model Context Protocol) erweitert, der auf den bestehenden Ansible-Kontrollen für Benutzeridentitäten, Zugangsdaten und rollenbasierten Zugriffen aufsetzt. Der MCP-Server kann auch im Read-only-Modus betrieben werden, um riskante Aktionen über Human-in-the-loop-Freigaben abzusichern. Hinzu gekommen sind AIOps-Solution-Guides. Der erste davon bietet Integrationen mit IBM Instana, ServiceNow und Splunk. Das ist für Betriebsumgebungen gedacht, in denen Observability-, ITSM- und Security-Signale bereits aus verschiedenen Systemen anfallen. Der Orchestrator soll diese Signale in kontrollierte Automatisierungsabläufe überführen, statt die vorhandenen Werkzeuge zu ersetzen.

Weiterlesen nach der Anzeige

Für Entwickler und Automatisierungsteams gibt es eine Erweiterung, über die per MCP KI-Anwendungen und MCP-Clients angebunden werden können, darunter Claude oder Cursor. Zudem unterstützt ein intelligenter Assistent „bring-your-own-knowledge“, mit dem Modellantworten stärker auf vorhandenes Betriebswissen, Playbooks und interne Abläufe zugeschnitten werden.


(fo)



Source link

Weiterlesen

Beliebt