Connect with us

Entwicklung & Code

C++26-Reflexion zur Kompilierungszeit | heise online


Im heutigen Beitrag meines C++-Blogs möchte ich auf die statische Reflexion in C++26 eingehen. Einer der großen Vorteile von Reflexion ist, dass wir die neue Funktion bereits ausprobieren können, da mit Clang ein Compiler verfügbar ist, der alle Facetten implementiert. Und auch der jüngst erschienene GCC 16 implementiert das Feature bereits.

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.

Anhand meiner typischen Anwendungsfälle habe ich untersucht, welche Aufgaben sich mit Reflexion besser lösen lassen. Eine Aufgabe, die mich den größten Teil meiner Karriere beschäftigt hat, war das Lesen und Schreiben von Daten, die über eine Netzwerkverbindung kamen. Die Definition von „Netzwerk“ war zu verschiedenen Zeiten unterschiedlich. Gemeinsam war jedoch, dass alles, was gesendet wurde, in Netzwerk-Byte-Reihenfolge (Big-Endian) verschickt wurde, und alles, was empfangen wurde, ebenfalls in Netzwerk-Byte-Reihenfolge ankam. Für manche Systeme machte das keinen Unterschied, da sie bereits Big-Endian-Maschinen waren. Aber nicht immer. Vor allem ARM setzte auf Little-Endian. Bei einem Teil der Systeme mussten die Daten beim Empfangen oder Senden daher byteweise vertauscht werden.

Wie tauscht man Daten?

Das Problem hier (war), wie tauscht man die Daten? Jeder Datentyp, der größer als ein Byte ist, muss jedes Mal getauscht werden. C++23 hat uns std::byteswap gegeben, wodurch POSIX-Funktionen wie htons überflüssig geworden sind. Das bedeutet zumindest eine Verbesserung im Hinblick auf Sicherheit.

Fangen wir mit einem Beispiel an. Der folgende Code zeigt die Datenstrukturen, die ich heute verwende.


enum class Color16 : uint16_t
{
};

struct RGB48 {
  Color16 red;
  Color16 green;
  Color16 blue;

  auto operator<=>(const RGB48&) const = default;
};

struct LEDState {
  bool  state;
  RGB48 rgbColor;

  auto operator<=>(const LEDState&) const = default;
};

struct LEDStateMessage {
  uint32_t messageId;
  LEDState state;

  auto operator<=>(const LEDStateMessage&) const = default;
};


Wie du sehen kannst, ist die letzte Struktur LEDStateMessage später die Wurzel. Diese Struktur enthält eine Struktur, die wiederum eine Struktur enthält. Wir gehen es heute also rekursiv an.

Weiterlesen nach der Anzeige

Alle structs verfügen über einen Dreiwege-Vergleichsoperator – das erleichtert die Überprüfung.

Was ich erreichen möchte, sieht in etwa so aus:


LEDStateMessage msg{.messageId = 3,
                    .state{.state = true,
                           .rgbColor{.red   = Color16{0x5u},
                                     .green = Color16{0x28u},
                                     .blue  = Color16{0x40u}}}};

Serialize(msg);


Die Daten sollten ausgetauscht oder besser noch an Ort und Stelle serialisiert werden. Ich gehe von einem System mit Speicherbeschränkungen aus, bei dem ich es mir nicht leisten kann, doppelt so viel Speicher zu verbrauchen.

Denke jetzt mal einen Moment darüber nach, wie viel Mühe du dir in der Vergangenheit gegeben hast, damit Serialize funktioniert. Ich für meinen Teil kann sagen, dass es mich viele Stunden gekostet hat.

Reflexion zur Rettung

Bist du bereit? Okay, hier kommt es:


