ZFX + Developia

sound abschalten: http://www.fanhow.com/knowhow:Disable_S ... e_81046677

jetzt muss ich auch noch jammern? ähm, hab immer zu wenig zeit!

mmh soweit ich das verstehe gehts ums muten von sound einzelner tabs/fenster (programmatisch)...

Krishty hat geschrieben:Ich lese das so: new char [] und new unsigned char [] fragen bei Allokationsfunktionen so viel Puffer zusätzlich zum eigenen Speicher an, dass jeder irgendwo im Programm definierte Typ, der in die Anzahl chars passt, die der Programmierer anfordert, in diesem neuen Array ausgerichtet platziert werden kann (und das Ergebnis dieses Ausdrucks ist dann auch die ausgerichtete Adresse). Das bedeutet wiederum: C++0x unterstützt bei new Ausrichtung – allerdings nur, wenn man den Speicher per new char[sizeof(T)] anfordert und dann ein Placement new mit dem eigentlichen Typ darauf ausführt (new (new char [sizeof(T)]) T();). Ich könnte mich aber auch irren – ist schon früh – oder in Wunschbestätigung dafür verfallen, dass ich außer Placement new schon seit Monaten mit C++’ new fertig bin.

Die Frage ist, worauf sich strictest fundamental Alignment bezieht, ich interpretiere den Draft eher so, dass ein manuell ausgerichtetes Objekt bereits over-aligned und folglich nicht mehr durch diese Reglung abgedeckt ist. Allerdings nur flüchtig überflogen.

Krishty hat geschrieben:Mal total ins Blaue geraten: Imo ist die Größe dabei nicht ausschlaggebend – wenn ein Objekt ausgerichtet deklariert ist, kann es nur an bestimmten Adressen instanziert werden. Das bedeutet: Falls ein Array-Element kleiner ist als das kleinste Vielfache seiner Ausrichtung, hat der Compiler überhaupt keine andere Möglichkeit, als zwischen den Elementen zu padden. Das muss jedoch nicht in der Klasse über ihre Größe geschehen, sondern kann auch bei der Array-Allokation geschehen. Gleichzeitig wird jede Zeigerarithmetik diesen Typ betreffend mit dem aufgerundeten Wert arbeiten, d.h (toObj + 1) != ((char*)toObj + sizeof(*toObj)). So würde ich es jedenfalls an Stelle der Compiler-Entwickler machen, wenn ich Klassen-Padding auf Teufel-komm-raus vermeiden wollte.
Momentan ist Ausrichtung aber eh noch ein Compiler-spezifisches Feature und damit ist alles, was du in diese Richtung schreibst, höchstwahrscheinlich unbeständig.

Ja das ist letztlich auch nicht so entscheidend, entscheidend wäre, dass die an operator new[] übergebene Größe OHNE den Array-Overhead immer ein Vielfaches des Alginements WÄRE. Wenn new[] tatsächlich korrekt mit manuell ausgerichteten Typen umgehen sollte, so wie es Visual C++ AFAIK im Moment durch echtes Padding der Struktur/Klasse akzeptabel umsetzt, dann lässt sich in diesem Fall die nicht-ausgerichtete Größe inklusive Overhead mit minimalen Rechenaufwand aufrunden, sofern nötig, und mit einer simplen Subtraktion ein um ein entsprechendes Offset UNTER die Ausrichtungsgrenze gesetzter Zeiger zurückgeben.

Krishty hat geschrieben:Die Idee, über die in Placement new [] übergebene Größe die Ausrichtung zu bestimmen, ist gut. Ich frage mich nur: Kommt dort die Array-Größe mit oder ohne Unkosten zum Speichern der Array-Größe an? Dasselbe wie in nicht-Placement new [] oder ein „bereinigter“ Wert?

operator new[] erhält die Größe inklusive Overhead. Wie es mit Placement aussieht weiß ich nicht, Placement array new habe ich wirklich noch nie gebraucht.

Ich habe die Array-Allokationsoperatoren dennoch kurzerhand für ausgerichtete Typen einfach entfernt, ich persönlich nutze praktisch nie dynamisch allozierte Arrays mit Default-Construction, wenn, dann doch eher uninitialisierter Speicher mit Einzelinitialisierung durch Placement new. Wozu also die Speicher- und Instruktionsverschwendung einer weiteren Ebene von Ausrichtungslogik...

