Schnelles C++ Programm, C# GUI, möglich?

Question

Ich bin dabei, eine Anwendung zu entwickeln, die Daten von einer Zeilenkamera mit etwa 2000 Zeilen (Bildern) pro Sekunde verarbeitet. Für diese Echtzeitanwendung halte ich C/C++ für den richtigen Weg. (Ich bin der Meinung, und andere werden mir zustimmen, dass verwalteter Code für diese Aufgabe einfach nicht geeignet ist).

Ich habe jedoch Folgendes getan sehr kleine MFC oder eine andere C++-GUI. Ich bin wirklich immer zu tun C # GUIs sehr gut, aber.

Daher erscheint es mir natürlich, den datenintensiven Code in C/C++ und die grafische Benutzeroberfläche in C# zu schreiben. Die GUI wird für die Einrichtung/Kalibrierung/Online-Überwachung verwendet (und möglicherweise für die Ausgabe von Daten über UDP, weil das in C# einfacher ist.

Daher möchte ich zunächst einmal wissen, ob jemand der Meinung ist, dass dies der richtige Weg wäre. Auf der Grundlage meiner Programmiererfahrung (gut in Low-Level-C-Algorithmen und High-Level-C# GUI-Design), es fühlt sich einfach richtig.

Zweitens bin ich mir nicht sicher, wie ich es am besten anstellen soll. Ich warf gerade zusammen eine Lösung in VS2005, die einige (extern "C") DLL-Funktionen von einer C#-Anwendung aufruft. Und um sicherzustellen, dass ich es tun konnte, schrieb ich auf einige globale Variablen in der DLL, und lesen Sie aus ihnen:

test.h

int globaldata;
extern "C" __declspec(dllexport) void set(int);
extern "C" __declspec(dllexport) int  get();

test.cpp

extern int data=0;
__declspec(dllexport) void set(int num) {
    data = num;
}

__declspec(dllexport) int get() {
    return data;
}

test.cs

[DllImport("test")]
private static extern void set(int num);

[DllImport("test")]
private static extern int get();

Aufruf von get() y set() richtig funktionieren ( get() gibt die Zahl zurück, die ich an set() ).

Ich weiß, dass man auch eine C++-Klasse exportieren kann, aber muss sie auch verwaltet werden? Wie funktioniert das? Gehe ich das richtig an?

Vielen Dank für Ihre Hilfe!

`** EDIT `**

Zuallererst, DANKESCHÖN für Ihre fantastischen Antworten bis jetzt! Ich bin immer unglaublich beeindruckt von Stack Overflow...

Ich denke, ich hätte nicht unbedingt auf die reine Geschwindigkeit eingehen sollen (diese kann in Prototypen und Benchmarks gemessen werden). Eine Sache, die mir mehr Sorgen bereitet, ist das nicht-deterministische Verhalten des Garbage Collectors. Diese Anwendung würde no eine Verzögerung von 500 ms bei der Durchführung der Müllabfuhr tolerieren.

Ich bin alles für die Codierung und versuchen dies in reinen C#, aber wenn ich vor der Zeit wissen, dass die GC und andere nicht-deterministische .NET Verhalten (?) ein Problem verursachen, ich denke, meine Zeit wäre besser verbracht Codierung es in C/C++ und herauszufinden, die beste C#-Schnittstelle.

Answer 1

Für C++ verwenden Sie C++/CLI - was eigentlich gar nicht so schlecht ist. Es ist viel besser als die alten verwalteten Erweiterungen.

Kommentar zur Leistung. Das hängt wirklich davon ab. Wie viel Hin und Her wird es zwischen Ihrem C++-Code und Ihrem C#-Code geben? Werden Sie einen Hintergrund-Thread haben, der Daten in C++ sammelt und diese regelmäßig an den C#-Code sendet? Wenn Sie eine Schnittstelle zu einem Gerät herstellen wollen, wird dies über eine serielle Schnittstelle, USB oder eine API geschehen, die Sie erhalten haben?

Answer 2

Ich stimme Mitch zu 100 % zu.

Wenn Sie nach der Untersuchung seiner Ressourcen immer noch das Gefühl haben, dass Sie einen nicht verwalteten Code verwenden müssen, können Sie eine "Business"-Schicht in C++ (oder in diesem Fall wirklich eine funktionale Schicht) schreiben und Ihre Benutzeroberfläche in C# schreiben. Verwenden Sie COM Interop um von C#/verwaltetem Code zu Ihrem nicht verwalteten Code aufzurufen.

Aber auch hier bin ich der Meinung, dass Sie dies nicht tun müssen.

Answer 3

Die Sprache, die Sie wählen, hat keinen großen Einfluss auf die Leistung (sagen wir, Sie können die Geschwindigkeit um 5/10% beeinflussen). Was den Unterschied ausmacht, sind die Algorithmen, die Sie verwenden, die Art der Datenverarbeitung, das Profiling Ihrer Anwendung usw. (die Leistung kann sich um das 10-fache ändern).

Answer 4

Ich habe es mit C++.NET gemacht

Da sowohl C++.NET als auch C# verwaltet werden, wüsste ich nicht, warum das nicht möglich sein sollte. Der Punkt ist, wie Sie es tun werden.

Mein Scanner konnte bis zu 3000 Zeilen pro Sekunde verarbeiten, aber die Hauptstrategie bestand darin, Blöcke von 32 Zeilen auf einmal anzuzeigen. Ich hatte keine strengen Anforderungen an die Echtzeit, so dass ich manchmal ein wenig im Rückstand sein konnte. Wenn Echtzeit für Sie sehr wichtig ist, sollten Sie einen Plattformwechsel in Betracht ziehen.

Es gibt eine Windows-Echtzeitlösung namens "InTime OS", die aber sehr mühsam zu bedienen ist.

Ein anderer Ansatz besteht darin, die harte Echtzeit in einer separaten DLL oder Bibliothek abzutrennen und C# in seiner eigenen Geschwindigkeit zeigen zu lassen, was es kann. Wirklich, der Benutzer wird nie in der Lage sein zu sagen, ob Ihre Schnittstelle 2000 fps oder 500 fps hat

Answer 5

Ich habe Erfahrung mit nativen C/C++- und C#-Systemen mit sehr geringer Latenzzeit.

• in C/C++ gehen 80 % der Prozessorzeit bei deterministischen malloc-Methoden verloren, aber der native Code ist 10x schneller als der MSIL-Code

• in C# ist die Speicherzuweisung schneller, da es sich um einen asynchronen Prozess handelt

Ihre Wahl muss durch das Verhältnis: Prozesszeit / malloc Anzahl getan werden

Also Granularität!!!

Die Lösung für C/C++ ist die Vorabzuweisung aller Puffer im Speicher (ggf. Verwendung von L2/L3-Cache)

Die Lösung für C# ist die Minimierung des P-Invoke-Konvertierungsmechanismus

Herzlichen Glückwunsch zu Ihrem Projekt, Paul