Anti-Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.

Re: Anti-Jammer-Thread

Beitragvon scheichs » 18.04.2018, 22:20

Super! Herzlichen!
scheichs
Establishment
 
Beiträge: 270
Registriert: 28.07.2010, 20:18

Re: Anti-Jammer-Thread

Beitragvon joggel » 26.04.2018, 08:38

Ich bin hier an einem Projekt, wo viel über Singleton-Pattern gelöst wird.
Ich finde das eine saubere Lösung.
So "müllt" man sich zB nicht die Klasse zu, mit Membern die vlt nur _Eine_ aufgabe haben. 8-)

Ich habe aber oft gelesen, das Singleton-Pattern eine "böse" Lösung ist.
Aber warum wird das so gesehen? Und gibt es da vlt eine gute/bessere Alternative?
bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1308
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Anti-Jammer-Thread

Beitragvon RustySpoon » 26.04.2018, 09:08

Ich glaube die Diskussion hatten wir hier schon 1-2x. Ich hab das als gefährliches Terrain in Erinnerung. :p

Ich will dich da auch gar nicht belehren. Persönlich betrachte ich das als eine technische Schuld die man eingeht aber es kann gute Gründe für technische Schulden geben. Außerdem ist z.B. Ressourcenmanagement so ein Aspekt, den man früher oder später immer irgendwo zentral erledigen will oder muss. Aber: Es ist und bleibt halt globaler Zustand. Du weißt nie so richtig, wann wer das Ding wie initialisiert hat (oder eben auch nicht). Sie verschleiern halt auch gern die Abläufe im Programm, es ist halt einfach da "mal fix rüberzugreifen". Es ist die Hölle (und ein Synchronisationspunkt) in Multithreading-Umgebungen und vernünftiges Unittesten ist praktisch unmöglich.

Auf der anderen Seite benutz ich die z.B. gern, wenn ich komplett zustandslose "Verhaltensobjekte" brauch. Sowas wie ein Comparator halt, der zum Sortieren einer Liste genutzt wird. Oder ein LabelProvider in der UI, oder ein Validator, oder oder oder... Das ist aber mehr oder weniger nur eine Mikrooptimierung um nicht tausende Mikroobjekte zu spammen und funktioniert ohne die genannten Nachteile nur, wenn die komplett zustandsfrei sind.

joggel hat geschrieben:So "müllt" man sich zB nicht die Klasse zu, mit Membern die vlt nur _Eine_ aufgabe haben.

Wie meinst du das?

Und gibt es da vlt eine gute/bessere Alternative?

Das hängt davon ab, was du damit anstellst und in was für einer Umgebung du Arbeitest. Wenn es dir um die Bequemlichkeit geht auf irgendwelche Services überall zugreifen zu können, solltest du vielleicht mal dein Domänenmodell überdenken. Ansonsten kann es sicher nicht schaden, sich mit sowas wie Dependency Injection zu befassen, das sorgt imho immer ganz gut dafür, dass man solche Schweinereien lässt. ;)

Aber wie gesagt, ohne deinen konkreten Anwendungsfall und Projektsituation zu kennen, finde ich es immer schwierig sowas zu bewerten. Vielleicht ist das in deinem Fall nach wirtschaftlichen Abwägungen etc. tatsächlich die beste Lösung. :)
RustySpoon
Establishment
 
Beiträge: 260
Registriert: 17.03.2009, 14:59
Wohnort: Dresden

Re: Anti-Jammer-Thread

Beitragvon joggel » 26.04.2018, 10:48

"Wie meinst Du das?"

Ich habe hier eine Klasse (Plugin) mit mehreren Methoden (Callbacks).
Diese Methoden werden von einer anderen Stelle aufgerufen vor oder nachdem etwas passiert ist.
Es wird an einer anderen Stelle eine Kette von Abläufen abgearbeiten.
Vor bzw. nach den einzelnen Schritten werden dann Callbacks aufgerufen.
Innerhalb dieser Callbacks kann ich dann optional spezifische Aufgaben erledigen, je nach Einstellung.
Bsp:
An einer ganz bestimmten Stelle möchte ich Informationen sammeln, wenn immer ein Callback aufgerufen wird.
Nun möchte ich aber nicht in meiner Pluginklasse einen Member (CollectorXY) haben, weil der ja nicht immer benötigt wird.
Also benutze ich an dieser ganz bestimmten Stelle ein Singleton (CollectorXY::instance().add(aXYThing)).

