spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Ehrlich gesagt klingt mir das ganze Beispiel ziemlich merkwürdig. Was genau macht es für einen Sinn, mehrere Threads auf die selbe COM1 Schnittstelle schreiben zu lassen? Spontan würd ich jedenfalls mal sagen, dass die Verwendung von Threads hier von vorn herein fehlgeleitet ist...

Das ist genau ein Anwendungsfall aus meinem Berufsleben. Viele Threads die aus einem Speicher, an COM1 angeschlossen, sporadisch Daten abfragen.
Der einzige Unterschied ist das die Threads schreiben und dann eine Antwort lesen.

Man sollte als Programmierer niemals das Denken aufgeben und sich nur an Vorgaben klammern. Es spielen ja viele Faktoren mit rein, die die gewählten Mittel evtl. beeinflussen. Und nur wegen bestimmter Richtlinien, immer alles genau nach diesem Konzept zu arbeiten, ist nicht unbedingt der richtige Weg. Aber man sollte nicht vergessen, dass es Gründe gibt, warum bspw. goto eher verpönt ist und sollte sich vor dessen Verwendung schon die Frage stellen, ob es sich nicht mit einfachen Mitteln besser lösen lässt. Aber hat man darüber nachgedacht und hat begründet, warum man hier auf dieses Code-Design zurückgreift, dann spricht nichts dagegen. Gerade natürlich, wenn man möglichst wiederverwendbaren Code schreiben will, sollte man aber evtl. doch ein paar Stunden Mehraufwand für klares Code-Design aufwenden.

Aber lieber sagt man Anfängern klar, was die gängige Meinung dazu ist und dass sie etwas nicht verwenden sollen, damit umso klarer wird, dass man sich vor der Verwendung eben wirklich Gedanken machen sollte.

und bei mir auf Arbeit verwenden wir nicht einfach bloß Singletons, sondern auch Singletons, die Singletons verwenden
und ich würde dennoch nicht sagen, dass das gut ist

wir verwenden zwar ebenfalls Unittests, aber nicht für Klassen, die auf Singletons zugreifen
(weil diese sich nicht so einfach automatisiert testen lassen, da die Funktionstüchtigkeit der Singletons gegeben sein muss)


und zu Goto in C#:
warum ist das Schlüsselwort "goto" in Java reserviert, aber ohne Funktion?

verschachtelte Schleifen:
wie schon geschrieben wurde, sollten diese ggf. aufgesplittet werden, da sie möglicherweise schon sehr viel Logik beinhalten
außerdem gibt es da etwas, womit man auch aus der tiefsten Verschachtelung sofort ausbrechen kann: return (man muss es nur richtig anwenden)


Multithreading:
und immernoch ist der Zweck mehrerer Threads nicht ganz klar
warum wird die Verarbeitung parallelisiert? was wird da denn (im Groben) verarbeitet?

Zitat von »stef«

Stell dir vor du schreibst eine Applikation in der mehrere Threads auf ein Gerät zugreifen das über RS232/COM1 am Hostrechner angeschlossen ist.

Dann würde ich jedem davon eine Klasse übergeben, die die Zugriffe auf das Gerät kapselt.

Zitat von »stef«

Die Threads öffnen ab und zu mal COM1 senden was raus und schließen COM1 wieder.

Halte ich für einen ganz schlechten Entwurf, wenn die Threads das selbst machen.

Zitat von »stef«

Um zu verhindern das es beim öffnen von COM1 kracht schachtelst du die Zugriffe in eine CS.

Ich? Nein, ich ganz sicher nicht. Meine Lösung steht oben.

Zitat von »stef«

Bei zwei Threads übergebe ich die CS vielleicht noch als Pointer an die Threads einzeln. Bei 30 Threads möchte ich den Entwickler sehen der die CS nicht global deklariert.

Jeder gute Entwickler würde das nicht machen. Sorry, Eure Künste in allen Ehren, aber ich finde das noch immer einen sehr sehr schlechten Entwurf. Faulheit war noch nie ein gutes Argument, um irgendwas global zu deklarieren.

Zitat von »stef«

Nenne mir einen vernünftigen Grund die CS irgend wo zu verbergen und via Zeiger an alle Threads einzeln zu übergeben außer "Weil man es so macht ..." !

Weil es sicherer ist, sich besser testen lässt, sich besser erweitern und wiederverwenden lässt. Außerdem vermeidet es Code-Duplikation.
Ach, du wolltest nur einen Grund, nicht gleich fünf. Sorry, wenn's nur ein Grund sein darf, dann finde ich keine Antwort.

Zitat von »BlueCobold«

Weil es sicherer ist, sich besser testen lässt, sich besser erweitern und wiederverwenden lässt. Außerdem vermeidet es Code-Duplikation.

Ach Cobold ... das ist doch genau das pauschale Lehrbuch bla bla was ich mit "weil man es so macht ..." meinte!

