@Synchor: Jau stimmt. Wenn ich an den alten Multi-Prozessor Rechner von meinen Chef denke: Der eine Prozessor hat die Platte initialisiert und der anderer wollte darauf zugreifen, was nicht ging da diese ja von ersten Initialisiert wurde. (Ok, es waren nicht die Prozessoren sondern diverse Services von NT, deren Main-Threads auf den verschiedensten Prozessoren liefen!). Wie gesagt: das ganze unter NT 4.0. Das Ergebnis war die reinste NT-Selbstverarschung: Beim booten, nach dem LogIn kam eine MessageBox mit "Festplatte nicht gefunden"!

@Test: hatte versucht, eine TForm-Kompatible Klasse zu schreiben die nur das aller notwendigste macht. Dummerweise werden dann die Ereignisse nicht automatisch zugewiesen. Schade, mann hätte dann nur in der Uses-Klausel Forms durch GLForms ersetzen müssen und voila. Ein Grund-Application- und Grund-Form-Objekt wären in der Unit gewesen und die wichtigsten Ereignisse hätte man dann gehabt. Aber leider ist dem eben nicht so...

Für mich gibt's noch 'nen Grund, VCL zu verwenden: ich find' es einfach übersichtlicher, ein Objekt zu haben anstellen einer Unit mit x prozeduren. Ich finde die API-Demos imme rirgendwie so "ungemütlich" und unübersichtlich. Ok, wenn man das API-Fenster in ein Objekt packt usw. dann geht's ja eigentlich auch. Ist größtenteils warscheinlich wirklich geschmackssache!

@Multithreading: Jemand hat mal gesagt: "Der beste Weg, mit Multithreading fertig zu werden und klar zu kommen ist, es erst gar nicht zu verwenden". Isst was drann. Wenn's nicht unbedingt notwendig ist, sollte man ohne Multithreading auskommen, da man sich sonst mächtig viel Probleme einhandeln kann! Wenns nicht anders geht, tja dann...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Das ist schon richtig, dass es keine echtes ist. Aber auch wenn du nur einen Prozessor hast, kommt es zu den selben Problemen wie mit zweien! Windows muss ja den derzeit laufenden Thread unterbrechen um einen anderen freie fahrt zu gewähren. Und Windows ist es egal ob dieser (der unterbrochen werden soll) gerade in einen Speicher reinschreibt oder nicht. Von daher muss synchronisiert werden um das zu verhindern.

Synchronisieren erzwingt, dass die Methode aus dem VCL-Thread aufgerufen wird. Und hält somit den eigentlichen Thread an. Zu viel Synchronisieren bremst also nur aus. Dafür gibt es ja auch andere möglichkeiten (TCriticalSection,...)

TCriticalSection ist ja eben eine Synchronisierungsmethode. Sie hält die Threads auf geschickte weise davon ab in die gleiche Sektion zu laufen(Enter, Leave, etc.). Das macht das Synchronize der VCL Threads doch auch, nur nicht mit einer CriticalSection(da diese nicht gerade schnell ist):

Das ist schon richtig. Die critical Section wartet aber in dem Thread bis der Block zwischen enter und leave wieder frei ist. Synchronize führt aber die Methode in dem VCL-Thread aus. Das bedeutet sobald ein Thread eine X belibige Methode synchronisiert müssel ALLE anderen auch warten auch wenn die wass ganz anderen synchronisiert haben wollen. Sobald der VCL-Thread in einer Methode steckt wird auch kein synchronize abgearbeitet. Das es ja über eine WindowsMessage geht. :-/
2 unterschiedliche critical Sections blockieren sich gegenseitig nicht.

den fall, dass du gleichzeit zeichnest in 2 nicht VCL Hauptthreads halte ich für einen exotischen Fall, dass er im Normalfall zu vernachlässigen ist - ich jedenfalls musste das noch nie tun - und bei verteiltem bilderrechnen nutzt man dann das synchronize eh nicht mehr, es sei denn man will beim berechenen zuschaun - stattdessen legt man sein bild irgendwo anders ab und übergibt es an die VCL erst, wenn man mit dem berechnen des eigenen Abschnitts fertig ist -> kein Synchronize und die möglichkeit, nicht nur auf unterschiedlichen Prozessoren, sondern auch auf komplett abgetrennten Maschienen(Netzverbindnung ist natürlich vorhanden) zu rendern.