Das meinte ich mit "So 'müllt' man sich zB nicht die Klasse zu, mit Membern die vlt nur _Eine_ aufgabe haben."
bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1308
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Anti-Jammer-Thread

Beitragvon DerAlbi » 26.04.2018, 10:51

Ich habe auch vor kurzem auch auf Singletons umgestellt, um Hardwareressourcen über sinnvolles RAII zu verwalten. Es gibt nunmal Peripherie, die es auf einer Platine (oder im Prozessor) nur 1x gibt, und da machen mehrere Instanzen der selben Sache keinen Sinn. Das ist dann über kurz oder lang darin ausgeartet, dass ich die einzelnen Instanzen immer per Referenz durch die Konstruktoren reichen musste, damit irgendeine Popelklasse ganz unten in der Hierarchie Zugriff auf die Hardware hat. Das hat irgendwann heftig gestunken.
Mittlerweile mache ich Referenz-Counting auf ein Singleton-Objekt und da wird es einfach de-initialisiert, wenn es nicht mehr benutzt wird. Dass geht dann sogar soweit, dass sobald alle Hardware die z.B. an einer bestimmen Versorgungsspannung hängt ungenutzt ist, die Versorgungsspannung einfach abgestellt wird, weil deren Referenz auch 0 wird. Power-Management for free.
In meinem Zusammenhang ist auch die Tatsache der Zustandbehaftung gar nicht so wild. Wenn 2 Klassen gleichzeitig den gleichen Schrittmotor treiben wollen, hab ich ein Problem ganz wo anders.
DerAlbi
Establishment
 
Beiträge: 214
Registriert: 20.05.2011, 05:37

Re: Anti-Jammer-Thread

Beitragvon Chromanoid » 26.04.2018, 11:45

Und wenn Du irgendwann mal einen zweiten Schrittmotor einbaust? :D

Nur Spaß, ich kann nur empfehlen Singletons großzügig zu nutzen, das spart Zeit. ABER NUR, wenn die Singletons nicht sich selbst verwalten und eigentlich wie normale Klassen entwickelt werden. Es geht mir nur um den "Lifecycle". D.h. man braucht für den sinnvollen Einsatz von Singletons am besten immer ein weiteres Singleton (Service-Registry oder was auch immer), das die anderen Singletons erzeugt und verfügbar macht. Das kann auch Dependency Injection sein, muss es aber nicht.
Zuletzt geändert von Chromanoid am 26.04.2018, 11:53, insgesamt 2-mal geändert.
Benutzeravatar
Chromanoid
Christian Kulenkampff
Moderator
 
Beiträge: 3698
Registriert: 16.10.2002, 19:39
Wohnort: Lüneburg
Alter Benutzername: atr_23

Re: Anti-Jammer-Thread

Beitragvon DerAlbi » 26.04.2018, 11:52

Naja, da ein zweiter Schrittmotor auch technisch etwas anderes machen wird, wird eine zweite Instanz ein getrenntes Singleton-Objekt werden.. Wenn beide Schrittmotoren zusammenarbeiten (ich hab sogar zwei) sind nicht die einzelnen Schrittmotoren die eigentliche Ressource (wenngleich die für sich selbst dem RAII-Schema folgen, da es getrennte Ansteuer-ICs sind), sondern die Engine, die die Schritte zwischen beiden Synchronisiert [und die 2 Schrittmotoren als Member hat].

Ich glaub du hast editiert, als ich geantwortet habe ^_^
DerAlbi
Establishment
 
Beiträge: 214
Registriert: 20.05.2011, 05:37

Re: Anti-Jammer-Thread