template
requires(not std::is_pointer_v) and std::is_trivially_copyable_v
constexpr void Serialize(T& data)
{
  if constexpr(std::is_array_v) {  // #A
    for(int i{}; i < std::size(data); ++i) { Serialize(data[i]); }

  } else if constexpr(std::is_enum_v) {  // #B
    data = static_cast(std::byteswap(std::to_underlying(data)));

  } else if constexpr(not std::is_class_v) {  // #C
    data = std::byteswap(data);

  } else {  // #D
    static constexpr auto members =
      std::define_static_array(std::meta::nonstatic_data_members_of(
        ^^T, std::meta::access_context::current()));

    template for(constexpr auto& mem : members) { Serialize(data.[:mem:]); }
  }
}


Die Implementierung von Serialize besteht aus vier Teilen. In Abschnitt #A prüft Serialize, ob es sich um ein Array handelt. Wenn der Datentyp passt, ruft die Implementierung Serialize für jedes Element des Arrays auf.

Als Nächstes prüft die Implementierung in #B, ob der Datentyp ein enum ist. In diesem Fall wird C++23s std::to_underlying zusammen mit std::byteswap verwendet, um die Bytes tatsächlich zu vertauschen.

Nun wird in #C, falls dieser Datentyp kein Klassentyp ist, std::byteswap auf die Daten angewendet.

So weit, so gut. Bisher ist das alles generischer Code, den du schon vor C++26 so schreiben konntest. Der knifflige Teil sind die Datenelemente von Klassentypen. Genau das wird in #D behandelt.

Dank der Reflexion-Fähigkeiten durchläuft die Implementierung alle Datenelemente der Klasse und ruft für jedes davon Serialize auf. Et voilà, ein hervorragender erster Entwurf einer generischen Serialisierungsfunktion.


(Matthias Parbel)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Android 17 Beta 4.1: Google behebt offenbar letzte Fehler vor Release


Eigentlich sagte Google im April, dass das Update auf Android 17 Beta 4 die „letzte geplante Beta“ des Entwicklungszyklus sei, bevor die Version als stabile Version veröffentlicht werde. Mit der Beta 4.1 kommt der Konzern also ein wenig überraschend um die Ecke. Zudem macht Google darauf aufmerksam, dass einige Hardwarepartner auch schon Betas für einige ihrer Geräte anbieten.

Weiterlesen nach der Anzeige

Das Update Android 17 Beta 4.1 ist den Release-Notes zufolge recht klein, steht aber für das Pixel 6 bis hin zu den Geräten der neuen Pixel-10-Serie zur Installation bereit. Der Build CP21.260330.011.A1 ist für Pixel 6/Pro/a Pixel 7/Pro bestimmt, während sich CP21.260330.011 an alle anderen Pixel-Modelle richtet.

Fehlerbehebungen im Fokus

Hinsichtlich der Neuerungen enthält die Beta 4.1 lediglich fünf kleine Fehlerbehebungen, jedoch keine neuen Funktionen. Die aus Googles Sicht wichtigsten neuen Features hatte der Konzern im Zuge der Android Show: I/O Edition am 12. Mai gezeigt – inklusive der agentischen KI Gemini Intelligence, die jedoch nur für High-End-Geräte bestimmt ist.

Google erklärt, dass es mit dem nun veröffentlichten Update ein Problem behebt, bei dem die Statusleiste fälschlicherweise keinen Signalbalken anzeigte, obwohl eine Verbindung bestand. Ebenso haben die Entwickler ein Problem mit der UI-Synchronisation gefixt, bei dem das Symbol für die Schnellsteuerung der mobilen Daten im Flugmodus aktiv blieb.

Lesen Sie auch

Zudem soll es keine Probleme mehr beim Anschluss externer Displays geben – zumindest sollen sie nun nicht mehr schwarz werden, wenn eine hohe Auflösung ausgewählt wird. Ebenso habe Google einen Fehler bei der Bluetooth-Audioübertragung behoben, der nach Systemunterbrechungen wie Timern zu einer Unterbrechung der Wiedergabe führte. Außerdem sollen Hörgeräte nach Inaktivität oder dem Aufladen nicht mehr automatisch aus den gekoppelten Geräten entfernt werden.

Weiterlesen nach der Anzeige

Android 17 Beta für „Partnergeräte“

