Bereits im Herbst oder Winter soll es so weit sein: Apple will Insidern zufolge erstmals einen Touchscreen in einen Mac einbauen. Die Hardware-Umstellung soll aber keinen grundsätzlichen Strategiewechsel darstellen, behauptet der üblicherweise gut informierte Bloomberg-Reporter Mark Gurman: Eine Fusion von MacBook und iPad steht demnach nicht an, zu einer Hybrid-Maschine kommt es nicht. Der Grund ist einfach: Apple hat nicht vor, aus zwei lukrativen Produktlinien eine einzige zu machen.

Touch als „Bonus“

Der neue Touchscreen-Mac – vermutlich in Form eines umgestalteten MacBook Pro – soll daher „Touch-freundlich“, aber nicht „Touch-first“ sein. Die Idee ist, dass Nutzer vergleichsweise bequem zwischen Finger- und Tastatursteuerung wechseln können sollen. Weder an der vollwertigen Tastatur noch am Trackpad soll sich etwas ändern, stattdessen wird macOS so angepasst, dass es sich alternativ auch mit den Fingern bedienen lässt. Eine gewisse Vorarbeit gab es bereits durch Apples Liquid-Glass-Interface in macOS 26, mit macOS 27 sollen sich Menüs, Icons und andere Bedienelemente automatisch anpassen, je nachdem, wie der Nutzer arbeitet. Die Maschine soll sich nicht anfühlen wie ein iPad, so Gurman. Es sei das MacBook, das man seit zwei Jahrzehnten kennt – Touch diene als „Bonus“.

Die Hardware soll sich vom Formfaktor her auch nicht ändern. So wird man den Bildschirm nicht nach hinten klappen können, um den Mac im reinen Tabletbetrieb zu verwenden. Wie angenehm die Touch-Bedienung im Rahmen einer Notebook-Anordnung sein wird, muss sich zeigen – schon der 2011 verstorbene Apple-Mitbegründer Steve Jobs hatte vor Jahren bemängelt, dass einem dabei potenziell der Arm abfällt. Resultat war das iPad als eigene Produktkategorie.

Umsatzfragen und ein riesiges Foldable

Apple will dennoch seine Einnahmen durch Mac und iPad nicht kannibalisieren. Sowohl iPads als auch Mac tragen im Jahr rund 30 Milliarden US-Dollar zum Umsatz bei. Intern gibt es aber auch noch weitere Pläne. So soll Apple nach wie vor an einem klappbaren iPad mit (sehr) großem Bildschirm arbeiten. Das Gerät soll aber nicht vor 2029 auf den Markt kommen. Bis dahin könnte Apple seine Trennung zwischen Mac und iPad noch einmal überdenken.

Davor will Apple, ebenfalls laut Gurman, ein erstes MacBook Air mit OLED-Display auf den Markt bringen, vermutlich aber nicht vor 2028 und ohne Touchscreen.

(bsc)

Im heutigen Beitrag zeige ich, wie modernes C++ den Code für eingebettete Systeme beeinflussen kann. Der Code nutzt Features bis zu C++23.

Das Beispiel, das ich unten zeige, dreht sich um mindestens zwei Fragen, die mir Kunden schon oft gestellt haben:

• Wozu ist consteval gut?
• Was ist dieser benutzerdefinierte Literal-Operator und warum sollte mich das interessieren?

Ich werde diese beiden Fragen beantworten, aber es nicht dabei belassen. Das unten stehende Beispiel aus der Praxis zeigt auch die neuesten Ergänzungen zu C++, die dazu beitragen, Code robuster und sicherer zu machen.

Was ist eine MAC-Adresse?

Ich gebe viele Kurse für Kunden, die eingebettete Systeme entwickeln. Ich habe lange in diesem Bereich gearbeitet und es hat mir sehr viel Spaß gemacht.

Ein immer wiederkehrendes Thema ist die Vernetzung. Obwohl es heutzutage verschiedene Netzwerktypen und -technologien gibt, wollen wir uns in diesem Beitrag mit dem Internetprotokoll (IP) beschäftigen. Die Basis der Netzwerkkommunikation ist die Netzwerkkarte (NIC). Jede NIC hat eine eindeutige Medium Control Address (MAC) zugewiesen bekommen. Die MAC-Adresse ist die Basis für alles, was darauf aufbaut, wie TCP/IP.

