ich habe hier ein kleineres größeres Problem. Ich habe die letzten Monate die Steuerung für eine Messanlage angefangen neu aufzusetzen. Die besteht im Wesentlichen aus einem Antrieb, einem Satz IO Klemmen, einer Kamera und der zugehörigen Bildverarbeitung und Auswertung.

Die alte Software basiert auf 6 oder 7 einzelnen EXE Dateien, die nur mit der C++ STL programmiert sind. Die Kommunizieren teilweise über TXT-Dateien. Und genau dieses langsame Vorgehen wollte ich vermeiden.

Ich habe das Ganze mit einer Oberfläche erweitert und umgestellt.

Die Antrieb, IO, Kamera und Bildverarbeitung sind Zustandsautomaten, die ich durch Threads und Events realisiert habe. Ein Thread der TThread-Klasse wird gestartet und mittels WaitFor eingeschläfert. Der Zustandswechsel erfolgt über Events.
Die vier obigen Threads werden durch einen weiteren Thread gestartet und gesteuert. Dieser Controller stellt die Schnittstelle zur Oberfläche dar.
Die ist mittels Forms realisiert. Im Grunde habe ich eine Formular Anwendung erstellt und darin die Threads implementiert. Der Hauptthread an sich muss somit nur noch die Obefläche rechnen. Die Arbeit machen die andern Threads.

Mein Problem:
Die Bildaufnahme und Bildverarbeitung werden durch eine BV Bibliothek namens Halcon implementiert. Diese Bibliothek lässt sich unter einem Borland Compiler nicht implementieren. Keine Chance die DLLs einzusetzen.
Neben der BV muss ich noch Treiber für die CAN-Anbindung von Motor und IO einbinden. Treiber für die Kamera kommen auch noch.
Bei diversen Anfragen kam meistens die Antwort, dass die Bibliotheken im Angebot für VS gemacht sind.

Das bedeutet ich muss umsteigen. Da ich eigentlich nur auf der VCL und der CLX, mit einigen STL und WinAPI Einschwüngen, programmiert habe, habe ich die absolute arschlochkarte. Alles nochmal bitte. Unter Visual Studio.
Borland war so schön einfach.
Jetzt habe ich ein Problem... MIT WAS eigentlich??? Ich wusste nur, dass Microsoft die Forms Klassen mittlerweile in Lizens nachbaut. Somit dachte ich mir, dass das doch relativ "simpel" sein müsste das nachzubasteln.

Jetzt steh ich hier ich armer Thor und bin so schlau als wie zuvor...

Meine Firma möchte das Ganze am liebsten vorgestern. Ich bin der Einzige, der hier programmieren kann. Naja ich bin definitiv alles andere als ein Pro... Übung macht den Meister. Ich muss dazu sagen, dass ich die MFC nicht mag. Alles so... umständlich.

Als ich mal drüber geschaut habe, dachte ich, dass ich C++/CLI nehmen kann. Mittlerweile wurde mir allerdings von Jochen abgeraten.
Soll ich jetzt C# lernen und auf .NET programmieren?
Oder nehme ich C++ laut STL, würze es mit Boost und werfe ein Oberflächenkit wie qt in den Topf?

Wie mache ich denn jetzt am Besten weiter... Was verwende ich an Bibliotheken? Welche Sprache?

Es ist mir wirklich wichtig hier rbauchbare Informationen zusammenzutragen, gerade weil ich keinen fragen kann.

Die Bildaufnahme und Bildverarbeitung werden durch eine BV Bibliothek namens Halcon implementiert. Diese Bibliothek lässt sich unter einem Borland Compiler nicht implementieren. Keine Chance die DLLs einzusetzen.

warum nicht? liegts am name mangling? vielleicht kannst du dir einen c-wrapper im visual studio bauen?

Ich bin gerade am Schmökern. Wenn ich das Recht verstehe kommen diese Möglichkeiten in Frage:

- Beim BCB bleiben und mir irgendwie aushelfen (Eigene DLLs mit Halcon unter VS erstellen und das C++ Mangling abstellen)
- C# lernen und unter C# programmieren
- C++/CLI NUR für die Forms einsetzen und sonst bei oldschool C++ bleiben, Threads entweder über pthreads (War doch Microsoft oder?) oder die Boost.
- Ich zeige MS und Borland den Mittelfinger, schnappe mir das VS, knalle Boost rein, packe eine Portion einer GUI dazu, schüttle das alles und programmiere zu 80% plattformunabhängig und packe ein wenig Winapi rein.
- Ich werde zum Ledernacken und pfeiffe auf alle Bibs und packe die reine Winapi aus.

extern "C"
{
#include "DLL.h" // wie auch immer die Header-Datei der DLL heißt
}

angeben.

Sollte es jedoch eine DLL mit C++-Schnittstelle sein (z.B. Verwendung von std::string oder std::iostream als Parameter), dann funktioniert es leider nicht und du mußt einen anderen Weg wählen.

Bevor du jedoch die komplette Anwendung neu schreibst, würde ich einfach mit dem MS-Visual Studio selber eine DLL (mit reiner C-Schnittstelle) erstellen, welche die Funktionen der externen DLL einfach wrappt und über oben gezeigten Weg die DLL mit dem Borland Builder einbinden.

Implib hat total versagt. Das war vor 6 Wochen mein erster Gedanke. Das Wrappen der Zweite. Haben wir aber verworfen. Die BV-Lib ist nicht die Einzige. Da kommen noch diverse Treiber dazu. --> Umständlichkeit.