derzeit habe ich auch den sonderbaren Fall, dass ich einen Thread zum Laden und berechnen von Daten habe und den zweiten einfach nur zum Rendern verwende. Und dort wird dann auch nirgendwo ein Synchronize stehen. Weil es nun mal mehr bremmst als eine critical Section.

*kopf schüttel* Leute, das ist doch immer wieder das gleiche. Kaum sagt einer: VCL oder API bricht ein kleinkrieg aus und man schaukelt sich gegenseitig hoch. Das iss nun wirklich schwachsinn. Den:

1.) OOP hat nichts mit API oder VCL zu tun. Zwar ist die VCL in OOP, kapselt letzendlich aber auch nur die API! Das sollte man nicht vergessen.

2.) Das Argument "warum Messages-Verarbeiten, die man eh sowieso brauch" hat durch aus was für sich.

3.) Das Argument "so viel Rechenzeit verbrät die VCL aber nicht" kann man auch stehen lassen.

Somit ist es wirklich Geschmakssache. Ich kann verstehen, wenn einer ein API-Fenster verwendet, weil er sagt "Das Fenster ist nur Mittel zum Zweck, den Rest brauch ich nicht". Aber jeder Programmier-Anfänger sollte erstmal die Finger von der API lassen. Wer sich auskennt, kann machen was er will. Somit mein Rat:

Anfänger -> Verwendet VCL.
Fortgeschrittene -> Macht doch was ihr wollt

Und er meint, sein Programm läuft langsam weil er ein VCL-Fenster verwendet, der ist IMO auch auf dem Holzweg. Mich würde an der Stelle nun aber echt mal ein unparteischer Geschwindigkeitstest interresieren um dem Leidigen Thema ein für alle mal ein Ende zu setzen!!!

