[Oparilames]

Guten Abend.


Ich habe mich die letzten Tage mal hingesetzt und mit dem Buch »C++ Lernen und
professionell anwenden« gearbeitet, weil ich gemerkt habe, dass ich durch mehr
oder weniger planlosem drauf los Programmieren/Lernen nicht weit gekommen bin.
Zudem möchte ich mich gleichzeitigt mit dem für mich neuen C++11-Standard an-
freunden.

Diesmal soll der Ansatz ein anderer sein: Ich weiß, worauf ich hin lerne und
ich möchte mich (und meinen Code) verbessern.
Nun dachte ich mir, ich fange mit etwas einfachem an, was sich leicht erweitern
lässt. Ein Projekt, an dem ich wachsen kann.

Und sieh an, wenige Tage danach, hatte ich die Idee zu einem Vokabeltrainer.
Ich habe noch nichts konkretes gecodet und möchte euch erstmal meine Gedanken-
gänge und Pseudo-Code nahelegen um zu fragen, ob ich das ganze richtig angehe …
Von Projektdesign habe ich noch 0 Ahnung.

Zuerst habe ich mir im Groben überlegt, was er können soll. Dazu sind die
Funktionalitäten in 3 Prioritätsstufen gegliedert:
[1]muss,
[2]sollte,
[3]wäre nett wenn

• Vokabel-Datein speichern und laden. [2]
  
  • Vokabel in 3 Sprachen/Unicode-Unterstützung [1]
  
  
• Einstellungen speichern und laden. [2]
• 3 Lernmodi anbieten:
  
  • 2- und 3-Sprach-Vokabeltraining, [1]
  • Sound-Datei für Vokabeln abspielen [2]
  • Beispielsatz-Übersetzungstraining [2]
  • Beispielsätze aussprechen [3]
  • Bilder-Memorie. [3]
  
  
• Auf gemachte Fehlertypen hinweisen:
  
  • Wortverwechslungen [1],
  • Sprachenverwechslung [1],
  • Zeichendreher [2],
  • Wortähnlichkeitsanalyse [3],
  
  
• generelles (sprachbezogenes, nicht wortbezogenes)
  Fehlerprotokoll merken [2]
• GUI [3]
• Code-Kommentierung [1]

Nach diesen Überlegungen habe ich versucht mir zu überlegen,
wie ich das Codegerüst aufbauen will. Dabei kam folgendes heraus:

Multi-Threading für verschiedene Programmebenen:
A) Laden/Speichern, Resourcenmanagement, I/O
B) Programmlogik (Vokabeln raussuchen, zusammenstellen usw.)
C) Sounds abspielen, Rendern (bei Konsole nur für
Farbänderungen etc. zuständig – also unnötig?)

Klassenkonzept (nennt man das so?):

cGame
{
    cLogicManager
    cIOManager
    cSoundAndRenderManager
}

cStringManager
{
    std::vector<std::string> germanStrings;
    std::vector<std::string> englishStrings;
    std::vector<std::string> japaneseStrings;
    std::vector<std::string&> curSentenc;
    void typoCut(strings & ...);  /* Zerlegt Strings in 60-75 char lange 
                                     Zeilen, sorgt für korrekte Leerzeichen
                                     (schmale in deutschen Abkürzungen usw.,
                                     Gedanken und Trennstriche gesondert)
                                  */
}

cLanguage
{
    string& name;
    void setNameL(languageID, std::string nameRef&);
    std::vector<cWord> words;    
    std::vector<cSyntaxRule> rules;
}

cWord
{
    string& nameG, nameE, nameJ;
    int type; // predicate,subject, Object
    int subtype; // word kinds like article
}

cSyntaxRule
{
    static ID;
    auto condition;// Funktionspointer
    void setWordtypeSentencePos(int wType, enum{predicate,subject, Object}
}

Die wichtigsten 2 Fragen die sich mir (im Moment) stellen sind:
1) Soll ich erst die reinen Funktionalitäten (Wortanalyse, das Training an sich)
umsetzen und später die Klassen darum herum bauen, oder gleich alles in Klassen packen?
2) Gehe ich die cLanguage vielleicht schon zu feingliedrig an? (Mache ich leider gerne.)

Für eure Unterstützung wäre ich euch sehr dankbar. =)


Mit freundlichen Grüßen
Oparilames