Zwölf Tage läuft mein Rechner problemlos durch (nachts immer im Standby-Modus). Aber heute morgen, wo ich ihn tatsächlich mal brauche (lies: zwingend benötige) hole ich ihn aus dem Schlaf und habe kein Netzwerk. Ich gehe auf „Reparieren“ und sehe noch im Task-Manager, wie sich das System mit 100 MiB/s vollsaugt, die keinem Prozess zugeordnet sind. Irgendwo bei 7 GiB hüpft dann die Maus rum und verharrt, das System reagiert auf keine Eingaben mehr, der Bildschirm wird übersäht von Fehlermeldungen von TrueCrypt bis zum Media Player (die meisten ohne leserlichen Text) und nichts geht mehr. Neustart dauerte eine Viertelstunde. Jetzt sind 20 offene Tabs verloren, ein paar ungespeicherte Dokumente, alle Downloads kaputt und der Media Player motzt wegen defekter Datenbanken rum. Und die Bahn streikt auch noch. Das passiert, wenn man sich auf Technik verlässt. Jeden Tag was Neues, Adam.

Auf die Gefahr hin, wie ein Arschloch zu klingen: Du *lernst* aber auch nicht, oder? Wir hatten das Thema doch schon einige Male?

Das sehe ich auch so. Gerade du Krishty der ständig über die Unzulänglichkeiten jeglicher Hard- und Software jammert solltest dir doch solcher Möglichkeiten bewußt sein. Irgendwie scheint dein Nutzerverhalten nicht an deine Paranoia angepasst zu sein ;).

So schlimm wie früher, dass man jeden Tag rebooten muss, ist es heute zwar nicht mehr, aber trotzdem: Wir haben die zweite Dekade des verdammten dritten Jahrtausends. Windows 95 ist 16 Jahre her. Wenn ich schon keine bekackten fliegenden Autos oder verfluchten Jetpacks haben darf, kann ich von einer komplett im neuen Jahrtausend entwickelten scheiß Architektur doch zumindest erwarten, dass es keine verheerenden Kernel-Abstürze gibt, oder? Und dreht das nicht so zurecht, als müsste ich mich halt damit abfinden, dass sowas passiert. Da hängt immer ein seines Jobs unfähiger und unwürdiger Idiot hinter, der für sowas gezüchtigt gehört, weil er gegen die beschissenen fundamentalen Regeln verstoßen hat, die eigentlich jeder Affe, der an sowas sitzt, kennen müsste. Oder weil er jemanden bestochen hat.

Und ich mache hier ja keine verflixte Rocket Science; ich hatte nicht einmal das verkorkste Visual Studio offen. Ich wollte echt nicht mehr, als im räudigen Netz zu surfen. Das kann doch nicht zu viel verlangt sein, dass ein verfickter Netzwerktreiber bei sowas nicht amok läuft, oder?!

Das Rad gibt es auch schon recht lange, sogar schon deutlich laenger als 16 Jahre, trotzdem kann man auch heute noch einen Platten haben.

Nur, dass ich keine Glasscherben in meine Netzwerkkarte stecke. Nein, um bei der Metapher zu bleiben: Was Treiber angeht, befinden wir uns in einer Welt, in der die Räder aus Teer sind und die Straßen aufblasbar und aus Gummi. Und wenn einer über ’ne Scherbe fährt, ist gleich die ganze Stadt fortbewegungsunfähig.

Nun ja, es gibt da sowas wie ein Autosave und die Möglichkeit, offene Tabs zu restaurieren, weil sowas immer mal wieder passieren kann. Und ich hatte schon mit Treibern unter Windows-XP embedded zu tun und kann dazu nur sagen: wenn du es besser kannst, nur zu :). Das ist wirklich mal ein echt ätzendes Thema. Von Hibernation will ich lieber gar nicht erst reden, weil uns so ziemlich alles, was schiefgehen kann, da schon auf die Füße gefallen ist. Irgendwann ist die Komplexität ( wie es bei deinem Problem garantiert auch der Fall war ) so groß, dass sie keiner mehr so ohne weiteres duchblickt.

Kleiner aber gemeiner Seitenhieb: sobald du große Projekte angehst und dich nicht nur in lokalen Optimierungen suhlst, weißt du, was ich meine. Die bringen auch Spass, keine Frage. Aber da gibt es noch eine sehr sehr große Welt darüber ;).

Gruß Kimmi

kimmi hat geschrieben:und die Möglichkeit, offene Tabs zu restaurieren

Nääh, leider total abgeschossen worden :/

kimmi hat geschrieben:Und ich hatte schon mit Treibern unter Windows-XP embedded zu tun und kann dazu nur sagen: wenn du es besser kannst, nur zu :).

Windows’ Treibermodell schreibe ich gern besser neu, aber erstmal muss ich meine anderen hundert Projekte fertig kriegen ;)

kimmi hat geschrieben:Kleiner aber gemeiner Seitenhieb: sobald du große Projekte angehst und dich nicht nur in lokalen Optimierungen suhlst, weißt du, was ich meine.

