performance c++ <> Delphi

[EWeiss]

Kurze Frage.

Wie hoch ist die Wahrscheinlichkeit das beim senden eines Event aus einer Delphi DLL C++ sich verschlucken kann und es zu einem Absturz der Anwendung kommt.
Gibt es Statistiken?

Mir möchte jemand erzählen das wenn er seine Scrollbar sehr schnell zum Ende bewegt wenn ein Movie spielt seine Anwendung dabei abstürzt.

Und sein Fix wäre im Event eine Postmessage an seine Winproc zu senden und dort erst den Code auszuführen
der eigentlich in das Event gehört.

Er ist der Meinung man könnt das nur beheben wenn man meine DLL nach C++ portiert (mache ich nicht)

gruss

[freimatz]

Kurze Antwort: Nein.

Bischen wirr geschrieben der Beitrag (so wie meine meist.)

Wie kann man ein Event an C++ schicken? C++ ist eine Programmiersprache :wink:

Wenn es um Probleme gibt und Postmessage ist im Spiel ist Delphi sicher so viel langsamer, als dass das irgendweine Rolle spielen könnte.

[hoika]

Hallo,

Zitat:

Mir möchte jemand erzählen das wenn er seine Scrollbar sehr schnell zum Ende bewegt wenn ein Movie spielt seine Anwendung dabei abstürzt.

Dann baue ihm eine Dummy-DLL, deren Aufrufe nichts machen zum Test.
Oder er soll sich eine c++-DLL bauen.

Und außerdem:
Wenn seine Anwendung abstürzt, was kannst du denn dafür ;)

[Zacherl]

Von der Performance ist C++ sicherlich besser als Delphi, aber das ist definitiv nicht die Ursache des Problems.

Verwendest du in deiner Dll oder er in seinem Programm mehrere Threads?

[Uwe Raabe]

Zitat:

Zitat von Zacherl (Beitrag 1378424)

Von der Performance ist C++ sicherlich besser als Delphi, aber das ist definitiv nicht die Ursache des Problems.

Genau! Ein fehlerhaftes Programm kann man bekanntlich in jeder Programmiersprache schreiben - in manchen ist das etwas schwieriger als in anderen. Allerdings glänzt C++ gerade in diesem Punkt nicht so besonders.

[Blup]

Wenn man überhaupt nicht weis was diese DLL und die Anwendung macht, kann man mit der Beschreibung nicht viel anfangen.

Eine Möglichkeit wäre z.B., die DLL ruft innerhalb eine Threads das Event auf.
Die Anwendung möchte im Event auf die VCL zugreifen.
Dann könnte der Eventhandler per PostMessage die Nachricht an den Hauptthread weiter leiten, der das darf.

[nahpets]

Zitat:

Zitat von Zacherl (Beitrag 1378424)

Von der Performance ist C++ sicherlich besser als Delphi, aber das ist definitiv nicht die Ursache des Problems.

Aber dann stimmt dashier nicht: Integer Performance Comparison for C++, C#, Delphi
Da kommt genau das gegenteilige Ergebnis raus.

[EWeiss]

Zitat:

Bischen wirr geschrieben der Beitrag (so wie meine meist.)

Kein Ahnung was du wirr meinst noch deutlicher kann man das nicht formulieren.

Zitat:

Zitat von Blup (Beitrag 1378426)

Wenn man überhaupt nicht weis was diese DLL und die Anwendung macht, kann man mit der Beschreibung nicht viel anfangen.

Eine Möglichkeit wäre z.B., die DLL ruft innerhalb eine Threads das Event auf.
Die Anwendung möchte im Event auf die VCL zugreifen.
Dann könnte der Eventhandler per PostMessage die Nachricht an den Hauptthread weiter leiten, der das darf.

Ich weis was er macht.
Also nochmal!

Meine DLL schickt ein Event an die Anwendung welche C++ verwendet.
Die Funktion die das Event signalisiert.

Code:

BOOL KVIDEOPLAYERDEF(KVideo_Initialize)(HWND MediaWindow, BOOL UseOverlay, CBEventNotice event);

Meine Reverenz.

Code:

typedef void(__stdcall *CBEventNotice)(TPlayerEvent);

sein Reverenz.

Code:

typedef void( *CBEventNotice)(TPlayerEvent);

er meint er braucht __stdcall nicht weil die Referenz selbst bei ihm nie aufgerufen wird.

Die CallBack bei mir.. funktioniert ohne Probleme.

Code:

