performance c++ <> Delphi

[mensch72]

Ich erspare mir mal Kommentare zu sync/async und wer hier "zu langsam" ist.

Ganz BlackBox und allgemein:
- die DLL ist hier der Master und erzeugt freundlicherweise NotifyEvents... dies tut sie aktuell via Aufruf einer CallBackFunktion
- wenn mein Programm das wäre, wessen CallBack da aufgerufen wird, dann MUSS ICH garantieren, das meine CallbackFunktion so schnell nur irgend geht funktioniert. Das kann ich per eigener Queue selbst machen oder ich nutze die WindowsMessageQueue... ist aber mein Bier und ich kann nicht erwarten, das die DLL selbst auch noch so freundlich ist, mir alle Events zu synchronisieren und zu puffern. Wenn ich die DLL "quäle" in dem meine Callbacks "zu lange" brauchen, kann es rein als Blackbox zwei Arten von Grundsatzproblemen geben:
- a: die DLL und alles was sie macht hängt so lange ich meine ersten EventCallbackFunktion nicht beende und so die Ausführung zur DLL zurückkehrt
- b: die DLL ruft wie auch immer die EventCallbackFunktion nochmal/mehrmals auf, also voll rekursiv... darauf sollte dann aber sowohl die DLL wie auch mein Programm vorbereitet sein

Wenn es nicht zuviel Aufwand ist, biete doch offiziell statt eines EventCallbacks auch eine Möglichkeit für eine EventMessage an, also lass deiner DLL vom Hauptprogramm ein FansterHandle und eine MessageID geben, was du per PostMessage per WPARAM und LPARAM mit 2 Werten für EventType und EventValue fütterst.
Das spart viel Stress. Wenn mehr Daten zu übertragen sind dann die einfach per UDP über "localhost" aus der DLL heraus schicken... dann so eine C++ oder was auch immer Programm doch da die Daten "auffangen"... "Synchrone EventCallBacks" nutzen wir nur mit/zwischen "eigenen" Programmen und DLLs, externes IPC wenn möglich per PostMessage oder per Pipe oder UDP.

Auf so Diskussionen über Schuld/Unschuld bei externen CallBacks verzichte ich, und realisiere es "asynchron" über einen vertrauenswürdigen OS-Puffer, also MessageQueue,Pipes oder Socket:)

[EWeiss]

Für die Messagen weise ich ein MessageHandle zu

Delphi-Quellcode:

FMessageHandle := Classes.AllocateHWnd(ProcMessage);

In der Function ProcMessage werte ich nun die Events aus.

Delphi-Quellcode:

if (iEventCode = EC_COMPLETE) or (iEventCode = EC_USERABORT) then // Event is reached
begin
  MediaControl.Stop;                          // Player Stopped
  SetMediaStreamPos(0);                       // Streamposition set to zero
  FPlayerState := psSTOPPED;                  // PlayerState is stopped
  if Win32MajorVersion >= 6 then             
    AllowMonitorPowerdown;                    // SetThreadExecutionState continuous
  if Assigned(FEventNoticeFunc) then          // if Event registerd > NULL
    FEventNoticeFunc(PlayEnded);              // send the Event

Wenn mir nun DirectShow die Message EC_COMPLETE oder bei Fehler EC_USERABORT dann reagiere ich darauf.
Siehe Code.

Ich wüsste jetzt nicht wie ich das noch besser machen sollte.
Das ist mein einziger Thread!

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1378440)

Zitat:

Da hat er vermutlich sogar recht, wobei das stdcall im Typedef sich auch keinesfalls negativ auswirken würde. Erfüllt halt vor allem die Funktion des selbstdokumentierenden Codes.

Nun ich bin davon ausgegangen das ein stdcall von Nöten ist um die Funktionsweise des Event zu gewähren.
Zumindest habe ich das bei unserer letzten Diskussion so verstanden.

Ja, also die Callback Funktion muss zwingend die

Delphi-Quellcode:

stdcall