Das hat nichts mit Projektgröße zu tun sondern mit das-muss-jetzt-raus-Haltung. Jedes Mal. Fängt bei der HAL (oder noch tiefer) an und dann dürfen sich die anderen (darüber, darunter und danach) 20 Jahre damit rumärgern. Und weil’s jeder macht fühlt sich auch keiner schuldig.

Irgendwann musst du auch mal raus mit edm Ding. Weil wenn man alles perfekt machen will, wird nichts fertig. Dazu gibt es bestimmt auch irgendwo einige Statistiken: wieviele Projekte nie das Licht der Welt erblickt haben, weil man sie "perfekt" machen wollte :).
Wenn man sich die Statistiken großer Projekte ( egal wo ) anschaut, sieht man in der Regel eine riese Zahl offener Defecte. Meiner Erfahrung nach gibt es keine Möglichkeit, Software komplett fehlerfrei zu bauen.

Gruß Kimmi

Das ist aber eine unangenehme Warheit die der Projektmanager nie hören will. Alle Kosten- und Terminpläne sollen eingehalten werden bei gleichzeitiger Null-Fehler-Strategie. :evil:

You made my day.

sehr geil, meine favoriten: :)

Verdammte Live ID. Ich habe meine E-Mail-Adresse geändert. Damit ändert sich natürlich nicht die Live ID. Heißt: Ich muss mich mit der Alten einloggen, aber mit der Neuen denken. Habe zehn Minuten gebraucht, um draufzukommen.

Und wtf hat Microsoft so viele Konten von mir? Eins von Live und eins für das MSDN, okay. Aber dann noch Expression und TechNet – da habe ich keinen Plan, wo die herkommen. Sind aber schon drei Jahre alt. Und kündigen kann man da irgendwie überhaupt nichts; ich werde immer nur zum Profil-Center weitergeleitet, wo mich Stock-Gesichter leer angrinsen. Und wenn ich auf die Hilfe klicke, will die erstmal wissen, ob ich mich wegen Windows 7 oder doch eher wegen Internet Explorer oder Office-Paket melde und ob mir das weiterhilft. Rage

Nicht zu vergessen der Microsoft-Connect-Account. Habe übrigens über die letzten drei Jahre meinen uralten Hotmail-Account langsam aber sicher abgeschaltet. Die haben tatsächlich in den letzten zehn Jahren kein IMAP gebacken bekommen.

Was ist Meme!? Wie ein anderes deutsche Wort für Milchkeks?

Wenn, dann richtig

ogmfi

verstehe...

http://de.wikipedia.org/wiki/Internet-Ph%C3%A4nomen ;)

Ich habe mich die letzten Tage mal an einer Vektorklasse versucht, unter anderem, um herauszufinden, was sich gegenüber der STL noch so rausholen lässt an Performance. Zunächst sah das sehr gut aus, bei angeschalteten Optimierungen und ausgeschaltetem _SECURE_SCL kam ich scheinbar nur mit Mühe an die Geschwindigkeit des STL-Vektors heran. Nachdem ich dann jedoch noch einige Exception-Handler eliminieren konnte, und außerdem das Inlining einiger Methoden unterdrückte, staunte ich nicht schlecht, als sich mein push_back ziemlich zuverlässig als ca. 50% schneller herausstellte, sowohl mit als auch ohne vorangehender Speicherreservierung.

Sehe ich mir außerdem den Compiler-generierten Code an, so kann ich langsam sehr gut nachvollziehen, worüber Krishty hier so häufig jammert: STL push_back bereichert bei vollem Inlining den generierten Code schonmal gut und gerne um 100 Instruktionen, mit meinem eigenen push_back komme ich dank gezielter Inline-Unterdrückung jetzt noch auf 15.

Fazit: Nun werde ich wohl doch meine eigene Vektorklasse behalten, insbesondere mit einigen Optimierungspolicies für POD-Typen (oder auch halb-POD, der Programmierer weiß ja, was er tut :P ) lässt sich da wohl ein beachtlicher Geschwindigkeitszuwachs erreichen. Auch wenn ich absolut keine Lust habe, da jetzt erstmal haufenweise Unit Tests zu schreiben, um die korrekte Funktionsweise auch wirklich sicherstellen zu können.

Hier … ist zwar unvollständig (z.B. fehlt der Zuweisungsoperator; habe ich bisher einfach nicht benötigt) und von meinem Framework abhängig (was ich aber nachliefern kann, falls die Dokumentation nicht ausreicht), aber wird bei mir seit einem halben Jahr erfolgreich eingesetzt und könnte dir helfen:
(Vergiss TCMap – die habe ich seit einem halben Jahr nicht instanziert und weiß nicht, ob sie funzt. Und es könnte hässliche Fehlermeldungen geben, falls du mal was rumschiebst, was keinen move-K’tor hat. Und der ::std-Namenskonvention folge ich sowieso nirgends – insbesondere, wenn ich length und size unterscheide.)