Beitragvon Chromanoid » 26.04.2018, 11:54

DerAlbi hat geschrieben:Ich glaub du hast editiert, als ich geantwortet habe ^_^
Genau, hab's jetzt noch mal hier reingeschoben: Im Falle des zweiten Schrittmotors kann man einfach zwei unterschiedlich benannte "Schrittmotor-Singletons" verwalten, die als Klasse zwar mehrfach instantiiert werden, vom Lifecycle her aber wie Singletons funktionieren.

Der größte Nachteil bei solchen Späßen ist meiner Erfahrung nach eigentlich immer nur Testautomatisierung bei verteilten Systemen (die dann nicht im gleichen Prozess laufen dürfen, da sie sich sonst die Singletons teilen) und aus dem gleichen Grund die Parallelisierung von automatischen Tests. Daher kann es durchaus Sinn machen, sich da etwas mehr Gedanken zu machen, wie die Singletons adressiert werden.
Zuletzt geändert von Chromanoid am 26.04.2018, 13:51, insgesamt 1-mal geändert.
Benutzeravatar
Chromanoid
Christian Kulenkampff
Moderator
 
Beiträge: 3698
Registriert: 16.10.2002, 19:39
Wohnort: Lüneburg
Alter Benutzername: atr_23

Re: Anti-Jammer-Thread

Beitragvon DerAlbi » 26.04.2018, 12:16

Ich weiß nicht, ob das in meinem Fall mit Hardware-Instanzen Sinn macht. Ein zweiter Motor wird z.B. über andere Pins angesteuert werden, dadurch wäre die Klasse nicht die selbe sondern würde sich mindestens in den Template-Argumenten unterscheiden. Ich glaube das ist bei enorm viel Hardware so.. (zumindest mit dem Mikrocontroller-Zeugs mit dem ich hier gerade rumwerkel)
DerAlbi
Establishment
 
Beiträge: 214
Registriert: 20.05.2011, 05:37

Re: Anti-Jammer-Thread

Beitragvon Matthias Gubisch » 26.04.2018, 14:18

Also ich versuche auch bei Hardware-Instanzen eine Singelton Implementierung zu vermeiden.

Meine Klasse wird dann zwar ähnlich dem SingletonPattern genutzt weil ich in dem Fall ein globales Objekt anlege auf das dann alle zugreifen.
Aber es gibt mir die Freiheit sofort eine zweite Instantz mit unterschiedlichen Parametern (in deinem Fall zum Beispiel die Pins) zu erzeugen sollte es doch mal eine zweite Instanz von etwas geben.
Bei externen Resourcen halte ich das sogar für relativ Wahrscheinlich während sich bei internen Microcontrollerresourcen selten was ändern wird.
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Matthias Gubisch
Establishment
 
Beiträge: 261
Registriert: 01.03.2009, 20:09

Re: Anti-Jammer-Thread

Beitragvon DerAlbi » 26.04.2018, 15:50

Globale Objekte sind für mMn so etwas keine gute Lösung. Ich arbeite z.B. mit einem STM32 (mehreren). Dort hat z.B. die interne Peripherie Glock-Gating (man kann die lahmlegen und damit Strom sparen). Dadurch macht RAII mehr sinn, weil man sich um das Ein/Ausschalten der Clock z.B in einem Konstruktor/Destruktor kümmern kann. Dafür muss man aber tracken, welche Clock wie oft referenziert wird usw. ICh würde auch in kleinen Mikrocontrollern soweit gehen, das Konzept zu verteidigen. Wer keine statische Speicherverwaltung nutzt [nutzen kann], kann den Singleton einfach mit placement-new in einem statischen char-Array entsprechender Größe erzeugen. Funktioniert super :-)
DerAlbi
Establishment
 
Beiträge: 214
Registriert: 20.05.2011, 05:37

Re: Anti-Jammer-Thread

Beitragvon joggel » 26.04.2018, 19:57

Ich glaube ich werde mal in Zukunft den Ansatz globaler Instanzen bzw. Singletons etwas verfolgen...also für mein nächstes Projekt.
Mal so am rande erwähnt..
bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1308
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Anti-Jammer-Thread