Während Google seine Betas nur für seine Pixel-Modelle anbietet, macht der Konzern darauf aufmerksam, dass einige Hardwarepartner Versionen der Android-17-Beta für ausgewählte Smartphones anbieten.

Zu den Partnern zählen Honor, iQOO, Lenovo/Motorola, OnePlus, Oppo, Realme, Sharp, Vivo und Xiaomi. Interessanterweise erwähnt Google seinen engen Partner Samsung nicht, obwohl der Konzern sein Betaprogramm auf One UI 9 auf Basis von Android 17 für die Galaxy-S26-Serie gestartet hat.

Für interessierte und wagemutige Besitzerinnen und Besitzer eines der kompatiblen Modelle hat Google eine Übersichtsseite gestaltet, die zu den jeweiligen Betaprogrammen führt.

Auf den Webseiten der Partner finden Nutzer jeweils Anleitungen, wie sie die Android-17-Beta installieren können. Die meisten bieten System-Images zum Herunterladen und Flashen an, einige unterstützen derweil zusätzlich Over-the-Air-Updates (OTA), wie etwa Samsung über sein eigenes Betaprogramm.


(Andreas Floemer)



Source link

Weiterlesen

Entwicklung & Code

Android öffnet ein paar Server-Ports


Google wird Android-Apps erlauben, ein Dutzend well-known Ports (kleiner als 1024) zu nutzen – etwa als Server respektive Service. Das öffnet neue Einsatzmöglichkeiten für populäre Android-Geräte, insbesondere im lokalen Netzwerk. Konkret sollen mit dem nächsten Update des Google Play Systems Android-Apps bei Bedarf Dienste auf diesen neun TCP-Ports anbieten dürfen: 20 und 21 (typischerweise für FTP genutzt), 22 (SSH/SFTP), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 445 (SMB), sowie die beiden regelmäßig für vernetzte Drucker eingesetzten Ports 515 (LPD) und 631 (IPP).

Weiterlesen nach der Anzeige

Hinzu kommen drei UDP-Ports: 319/320 (typischerweise für Zeitgeber-Synchronisierung mittels PTP) und 443 (für das QUIC-basierte WWW-Protokoll HTTP/3). Das geht aus einer am Wochenende veröffentlichten Mitteilung im öffentlichen Bugtracker Androids hervor. Kein Glück haben beispielsweise Nutzer von TFTP (UDP-Port 69) oder Doom-Fans (klassisch Port 666).

Bislang sperrt Google auf seinen Android-Versionen grundsätzlich Ports kleiner 1024. Nur wenn solche Android-Implementierungen gerootet sind, kann der Administrator die sogenannten well-known Ports zugänglich machen. Das schwächt unter Umständen bestimmte IT-Sicherheitsmaßnahmen.

Ein bisschen Glasnost

Daher regen Entwickler im Android Bugtracker seit vielen Jahren an, die Einschränkung fallen zu lassen. Doch Google hat das mehrfach als „absichtliches Verhalten” eingestuft und das Gesuch abgelehnt („Won’t Fix”). Im Oktober 2021 überraschte ein Googler mit der „Erklärung”, dass „raw sockets konstante Quelle für kernel exploits” seien, weshalb die Verbesserung nicht infrage komme. Dabei hatte niemand nach raw sockets (OSI-Layer 2 oder 3) gefragt, sondern lediglich nach Zugang für unprivilegierte Apps auf Layer 4.

Auch den zumindest dritten Anlauf vor gut vier Jahren hat Google mit „Won’t Fix” abgeschmettert. Doch vorige Woche entdeckte ein womöglich deutscher Entwickler, dass Anwendungen in der Developer Preview auf Android 17 Zugriff auf die UDP-Ports 319 und 320 ergattert haben.

Daraufhin rang Google sich zu einer teilweisen Öffnung durch, auch für altere Androids. Die grundsätzliche Herangehensweise, well-known Ports zu sperren, bleibt aufrecht. So viel Orthodoxie muss offenbar sein. Immerhin wird die Nutzung der zwölf obgenannten Ports ermöglicht.

