Softwareentwicklung ist ******e

[flashpixx]

Öhm, die "Vereinfachungs-API" kann doch die komplexe API verwenden.

Und wer schreibt das? Da müssen die Entwickler einmal den komplexen API Code entwickeln und dann darauf aufbauend den vereinfachten Code. Mach doch mal eine Wirtschaftlichkeitsbetrachtug und gleichzeitig dazu eine Projektplanung, denn wenn nun die komplexe API geändert wird, dann kann erst nachdem die Änderung abgeschlossen ist, die vereinfache verändert werden. Wie lange ist dann z.B. ein Releasezyklus und was verursacht der an Kosten....

[Klotzkopp]

Öhm, die "Vereinfachungs-API" kann doch die komplexe API verwenden.

Du möchtest, dass der API-Anbieter für dein spezielles Detailproblem eine einfache Lösung entwickelt, testet und pflegt, weil du den Aufwand, es selbst zu tun, für zu hoch hältst? Siehst du, wo hier die Logik klemmt?

Es gibt vermutlich tausende Detailprobleme wie deines. Da sollte es dich nicht wundern, wenn deines unter Umständen nicht so hoch auf der Prioriätenliste steht.

[FinalFantasy]

Naja, ich schätze den Aufwand für so eine einfachere API eigentlich nicht allzuhoch ein, vorallem nicht, wenn sie jemand implementieren würde, der die komplexe API schon sehr gut kennt, vielleicht sogar selbst (mit)entwickelt hat.

Diese API-Stufen sollten daher sinnvollerweise auch vom gleichen Team entwickelt werden. Sollte es doch mal Änderungen geben, werden die gleich für beide Fälle geändert. Klar ist das ein Mehraufwand, aber es entfällt schonmal der (prodzedurelle) Schritt, dass erst eines, dann das andere geändert werden kann.

Weil ich selbst den Aufwand nicht so hoch einschätze, vorallem, wenn man sich nicht extra deswegen zuerst in die komplexe-API einarbeiten muss, glaube ich, dass das keinen bemerkenswerten Einfluss auf die Wirtschaftlichkeit des Projekts hätte.

Gesamtwirtschaftlich gesehen, hat es aber einen riesen Einfluss, denn so hat nicht einmalig der Frameworkprovider aufwand, sondern jedesmal der, der es für einen einfachen Fall anwenden will.

Ich weigere mich jetzt auch einfach mal, das einfache Abspielen eines Audiofiles als "spezielles Detailproblem" anzusehen. Das ist nichts sonderlich ausgefallenes. Qt ist ja auch in erster Linie ein GUI-Framework, nicht zum Spieleentwickeln... fraglich, ob man da in erster Linie die komplexe API braucht (haben will) oder vielleicht doch lieber die einfachere?

Und nein, auch wenn ich den Aufwand nicht für zu hoch halte, erwarte ich doch irgendwie, dass sowas vom Framework schon abgedeckt wird. An vielen anderen Stellen hat Qt z.b. auch genau sowas. Letztendlich implementier ichs ja jetzt auch selbst, oder ich lass das ganze Projekt sein.

Und bevors jetzt hier so weitergeht: Ja, wäre da nicht die Linuxseite, würde ichs durchaus mal mit C# probieren.

[Klotzkopp]

Ich hab gerade mal ein wenig recherchiert. Ohne mich genauer einzulesen oder das auszuprobieren: Ich habe den Eindruck, dass mit Phonon die Wiedergabe einer Audiodatei ein Zweizeiler ist.

[flashpixx]

Ich habe den Eindruck, dass mit Phonon die Wiedergabe einer Audiodatei ein Zweizeiler ist.

Phonon multimedia framework | Documentation | Qt Developer Network

     Phonon::MediaObject *mediaObject = new Phonon::MediaObject(this);

     mediaObject->setCurrentSource(Phonon::MediaSource("/mymusic/barbiegirl.wav"));

     Phonon::AudioOutput *audioOutput = new Phonon::AudioOutput(Phonon::MusicCategory, this);

     Phonon::Path path = Phonon::createPath(mediaObject, audioOutput);

Backends expose information about the underlying system. It can tell which media formats are supported, e.g., AVI, mp3, or OGG.

[FinalFantasy]

Naaaja. Ich hab mir das Qt Example MedaiPlayer angeguckt, ist zu nem Großteil eigentlich schon das was ich will... mit anderen Worten, ich könnte direkt auf diesen Source aufbauen.

Ich kann auch sehr wohl unterscheiden, was in dem Beispiel alles "drumherum" ist, aber zum einfachen Abspielen dürfte wohl zumindest das nötig sein:

audioOutput = new Phonon::AudioOutput(Phonon::MusicCategory, this);

mediaObject = new Phonon::MediaObject(this);

metaInformationResolver = new Phonon::MediaObject(this);

Phonon::createPath(mediaObject, audioOutput);


mediaObject->setCurrentSource(sources[row]);

mediaObject->play();

Sind schonmal 6 Zeilen. Klar kann man das auch einfach kopieren, ich steh aber nicht so auf kopierten Code, den ich nicht verstanden habe. Es werden auch keinerlei Einstellungen oder Parameter mit 3 Zeilen getätigt, die könnten also auch wegfallen:

mediaObject = new Phonon::MediaObject(this);

mediaObject->setCurrentSource(sources[row]);

mediaObject->play();

Und da selbst dort noch nicht sonderlich viel "besonderes" drinsteckt, würde ich eher zu sowas hier tendieren:

Phonon::play("nelson.mp3");

[Klotzkopp]

Man muss wohl nicht mal den Pfad erzeugen:

Phonon::MediaObject *music =

     Phonon::createPlayer(Phonon::MusicCategory,

                          Phonon::MediaSource("/path/mysong.mp3"));

 music->play();[/code]

Darum eine Wrapperfunktion drumherum zu basteln, sollte ja kein Problem darstellen.

[flashpixx]

Und da selbst dort noch nicht sonderlich viel "besonderes" drinsteckt, würde ich eher zu sowas hier tendieren:

Phonon::play("nelson.mp3");

Warum schreibst Du nicht dafür Dir gerade selbst eine Funktion in einem Namespace oder eine statische Methode in einer Deiner Klassen !? Dann hast Du genau das was Du willst

[Guybrush Threepwood]

Und da selbst dort noch nicht sonderlich viel "besonderes" drinsteckt, würde ich eher zu sowas hier tendieren:

Phonon::play("nelson.mp3");

und wie stoppst oder pausierst du das dann?

[FinalFantasy]

Phonon::stop();

Phonon::pause();

[/PHP]

[flashpixx]

Phonon::stop();

Phonon::pause();

[/PHP]

das sind statische Aufrufe, irgendwo müssen aber die entsprechenden Objekte abgelegt werden, d.h. damit erzeugst Du eine Struktur, die nicht multithreadfähig bzw. thread-safe ist, denn zu den statischen Methoden muss eben auch der Zugriff auf das Device statt finden.

[FinalFantasy]

Es spricht nichts dagegen, für diese statischen Aufrufe intern ein Objekt zu halten. Man kann die Zugriffe auch innerhalb dieser statischen Methoden threadsafe machen, dabei ists doch völlig egal, ob ich eine statische Methode aufrufe, oder eine "normale" Methode.

Wenns dir besser gefällt, von mir aus auch:

Phonon::instance()->play();

[Guybrush Threepwood]

und was soll dir das Ganze dann für einen Vorteil bringen abgesehen davon das du dich total unnötig einschränkst?

Phonon::MediaObject *music =

     Phonon::createPlayer(Phonon::MusicCategory,

                          Phonon::MediaSource("/path/mysong.mp3"));

 music->play();

Das ist eine Zeile mehr, dafür hast du aber viel mehr Möglichkeiten...

[flashpixx]

Es spricht nichts dagegen, für diese statischen Aufrufe intern ein Objekt zu halten. Man kann die Zugriffe auch innerhalb dieser statischen Methoden threadsafe machen, dabei ists doch völlig egal, ob ich eine statische Methode aufrufe, oder eine "normale" Methode.

Ein Singleton-Pattern führt nicht zwingend zu Thread-Sicherheit. Was passiert bei dem ersten Aufruf, wenn Du das Objekt erzeugst und der Aufruf aus 2 Threads geschieht, welches Objekt wird dann bei instance() geliefert? Da Du hier einen Zeiger verwendest, werden bei 2 Threads mit new 2 Objekte auf dem Heap allokiert, welches von den beiden wird dann an Deine interne Variable gebunden?

[FinalFantasy]

und was soll dir das Ganze dann für einen Vorteil bringen abgesehen davon das du dich total unnötig einschränkst?

Einschränken? Andersrum warum soll ich mich mit Features rumschlagen, die ich gar nicht will/brauche?

Ein Singleton-Pattern führt nicht zwingend zu Thread-Sicherheit.

Ja alles klar, weil normale Methoden in einer Klasse ja soviel threadsicherer sind, wenn man sich nicht selbst drum kümmert... Dann muss malt halt in der instance() Methode einen Mutex verwenden, oder ganz einfach einen bool? Wie man es in jeder anderen Methoden mit kritischen Zugriffen auch machen müsste.

[a3quit4s]

Singletons macht kein Mensch mehr, nimm ne Factory.

[Guybrush Threepwood]

Einschränken? Andersrum warum soll ich mich mit Features rumschlagen, die ich gar nicht will/brauche?

Kann ja sein das du das unbedingt so haben willst und dir alle Konsequenzen daraus egal sind aber dann kannst du doch nicht wirklich erwarten das das so in das Framework übernommen wird.

[flashpixx]

Ja alles klar, weil normale Methoden in einer Klasse ja soviel threadsicherer sind, wenn man sich nicht selbst drum kümmert... Dann muss malt halt in der instance() Methode einen Mutex verwenden, oder ganz einfach einen bool? Wie man es in jeder anderen Methoden mit kritischen Zugriffen auch machen müsste.

Bei einem mit new allokierten Speicherbereich, muss man sich als Entwickler selbst um das entfernen der Referenz kümmern. Wenn ich in einer Methode ein Objekt erzeuge (nicht mit new), diese Methode aus mehreren Threads aufgerufen wird, dann kann ich sicher sein, dass der Compiler mir innerhalb des aktuellen Stackframes die notwendigen Bereiche allokiert, den Konstruktor der Klasse aufruft und am Ende der Methode den Speicher wieder frei gibt und die Destruktoren aufruft.

In Deinem Fall des Singeltons brauchst Du einen Mutex, einfacher Bool reicht da nicht, da eine einfache Variable / Property kein Semaphor ist.

[azett]

Mal ne generelle Betrachtung: Wenn ich alle gewünschten Tracks immer erst von Hand anchecken müsste, um nen Datenträger fürs Auto zu befüllen, bekäm ich ne Meise - ich mach das per Zufall und bin total glücklich damit