Die C Schnittstelle, an die du denkst kann man vergessen. Ich hab mit dem Support telefoniert. Und der meinte, dass die einzige Möglichkeit die COM Schnittstellen wären. Sie hätten schon vor Jahren angefangen Support Anfragen an Borland zu stellen, weil der Compiler nicht will, haben aber nie eine Reaktion bekommen.

Ich hab jedenfalls den Eindruck, dass die meisten Bibliotheken oder Treiber, die man kauft nur MSVC mögen. Ich finde, dass einfach Microsoft so sehr die Finger in der Industrie hat, dass es zuviele Hürden gibt. Auch die Boost ist erst seit kurzem wirklich unter Borland laufend.

Also sämtliche BV-Firmen, in denen ich Leute kenne, arbeiten mit dem Studio. Bis auf den einen oder anderen Enthusiasten, der Linux benutzt.

unter linux ist man bestimmt genauso aufgeschmissen wenn man c++ programmiert aber nicht gpp, sondern codewarrior oder was es da sonst noch gibt benutzt.

Ich weiss. Aber das COM Konzept bedeutet für mich böhmische Dörfer.

COM jedenfalls würde ich mir mal ansehen. Es gibt zwar ein paar Hürden beim Einstieg, doch mußt du dir überlegen, ob diese oder der komplette Wechsel auf VS schwerer wiegen.

Shogun (ups logout) schrieb:

Die C Schnittstelle, an die du denkst kann man vergessen. Ich hab mit dem Support telefoniert. Und der meinte, dass die einzige Möglichkeit die COM Schnittstellen wären. Sie hätten schon vor Jahren angefangen Support Anfragen an Borland zu stellen, weil der Compiler nicht will, haben aber nie eine Reaktion bekommen.

Wenn es eine C-Schnittstelle ist, woran sollte es dann scheitern? Sicher nicht am BCC. Mehr Details bitte.

cpt. obvious schrieb:

warum borland da nicht für mehr kompatibilität sorgt, ist für mich unbegreiflich. das name mangling nachzubauen kann ja so schwer nicht sein.

Für Borland zählt ja nicht nur die Microsoft-, sondern vor allem die Abwärts- und Delphi-Kompatibilität. Und diese überliefern nun mal ein eigenes Objektdateien-, Datenstruktur- und .LIB-Format sowie eigene Name-Mangling-Konventionen. Würde man den BCC binärkompatibel mit einem anderen Compiler machen wollen, müßte man all diese ändern, und bei dem Aufwand, und da man sich die kompatibilitätsabhängige und die Delphi-orientierte Kundschaft damit verscherzt, könnte man gleich den anderen Compiler lizensieren.

Ich hoffe, dir ist es jetzt begreiflich

cpt. obvious schrieb:

warum borland da nicht für mehr kompatibilität sorgt, ist für mich unbegreiflich. das name mangling nachzubauen kann ja so schwer nicht sein.

Für Borland zählt ja nicht nur die Microsoft-, sondern vor allem die Abwärts- und Delphi-Kompatibilität. Und diese überliefern nun mal ein eigenes Objektdateien-, Datenstruktur- und .LIB-Format sowie eigene Name-Mangling-Konventionen. Würde man den BCC binärkompatibel mit einem anderen Compiler machen wollen, müßte man all diese ändern, und bei dem Aufwand, und da man sich die kompatibilitätsabhängige und die Delphi-orientierte Kundschaft damit verscherzt, könnte man gleich den anderen Compiler lizensieren.

Ich hoffe, dir ist es jetzt begreiflich

nein, ist es nicht. das ist ja alles schön und gut. das sollte borland aber nicht daran hindern, die kompatibilität *zusätzlich* einzubauen, zumindest was die verwendung von msvc-libs betrifft. implib reicht dafür offenkundig nicht aus. damit würde man sich sicher nix verscherzen, im gegenteil.

wenn microsoft auf proprietäres gedöns setzt, schimpfen immer alle. wenn borland das zum leidwesen seiner kunden macht, dann ist das voll in ordnung, der kompatibilität mit sich selber wegen. lustigerweise wird bei msvc ja das offene format (COFF) benutzt.

das sollte borland aber nicht daran hindern, die kompatibilität *zusätzlich* einzubauen, zumindest was die verwendung von msvc-libs betrifft.

Klar wäre es mit vertretbarem Aufwand möglich, mit den Namensdekorierungen von VC++ umzugehen. Und dann? Du kannst die Funktionen theoretisch aufrufen, aber übergibt VC++ this im gleichen Register, oder gar über den Stack? Wie wird der Rückgabewert übergeben? Wo ist der VTable-Zeiger innerhalb einer Klasse? Wie ist die VTable aufgebaut? Gibt es u.U. spezielle Optimierungen in diesem Bereich? Wie ist die dynamische Speicherverwaltung genau implementiert, was hat zu passieren, wenn ein Objekt mit delete freigegeben wird? Wie genau sind Exceptions implementiert?

All das sind Fragen, die auftauchen, weil der C++-Standard ihre Implementation nicht genau spezifiziert hat. Der C-Standard zusammen mit ein paar Windows-Konventionen ist da ergiebiger: eine C-Funktion im Stil der WinAPI (kein Rückgabewert größer als Register, Übergabe von Datenstrukturen per Zeiger) ist völlig compilerunabhängig. Da der C++-Standard keine Vorgaben hinsichtlich der genannten Punkte macht, gilt grundsätzlich: kompilierter C++-Code ist zwischen verschiedenen Compilern nicht austauschbar. Und der BCC ist da kein Sonderfall.