[Multithread]

Hast du dir auch überlegt woher du den Wortschatz lädts und wie du die Spielstände speichern möchtest?

Zu deinen Fragen:
1. Zuerst würde ich das Klassengerüst machen mit den Containerklassen (Wort,Sprache,...)
Danach das füllen dieser und ganz zum Schluss die Anzeige. Erst wenn das einigermassen klappt würde ich die vergleichsalgorithmen anpacken.

2. Nö, passt aus meiner sicht, jedoch würde ich dir dict's empfehlen anstelle von Listen, mit der Sprache/SprachId als Primary-key
SyntacRules passt als liste

[ojas]

Von Projektdesign habe ich noch 0 Ahnung.

Das Problem an der Softwareentwicklung ist, dass eine Vielzahl von einzelnen Anweisungen (Variablenbelegung, Schleifen, Verzweigungen, Funktionsaufrufen, etc) zusammenarbeiten müssen um letztendlich das zu tun, was der Entwickler will und wenn nur eine dieser Anweisungen falsch ist, das gesamte Programm nicht funktioniert.

Diese Komplexität bekommt man durch einen Devide&Conquer-Ansatz in den Griff. Dabei wird das Problem in Teilprobleme aufgeteilt, die über wohl definierte Schnittstellen kommunizieren.

Die klassische erste Aufteilung ist die sogennante Drei-Schichten-Architektur. Sie besteht aus

1. Externen Schnittstellen wie zum Beispiel grafischer Benutzeroberfläche, Kommandozeilensteuerung, Webservices, Batchverarbeitung,
2. Anwendungskern der die für den Benutzer relevanten Objekte und deren Verhalten abbildet. In deinem Fall sind das zum Beispiel Vokabel und Übersetzung.
3. Persistenz speichert Daten so das sie auch beim nächsten Programmstart wieder verfügbar sind. Normalerweise wird hier eine relationale Datenbank verwendet. Wenn du SQL kannst, dann empfehle ich das auch in diesem Fall, z.B. in Form von SQLite.

Funktionsaufrufe passieren dabei nur von einer Schicht zur direkt darunter liegenden Schicht. Das heißt, weder dürfen die Externen Schnittstellen Funktionen der Persistenz unter Umgehung des Anwendungskerns aufrufen, noch darf der Anwendungskern Funktionen der Externen Schnittstellen aufrufen. Wäre letzteres möglich, dann gäbe es zyklische Abhängigkeiten (nämlich dass die Externen Schnittstellen den Anwendungskern benötigen und der Anwendungskern die Externen Schnittstellen).

Multi-Threading

Nein. Multi-Threading ist so kompliziert, dass man sehr genau darüber nachdenken sollte, ob es auch tatsächlich notwendig ist.

... für verschiedene Programmebenen:
A) Laden/Speichern, Resourcenmanagement, I/O
B) Programmlogik (Vokabeln raussuchen, zusammenstellen usw.)
C) Sounds abspielen, Rendern (bei Konsole nur für
Farbänderungen etc. zuständig – also unnötig?)

Das geht schon mal in die richtige Richtung. Ich erkenne in A), B), und C) die drei Schichten 3. Persistenz, 2. Anwendungskern und 1. Externe Schnittstellen.

Klassenkonzept (nennt man das so?):

Man nennt es Entwurf. Dazu ist es aber noch zu früh. Am Anfang steht die Anforderungsermittlung. Das ist ungefähr das was du schon unter Funktionalitäten beschrieben hast, muss aber detailierter durchgeführt werden. Dazu eignen sich User Stories und (evtl darauf aufbauend) Use Cases.

In der Analyse werden dann die in der Anforderungsermittlung gefundenen Use Cases und die daran beteiligten Objekte als Klassen modelliert. Dazu gibt es CRC-Karten und UML-Klassendiagramme.

Darauf folgt der Architekturentwurf. Dabei wird eine Architektur ausgewählt (wie gesagt, Drei-Schichten-Architektur außer du hast gute Gründe die dagegen sprechen) und die Klassen in die Architektur eingefügt.

Beim anschließenden Grobentwurf werden die in der Analyse noch recht informell spezifizierten Klassen detailierter ausgearbeitet.