Konvention besitzen (weil das bei dir in der Dll ja auch der Fall ist). Beim Funktionszeiger Typedef scheint es wohl egal zu sein (wundert mich eigentlich, weil die C++ Compiler in der richtigen Konfiguration eigentlich sehr pingelig sind). Warum dein Kontakt die Calling Convention hier zwanghaft weglassen will, leuchtet mir aber trotzdem nicht ein. Ziemlich gefährlich, wenn er mal selbst eine Variable dieses Typs im C++ Programm zuweisen will und außerdem aus Korrektheitsgründen einfach falsch. Ohne

Delphi-Quellcode:

stdcall

bleibt es wie man es dreht und wendet der falsche Typ.

[EWeiss]

Na ja seine Meinung ist halt das er schon sehr lange sich mit Callbacks beschäftigt
und MF das genauso machen würde deshalb will er stdcall nicht.

OK sei's drum. Ich lasse es drin weil es einfach richtig aussieht. LOL

gruss

[TiGü]

Was ist denn MF? Media Foundation?

[OlafSt]

Ich tippe mal, das hier "MFC" gemeint ist. Microsoft Foundation Classes.

MFC ist aber nur eine Bibliothek für Windows-Controls, so wie die VCL in Delphi auch nur eine Bibliothek ist. Das hat nix mit C++ zu tun (die MFC wurde damals für Visual C (ohne ++) entwickelt), so wie die VCL auch nicht "Delphi" ist.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1378484)

Was ist denn MF? Media Foundation?

Richtig!
Es geht ja um das abspielen von Media Dateien.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1378465)

Na ja seine Meinung ist halt das er schon sehr lange sich mit Callbacks beschäftigt
und MF das genauso machen würde deshalb will er stdcall nicht.

An deiner Stelle würde ich hier keinen Support mehr geben, da er sich zu 100% irgendwo den Stack zerschießt. Da ist es kein Wunder, dass überall komische Exceptions rumfliegen.

Sollte auch für ihn ganz einfach zu testen sein. Wenn Typedef und Funktion die gleiche Calling Convention besitzen, funktioniert alles wunderbar:

Code:

typedef void (__stdcall *TestFuncPtr)(const char*);

void __stdcall func(const char* text)
{
    puts(text);
}

int main()
{
    // Ohne das reinterpret_cast weigert sich mein VS sogar schon den Code zu kompilieren.
    // (Was auch das korrekte von mir erwartete Verhalten darstellt)
    // Bei gleichen Calling Conventions kann der Cast weggelassen werden.
    TestFuncPtr test = reinterpret_cast<TestFuncPtr>(&func);
    test("test");
    return 0;
}

Lässt er jetzt an einer der Stellen das

Delphi-Quellcode:

stdcall

weg oder ändert es zu

Delphi-Quellcode:

cdecl

, dann wird unmittelbar nach dem Ausführen von

Delphi-Quellcode:

test

der Stack corrupted (was mir mein VS im Debug Mode sogar auch ordnungsgemäß in einer Fehlermeldung mitteilt).
Es muss immer an beiden Stellen gleich sein. Die erste Stelle ist aber in deinem Fall deine Dll, weshalb du ihm die

Delphi-Quellcode:

stdcall

Convention vorgibst. Daran muss er sich halt halten. Ob er will oder nicht. Sonst kracht es.

[p80286]

Do not argue with an idiot. He will drag you down to his level and beat you with experience.

Selten einen so treffenden Footer gesehen.
(Es soll allerdings auch bei der C-Fraktion ganz vernünftige Menschen geben.

Zitat:

Zitat von Zacherl (Beitrag 1378514)

Es muss immer an beiden Stellen gleich sein. Die erste Stelle ist aber in deinem Fall deine Dll, weshalb du ihm die

Delphi-Quellcode:

stdcall

Convention vorgibst. Daran muss er sich halt halten. Ob er will oder nicht. Sonst kracht es.

Dem ist nichts hinzu zu fügen.

Gruß
K-H

[EWeiss]

Werde ihm das mal verklickern ;)
Mit meinem perfekten Englisch (Ironie an/aus)

Danke.

Zitat:

An deiner Stelle würde ich hier keinen Support mehr geben, da er sich zu 100% irgendwo den Stack zerschießt. Da ist es kein Wunder, dass überall komische Exceptions rumfliegen.

Ja so wie mit dem Slider beim Event..

gruss