Technisch gesehen setzt Google die neue Port-Whitelist mittels eBPF (extended Berkley Packet Filter) um. Das erfolgt in jenem APEX-Modul, das in Android Mainline für Datenverbindungen samt Tethering zuständig ist. Solche Module können durch Google Play Updates erneuert werden und bedürfen keines Updates des gesamten Betriebssystems. Der Konzern könnte Zukunft also relativ einfach weitere well-known Ports zur Verfügung stellen, wenn er denn möchte.

Weiterlesen nach der Anzeige

Voraussetzungen und Vergleich

Voraussetzung für den neuen Portzugriff sind sowohl mindestens Android 13 (API-Version 33 und höher) als auch mindestens Linux-Kernel 5.15. Damit sind Anwender erst mit Systemen, die neu mit Googles Android 14 ausgeliefert wurden, auf der sicheren Seiten. Mobiltelefone, die mit Googles Android 13 neu ausgeliefert wurden, durften Kernel 5.10 oder 5.15 nutzen, sind also nicht alle mit dabei. Geräte, die mit älteren Android-Versionen auf den Markt gekommen und später auf jüngere Versionen des Betriebssystems upgegradet worden sind, können sogar mit noch älteren Kernel-Versionen laufen.

Bei den Android-Varianten Android Auto, TV und Wear könnte die Verbesserung länger auf sich warten lassen. Das gilt auch für Android Go; das ist eine für weniger leistungsstarke Handys und Mobilfunknetze optimierte Android-Variante.

Die Einschränkung der niedrigen Ports ist auch bei anderen Linux-Systemen üblich. Allerdings ist es dort Administratoren in der Regel ein Leichtes, bei Bedarf Anwendungen den Zugriff zu gestatten. Für MacOS galt das nicht, doch können nicht-privilegierte Anwendungen seit Version 10.14 über die Wildcard-Adresse 0.0.0.0 auch an well-known Ports andocken. Den nicht auf Linux basierenden Betriebssystemen iOS und Windows ist die strikte Portnummern-basierte Blockade fremd.


(ds)



Source link

Weiterlesen

Entwicklung & Code

Proxmox Datacenter Manager 1.1 wird Schweizer Taschenmesser für Proxmox-Cluster


Die Wiener Proxmox Server Solutions GmbH hat ihren Proxmox Datacenter Manager 1.1 veröffentlicht. Der Datacenter Manager bietet eine zentrale, einheitliche Web-Konsole, um alle Instanzen des Proxmox Virtual Environment (VE) und des Proxmox Backup Servers zu managen. Der gesamte Cluster samt aller Nodes kann so organisationsübergreifend verwaltet, überwacht und skaliert werden. Die neue Version 1.1 des Proxmox Datacenter Managers bietet automatisierte Workflows für das Ausrollen von Nodes, eine umfassende Subskriptions-Verwaltung, ein einheitliches Ceph-Cluster-Monitoring sowie ein erweitertes, zentrales Gast- und Snapshot-Management.

Weiterlesen nach der Anzeige

Mit Version 1.1 erweitert der Proxmox Datacenter Manager seine Rolle zum zentralen Konfigurationsserver für automatisiertes Host-Provisioning in verteilten Infrastrukturen. Administratoren können sogenannte Antwortdateien mit vordefinierten Installationsparametern zentral verwalten und für das unbeaufsichtigte Ausrollen neuer Hosts bereitstellen. Die Abläufe sind über den neuen Bereich „Automatische Installationen“ im Reiter „Remotes“ direkt im Webinterface erreichbar. Dort lässt sich auch der Fortschritt laufender Installationen in Echtzeit überwachen.