Nach dem Grobentwurf (!!!) entscheidet man sich, welche Technologien für die Implementierung verwendet werden: Programmiersprache, Bibliotheken für Persistenz und Benutzeroberfläche, sonstige Bibliotheken (z.B. für XML- oder JSON-Import) etc.

Im Feinentwurf wird der Grobentwurf dann auf die ausgewählten Technologien übertragen. Anschießend erfolgt die Implementierung.

So jedenfalls die Theorie

Code-Kommentierung [1]

Das ist eine sehr gute Idee. Allerdings kommentieren viele Leute die falschen Dinge (nämlich wie etwas berechnet wird). Interessant ist aber eigentlich nur, was berechnet wird. Dazu solltest du zu jeder Funktion kommentieren

• Welche Bedingungen müssen erfüllt sein, damit die Funktion aufgerufen werden darf (Vorbedingungen, englisch Preconditions).
• Welche Bedingungen sind erfüllt nachdem Funktion aufgerufen wurde (Nachbedingungen, englisch Postconditions).

Beispiel

/**
 * Berechnet die Quadratwurzel einer Zahl.
 *
 * @pre f >= 0
 * @post Das Quadrat des Rückgabewertes ist nahe bei f
 */
float sqrt(float f) {
  // Hier kann kurz beschrieben werden, welches Verfahren verwendet wird
  // aber das interessiert den Benutzer meistens garnicht. 
  // Für den Benutzer der Funktion sind die Angaben über gültige
  // Werte für f und was der Rückgabewert aussagt wichtiger.
}

2) Gehe ich die cLanguage vielleicht schon zu feingliedrig an? (Mache ich leider gerne.)

Du gehst in allen Klassen schon zu feingliedrig heran. Zum Beispiel hast du dich schon auf drei Sprachen festgelegt und lädst immer das komplette Wörterbuch in einen std::vector.

Mir fallen spontan drei Teile des Anwendungskerns ein:

• Vokabeln verwalten
• Vokabeln lernen
• Lernfortschritt auswerten

Es wäre schade, wenn du diese drei Teile in deiner Anwendung nicht deutlich voneinander trennen würdest. Wenn du diese Teile in deiner Anwendung deutlich von einander trennst, dann kannst du nämlich ...

• 3 Lernmodi anbieten:
• Auf gemachte Fehlertypen hinweisen:

... bie Bedarf neue Lernmodi und Fehlertypen hinzufügen ohne allzu große Änderungen an den anderen Teilen der Anwendung vorzunehmen.

[Headcool]

Nein. Multi-Threading ist so kompliziert, dass man sehr genau darüber nachdenken sollte, ob es auch tatsächlich notwendig ist.

Würde ich nicht sagen. Es kann sogar helfen die einzelnen Layer sauberer zu trennen. Perfekte Gelegenheit eine Message Queue einzubauen.
Außerdem sind Programme die hängen wenn bspw. ein File geladen werden echt beschissen.

[ojas]

Es kann sogar helfen die einzelnen Layer sauberer zu trennen.

Wenn man das ohne Multithreading nicht hinbekommt, dann führt es eher zu Heisenbugs, als zu einer sauberen Trennung.

Außerdem sind Programme die hängen wenn bspw. ein File geladen werden echt beschissen.

Ich sehe im Moment keine Notwendigkeit, die ganze Datei in den Speicher zu laden.

Und Threads Cannot be Implemented as a Library.

[Multithread]

Würde ich nicht sagen. Es kann sogar helfen die einzelnen Layer sauberer zu trennen. Perfekte Gelegenheit eine Message Queue einzubauen.
Außerdem sind Programme die hängen wenn bspw. ein File geladen werden echt beschissen.

Wenn jemand noch wenig Ahnung vom Coden hat und gleich mit Multithreading anfängt, dann frustriert das nur.
Es hat durchaus gründe wieso das Multithreading für so viele Programmierer ein Schwarzes Tuch ist.

Wenn man das ohne Multithreading nicht hinbekommt, dann führt es eher zu Heisenbugs, als zu einer sauberen Trennung.

Damit habe ich in den 4 Jahren wo ich schon Multithreading Code noch nie Probleme gehabt

Ich empfinde es als wichtig Software vom beginn weg auf Multithreadingfähigkeit zu Designen, ansonsten wird es nur mühsamer Multithreading zu implementieren.

