ein Wrapper?

zeropage

Also wird das eine Art Skript Interpreter?

Eher eine, wie man früher bei Interpretersprachen sagte, "Befehlserweiterung". Etwas wie eine Bibliothek, nur auf einem sehr niedrigeren Niveau. Und nur für eine bestimmte Oberfläche und einen bestimmten Anwendungszweck.

zeropage

Vielleicht sollte ich mal nachholen, ein Beispiel für die Anwendung zu zeigen. Nur um eine Vorstellung zu haben.

Dies war eine kleine Fingerübung für den bisherigen Code.
towers of hanoi in windows console

Unterfliege

@lemon03 Ich sehe folgende Möglichkeiten:

Verbesserungsabfrage im ctor (NICHT zu empfehlen)
Funktion Sound::is_ready oder so hinzufügen und die Abfrage in einer Schleife bei der Erstellung übernehmen (vermutlich mein Weg)
exception abfangen und Abfrage starten

Vielleicht habe ich aber noch eine Möglichkeit übersehen.

hustbaer

@ sagte in ein Wrapper?:

I/O im Konstruktor ist sehr unschön, meiner Meinung nach.

Wieso?
Bzw. genauer: An welchem Teil störst du dich?

Ich sehe da genau in (vermutliches) Problem, und das ist der Aufruf der _pressKey() Funktion. Checken ob ein File existiert im Ctor ist OK. Logging im Ctor ist OK. Im Fehlerfall (und nur im Fehlerfall) darauf zu warten dass der Benutzer ne Taste drückt (was _pressKey() wohl vermutlich macht), ist mMn. nicht OK.

Der Grund dafür hat aber nicht viel mit "I/O im Konstruktor" zu tun.

zeropage

Meine "Sound Klasse" wurde ja schon gründlich auseinandergenommen, weshalb man davon ausgehen kann, das sie so nicht mehr existiert. Die ganze Entwicklung wurde für sie sogar pausiert, bis andere Fragen geklärt sind.

Aber ich wollte nur kurz etwas zu _presskey() schreiben. Vielleicht wird da zuviel hinein interpretiert. Es soll nur mich eine Anzeige sein, das etwas nicht geklappt hat. Da ich eh einige Funktionen habe, die auf Tastendruck warten, habe ich eine solche dort einfach eingefügt. Irgendwie muss es ja stoppen, damit ich die Ausgabe sehen kann.

Das dies keine optimale Idee ist, ok. Aber es war kein tieferer Sinn dahinter. Nur eben Ausgabe anzeigen.

zeropage

Wenn ich die Funktion, die einfach ein "ready" ausgibt und wartet, also ready();eingefügt hätte, wären dann ebensolche Fragen aufgetaucht, obwohl die Funktion die selbe ist? Oder wäre man dann der Ansicht, danach würde das Programm beendet?

hustbaer

@lemon03 sagte in ein Wrapper?:

Wenn ich die Funktion, die einfach ein "ready" ausgibt und wartet, also ready();eingefügt hätte, wären dann ebensolche Fragen aufgetaucht, obwohl die Funktion die selbe ist? Oder wäre man dann der Ansicht, danach würde das Programm beendet?

Bin mir nicht sicher ob ich die Frage verstehe, bzw. ob du verstanden hast warum ich das Warten auf User-Input in einem solchen Konstruktor doof finde.

Mir geht es darum dass so eine Klasse schwer korrekt zu verwenden ist bzw. auch das "principle of least astonishment" verletzt. Stell dir vor du kopierst die Klasse in ein Spiel, kein Textmode Spiel sondern eins mit schöner Grafik, das Fullscreen läuft, und dann überleg dir was passiert wenn er ein File nicht findet.

Wenn du nur die Fehlermeldung ausgeben möchtest, dann gib halt einfach die Fehlermeldung aus. Wenn du unbedingt möchtest dass man sie bestätigen muss, dann mach wenigstens ne eigene Funktion showModalErrorMessage oder so, die die Meldung anzeigt und auf die Bestätigung wartet. Dann kann man diese wenigstens so anpassen wie man es braucht, je nach Projekt.

Das selbe gilt im Prinzip auch für die Ausgaben auf std::cerr. D.h. eine spezielle Logging-Funktion wäre besser als einfach auf std::cerr rausschreiben.

Der wichtigste Punkt ist IMO aber wirklich dass hier das "principle of least astonishment" dadurch verletzt wird, dass ein Konstruktor einer Sound-Klasse eine Meldung anzeigt und dann auf User-Input wartet. Und damit das Programm anhält und nebenbei noch den Zustand von std::cin ändert. Damit rechnet man einfach nicht.

So wie ich das verstanden habe, möchtest du dem Programmbenutzer das auswählen einer Sound-Datei überlassen? Das gehört auf keinen Fall in den Konstruktor. Bevor du überhaupt eine Instanz deines Musik-Objekts erzeugst, fragst du nach dem Dateinamen. Dann überprüfst du, ob die Datei überhaupt existiert. Tut sie das, erstelle das Musik-Objekt. Tut sie das nicht (oder fehlen dir die leserechte), frag am besten nochmal nach der Datei. In deiner Klasse solltest du bei Fehler schlussendlich nur noch Exceptions werfen. Wenn du diese dann auch behandeln willst, dann kannst du das machen.

zeropage

Ok, danke.

Ein gewagter Vergleich wäre zum Beispiel std::ifstream(). Dort übergibt man am Ende ja auch einen string, nämlich den Filenamen, das geöffnet/gelesen werden soll?

Und auch dort wird erst dann geprüft, ob es das File gibt. Anders funktioniert es oben doch auch nicht? Ich will ein sound-file laden und übergebe den Fileamen. Es wird nichts gefunden, also stop.

Die Frage ist jetzt, wie ich den stop auslöse. Ob ich im Fehlerfall nur ein flag oder ähnliches zurückgebe. Darum geht es doch, oder? Nicht das ich einen Filenamen übergebe, sondern die Reaktion im Fehlerfall?

zeropage

@spiri sagte in ein Wrapper?:

So wie ich das verstanden habe, möchtest du dem Programmbenutzer das auswählen einer Sound-Datei überlassen? Das gehört auf keinen Fall in den Konstruktor. Bevor du überhaupt eine Instanz deines Musik-Objekts erzeugst, fragst du nach dem Dateinamen. Dann überprüfst du, ob die Datei überhaupt existiert. Tut sie das, erstelle das Musik-Objekt.

Also erst etwas wie ein beliebiges open() und wenn das erfolgreich ist, dann Sound::load()? Oder wäre durch diese statische Methode die Sache mit dem Konstruktor erledigt, weil es keinen mehr gibt?