Zitat von »stef«

Zitat von »BlueCobold«

Weil es sicherer ist, sich besser testen lässt, sich besser erweitern und wiederverwenden lässt. Außerdem vermeidet es Code-Duplikation.

Ach Cobold ... das ist doch genau das pauschale Lehrbuch bla bla was ich mit "weil man es so macht ..." meinte!

Gegenfrage: Verwendet ihr bei euch automatisierte Test, wie Unit-Tests?
ich bezweifle es, denn dann hättet ihr schon festgestellt, dass solche Tests aufgrund der starken Abhängigkeiten nur bedingt durchführbar sind
wenn das Messgerät gerade nicht verfügbar ist o. ä. kann man die darauf aufbauende Funktionalität nicht testen, da man keine Möglichkeit hat, sie mit Testdaten zu füttern
außerdem muss man vorher alle Parameter wissen, um das Ergebnis richtig bewerten zu können - bei dem Messgerät könnte es ggf. gewisse Schwankungen zwischen 2 Messungen geben, wodurch das nicht zwingend gegeben ist

es hat schon einen Grund, warum so viele sowas schreiben

Zitat von »stef«

Zitat von »BlueCobold«

Weil es sicherer ist, sich besser testen lässt, sich besser erweitern und wiederverwenden lässt. Außerdem vermeidet es Code-Duplikation.

Ach Cobold ... das ist doch genau das pauschale Lehrbuch bla bla was ich mit "weil man es so macht ..." meinte!

Nein, die Aussage stammt aus meiner eigenen Erfahrung heraus. Und merkwürdigerweise stimmt das mit *guten* Lehrbuchmeinungen überein. Aber is schon klar, ich liege komplett falsch und Du liegst genau richtig. Man sollte globale Variablen benutzen, gerade wenn man sonst so viele Parameter an so vielen Stellen übergeben müsste und zu faul dazu ist... Und wenn man's kapseln will, macht man am besten gleich ein Singleton draus. Schon klar, schon klar.
Also wozu diskutieren? Du weißt es doch eh besser und schmetterst die "guten Argumente", nach denen Du gefragt hast, als "das steht pauschal in jedem Lehrbuch, also ist es Unfug" ab. Es gibt also keinen Grund weiter darüber zu diskutieren.

Zitat von »stef«

Zitat von »BlueCobold«

Weil es sicherer ist, sich besser testen lässt, sich besser erweitern und wiederverwenden lässt. Außerdem vermeidet es Code-Duplikation.

Ach Cobold ... das ist doch genau das pauschale Lehrbuch bla bla was ich mit "weil man es so macht ..." meinte!

Nur mal was zum Nachdenken: Vielleicht hat es einen Grund, wieso diese Dinge in allen guten Lehrbüchern stehen!? Kann es sein, dass du einfach alles, was so in Lehrbüchern steht, pauschal ablehnst?

Das Beispiel mit einer Datenbankverbindung oder Schnittstelle die in 30 Objekten in 30 verschiedenen Threads benutzt wird klingt nach einem Musterbeispiel für Dependency Injection und nicht für ein Musterbeispiel für eine globale Variable.

Zitat von »BlueCobold«

Nein, die Aussage stammt aus meiner eigenen Erfahrung heraus. Und merkwürdigerweise stimmt das mit *guten* Lehrbuchmeinungen überein. Aber is schon klar, ich liege komplett falsch und Du liegst genau richtig. Man sollte globale Variablen benutzen, gerade wenn man sonst so viele Parameter an so vielen Stellen übergeben müsste und zu faul dazu ist... Und wenn man's kapseln will, macht man am besten gleich ein Singleton draus. Schon klar, schon klar.

Hör auf mir Sachen in den Mund zu legen die ich nie behauptet habe !
Ich habe gesagt das man die Benutzung von GOTO und globalen Objekten nicht von vornherein und prinzipiell verteufeln sollte.
Daraus die Aussage abzuleiten "Man sollte globale Variablen und goto benutzen ..." ist völliger Blödsinn ! Meine Güte, ich rede hier von Ausnahmen !
Wenn jemand auf mich zukommt und sagt "Hey, ich habe da ein Problem in C++ umgesetzt und dabei GOTO verwendet. Ist das so OK ?"
dann sehe ich mir das in Ruhe an und hole nicht den Exorzisten !
In 99% der Fälle werde ich dann genau das sagen was du auch sagst: Es ist geschickter das mit Exceptions, return oder was immer umzusetzen.
Es gibt aber Fälle in denen GOTO einfacher und übersichtlicher ist und deshalb immer noch eine (wenn auch geringe) Daseinsberechtigung hat.
Warum glaubst du habe sich die Entwickler von C# dazu entschlossen GOTO wieder (in JAVA war es nicht drin) mit aufzunehmen ?
Weil sie die Nacht vorher zuviel gesoffen haben oder weil sie zum Schluss gekommen sind das es in manchen Fällen hilfreich sein kann ?
Auch globale bzw. public static objects kann man in C++, JAVA und C# deklarieren. Wenn das ausschließlich Nachteile mit sich bringt warum ist es denn da drin ?
Im übrigen wäre ich mit Begriffen wie "zu faul", "schlechtes Design" usw. vorsichtig. Du kennst weder mich, noch meine art zu Arbeiten und auch nicht woran ich arbeite.
Weis auch nicht warum du immer beim dritten Post gleich auf 180 bist nur weil mal jemand was aderst sieht als du.

