Docs

C++ component API

Eine C++-Pipelogic-Komponente ist component.yml plus src/main.cpp. Das YAML deklariert die plattform­seitigen Eingaben, Ausgaben, Configs, Dateien und Build-Einstellungen; main.cpp enthält die Worker-Logik, die im Komponenten-Binary läuft. Das Build-System kompiliert diesen Einstiegspunkt und liefert ihn innerhalb des deployment aus.

Diese Seite ist der Index für die C++ component API. Die detaillierten Seiten liegen unter component-api/cpp/ — Class Description, factory-typed-Komponenten, stateful-Muster, Fehlerbehandlung, Header und die vollständige Typreferenz.

Für C++-Komponenten (language: cpp) ist die einzige Datei, die du schreibst, src/main.cpp. Es gibt keine xmake.lua in deinem Komponentenverzeichnis — die Build-Base besitzt das Build-Skript. Die Compile-Stufe behandelt main.cpp als Einstiegspunkt, linkt sie gegen die C++ ML SDK runtime + deine deklarierten xmake_packages: und erzeugt das Komponenten-Binary, das die Plattform in einem Container ausführt.

Dieser Index listet jedes Dokument unter component-api/cpp/ auf und was es abdeckt. Lies der Reihe nach, wenn du noch nie eine C++-Komponente geschrieben hast; springe zu einer bestimmten Seite, wenn du weißt, welche Form/welches Thema du suchst.

Erforderliche Lesereihenfolge

  1. component-api/cpp/types — was Message, Object<T>, String, List<T>, Tuple<T...> bedeuten. Jedes andere Dokument setzt diese voraus.
  2. component-api/cpp/headers — Header-Katalog. Welches #include bringt was.
  3. component-api/cpp/config — parse_config, read_config, mutable Parameter.
  4. Wähle die Komponentenform, die zu deiner component.yml passt (nächster Abschnitt).
  5. component-api/cpp/errors — Ausnahmen, Log-Konventionen.

API-Referenzen

Wenn du die exakte Signatur für jedes öffentliche Member jedes Typs brauchst, nicht die erzählende Erklärung:

  • Types reference — jeder Name in types.hpp: atomare Tags, List/Tuple/Union/Record/Named, der concepts::-Namespace, Type, TypeManager, alle create_*-Factories.
  • Object reference — jedes öffentliche Member von Object<T>, Reference<T>, ConstReference<T> über alle 8 zugrundeliegenden Arten, plus die Lifetime-/Aliasing-Invarianten.

Die erzählenden Dokumente oben sind weiterhin der richtige Einstiegspunkt — diese Referenzen existieren für Fragen wie „was ist die exakte Signatur von mutable_get auf einer statischen Reference<Record>?".

Komponentenformen

Wähle die Form danach, wie viele Eingaben du nimmst, ob sie 1-zu-1 abbilden und ob du Zustand oder Pull-Kontrolle brauchst:

Verwende diese FormWann
component-api/cpp/single-ioEine Eingabe, eine Ausgabe, zustandslos. Der Standard und einfachste Fall.
component-api/cpp/multi-input-positionalMehrere Eingaben, die immer zusammen ankommen (1-tick-pro-tick), jede ein Message-Argument.
component-api/cpp/vector-ioMehrere Eingaben/Ausgaben als std::vector<Message> (variadisch / generisch).
component-api/cpp/statefulDu brauchst Zustand über Nachrichten hinweg (Zähler, EMA, Session-Map, Akkumulator).
component-api/cpp/factory-typedDie Komponentenform hängt vom verbundenen Typ ab (Generics wie t).
component-api/cpp/class-descriptionDu brauchst volle Pull-Kontrolle (Rate-Limiter, Batcher, asynchrones Streaming, Lifecycle-Hooks).

Skelett

Jede main.cpp beginnt und endet so:

#include "pipelogic/pipelogic.hpp"using namespace ppl;// ... your worker function(s) ...PIPELOGIC_MAIN() {  run(<your_function>);  return EXIT_SUCCESS;}

PIPELOGIC_MAIN() ist ein Makro, das zu int main(int, char**) plus dem runtime-Bootstrap expandiert. Du schreibst niemals selbst int main. Der einzige Aufruf im Makro-Body ist run(...) — die Variante, die zu deiner Komponentenform passt (jedes Formdokument zeigt die exakte Form).

return EXIT_SUCCESS; ist verpflichtend — das Makro verlangt, dass der Body etwas zurückgibt.

Build-Konfiguration

build_system: in component.yml wählt die Compile- + runtime-Base (siehe concepts/build-systems). Für C++-Komponenten:

build_systemBringt
2C++ ML SDK Toolchain und runtime, keine zusätzlichen ML-Libs.
2-ml2 + OpenCV, die ML-Header des C++ ML SDK, gängige Inferenz-Abhängigkeiten.

Für Bibliotheken über die Base hinaus liste sie unter xmake_packages: in component.yml auf:

xmake_packages:  - libcurl  - nlohmann_json

Verwende die strukturierte Form, wenn das xmake-Paket Configs benötigt:

xmake_packages:  - require: arrow 7.0.0    package: arrow    configs:      parquet: true      csv: false      snappy: true      zstd: true

require ist die exakte add_requires(...)-Spezifikation. package ist der Name, der an add_packages(...) übergeben wird; lass ihn weg, wenn der abgeleitete Name korrekt ist. configs bildet direkt auf xmake {configs = {...}} ab.

Der Build löst diese aus xmakes Paket-Registry auf — du schreibst kein Build-Skript.

Verwandt

  • component.yml — jedes Feld in component.yml, einschließlich worker.input_type(s), output_type(s), config_schema:, file_schema:, xmake_packages:, depends_on:.
  • Typen — der Typkatalog, der in worker.input_type: / output_type: verwendet wird.
  • Build Systems — was build_system: wählt.

War diese Seite hilfreich?