Kleine Vorwahrnung: Sollte dieser Thread wirklich esklaieren und die ein oder anderen Persönlich oder eingeschnappt, aufbrausend oder sonstwas werden, wird der Thread geschlossen! (Wie gesagt: ist nur 'ne Vorwarnung. Bisher kein Grund aber kleine Tendenzen sind IMO in diese Richtung schon leicht sichtbar.) Seine Meinung sachlich zu sagen ist ok. Aber den "Streß-modus" oder ähnliches einzuschalten ist nicht angesagt! Fehlt nur noch, das wieder jemand mit "C/C++ oder Delphi" anfängt (sollte keine Aufforderung sein!)

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Nein nein, dann müsste man die VCL auch nicht synchronisieren, wenn das Windows machen würde. Critical Sections, Mutexe, Semaphoren, etc. werden in vielen Multithreaded Anwendungen verwendet, sobald sich die Threads Speicherbereiche Teilen, was allein daran liegt, dass das gar nicht anders geht. Nutzt du diese nicht crasht dir dein Programm - auf irgendeine weise, z.B. Bluescreen, Schutverletzung, Taskabbruch oder einfach nuir wegen total unbrauchbaren Daten. Mich jedenfalls hat mein windows noch nie zwangssynchronisiert, doer verstehe ich dich einfach falsch? Jedenfalls fällt die VCL Synchronisierung auch darunter und du musst das in Threads nunmal manuell machen, da wenn dies die VCL selbsttätig machen würde, sie um einiges langsamer werden würde.


Das hat niemand gesagt, nur kommen hier einige Posts so rüber, als wäre VCL so schrecklich lahm, dass man unbedingt API nehmen müsse und du hast inzwischen selber gesagt dass das unsinn ist.

So ist das numal, wenn jemand einen Glaubenskrieg aufwärmt - genauso wie OpenGl vs. Direct3D, C++ vs Delphi, API vs. VCL,... Da ist ein wenig geplänkel doch normal - sowas darfst du hier bitte nicht zu ernst nehmen, vorrangig hier ist doch, dass alle Spass haben, bei ihrem tun - wenn dich dieser Thread also nervt, übergeh ihn bitte, damit du uns noch weiterhin beehren kannst, ohne ständig hieran zu denken :blink:

Ach da hängt der Hammer... Nun meinetwegen, das kann man glatt durchgehen lassen, da TThread tatsächlich in der VCL Bibliothek Classes deklariert ist. In jedem Fall bleibt die Klasse TThread aber immernoch eine schöne Kapselung, die einem unnötige Arbeit abnimmt

Also ich habe mir mal gerade den Quelltext zu TThread angesehen und dort finde ich keine Interaktion mit Komponenten, die von TPersistent abgeleitet sind.

Definition von TThread:


Nachdem ich grob die Implementierung angesehen habe, werden nur API-Calls und Callbacks gekapselt, und somit ist es eine einfache Möglichkeit mit Windows- oder Linux-Threads zu arbeiten.

KidPaddle

_________________
http://www.seban.de

das ist schon klar - nur gehört diese Klasse(bei Delphi 5 zumindest) in die Unit Classes, die Teil der VCL ist. Dass sie Prima zum arbeiten mit Linux/Windows Threads geeignet ist, ist natürlich klar. Ansonsten zeigst du hier TThreadList und nicht TThread

:wacko: Schande über mich! :wacko: (Irgendwie fehlt diese sich Schämen-Icon mir)

Und was macht das aus, das TThread in der Unit Classes ist?



Diese Aussage ist somit, und das wars weswegen ich nachgesehen habe, nicht gültig. Ob das Ding nun in der Unit Classes ist, ist dabei ohne Belang, oder?

KidPaddle

_________________
http://www.seban.de

Nachdem ich jetzt den ganzen Thread gelesen habe, geb' ich halt auch noch meinen Senf dazu:

Die Diskussion scheint ja eher darum zu gehen, ob der OpenGL Renderkontext in einem Delphiformular aufscheint, oder nicht - denn natürlich kann man die VCL auch in eigenen (über die Windows API generierten) Fenstern nutzen - z.B. um JPEGs zu laden oder was auch immer. Sogar den Formulardesigner kann man (etwa für komplexe Dialoge) nutzen, indem man das entsprechende Formular einfach erstellt, per "uses" Klausel ins Hauptprogramm einbendet - und dann halt dort bei Bedarf kreiert und anzeigt.

Ich benutze für meinen OpenGL spezifischen Code lieber eine selbst generierte Fensterklasse, da ich insofern flexibler bin, als ich bei der WinAPI Funktion CreateWindow z.B. das Handle eines VCL-Formulars als Elternfenster angeben kann (unter Verwendung von WS_CHILD habe ich dann sozusagen eine VCL-Anwendung, zum exakten Positionieren ist eine Bevelkomponente ganz praktisch) - und dennoch kann ich den MessageHandler des Fensters selbst definieren, ohne auf die von der VCL vorgegebenen Ereignisse zurückgreifen zu müssen.
Will ich hingegen ein völlig eigenständiges Fenster haben, gebe ich halt kein Elternfenster an - und das brauche ich genau dann, wenn ich eine Anwendung schreibe, die z.B. im Vollbild mit einer anderen Auflösung laufen soll, bzw. wenn ich unabhängig von der verwendeten Delphiversion sein möchte.

Die VCL benutze ich zwar gern für meine eigenen Anwendungen (und vor allem der Formulardesigner ist extrem praktisch, da kann sich auch Visual Studio .NET verstecken), würde aber z.B. meinen Sourcecodegenerator Mcad nie VCL spezifischen Code erstellen lassen, da ich nur so sicher stellen kann völlig unabhängig von der verwendeten Delphiversion zu sein (dass sich die Object Pascal Sprachdefinition grundlegend ändert, ist ja eher unwahrscheinlich). Wie gesagt ist es ja dann nicht schwierig, für eine konkrete Anwendung, bei der ich genau weiß, mit welcher Delphiversion ich sie kompilieren möchte, die VCL einzubinden.

Viel Spass beim Programmieren,

Martin
<a href='http://mcad.delphigl.com' target='_blank'>http://mcad.delphigl.com</a>

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/