Beitragvon joeydee » 27.04.2018, 13:47

Weiß nicht ob Anti-Jammern oder eher doch Jammern: OpenGL 4 compiliert und läuft nun auch auf dem Mac. PC war problemlos.

Probleme waren u.a.:
- Andere Header für Extensions (für Shader-Pipeline) -> andere Reihenfolge der includes (auch im Zusammenspiel mit SDL)
- Mac hat Versionsanforderung 3.x ignoriert und scheinbar immer automatisch auf 4.1 forward compatibility geschaltet. Plötzlich hagelt es "invalid operations" für Funktionen, die ich nach spec eigentlich vorausgesetzt hatte. Scheint, dass ich nun 4.1 als gemeinsamen Nenner nehmen muss, zumindest für meine Geräte.
- Mein PC verarbeitet dann (unter 3.x und glew) z.B. glDrawElements(GL_QUADS) oder glUniformMatrix4dv(), Mac mag die nüscht. Natürlich ohne Compile- und Laufzeitfehler.
- Der Rest war hausgemacht, da ich z.B. das genaue Zusammenspiel von VBOs und VAOs doch noch nicht so gut kannte. Auch hier scheint der PC mehr zu "verzeihen".

Naja, viel Zeit und Nerven verloren, aber jetzt gehts erstmal. Bin gespannt obs der PC heute abend auch wieder schluckt.
Bis zum nächsten Problem.
joeydee
Establishment
 
Beiträge: 598
Registriert: 23.04.2003, 15:29

Re: Anti-Jammer-Thread

Beitragvon MasterQ32 » 27.04.2018, 14:24

- Mac hat Versionsanforderung 3.x ignoriert und scheinbar immer automatisch auf 4.1 forward compatibility geschaltet. Plötzlich hagelt es "invalid operations" für Funktionen, die ich nach spec eigentlich vorausgesetzt hatte. Scheint, dass ich nun 4.1 als gemeinsamen Nenner nehmen muss, zumindest für meine Geräte.

Das ist soweit ich weiß legal mit nem Forward Compatible Context (weil alles ab 3.3 sinnvoll rückwärtskompatibel ist), da du "mindestens 3.3" anforderst und in den nachfolgenden Versionen alles aus den Vorgängern enthalten ist

- Mein PC verarbeitet dann (unter 3.x und glew) z.B. glDrawElements(GL_QUADS) oder glUniformMatrix4dv(), Mac mag die nüscht. Natürlich ohne Compile- und Laufzeitfehler.

GL_QUADS ist seit OpenGL 3 depreciated: https://www.khronos.org/registry/OpenGL ... rays.xhtml
glUniformMatrix4dv ist ne extension, https://www.khronos.org/registry/OpenGL ... r_fp64.txt die wohl nicht überall verfügbar ist. Ist ab OpenGL 4.0 Teil von Core. Mit http://realtech-vr.com/admin/glview bzw. glxinfo unter Linux. Auf Mac OS weiß ich es leider nicht

Auch hier scheint der PC mehr zu "verzeihen".

Falls du nen NVIDIA-Grafiktreiber hast: Mein Beileid, die "fixen" all deine Fehler ohne mit der Wimper zu zucken und reporten dafür nicht mal Diagnostics. Der Code tut dann halt auf AMD und Intel nicht, weil er nach OpenGL-Standard nicht legal ist
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 1121
Registriert: 07.10.2012, 14:56

Re: Anti-Jammer-Thread

Beitragvon joeydee » 27.04.2018, 15:50

Mac: AMD Radeon R9 M395; PC: AMD Radeon R7 200
Warum Quads und dv nicht gehen hatte ich schnell rausgefunden, nachdem ich die Fehler weiter eingrenzen konnte. Erst dadurch bin ich darauf gekommen, dass was mit der angeforderten vs. tatsächlichen Version nicht stimmen kann.
Muss ich mir nochmal genauer ansehen, ich verstand das irgendwie anders mit forward und backward, aber bin ja lernfähig.
joeydee
Establishment
 