Zitat von »dot«

Nur mal was zum Nachdenken: Vielleicht hat es einen Grund, wieso diese Dinge in allen guten Lehrbüchern stehen!? Kann es sein, dass du einfach alles, was so in Lehrbüchern steht, pauschal ablehnst?

Auf keinem Fall ! Ich sage nur das zwischen Lehrbuch und Praxis ein Unterschied besteht. Vieles was in Lehrbüchern steht relativiert sich im alltäglichem Berufsleben.
Das ist wie mit dem Autofahren. Nach ein paar Monaten im Straßenverkehr setzest du auch keinen Blinker mehr wenn du ein geparktes Auto am Straßenrand umfährst.
Ist deshalb die Fahrschule im allgemeinen schlecht ? Nein, man lernt viele Dinge die man Später gut gebrauchen kann und andere die man einfach ignoriert.
Hier wird immer viel erzählt von Programmierstil und Design. Was ist wenn du ein großes Projekt von einem Kollegen erbst und auf das Grunddesign keinen Einfluss mehr hast?
Weigerst du dich dann daran zu arbeiten weil das Design mies ist? Was machst du wenn sich Rahmenbedingungen auf denen dein Design Fußte sich plötzlich ändern ?
Ich würde jedem angehenden Softwareentwickler dazu raten sich wenn möglich an die Lehrbücher zu halten. Wenn man dann in einer Firma landet die ausschließlich nach Handbuch entwickelt,
Perfekt. Meistens lassen so Sachen wie vom Management commitete Dedlines das in vielen Fällen nur bedingt zu. Dann ist es wichtig eine Balance zwischen Theorie und Praxis zu finden.
Wenn du dann auf Teufel komm raus an irgendwelchen Designrichtlinien fest hältst weil du die mal an der Uni eingebläut bekommen hast kann es sein das du schnell mal beim Chef antanzen musst.

Zitat von »Fred«

Man sollte als Programmierer niemals das Denken aufgeben und sich nur an Vorgaben klammern. Es spielen ja viele Faktoren mit rein, die die gewählten Mittel evtl. beeinflussen. Und nur wegen bestimmter Richtlinien, immer alles genau nach diesem Konzept zu arbeiten, ist nicht unbedingt der richtige Weg. Aber man sollte nicht vergessen, dass es Gründe gibt, warum bspw. goto eher verpönt ist und sollte sich vor dessen Verwendung schon die Frage stellen, ob es sich nicht mit einfachen Mitteln besser lösen lässt. Aber hat man darüber nachgedacht und hat begründet, warum man hier auf dieses Code-Design zurückgreift, dann spricht nichts dagegen. Gerade natürlich, wenn man möglichst wiederverwendbaren Code schreiben will, sollte man aber evtl. doch ein paar Stunden Mehraufwand für klares Code-Design aufwenden.

Aber lieber sagt man Anfängern klar, was die gängige Meinung dazu ist und dass sie etwas nicht verwenden sollen, damit umso klarer wird, dass man sich vor der Verwendung eben wirklich Gedanken machen sollte.

Wenigstens einer. Ich hatte schon angefangen an mir zu zweifeln … Danke !

Zitat von »Sacaldur«

Multithreading:
und immernoch ist der Zweck mehrerer Threads nicht ganz klar
warum wird die Verarbeitung parallelisiert? was wird da denn (im Groben) verarbeitet?

Eigentlich wollte ich nicht so genau darauf eingehen, aber was soll es. Mein Baby ist ein Datenbank gestütztes Tool mit dem in unserer Produktion mehrere "Geräte" gleichzeitig programmiert werden.
Der Zugriff auf den an COM1 angeschlossenen Speicher ist dabei nur ein geringer Teil. Der Prozess des Programmierens läuft also Parallel ab um einen hohen Durchsatz zu erreichen.

Zitat von »Sacaldur«

Gegenfrage: Verwendet ihr bei euch automatisierte Test, wie Unit-Tests?

Nein !!!
Das System ist Objektorientiert aufgebaut. Das Hilft schon mal eine Menge bezüglich Erweiterung ohne Seiteneffekte.
Getestet wird indem ein Gerät programmiert wird und dieses dann zwecks Test zur Q geht.