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)

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)

Das eigene Softwareprodukt entwickeln und verkaufen: Wenn ein Projekt langsam an Fahrt aufnimmt, Nutzerzahlen gewinnt oder Popularität in Fachkreisen erlangt, liegt der Gedanke nahe. Doch an welchem Punkt ist es überhaupt sinnvoll, darüber nachzudenken? Klaus Wagner, Gründer von ox8 Corporate Finance, gewährt einen Blick hinter die Kulissen.

Herr Wagner, an welchem Punkt im Entwicklungsprozess kann man darüber nachdenken, ein Softwareprodukt zu verkaufen? Welche Voraussetzungen sollte es bereits mitbringen?

Heutzutage verkaufen die meisten Softwareunternehmen keine einmaligen Lizenzen für fertige Produkte mehr. Stattdessen dominieren Abo-, Miet- oder SaaS-Modelle, bei denen Lizenzen zeitlich begrenzt vergeben werden – oft mit dem Versprechen einer kontinuierlichen Weiterentwicklung und regelmäßiger Updates. Das wirkt sich unmittelbar auf die Go-to-Market-Strategie aus: Softwareprodukte werden heute deutlich schneller auf den Markt gebracht als früher. Ein vollständig ausgereiftes Produkt ist nicht mehr Voraussetzung für den Verkaufsstart. Wichtig ist vielmehr, dass die Software einen klaren Mehrwert für die Zielgruppe bietet, ein konkretes Kundenbedürfnis adressiert und für den Endnutzer bereits funktional und benutzbar ist – also mindestens ein Minimum Viable Product (MVP) darstellt. Natürlich sollte bereits zum Verkaufsstart ein valider Business Case erkennbar sein, das Produkt muss zum Markt passen – selbst wenn es noch nicht final ausgereift ist. Weitere Funktionalitäten und Optimierungen – insbesondere im Frontend – folgen dann schrittweise, basierend auf Nutzerfeedback und Marktanforderungen.

Und welche Softwareprodukte sind im Augenblick besonders gefragt? Wie wichtig sind Hypes?

Auf Basis unserer Marktbeobachtungen und laufender M&A-Mandate sehen wir, dass Softwareprodukte mit wiederkehrenden Umsätzen weiterhin besonders gefragt sind – sowohl bei Kunden als auch bei Investoren. Geschäftsmodelle auf Abonnementbasis bieten eine hohe Planbarkeit der Einnahmen, was speziell für Investoren bei der Unternehmensbewertung ein zentrales Kriterium darstellt. Wenn solche Modelle zusätzlich durch starke operative Kennzahlen überzeugen, steigt ihre Attraktivität erheblich. Das können etwa signifikantes Umsatzwachstum, hohe Kundenbindung – Stickiness –, geringe Abhängigkeit von einzelnen Großkunden sowie langfristige Vertragslaufzeiten sein. In solchen Fällen sind Investoren oftmals bereit, eine höhere Bewertungs-abhängige Prämie zu zahlen, da sie das Modell als stabil, skalierbar und nachhaltig einschätzen Gleichzeitig spielen technische Hypes im M&A-Markt durchaus eine Rolle – aktuell etwa rund um KI-gestützte oder KI-native Softwareunternehmen. Sie gelten als besonders zukunftsfähig, öffnen neue Anwendungsfelder und bieten die Chance auf nachhaltige Wettbewerbsvorteile. Investoren suchen also verstärkt nach zukünftigen Schlüsselunternehmen mit echtem Mehrwert und klarer Differenzierung im Wettbewerb. Hypes sind dabei nicht nur kurzfristige Phänomene, sondern wichtige Impulsgeber: Sie lenken das Kapital in bestimmte Innovationsfelder, beschleunigen technologische Entwicklung und wirken oft als Treiber für gesamte Branchen.

Wie preist man sein Produkt dann ein? Muss ich mich voll auf das Angebot eines Käufers verlassen oder gibt es Anhaltspunkte, nach denen ich mich richten kann?

Die Preisgestaltung von Software ist ein komplexes Thema – geprägt von Markttrends, Wettbewerbsanalysen und dem wachsendem Einfluss spezialisierter Pricing-Experten. Viele vertreten den Anspruch, den idealen Ansatz für eine optimale Preisstrategie gefunden zu haben. Idealerweise verfolgt man einen wertbasierten Ansatz, bei dem sich der Preis am konkreten Nutzen orientiert, den das Produkt für den Kunden stiftet – also am geschaffenen Mehrwert oder an messbaren Effizienzgewinnen. Auf dieser Basis lässt sich eine nachvollziehbare Preisstruktur entwickeln. Natürlich darf man hierbei den Wettbewerb als Referenzrahmen nicht aus den Augen verlieren: Etwa bei der Frage, ob das eigene Produkt eine Premium-Positionierung rechtfertigt oder preislich im Mittelfeld angesiedelt sein sollte. Es ist dabei entscheidend, wie hoch die Akzeptanz unterschiedlicher Preismodelle in der jeweiligen Zielgruppe und im Zielmarkt ist. Unsere Erfahrung zeigt übrigens: Fast alle Softwareunternehmen, die wir betreut haben, haben ihre Preisstruktur im Laufe der Zeit mindestens einmal deutlich angepasst.

Herr Wagner, vielen Dank für die Antworten.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(kki)