Eine MAC-Adresse besteht aus genau sechs Bytes. Eine Möglichkeit, eine MAC-Adresse in Code darzustellen, ist folgende:

struct MACAddr {
  std::array data;
};

Die für Menschen lesbare Form der MAC-Adresse stellt diese sechs Bytes als Hexadezimalziffern dar, die zu zweit gruppiert und durch einen Doppelpunkt oder einen Bindestrich getrennt sind, wie hier:

12:34:56:78:90:AB

Einige dieser MAC-Adressen sind schon beim Kompilieren bekannt, andere können Nutzer während der Laufzeit eingeben.

Parsen einer MAC-Adresszeichenfolge.

Als ersten Schritt schauen wir uns an, wie eine Funktion, die eine MAC-Adresse in Zeichenfolgenform konvertiert, in eine 6-Byte-Version umgewandelt werden kann. Oben ist MACAddr als Basis. Aus Gründen der Speichersicherheit habe ich mit std::array angefangen. Ich ersetze alle C-Arrays durch die stärkere C++-Version, wo es geht. Der große Vorteil ist, dass ich jederzeit die Größe abfragen kann.

Für die Parsing-Funktion ist eine Zeichenfolge nur dann gültig, wenn sie mindestens 17 Zeichen enthält (6 Bytes mal 2 aufgrund des Hexadezimal-Formats plus 5 Trennzeichen). Das Auffinden der Trennzeichen ist ein weiterer Punkt.

In macFromString ist eine mögliche Implementierung:

constexpr std::expected  // #A
macFromString(std::span addr)    // #B
{
  // #C
  if(addr.size() < 17) { return std::unexpected(std::errc::message_size); }

  MACAddr res{};

  // #D
  for(int i = 0; auto& val : res.data) {
    // #E
    // C++26 will have .at!
    if((i < 5) and (addr[2] != ':')) {
      return std::unexpected(std::errc::message_size);
    }

    auto isAllowedHexChar = [](char c) {
      return ((('a' <= c) and ('f' >= c)) or  // isalpha reduced
              (('A' <= c) and ('F' >= c)) or  // isalpha reduced
              (('0' <= c) and ('9' >= c))     // is digit
      );
    };

    // #F
    if(not(isAllowedHexChar(addr[0]) and isAllowedHexChar(addr[1]))) {
      return std::unexpected(std::errc::invalid_argument);
    }

    // #G
    if(std::from_chars(addr.data(), addr.data() + 2, val, 16).ec !=
       std::errc()) {
      return std::unexpected(std::errc::message_size);
    }

    // #H
    addr = addr.subspan((addr.size() >= 3) ? 3 : addr.size());
    ++i;
  }

  return res;
}