Für die Absicherung des Provisioning-Prozesses setzt Proxmox auf einen tokenbasierten Mechanismus: Nur autorisierte Zielsysteme erhalten Zugriff auf die hinterlegten Konfigurationen. Damit adressiert Proxmox vor allem größere Cluster- und Edge-Szenarien, in denen konsistente Rollouts und zentrale Verwaltung entscheidend sind. Wie das aktuelle Proxmox Virtual Environment 9.2 basiert auch der Proxmox Datacenter Manager 1.1 auf Debian GNU/Linux 13.5 „Trixie“ mit Linux-Kernel 7.0 inklusive aktualisierter Pakete und Bugfixes sowie OpenZFS 2.4.2.

Zentrale Verwaltung von Subskriptionen

Ebenfalls neu im Proxmox Datacenter Manager 1.1 ist eine zentrale Subscription-Registry, um die Verwaltung von Lizenzschlüsseln in verteilten Infrastrukturen zu vereinfachen. Administratoren können Subscription-Keys zentral vorhalten, einzelnen Remotes zuweisen und bei Bedarf wieder entkoppeln. Das reduziert den Verwaltungsaufwand insbesondere in Multi-Site-Umgebungen mit vielen Hosts. Zudem lassen sich Subscription-Keys direkt in vorbereitete Antwortdateien integrieren. Neue Hosts registrieren ihre Subscription damit automatisch bereits während der Installation. Die Funktion verzahnt Lizenzmanagement und automatisiertes Provisioning und soll konsistente Deployments in größeren Proxmox-Umgebungen erleichtern.

Der Proxmox Datacenter Manager 1.1 erweitert das Monitoring verteilter, hyperkonvergenter Infrastruktur-Umgebungen (HCI) um eine native Überwachung angebundener Ceph-Cluster. Administratoren erhalten über ein zentrales Dashboard konsolidierte Einblicke in Zustand, Kapazität und Echtzeit-Performance mehrerer Cluster. Die einheitliche Ansicht erleichtert insbesondere den Betrieb verteilter Proxmox-VE-Infrastrukturen und reduziert den Aufwand für die Analyse einzelner Standorte. Darüber hinaus liefert das Monitoring detaillierte Statusinformationen zu Object Storage Daemons (OSDs), Monitoren, Managern, Metadata Servern (MDS), Storage-Pools, CephFS sowie relevanten Cluster-Flags. Damit adressiert Proxmox vor allem Betreiber größerer HCI-Deployments mit hohen Anforderungen an Transparenz und Betriebsüberwachung.

Zentrales Guest- und Snapshot-Management

Weiterlesen nach der Anzeige

Mit Version 1.1 legt der Proxmox Datacenter Manager den Grundstein für ein zentrales Guest-Management über mehrere Remotes hinweg. Virtuelle Maschinen auf Basis von QEMU sowie LXC-Container lassen sich nun in einer gemeinsamen Ansicht verwalten, wahlweise als sortierbare Tabelle oder in einer nach Remotes strukturierten Baumansicht. Textfilter erleichtern die Suche nach einzelnen Gästen, während häufig genutzte Aktionen direkt aus der Übersicht heraus verfügbar sind.

Neu hinzu kommt ein zentrales Snapshot-Management: Snapshots lassen sich in einer Parent-Child-Struktur anzeigen, erstellen, wiederherstellen oder löschen. Auch das Bearbeiten von Beschreibungen ist möglich. Ergänzend führt Proxmox den Befehl „Resume“ für pausierte oder suspendierte QEMU-VMs ein. Die Funktionen markieren den ersten Schritt hin zu einer umfassenderen Guest-Orchestrierung, die in kommenden Releases weiter ausgebaut werden soll.

Preise und Verfügbarkeit

Geplante Funktionen sowie alle Verbesserungen und Neuerungen des Proxmox Datacenter Managers 1.1 beschreibt dessen Roadmap detailliert. Der Proxmox Datacenter Manager 1.1 steht als Open-Source-Software ab sofort zum Download bereit und kann kostenlos eingesetzt werden. Die Software selbst ist kostenlos, ihr Einsatz erfordert allerdings aktive Enterprise Support Subscriptions für alle verwalteten Produkte.


(axk)



Source link

Weiterlesen

Beliebt