void __stdcall OnPlayerEvent(TPlayerEvent event)
{
    if (event == PlayEnded)
    {
        KillTimer(MovieHandle, MOVIE_TIMER);
        // IMediaSeeking mach probleme wenn Position weniger dann auf Max setzen
        INT64 MaxPos = (aMediaProperty.PlaybackLength / 10000) / 1000;
        if (Position < MaxPos)
            SetScrollPos(MovieHandle, SBS_HORZ, (int)MaxPos, TRUE);
        else
            SetScrollPos(MovieHandle, SBS_HORZ, 0, TRUE);
    }
}

Die Callback bei ihm.

Code:

void __stdcall OnPlayerEvent(TPlayerEvent event)
{
    if (event == PlayEnded)
    {
         if (CheckLoopMode()) {
            KVideo_Play();
         } else {
            SetStatusText(L"Closed");
            DisableRestoreState();
            Media_Stopped();
         }
    }
}

Hier soll es jetzt krachen wenn er seinen Slider schnell zum Ende bewegt.
Er hat das jetzt so umgangen.

Code:

void CALLBACK OnPlayerEvent(TPlayerEvent event) {
    PostMessage(hMain, WM_COMMAND, MAKLNG(IDC_PLAYENDED, 0), NULL);
}

WinProc

Code:

        case IDC_PLAYENDED:
            if (CheckLoopMode()) {
                KVideo_Play();
            } else {
                SetStatusText(L"Closed");
                DisableRestoreState();
                Media_Stopped();
            }
            break;

er ist der Meinung das es an Delphi liegt.
wäre zu langsam.

Zudem gäbe es das Problem das meine DLL synchron und MF asynchron laufen das wäre das Problem warum meine DLL zu viel CPU verwenden würde beim abspielen der Videos.

Zitat:

Verwendest du in deiner Dll oder er in seinem Programm mehrere Threads?

Ich nicht er schon.


gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1378429)

er ist der Meinung das es an Delphi liegt.
wäre zu langsam.

Zudem gäbe es das Problem das meine DLL synchron und MF asynchron laufen das wäre das Problem warum meine DLL zu viel CPU verwenden würde beim abspielen der Videos.

Selten so blöde Aussagen gehört, die jedlicher Logik entsagen :-D

Zitat:

Zitat von EWeiss (Beitrag 1378429)

Zitat:

Verwendest du in deiner Dll oder er in seinem Programm mehrere Threads?

Ich nicht er schon.

Dann wette ich schon fast drauf, dass hier irgendwo die Ursache zu finden ist.

Zitat:

Zitat von EWeiss (Beitrag 1378429)

er meint er braucht __stdcall nicht weil die Referenz selbst bei ihm nie aufgerufen wird

Da hat er vermutlich sogar recht, wobei das

Delphi-Quellcode:

stdcall

im Typedef sich auch keinesfalls negativ auswirken würde. Erfüllt halt vor allem die Funktion des selbstdokumentierenden Codes.

[EWeiss]

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.

Nun wie schon erwähnt bin kein besonders guter Kenner von C++ aber versuche mein bestes mit eurer Unterstützung..

gruss

[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

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1378513)

Zitat:

Zitat von TiGü (Beitrag 1378484)

Was ist denn MF? Media Foundation?

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

Entweder hat er was nicht verstanden oder du oder ihr redet aneinander vorbei.

Die flachen Funktionen und auch die Methoden vom Media Foundation SDK sind alle mit stdcall; getaggt.
Ich denke, er meinte eher die Art und Weise, wie mit Callbacks im Umfeld von Medien-abspielen umgegangen wird.

[EWeiss]

Nö.. er meint er hat sehr viel Erfahrung mit Callbacks mehr ist da nicht zu sagen.
Er lässt sich halt aufgrund seiner Erfahrung (die er hat) einfach von einem Anfänger C++ nichts sagen)
Das ist das schwierige bei solchen Leuten.

gruss

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1378514)

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.

Antwort!

Zitat:

That is perfectly valid for 32-bit, but i am working in 64-bit that is using only FASTCALLS

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1378522)

Zitat:

That is perfectly valid for 32-bit, but i am working in 64-bit that is using only FASTCALLS

Wenn er ausschließlich für 64-Bit kompiliert, dann hat er recht - dann macht es zumindest keinen Unterschied. Ist trotzdem kein guter Stil, weil er so immer alles ändern muss, falls er doch mal für eine andere Plattform builden will.

[EWeiss]

Zitat:

falls er doch mal für eine andere Plattform builden will.

NA ja egal will er nicht..
Interessiert sich nicht mehr für 32BIT.

Das Problem dabei ist nur wenn er seinen Source schon veröffentlicht und andere hätten lieber 32Bit
weil ihr System nun mal auf 32Bit ausgelegt ist dann müssen diese alles ändern ;)

Nicht mein Problem.

gruss

[OlafSt]

Oder man nimmt eine andere Bibliothek. Würde ich jedenfalls machen, wenn sich einer so betonköpfig verhält :)