Ich fange mit dem Rückgabedatentyp std::expected (#A) an. Dieser Typ ist seit C++23 verfügbar. Wie du siehst, ist der erste Template-Parameter der Datentyp, den du im besten Fall erwarten darfst (daher der Name expected), und der zweite Parameter ist der Datentyp für die Fehlerbedingung. Einfachheitshalber habe ich hier std:errc verwendet. Du solltest immer einen Datentypen wählen, der auf die Anforderungen in deiner Codebasis zugeschnitten ist.

Die Stärke von std::expected liegt darin, dass es entweder einen Wert oder einen Fehlercode enthält. Es gibt zwar ungültige MAC-Adressen, aber nehmen wir mal den einfachen Weg und betrachten die Adresse als ungültig, wenn die Zeichenfolge zu kurz ist, die erforderlichen Trennzeichen nicht enthält oder ungültige Zeichen enthält (wie T, das keine Hexadezimalzahl ist). Der Einsatz von std::expected hilft dabei, das Out-Parameter-Muster zu entfernen, das ich ungern mag.

Als Nächstes siehst du, dass macFromString in #B einen std::span als Parameter verwendet. Das Schöne an std::span, der in C++20 hinzugefügt wurde, ist, dass es eine sehr kostengünstige Ansicht der Originaldaten ist, während std::span die Datengröße beibehält. All diese Punkte machen std::span zum perfekten Datentyp, um Array-ähnliche Daten zu übergeben und dabei trotzdem die Grenzen sicher einzuhalten.

Als Erstes prüfe ich in macFromString, ob die Zeichenfolge lang genug ist (#C). Dank std::span ist das nicht nur einfach, sondern auch sicher.

Was passiert, wenn die Zeichenfolge zu kurz ist? Das wäre unerwartet. Deshalb gebe ich in diesem Fall ein std::unexpected mit einem std:errc-Code zurück. Hier zeigt sich die Schönheit von std::expected: Der Fehlerfall wird absolut klar gekennzeichnet.

Schauen wir uns jetzt die Konvertierung an, für die eine Schleife nötig ist. Ich setze eine bereichsbasierte For-Schleife (#D) ein und verwende dafür C++20 mit einem Initialisierer meiner Zählvariablen i.

Ich überprüfe innerhalb der Schleife auf das Trennzeichen, das sich an Position zwei in std::span befindet, wenn wir den letzten Teil nicht betrachten. Das ist dasselbe Verfahren wie oben in #C: Wenn kein Trennzeichen vorhanden ist (oder ein anderes), gebe ich in #D std::unexpected zurück.

In #F wird überprüft, ob die beiden aktuell betrachteten Zeichen im Bereich eines gültigen Hexadezimal-Zeichens liegen. Leider ist std::isdigit nicht constexpr. Das Gleiche gilt für std::isalpha, aber das fehlende constexpr bei dieser Funktion ist nicht so wichtig, da hier ein reduzierter Bereich erforderlich ist.

Als Nächstes kommt in #G die eigentliche Konvertierung. Ich benutze std::from_chars aus C++17. Das Schöne daran ist, dass ich die Werte aus std::span direkt übergeben kann, obwohl sie nicht mit dem üblichen Hexadezimalzahl-Indikator 0x beginnen. Ich kann std::from_chars mitteilen, welche Basis die Zahl hat.

Sollte die Konvertierung fehlschlagen, überprüfe ich den Fehlercode ec[/code und gebe erneut ein [code]std::unexpected zurück. Für deinen Code ist es nützlich, verschiedene Fehlerwerte zu verwenden, um anzuzeigen, an welcher Stelle die Konvertierung fehlgeschlagen ist.

Der letzte Schritt in #H besteht dann darin, das std::span mithilfe seiner subspan-Funktionalität weiterzuschieben. Hier musst du vorsichtig sein: Wenn du den Bereich verlässt, ist das Verhalten undefiniert. Deshalb überprüfe ich, wie viele Elemente noch übrig sind, und gehe entweder um diese Anzahl weiter oder um die Anzahl, die noch übrig ist. Der letzte Teil gilt immer für das letzte Ziffernpaar, das ohne nachfolgendes Trennzeichen kommt.

Es ist wichtig, nicht zu vergessen, i als letzten Schritt zu erhöhen. Dann haben wir einen robusten und sicheren MAC-Adressen-Parser, der die neuesten C++-Funktionen nutzt.

Warum constexpr?

Ein kleines Detail, das ich bei der Erläuterung der Implementierung von macFromString noch nicht angesprochen habe, ist die erste Zeichenfolge in der Funktionsdeklaration, die das Schlüsselwort constexpr bildet.

Die Antwort ist einfach: Wir wollen macFromString zur Kompilierungszeit aufrufen können. Hier kommt der anfangs erwähnte Literal-Operator (UDL) zum Tragen.

Eine interessante Eigenschaft des UDL-Operators ist, dass er nur mit Konstanten zur Kompilierungszeit aufgerufen werden kann. Du kannst den UDL-Operator manuell und damit mit Laufzeitwerten aufrufen, aber das widerspricht völlig dem Zweck eines Operators.

Wir benötigen einen UDL _macaddr, der ein MACAddr-Objekt zurückgibt, damit der folgende Code gültig ist:

// #A
auto data{std::to_array("12:34:56:78:90:AB")};
auto m = macFromString(data);

auto compileTimeMAC = "12:34:56:78:90:AB"_macaddr;

Die Implementierung des UDL-Operators ist recht einfach:

consteval MACAddr operator""_macaddr(const char* str, size_t length)
{
  return macFromString({str, length}).value();
}

Ich benutze die UDL-Operatorform, die ein const char* und ein std::size_t nimmt. Der Compiler erkennt freundlicherweise die Größe der Konstantenzeichenfolge zur Kompilierungszeit und teilt sie dem Operator mit. Damit sind alle Informationen zum Aufruf von macFromString vorhanden. Das Beste daran ist, dass die Zeichenfolge und die Länge immer zu 100 % übereinstimmen, da wir absolut nichts damit zu tun haben. Gib einfach die Daten weiter und bilde beim Aufruf von macFromString ein std::span.

Aber macFromString gibt ein std::expected zurück, mehr als nur ein MACAddr. Was tun? Ich rufe einfach .value für das Ergebnis von macFromString auf. Falls std::expected keinen Wert enthält, löst der Datentyp eine Exception aus. Aber ist das nicht schlecht? In anderen Fällen vielleicht schon, aber hier finde ich es mehr als okay, ich finde es großartig!

Hast du das erste Schlüsselwort bemerkt, das ich für den UDL-Operator verwendet habe? Es ist consteval! Ich erzwinge, dass diese Funktion nur zur Kompilierungszeit ausgewertet wird. Bei einer ungültigen MAC-Adresszeichenfolge führt die Ausnahme zum Abbruch des Kompilierungsvorgangs. So kannst du solche Fehler effektiv während der Entwicklung abfangen. Keine fest codierte MAC-Adresse sollte ungültig sein, oder?

consteval hat hier noch einen weiteren Vorteil: Wenn die Implementierung von macFromString nicht constexpr wäre, beispielsweise wegen eines Throw oder anderen undefinierten Verhaltens, würde die Auswertung des UDL zu einem Laufzeitaufruf werden. Das ist sicher nicht das, was du willst.

Robuster, sicherer und besser lesbar

Die gezeigten Elemente helfen dir, deinen Code robuster zu machen und die Sicherheit sowie die Lesbarkeit zu verbessern.

Die Anwendung der neuesten Funktionen von C++ ist in vielerlei Hinsicht vorteilhaft. Eine weitere Erkenntnis: Als Faustregel gilt, dass du jeden UDL-Operator in C++20 und höher als consteval definieren solltest.

(rme)

Agentic AI geht über klassische GenAI-Anwendungen hinaus, indem sie autonome, zielgerichtete Agenten einsetzt, die Tools verwenden, Entscheidungen unterstützen und Aufgaben über mehrere Schritte hinweg eigenständig ausführen können. Dadurch rückt neben der reinen Modellleistung vor allem die Fähigkeit in den Mittelpunkt, zuverlässige End-to-End-Workflows aufzubauen – inklusive der passenden Balance beim Autonomiegrad, eines pragmatischen Risikomanagements und klar messbarer Ergebnisse.

Über sieben Stunden ausgewähltes Fachprogramm

Am 22. April widmet sich die Hot Topics einen ganzen Tag lang um die Chancen und Herausforderungen von Agentic AI. Expert:innen aus Beratung, Technologie und Praxis zeigen, wie man geeignete Use Cases identifiziert, Agenten schrittweise in Prozesse integriert und was in der Umsetzung wirklich funktioniert (und was nicht).

Breites Themenspektrum auf der Agenda

Die Veranstaltung richtet sich an IT-Verantwortliche, Digitalisierungs- und Innovationsverantwortliche sowie alle, die sich mit dem produktiven Einsatz von KI-Agenten beschäftigen. Ein zusätzlicher Anreiz für Schnellentschlossene: Noch bis zum 27. März ist das Ticket zum vergünstigten Preis von 249 Euro erhältlich.

Das Online-Event findet am 22. April 2026 statt. Alle Informationen zur Veranstaltung und Anmeldung finden Sie auf der Webseite.

()