Ich sehe im Moment keine Notwendigkeit, die ganze Datei in den Speicher zu laden.

Ich sehe nichts was dagegen sprechen würde. Gerade beim Dateien laden, kann man gut erste Multithreading Erfahrungen sammeln, alles andere würde ich vorläufig noch im Haupthread belassen.

[ojas]

Damit habe ich in den 4 Jahren wo ich schon Multithreading Code noch nie Probleme gehabt

Das heißt dann im Umkehrschluss, dass du auch ohne Multithreading eine saubere Trennung der Schichten hinbekommst.

[Headcool]

Wenn man das ohne Multithreading nicht hinbekommt, dann führt es eher zu Heisenbugs, als zu einer sauberen Trennung.

Geht ja nicht darum, dass man es nicht kann, sondern dass man aus Zeitdruck oder Faulheitsgründen einfach mal nicht den schönen "richtigen" Weg geht sondern den direkten. Und dieses Verhalten wird im Normalfall nicht sanktioniert, es sei denn man nutzt Multithreading. Dann gibts wirklich hässliche Bugs. Aber man greift nicht zweimal auf die heiße Herdplatte.

Ich sehe im Moment keine Notwendigkeit, die ganze Datei in den Speicher zu laden.

Sehe ich auch nicht. Trotzdem kann es passieren, dass die HDD längere Zeit braucht um ein File bereitzustellen, zb. wenn sie gerade aus dem Standby aufwacht. Und dann hängt das Programm weil die IO Routine die GUI blockiert

Und Threads Cannot be Implemented as a Library.

Da bin ich nicht ganz damit einverstanden. Diese Fehler entstehen hauptsächlich wenn man direkt auf gemeinsamen Speicher zugreift. Jemand der soetwas macht, sollte ensprechende Probleme kennen und ggf Gegenmaßnahmen treffen wie zb. Inline Assembly oder lock prefix.
Bei normaler Verwendung treten solche Fehler sehr selten auf, da die meisten die solche Fehler lange suchen auch einen Bugreport an den Compilerhersteller schicken, welcher diesen dann behebt.
Noch dazu ist es heute üblich bei Performanceverbesserungen nicht direkt Threads sondern Data Parallelism zu verwenden, da Threads nicht skalieren.

Wenn jemand noch wenig Ahnung vom Coden hat und gleich mit Multithreading anfängt, dann frustriert das nur.
Es hat durchaus Gründe wieso das Multithreading für so viele Programmierer ein Schwarzes Tuch ist.

Wenn man prozedural programmieren kann ist man auch bereit für Threads. Da ist der TE schon weiter.

[Marthog]

Die Frage bei Multithreading ist auch, ob es sich wirklich lohnt und wenn ja, welche Art.
Wenn man mehrere Threads hat, sollte man sie schon weitgehend nicht blockierend laufen lassen, sonst gewinnt man kaum etwas. Da du Daten laden parallelisieren willst, solltest du eher ein Task basiertes Modell bauen, also so dass der Hauptthread Tasks in Auftrag gibt und die Ergebnisse irgendwann abholt. Dazu könntest du std::future verwenden, aber ich habe mal von einem Experten gehört, dass future ziemlich schlecht sein soll, den Grund aber nicht komplett nachvollzogen. Vielleicht könntest du auch eine andere library mit Threadpool verwenden.
Ich habe mir für ein Projekt ein eigenes Taskmodell geschrieben, dass einen Mainthread und mehrere WorkThreads hat. Der MainThread schiebt dann immer Tasks in den Threadpool und wenn ein Tasks fertig ist, schieben er einen neuen Tasks in den Hauptthread, der die Aufgabe abschließt und nicht thread-sichere Teile erledigt.

Bei anderen Fällen könntest du auch OpenMP oder etwas vergleichbares nutzen, aber hier lohnt sich das wohl nicht, denn damit kann man afaik nur for-schleifen etc parallelisieren und keine verschiedenen Aufgaben abarbeiten.

Wenn man prozedural programmieren kann ist man auch bereit für Threads. Da ist der TE schon weiter.