Beiträge: 598
Registriert: 23.04.2003, 15:29

Re: Anti-Jammer-Thread

Beitragvon joggel » 09.05.2018, 14:02

Bild
bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1308
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Anti-Jammer-Thread

Beitragvon Krishty » 09.05.2018, 17:47

Kommentar zur Nachricht, dass Notepad nun auch Linux- und MacOS-Zeilenumbrüche (CR und/oder LF statt CR+LF) darstellen kann (https://blogs.msdn.microsoft.com/comman ... n-notepad/):

Notepad ist tatsächlich bloß ein Fenster mit riesigem Standard-Edit-Feld (Common Control, um in der Win32-Sprache zu bleiben). Das konnte nie was anderes als CR+LF – und das ist ein scheiß Problem bei plattformunabhängiger UI-Programmierung. Auf Windows muss man bei allem, was man ausgibt, die Zeilenenden ändern. Ich hoffe tief und innigst, dass die Meldung bedeutet, dass Standard-Edit-Felder nun ebenfalls alle Arten von Zeilenenden schlucken. Ich habe kein Windows 10, um das zu testen – aber wenn es ginge, wäre die Tragweite klar.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6424
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Anti-Jammer-Thread

Beitragvon Krishty » 09.05.2018, 22:42

And last, but not least in this section, I want to highlight that Visual C++ is now conforming to ++11, C++14, and C++17. Yes: the MSVC compiler toolset in Visual Studio version 15.7 conforms with the C++ Standard!
Wenn mir das vor fünf Jahren jemand prophezeit hätte … ich hätt’s nicht geglaubt.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6424
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Anti-Jammer-Thread

Beitragvon Krishty » Gestern, 23:39

Mein Viewer kompiliert endlich vollständig mit Clang (ohne Microsoft-Erweiterungen, -fno-ms-extensions!).

Das war ein langer Weg.

Bisher sind die Ergebnisse unterirdisch:
  1. die Debug-Version zeigt kein Bild an (bestimmt ein Typo in meinem ungetesteten Vektor-Code)
  2. die Release-Version stürzt ab
  3. die PDB enthält nur Funktionsnamen; keine Quelldatei- oder Zeilenangaben (Debugging wird lustig …)
  4. die Executable ist fett (ich bin leider noch mit Microsofts CRT unterwegs)
  5. ich habe noch keinen Plan, wie ich das Icon einbinde (da muss es aber was geben)
  6. ich bin völlig ratlos, wie ich die statische Analyse ausführen soll
Der Weg wird auch lang bleiben:
  • Manifest von Hand erzeugen statt durch Visual C++
  • Debug-Informationen geradebiegen
  • Debugging
  • mit allen Warnungen kompilieren
  • mit -fsanitize=undefined kompilieren
  • libc statt VCRT einbinden
  • Icons etc. einbinden
… danach habe ich dann hoffentlich einen schönen Compiler-Vergleich. Bestenfalls auch ein besseres Programm.

Ein mega Ärgernis war: __builtin_assume() schmeißt eine Warnung, falls der Ausdruck Side Effects hat. Eigentlich eine gute Idee, würde Clang nicht immer für jede Funktion Side Effects annehmen. Da ich Assumptions im Debug-Modus als Assertions nutze, habe ich aber überall sowas wie assert(isEmpty(data));. Also musste ich 2000 Funktionen __attribute__((pure)) und __attribute__((const)) deklarieren, damit diese Warnungen verschwinden.

Besonders lustig ist in diesem Zusammenhang, dass die Built-Ins von Clang selber nicht korrekt deklariert sind. Ich kriege also Warnungen, wenn ich sowas schreibe wie

  assert(0x000 == (0xFFF & __builtin_ia32_pmovmskb128(min > max))); // All lanes of min must be <= max!

  Warning: '__builtin_assume' has side effects that will be discarded [-Wassume]
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6424
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Vorherige

Zurück zu Allgemeines Talk-Brett

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron