Jammer-Thread

[Krishty]

Ich kann dir insofern folgen, als dass der Move-Zuweisungsoperator nicht gegen Selbstzuweisung geschützt ist und das dann furchtbar in die Hose geht. Das gilt genau so für Cric::types::TCNullTerminatedPODHeapArray (also die String-Klasse) … verdammt … bei der Bildverarbeitung habe ich diesen Fall ordentlich abgesichert, an den anderen beiden Stellen habe ich ihn schlicht und einfach vergessen. Danke, damit hat sich das online-stellen schon ausgezahlt :D Aber ich würde eh CodingCats Container empfehlen, wegen der Allocator-Unterstützung und allem.

Was das Swapping angeht, glaube ich, dass du darauf hinaus willst, dass das verschobene Objekt in den meisten Fällen tatsächlich sofort zerstört wird und man durch Vertauschung einen D’toraufruf sparen würde.(?) In Einzelfällen, in denen man manuell verschiebt und das verschobene Objekt noch kurz existiert, „verschleppt“ man dann aber die Wirkung der Zerstörung der originalen Array-Elemente bis ans Ende des Scopes. Ich weiß nicht, ob das nicht irgendwann problematisch werden könnte (ich benutze den Container z.B. auch zur Speicherung von automatisierten COM-Schnittstellen und stelle mir da schwebende Referenzen bis zum Ende des Scopes vor).

[anonym]

Genau das meinte ich.

[CodingCat]

Die grandiose developer.nvidia.com-Seite wurde neu gemacht und im Zuge dessen scheinbar jegliche Kategorisierung der unzähligen dort gesammelten Publikationen aufgegeben. Ich finde mich überhaupt nicht zurecht. :-(

Nachtrag: Nicht mal die spärlich verteilten Tags scheinen zu stimmen, schlimmer als auf GameDev.net, dort findet man seit dem Relaunch auch nur noch mit extremem Durchhaltewillen und einem messerscharfen Orientierungssinn überhaupt in die Richtige Kategorie.

[Krishty]

CStandardOutputStream<false> stdout; // error C2090: function returns array
Ich hasse #defines

[CodingCat]

Bah, statische Initialisierungsreihenfolge. Lässt sich ja wunderbar kontrollieren mit "lokalen" statischen Variablen (aka Meyer's Singleton):

Code: Alles auswählen

const Type& getStatic()
{
   static Type myStatic;
   return myStatic;
}

Nur wirft der Compiler dann natürlich bei JEDEM ZUGRIFF haufenweise Code raus, um zu checken, ob das Ding denn schon initialisiert wurde. Bei einer einfachen statischen Variable dagegen kann ich mir nie sicher sein, ob sie denn schon initialisiert wurde. Großartig!

Nachtrag: Und jedes Mal wenn ich länger als 10 Minuten im C++ Standard blättere, zeigt Adobe Reader massive Memory/Resource-Leak-Erscheinungen, zunächst verschwinden nach und nach sämtliche Buttons, am Ende bleibt vom angezeigten Dokument nur noch schwarze Schmiere übrig.

[Krishty]

Ich war schneller, und bei mir war es noch sinnfreier!

Nachtrag: Und jedes Mal wenn ich länger als 10 Minuten im C++ Standard blättere, zeigt Adobe Reader massive Memory/Resource-Leak-Erscheinungen, zunächst verschwinden nach und nach sämtliche Buttons, am Ende bleibt vom angezeigten Dokument nur noch schwarze Schmiere übrig.

Chrome lädt den C++0x-Draft bei mir immer nur im zweiten Anlauf; im ersten stürzt das Tab ab.

Was sollen eigentlich die ganzen Sonderzeichen dazwischen? Die ersetzen z.B. scheinbar willkürlich in Wörtern ff durch ein Doppel-f-Sonderzeichen. Ist das, damit die nachweisen können, wenn man klaut? Die werden doch eh zu weißen Blöcken, wenn man die irgendwo einfügt …

[Tejio]

Yeah....I love Google Chrome! Jetzt ist es offiziel!

Aarggh, wieso zum Teufel entsteht in OpenGL ein Texturfehler, wenn ich einen Mausklicke per Event an Berkelium / Chromium / Webkit sende?!?! Da darf ich mich weiter durch die Quellen von Chromium durchwühlen, um diesen bekloppten Fehler zu finden....Wo ist der nächste Baum? iwo muss ich den Strick anbringen....

[Krishty]

Nochmal ein Nachtrag zur Initialisierungsreihenfolge:

Das ist die einzige Situation, in der ich es sinnvoll finde, Java-mäßig alles in eine Programm-Klasse packen zu müssen. Dann sind nämlich alle statischen Daten Attribute und unterliegen somit einer festen Initialisierungsreihenfolge (nämlich der, in der sie deklariert wurden – obwohl das genau bei Java wieder anders sein könnte, weil die ja keine Initialisierungslisten kennen). Dann hat man nur eben mehr Schreibarbeit, weil man die referenzierten Objekte als K’torparameter übergeben muss.

Da ich für meine Sprache eh einen Abhängigkeitsbaum aufbauen und zyklische Abhängigkeiten vermeiden muss (um festzustellen, in welcher Reihenfolge ich überhaupt kompilieren muss), könnte ich versuchen, diesen Scheiß auch ohne globale Klasse ein für alle Mal auszumerzen … ist aber jetzt pure Träumerei. A rush of blood to the head.

[eXile]

Mein Internetprovider kommt seiner Hauptaufgabe nicht nach und ich habe nun schon zwei Tage lang kein Internet. Nun hab' ich mir eine Liste gemacht, was ich alles aus dem Internet brauche, bin in die Uni gefahren, alle Seiten auf den USB-Stick abgespeichert und kann weiterarbeiten. Für diesen Post hat's auch noch gereicht.

[Krishty]

Ich hasse, dass sich Stack und Heap in Debug- und Release-Builds anders verhalten. Andere Allokationsmuster, Standardinitialisierung mit Magic Numbers und der ganze Scheiß. Ich habe in den letzten paar Jahren nicht einen einzigen Bug durch eine Magic Number gefunden, aber dafür sicher ein paar Stunden darauf verschwendet, herauszukriegen, warum es im Debug-Build läuft und im Release-Build kracht.

Wenn ihr mir helfen wollt, dann sorgt dafür, dass im Debug-Modus ungültige Speicherabschnitte bei jedem Start (oder besser noch: Nach jedem Funktionsaufruf!) mit anderen Zufallszahlen umgewühlt sind. Aber bitte keine bekackten Magic Numbers mehr. Was Undefiniertes mit stabilen numerischen Werten vollzupumpen um auf die Undefiniertheit aufmerksam zu machen ist doch Hämorrhoiden-Creme auf Brötchen – eigentlich für’n Arsch.

[Chromanoid]

Das war damals praktisch der Hauptgrund warum ich mich von C++ abgewendet habe.

[Schrompf]

Ich find's nützlich und habe schon so manche Dummheit damit gefunden. Einzig bei bools, bei denen die Werte auf ein wohldefinierte "true" hinauslaufen, sind problematisch.

[Krishty]

Du hast daför ja auch deine Relug-Konfiguration.

[CodingCat]

Nachdem ich herausgefunden habe, wie ich von außen in meine Klasse beliebig viele implizite Casts (von und zu beliebigen anderen Klassen) injecten kann, und diese in erstere Richtung mittels SFINAE außerdem gezielt vor Mehrdeutigkeiten schützen konnte, wäre mein ultradünner String-/Nullterminated-Range-Parameter-Wrapper nun fast perfekt... wenn man SFINAE auf überladene Cast-Operatoren anwenden könnte .... und was ist das überhaupt für ein Gehacke, warum gibts enable_if noch immer nicht als sauberes Sprachfeature? :evil:

[CodingCat]

Warum gibt es keine standardisierten Funktionen, die einfach nur effizient Strings festen Formats in numerische Werte und zurück konvertieren, ohne dabei jegliche Locales zu befragen? Nebenbei ein paar Messungen...

Code: Alles auswählen

itoa: 9.874
sprintf: 53.948
num_put: 87.56

_gcvt: 152.328 // Boah wieso ist das lahmer als sprintf?
sprintf: 122.837
num_put: 161.695

atoi: 7.287
sscanf: 20.888
num_get: 43.248

atof: 61.477
sscanf: 97.449
num_get: 64.575

Tja, nur was mit den Locales tun, ich kann ja nicht vor jeder Konvertierung auf Verdacht die globale Locale zurücksetzen. Bei num_put / num_get (C++ Locale Library) bestimme ich die Locale, aber wie unschwer zu erkennen, sind diese nicht immer die effizientesten Alternativen...

[Schrompf]

Wie schlägt sich da boost::lexical_cast? Wobei ich nicht weiß, inwieweit da die locale berücksichtigt wird.

[CodingCat]

Code: Alles auswählen

int_to_char: 2.164 // eigenes itoa, profitiert wohl kräftig vom Inlining
itoa: 9.745
sprintf: 68.299
num_put: 89.264
lexical_cast: 34.279 // ist wie im Header zu sehen ebenfalls für ints optimiert worden

_gcvt: 153.676
sprintf: 121.372
num_put: 169.851
lexical_cast: 407.313 // nutzt Streams, also das rohe num_put nochmal unter einigen Library-Schichten begraben

char_to_int: 0.731 // eigenes atoi
atoi: 7.206
sscanf: 20.708
num_get: 41.197
lexical_cast: 229.242 // Stream-Performance!

atof: 62.108
sscanf: 96.223
num_get: 74.776
lexical_cast: 410.714

Ich hatte ja gehofft, heute mal eben ein eigenes atof / ftoa implementiert zu bekommen, aber nur weil man die IEEE-Werte schnell extrahiert hat, weiß man leider noch lange nicht, allgemeingültig was sinnvolles damit anzufangen... :-/

Anmerkung: Es handelt sich btw. um Millisekunden bei 100.000 Konvertierungen.

[Chromanoid]

Wenn du schon ein englisches Locale in deinem Post benutzt, dann bitte "Es handelt sich btw. um Millisekunden bei 100,000 Konvertierungen." :) ;)

[CodingCat]

ich habe das mal durch den ganzen Locale-Jungle nachverfolgt, wenn man das gesehen hat, wundert einen wohl nichts mehr. Letztlich läuft praktisch alles auf sprintf raus, je nach gewünschter Flexibilität wird das Ergebnis von sprintf mittels Find & Replace hinterher einfach an eine gegebene nicht-globale Locale angepasst, was auch erklärt, warum das einzig kontrollierbare num_put langsamer ist - es macht nichts anders, sondern einfach mehr. Es kommt noch besser - aufgrund der nicht-lokalen Natur dieser ganzen verkorksten Locale-Wirtschaft gibts hier und da immer wieder nette Thread-Locks, die wohl diesen ganzen superglobalen Verhau vor Crashs bewahren.

Dann werde ich wohl auch einfach sprintf mit anschließendem Komma/Punkt-Find-&-Replace nutzen, wenn nicht mal die das richtig hinbekommen... :evil:

[Chromanoid]

Gibt's für C++ nicht so Formatter deren Locale man setzen kann? Sind die dann echt so langsam? Ich habe eben mal geschaut ich komme mit Java (mit Locale) auf ca. 50ms bei Int2Str und 130ms bei Double2Str.

[Krishty]

Ist doch echt ein Witz. Aber wenn der Standard keine Konvertierungen von und zu Strings vorschreibt, tut auch keiner was. Mit GCC kann man ja schließlich schon froh sein, wenn man überhaupt was außer printf() vorfindet.

Ich habe diese Lokalisierungsbemühungen auch nie verstanden. Warum diese enormen Anstrengungen, alles irgendwie mit allen Sprachen kompatibel zu machen, anstatt ::std::ostream strikt US-ASCII zu halten (weil in den Programmkernen eh alles nur damit läuft) und dann für GUI-Programmierer sowas wie ::std::localized_ostream anzubieten, dem man dann munter alle Locales in den Popo stecken könnte wenn Leistung und Komfort (Locales und Facets sind schließlich auch nicht trivial zu benutzen) egal sind? Ach, Blutdruck. Sonne scheint so hell, Vögel singen schief, …

[Schrompf]

Ok, boost::lexical_cast von Zahl zu String erzeugt ja einen temporären String unbekannter Länge. Das läuft auf ne Allokation hinaus, was in C++ doch drastisch langsamer ist. Die Gegenrichtung müsste hinreichend schnell sein, allerdings in jeder Version.

Eigenjammer: ich habe soeben gekündigt.

[Krishty]

… und damit meine 2^10te Nachricht ordentlich in den Schatten gestellt.

Eigenjammern ist übrigens ein wundervoller Neologismus :)

[joggel]

....
....
Eigenjammer: ich habe soeben gekündigt.

Mist, hoffe findest schnell was!
Hier is im Moment auch ziemlich scheisse... !!
Überlege auch ab un an, alles hinzuschmeissen, und auszuwandern... :D
Als Eremit auf ner Insel
oder...

[Schrompf]

--- Moderator-Aktion: Diskussion zur möglichen Selbständigkeit in eigenes Thema herausgetrennt. Im hiesigen Thread darf weiter gejammert werden :-)

[Schrompf]

Den Teil von Despotists Beiträg möchte ich hier beantworten:

Möchtest du etwas zu den Gründen deiner Kündigung sagen? Wenn es von dir ausging passt es ja eigentlich nicht in den Jammer Thread wenn es ein Befreiungsschlag war .

Ochja, aus aktuellem Anlass gern:

Die hiesige Software kollabiert in ihrem Eigengewicht. 6 Millionen Zeilen C-Code. C++ ist verboten aufgrund mancher berechtigter und vieler unberechtigter Ängste. Die Codebase soll über sechs Generationen von Geräten und dutzenden Varianten für Auftraggeber funktionieren. Gleichzeitig gibt es hier Programmierer, die immernoch Code schreiben, als wäre das noch die 10Mann-Firma von vor 10 Jahren. Es gibt Leute, die halten die Jagd nach einem Speicher-Überschreiber für unnötig und ein Lesen über Array-Grenzen hinaus ist ja ok, "weil's ja nur Lesen ist". Wir stapeln jetzt schon seit einem Jahr Hack auf Hack, immer heißt es "nächste Woche ist Release, mach nur einen schnellen Fix". Aber es ist permanent irgendwo Release! Jede größere Änderung, die uns auf Dauer Pflegeaufwand ersparen könnte, wird aus Angst um die Stabilität bestehender Produkte verboten. Nur dass die ja eh aus einem der dutzenden Branches gebaut werden. Die Hälfte aller Fehler treten im Trunk gar nicht auf, sondern sind nur auf das Davondriften dutzender Branches zurückzuführen. Wir haben inzwischen einige Leute in der Firma, die vollzeit nur mit dem Mergen beschäftigt sind. Genau heute kam nun eine Mail rum, dass ab sofort zu jedem Branch ein zusätzlicher Bugfix-Branch gegründet wird, in dem gefixt wird. Und aus dem wird dann der Bugfix rübergemergt, falls er sich bewährt hat. Diese Fixes werden dann manuell von jedem persönlich auch in die anderen Branches reingemergt und wieder Merge-Mails verschickt, damit die Änderungen in die jeweiligen Partner-Branches reinkommen.

Nur dass die Software das nicht verträgt. Konflikte, wohin das Auge schaut. Die Modularisierung ist übel aufgeweicht, hunderte kleiner Nebengriffe und "schneller Bugfixes kurz vorm Release" haben die Software zu einem verbastelten unkontrollierbaren Monster verkommen lassen. Da läuft dann auch ein selektives Übertragen von Änderungen mehr auf eine doppelte Neuentwicklung hinaus.

Ich will dieses Theater nicht mehr mitmachen.

[Despotist]

Das hört sich ja wirklich schlimm an. Aber denkst du dass es irgendwo anders ist?

Aber so ein Zustand ist in jedem Fall ein Managementfehler. Das magische Dreieck ist deinem Chef bekannt?

Deine Firma hat nicht zufällig die Initialen SS?

[joggel]

Ich denke, das ist ein Problem bei Produkten an denen mehrer/viele Entwickler mitarbeiten und wo das Produkt auch noch Konkurenzfähig sein muss! (Termindruck, etc..)

[Schrompf]

Ich mag keine Namen nennen. Mein richtiger Name ist zum Glück so ein Allerweltsname, dass ich recht sicher vor Google-Nachstellungen bin :-)

Das schlimme ist ja, dass ich durchaus einige Ideen hätte, wie man es besser machen könnte. Ich bin aber mit meinen Vorschlägen und Ideen immer abgeprallt. Irgendwann muss man sich halt entscheiden, ob man es akzeptiert oder seinen Hut nimmt. Ich habe mich entschieden.

[hagbard]

Also dieses "bloß nichts ändern es könnte ja etwas umfallen lieber ein großes Pflaster darauf kleben" scheint relativ weit verbreitet zu sein. Das kenn ich auch hier zur Genüge aber man regt sich mit der Zeit nicht mehr so sehr darüber auf. Aber wenn dann noch ein so chaotisches Versionsmanagement hinzukommt kann ich verstehen dass man die Schnauze irgendwann voll hat.

Edit: Das mit den magischen Dreieck muss ich mir merken. Die meisten Projektmanager tuen immer so als ob das eher drei sich gegeneinander bedingende Faktoren sind.