Den Hauptvorteil an einem eigenen vector sehe ich nicht einmal in der Leistung, sondern in der Möglichkeit, dank move-Konstruktion Objekte zu speichern, die sich mangels Kopierbarkeit in „gewöhnlichen“ Vektoren nicht unterbringen lassen. Das hat bei mir sehr vieles sehr viel sauberer gemacht.

Nachtrag: Jetzt, wo ich nochmal drübergucke, sehe ich, dass ich da wieder einen hässlichen Zombie-State habe (myBegin ist nullptr), den ich durch eine Nullallokation im Standardk’tor wegkriegen könnte. Wenn man jedem Vektor bei der Konstruktion einen Größenvoranschlag mitgibt, dürfte das nur positive Auswirkungen haben und die Implementierung vereinfachen. Direkt mal testen.

Danke, ich orientiere mich ja schon seit geraumer Zeit immer wieder mal an deinem Code. ;-) In diesem Fall werde ich meine Implementierung allerdings wohl so lassen wie ich sie jetzt habe, wenn sie schonmal so ausgiebig optimiert ist. Die Optionalität von Default- und Copy-Konstruktor sind natürlich eine feine Sache, aber die habe ich, wenn ich das richtig einschätze, bei korrekter Benutzung dank Lazy Instantiation bei Templates auch so, wenn auch nicht gesichert, lediglich implizit.

Im übrigen habe ich aus purer Faulheit meinen aktuellen Code bei google gehostet, in der Hoffnung, dass hier niemand gleich Catplag aufmacht, poste ich einfach mal den Link: http://code.google.com/p/lean-cpp-lib/ (vieles noch ungetestet, manches nur eben aus altem Code rüberkopiert, wenns "fertig" ist gibts vielleicht noch ein paar Samples und ne Doxygen-Doku)

Oooh, sehr schön – da habe ich ja heute schön was durchzuarbeiten.

CodingCat hat geschrieben:ich orientiere mich ja schon seit geraumer Zeit immer wieder mal an deinem Code. ;-)

Jaa, einiges kommt mir bekannt vor :D

CodingCat hat geschrieben:In diesem Fall werde ich meine Implementierung allerdings wohl so lassen wie ich sie jetzt habe, wenn sie schonmal so ausgiebig optimiert ist.

Vor allem ausgestattet mit Allokatoren und allem drum & dran – dass sie schon so ausgewachsen ist, hatte ich garnicht vermutet.

CodingCat hat geschrieben:in der Hoffnung, dass hier niemand gleich Catplag aufmacht

Insider?

Krishty hat geschrieben:

CodingCat hat geschrieben:in der Hoffnung, dass hier niemand gleich Catplag aufmacht

Insider?

Hab' grad fünf Minuten dran gehangen. Stichwort: guttenplag.

Nachträge: An Krishty und Cat: Vielen Dank für das Publikmachen, ich werde bei Zeiten bestimmt da auch mal mich durchwühlen ;). An Cromanoid: Tja, ich machs wie auf Stackoverflow. Erst kleine Stubs schreiben, damit man erster ist, dann Ninja-Edits hinterherschieben ;)

Och menno du bist mir zuvor gekommen, es ist so selten, dass ich ihn mal belehren kann :D

Argh; na klar, danke. Ich habe das die ganze Zeit englisch zu interpretieren versucht … und schiebe es außerdem auf Schlafentzug, Kater und Ungeduld (um beim Thema dieses Themas zu bleiben).

Chromanoid hat geschrieben:es ist so selten, dass ich ihn mal belehren kann :D

Mein persönliches Geburtstagsgeschenk … und eXile steckt den Finger in die Torte. Unverschämtheit!

Hier ist jedenfalls das aktuelle Cric Framework zum abschielen, diesmal sogar mit D3D11-Wrappern und allem.

Gibt es einen Grund, dass der Container-Move-Assignment-Operator anstatt von Member-Swaps mit anschließender Zerstörung der nicht mehr benötigten Ressourcen durch den Destruktoraufruf des anderen Containers den anderen Container in einen leeren Zustand versetzt? Spontan würde mir nur auffallen, dass der Speicher bei expliziten Moves von Scopevariablen vor verlassen des Scopes freigegeben wird. { Type a, b; a = std::move(b); /* Speicher haben oder nicht haben */ ... }. Aber dann ist Selfassignment in dieser Implementierung für die Programmstabilität eher unvorteilhaft (a[0] = ...; a = std::move(a); true == (a == Container()); a[0] = ...; ) ;) (Ich hoffe, ich habe mich jetzt nicht komplett vertan. Spezifikation kenne ich dazu nicht)
Hinsichtlich des Frameworks: Respekt und Danke für solch eine riesige Informationsquelle. Ich mach mich dann mal wieder an meine Java-Hausaufgaben :(