Nein. Bei Threads muss man viel mehr beachten, denn man darf nicht einfach auf irgendetwas zugreifen, außer es ist garantiert, dass kein anderer Thread gleichzeitig etwas ändert. Normal schreibt man einfach in irgendwelchen Speicher, ruft irgendwelche Funktionen auf etc, aber bei Threads muss man sich immer anschauen, was den überhaupt passieren soll, auf welche Resourcen überhaupt zugegriffen wird und wie die Rückgabe ausgewertet wird. Wenn kann zwar relativ einfach mit einem Mutex alles mögliche sperren, aber wenn die Threads zu sehr synchronisiert werden, sind sie nicht mehr so schnell.

[Headcool]

Nein. Bei Threads muss man viel mehr beachten, denn man darf nicht einfach auf irgendetwas zugreifen, außer es ist garantiert, dass kein anderer Thread gleichzeitig etwas ändert. Normal schreibt man einfach in irgendwelchen Speicher, ruft irgendwelche Funktionen auf etc, aber bei Threads muss man sich immer anschauen, was den überhaupt passieren soll, auf welche Resourcen überhaupt zugegriffen wird und wie die Rückgabe ausgewertet wird. Wenn kann zwar relativ einfach mit einem Mutex alles mögliche sperren, aber wenn die Threads zu sehr synchronisiert werden, sind sie nicht mehr so schnell.

Da hast du mich falsch verstanden. Ich sagte nachdem man prozedural programmieren kann sei man "bereit" für MultiThreading. Damit meine ich bereit es lernen, nicht es schon zu können.
Es gibt übrigens mittlerweile eine Technologie namens TSX die das ganze viel einfacher und perfomanter macht.
TSX funktioniert so, dass mehrere Threads in eine kritische Sektion hineingelassen werden. Wenn es zu einem Problem wie bspw. False Sharing kommt, erkennt die CPU das, macht den Fehler rückgängig und führt die Threads seriell aus. Da solche Fehler zwar absolut häufig, aber relativ selten auftreten führt das in vielen Fällen zu einem Performancegewinn.

[Multithread]

Die Frage bei Multithreading ist auch, ob es sich wirklich lohnt und wenn ja, welche Art.
Ich habe mir für ein Projekt ein eigenes Taskmodell geschrieben, dass einen Mainthread und mehrere WorkThreads hat. Der MainThread schiebt dann immer Tasks in den Threadpool und wenn ein Tasks fertig ist, schieben er einen neuen Tasks in den Hauptthread, der die Aufgabe abschließt und nicht thread-sichere Teile erledigt.

Ich bin also nicht der einzige verrückte der er so macht

Nein. Bei Threads muss man viel mehr beachten, denn man darf nicht einfach auf irgendetwas zugreifen, außer es ist garantiert, dass kein anderer Thread gleichzeitig etwas ändert. Normal schreibt man einfach in irgendwelchen Speicher, ruft irgendwelche Funktionen auf etc, aber bei Threads muss man sich immer anschauen, was den überhaupt passieren soll, auf welche Resourcen überhaupt zugegriffen wird und wie die Rückgabe ausgewertet wird. Wenn kann zwar relativ einfach mit einem Mutex alles mögliche sperren, aber wenn die Threads zu sehr synchronisiert werden, sind sie nicht mehr so schnell.

Das ist für solch keine Aufgaben etwas zu hoch gegriffen. Dort kann man relativ leicht noch sagen das jeweils nur ein Thread auf eine bestimmte resource zugreift.

Da hast du mich falsch verstanden. Ich sagte nachdem man prozedural programmieren kann sei man "bereit" für MultiThreading. Damit meine ich bereit es lernen, nicht es schon zu können.
Es gibt übrigens mittlerweile eine Technologie namens TSX die das ganze viel einfacher und perfomanter macht.
TSX funktioniert so, dass mehrere Threads in eine kritische Sektion hineingelassen werden. Wenn es zu einem Problem wie bspw. False Sharing kommt, erkennt die CPU das, macht den Fehler rückgängig und führt die Threads seriell aus. Da solche Fehler zwar absolut häufig, aber relativ selten auftreten führt das in vielen Fällen zu einem Performancegewinn.

Wenn wirklich so viel Performancegewinn rausschaut am ende, dann frage ich mich eher ob da nicht sonst noch was schiefgelaufen ist.

Allerdings ist es schön das da auch HW seitig langsam Erleichterungen bezüglich gemeinsamer datenverwaltung kommen. Bleibt noch zu hoffen das dies auch in den Hochsprachen mit JIT alsbald ankommt.