Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
kaiserludi hat geschrieben:Ich muss mich eben nicht daran erinnern, da es mir ja der Prefix jederzeit verrät.
Du musst dich daran erinnern, dass die Variable ein Präfix hat. ;-)
Nö, steht doch überall, wo sie im Code auftaucht, dran.
CodingCat hat geschrieben:
kaiserludi hat geschrieben:Wenn du der einziger Programmierer an dem projekt bist, kannst du ja auch in der Regel alleine die Namensgebung bestimmen, bist du es hingegen nicht, dann müssten sich alle anderen auch daran halten, konsequent immer this-> und :: zu schreiben, denn gerade bei Code, den man nicht wie seine Westentasche kennt, bringt sowas ja am meisten, und da wird man sie noch weit eher von Präfixen überzeugen können.
Genau davon rede ich doch, wenn ich nicht der einzige Programmierer bin, kann ich die Namensgebung in der Regel auch nicht beeinflussen. Dann muss ich auch niemanden überzeugen, sondern selbst einen Weg finden, damit optimal umzugehen. Und wäre die vorgegebene Konvention, keinerlei Präfixe einzusetzen (und ich denke, es gibt da draußen heute etliche Firmen, die in dieser Richtung zum Beispiel die JCC durchsetzen), dann wäre die konsequente explizite Auswahl des Kontexts in dem Code, den ich selbst für diese Firma schreiben müsste, eben die verantwortungsvollste Art und Weise, damit umzugehen.
Genau das meine ich, wenn ich sage, Namensgebung ist ein Non-Issue. Unabhängig von den Vorschriften zur Namensgebung findet sich fast immer ein Weg, sicher damit umzugehen, auch wenn dieser Weg vielleicht von anderen in diesem Rahmen gängigerweise nicht verfolgt wird. Aber das ist dann nicht mein Problem, es sei denn, ich muss deren Code warten. Und in diesem Fall kriege ich für deren Mist ja sogar Geld. ;-)
Gehöre ich hingegen zu denjenigen, die die Namensgebung beeinflussen können, dann wähle ich natürlich die Namensgebung, die von sich aus für alle im Alltagsgebrauch das kleinste Risiko birgt. Und in diesem Fall sind wir uns bezüglich Präferenzen ja offensichtlich weitestgehend einig.
Ich denke bloß, wenn man mit 10 Personen an einem Projekt arbeitet, dann bringt es nicht sonderlich viel, wenn einer davon konsequent überall -> und :: einsetzt, selbst für diesen selbst nicht, denn er wird wohl öfter mit dem Code von den anderen 9 konfrontiert sein als mit seinem eigenen und noch dazu wird er in seinem eigenen sich eh leichter zurecht finden als in dem der Kollegen, wodruch der Nutzen bei selsbt geschriebenem Code kleienr sit, als bei welchem, der schon exixistiert, wenn man sich in ihn einarbeitet.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
kaiserludi hat geschrieben:Ich denke bloß, wenn man mit 10 Personen an einem Projekt arbeitet, dann bringt es nicht sonderlich viel, wenn einer davon konsequent überall -> und :: einsetzt, selbst für diesen selbst nicht, denn er wird wohl öfter mit dem Code von den anderen 9 konfrontiert sein als mit seinem eigenen und noch dazu wird er in seinem eigenen sich eh leichter zurecht finden als in dem der Kollegen, wodruch der Nutzen bei selsbt geschriebenem Code kleienr sit, als bei welchem, der schon exixistiert, wenn man sich in ihn einarbeitet.
Das bestreite ich ganz offensichtlich ja auch gar nicht, nichts anderes habe ich doch im vorangegangenen Post geschrieben.
beason hat geschrieben:Nvidia is artificially limiting the compute speed of their consumer graphics cards, including the new GTX680. If so that is extremely disappointing.
This is DEFINETLY not true. There is no artificial slowdown in the driver/software or hardware crippling involved, its just a change of priorities that was chosen for this line of GPUs (i.e. mainly reducing power consumption drastically while keeping gaming performance at least on-par). For the last generation (Fermi) it was rather the opposite (i.e. huge jump in performance for compute, but moderate jump for games, except for the dx11 features of course).
toxie ist Carsten Wächter, jetzt bei Nvidia, zur Verifikation meiner Aussagen siehe hier und hier. Nur, damit ihr in den kommenden Wochen keiner Fehlinformation aufsetzt.
Oh, das kannte ich auch noch nicht. Schon wieder ein hochinteressantes Papier, das in die Richtung dessen geht, was ich demnächst ausprobieren möchte. Allerdings bräuchte man auch hier wohl pro Rekursionsebene ein Scatter bzw. bei der Rückkehr ein Gather, um bei der parallelen Abarbeitung selbst Kohärenz herstellen zu können. Möglicherweise wären diese Speicherzugriffe aber gar nicht mal so problematisch, weil pro Rekursionsebene Strahlen immer nur in zwei neue Bereiche verteilt werden müssten, da dürften sich die meisten Zugriffe doch in zwei Blockoperationen zusammenfassen lassen.
///LocalShapeInfo gives extra information for complex shapes
///Currently, only btTriangleMeshShape is available, so it just contains triangleIndex and subpart
Aha, die aktuelle Kepler ist also nur die kleine Kepler. Die große Kepler kommt im Q4, und auch erst damit die versprochene Verbesserung der Compute-Performance.
Erklärt auch, warum in der nouveau-Präsentation von der XDC2011 die als „half-Kepler“ bezeichnet wird. Blödfug, das bezog sich auf einige Karten aus der 500er-Reihe.
Hab auch schon häufiger gelesen, dass die GTX680 "nur" die 560Ti der 600er Reihe sein soll. Wieso sie das jetzt gemacht haben frag ich mich allerdings. Das macht irgendwie deren ganze Namensgebung der letzten Karten kaputt.
Wusstet ihr, dass HLSL eine noise-Funktion für Perlin-Noise hat?
Ha, aber nur für Shader Model 1 unter dem Spezialtarget tx_1_0. Korrekt, kein Pixel oder Vertex Shader, sondern ein Texture Shader. Ein Relikt grauer Vorzeiten, als die Geforce 3 rauskam, und die Radeon 8500 nachzog.
Damit konntest du z.B. in einem Effect File eine Funktion haben, die eine Textur, die der Effect benötigte, generiert hat...lang ist's schon wieder her :D ...
Die richtige Lösung™ wäre ein Fixkomma-Datentyp der automatisch von 360° auf 0° umwrappt, zusammen mit einem Satz optimierter trigonometrischer AVX-Vektorfunktionen (sin(·) bzw. cos(·) usw. geben dann für · als dieser Datentyp einen half/float/double zurück). Oder man macht stattdessen was sinnvolles mit seiner Zeit.
Doof nur, dass Quaternionen in einen Winkel bis zu 720° umgewandelt werden können.
eXile hat geschrieben:Oder man macht stattdessen was sinnvolles mit seiner Zeit.
Es ist der einzige Kampf, den es zu kämpfen lohnt (wobei mir Parallelisierung den Aufwand nicht wert ist).
eXile hat geschrieben:Die richtige Lösung™ wäre ein Fixkomma-Datentyp der automatisch von 360° auf 0° umwrappt, zusammen mit einem Satz optimierter trigonometrischer AVX-Vektorfunktionen (sin(·) bzw. cos(·) usw. geben dann für · als dieser Datentyp einen half/float/double zurück).
Ich will’s schon seit Monaten so realisieren (mit Einheiten rechne ich eh nur noch an den äußersten Rändern meiner Logik); aber die Zeit ist halt zu kn
Warum meinen so viele Software Ingenieure, dass sie bessere Task-Libraries schreiben können als zum Beispiel Intel mit der TBB? Und warum muss das bei uns in der Firma sein?
UND WARUM MUSS ICH DEN SCHEISS SCHON WIEDER DEBUGGEN????? :evil: :evil: :evil: :evil:
PS: GIbt es dafür was intelligenteres als hellgrind und den Intel Inspector?
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Kommt wohl drauf an, wann die Entscheidung gefaellt wurde, das selbst zu machen.
TBB wurde erst Mitte 2007 OpenSource, und lief damals _nur_ auf x86. Nicht die besten Vorraussetzungen, falls man auch andere Architekturen bedienen muss.
Letztes Jahr. Unsere einzige Plattform ist x86(_64)...
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Ich wünsche mir folgende Operatoren:
result = aBool?myVar;
result = aBool!?myVar;
Ohne muss ich immer if() nutzen, wenn ich nicht gerade result = aBool?myVar:result; schreiben will, dabei finde ich ein knackig kurzes ? so viel eleganter :(
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Krishty hat geschrieben:Ich sitze schon zwei Tage daran, eine Sprite via Direct3D 9 1:1 in einer 3D-Szene anzuzeigen.
Habe den Fehler endlich gefunden:
Im Pixel Shader war das Texturkoordinatenregister mit Centroid Sampling deklariert. Dadurch wurden die Texturkoordinaten der Quads verzerrt. Alles, weil ich zu faul war, extra für den Zweck einen neuen Pixel Shader zu schreiben.
Aber, was soll’s – hat ja bloß zwei Wochenenden gekostet.
Das ist wirklich eine Frechheit, dass der Treiber selbst bei Application-Controlled mal locker flockig einen Blur über das ganze Bild haut.
Und Wahnsinn, was ich gerade wieder mit Qt durchmache. Das Programm stürzt mal wieder beim Beenden ab. Der Grund? Out of order Destruction dank ereignisgesteuerten Programmablaufs. Erstmal habe ich alle deleteLater()-Aufrufe rausgeworfen, welche von Qt empfohlen werden, um ggf. auch noch in der Event Queue verweilenden Ereignissen für das jeweils zu zerstörende Objekt eine Erfolgreiche Verarbeitung zu gewährleisten, bevor das Objekt in die ewigen Jagdgründe einziehen darf. (In diesem Fall wird das Delete-Ereignis ganz hinten, hinter allen anderen wartenden Ereignissen eingereiht). Das mag unglücklicherweise in manchen Fällen höchst spontan auftretender Ereignisse (wohl vor allem Systemereignisse und damit das Hauptfenster betreffend) notwendig sein, führt aber im Allgemeinen dazu, dass bereits unwideruflich im Sterben liegende Objekte das ganze Programm in ein orchestriertes Feuerwerk von Zugriffsverletzungen verwandeln, wann immer sie abhängige Objekte einfach mal unverbindlich zur späteren Destruktion mit massig dangling Pointers in die Schlange stellen.
Leider ist das Übel damit noch lange nicht beseitigt. Jetzt erst tritt der wilde Qt-Code-Jungle so richtig auf den Plan. In einem undurchsichtigen Wald von hierarchischen Abängigkeiten sterben am Ende des Programms die Widgets wie die Fliegen in scheinbar willkürlicher Reihenfolge dahin, Qt selbst macht von ereignisgesteuerter Zerstörung massiven Gebrauch. So teilt mein Code zwar allen Bedienelementen umfassend und punktgenau mit, wann das Dokument sich verabschiedet, dieses Timing geht jedoch in den Tiefen der Qt-Tree-View-Model-View-Controller-Logik dank ereignisgesteuerten Abbruchs einer noch in der Ausführung befindlichen Objekteigenschaftsbearbeitungsoperation gleich wieder verloren. Wenn das Widget des zugehörigen Bearbeitungswerkzeugs denn dann endlich das Zeitliche segnet, ist die UI längst aufgeräumt, das Dokument gespeichert und entsorgt, und das Widget sprengt den Editor mit seinem Versuch, die abgebrochene Operation ordnungsgemäß rückgängig zu machen.
Update: Ich sehe tatsächlich keine andere Möglichkeit, als für Dokumente auf verzögerte Zerstörung mittels deleteLater() zurückzugreifen. Die Masse von Ereignissen, die durch den Dokumentenwechsel zu nullptr noch ausgelöst werden, lässt sich kaum kontrollieren, geschweige denn überhaupt überblicken. Zum Glück sind Dokumente so vom Rest des Programms abgekoppelt, dass mir eine Out-of-Order-Zerstörung hier keine allzu großen Bauchschmerzen bereiten muss. Nichtsdestotrotz ist diese verzögerte Programmlogik durch Ereignisse höchst problematisch, wenn das zugrundeliegende Framework nicht trotzdem für allzeit konsistenten Zustand sorgt.
Jedesmal wenn ich dich hier posten seh, bin ich ein großes Stück mehr froh dass ich Qt nicht verwend und um einen Grund reicher wieso sich das in Zukunft nicht ändern wird :D
Und ich frage mich jedes mal, was Du eigentlich anders machst als ich. Ich benutze Qt seit 1852 (ihr wisst schon, damals...) und habe noch nie solche Probleme damit gehabt. Nicht mit Threads, nicht mit Models, nicht mit Widgets. Einfach new( irgendein Parent) und das war's. Fire and forget. :)
Ja, das ist mir auch ein Rätsel. Mit Threads hatte ich übrigens noch keine Probleme, was aber aller Erfahrung nach alleine daran liegt, dass ich sie im Rahmen von Qt noch nie eingesetzt habe. Dennoch muss ich zugeben, dass ich nicht weiß, was ich ohne Qt machen würde, jedenfalls ganz sicher keine UI-Programmierung.
Hach, beim Studium von Zahnmedizin kann man auch 'ne Menge jammern. Man muss nicht nur die größten Gebühr- und Materialkosten überhaupt bezahlen, man muss die Semester auch wiederholen, wenn man nicht genug Patienten, die genau das brauchen, was man machen muss, findet...
(Falls hier jemand aus Bonn kommt und was zu machen hat kann er mich also gern anschreiben ;))
Zugegebenermaßen nicht die übliche Jammerei hier, aber das musste auch mal sein :)
http://www.borncity.com/blog/2007/05/18 ... ion-patzt/
Da kann Windows endlich mit Bordmitteln partitionieren und dann muss man dafür so einen Marathon bewältigen :(
2 mal den kompletten Inhalt der Datenpartition umher kopieren, sind ja nur ein paar hundert GB...
Zum Glück habe ich die wirklichen Speicherplatzfresser auf externen Platten rumliegen, sonst würde es wohl Tage dauern, die Systempartition mal ein wenig zu vergrößern.
Dass 50GB heutzutage beim besten Willen nicht mehr für ein reines OS ohne Auslagerungsdatei, etc. ausreichen, ist auch einfach nur noch lächerlich. Ich hoffe mit 100GB habe ich jetzt Ruhe.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
… bietet AVX keine 256-bittigen Integeroperationen?
… kommen die erst mit Haswell?
… kommen die Gather-Operationen erst mit Haswell?
… kommen die beliebigen Shuffle-Operationen erst mit Haswell?
Gerade der erste Punkt nervt mich irgendwie gewaltig. Die können 256-bittige Floating-Point-Operationen implementieren, aber keine Integer-Operationen?
Andererseits sieht AVX2 (mit Integer-, Gather- und beliebigen Shuffle-Support) damit wie ein neuer herausragender Standard im Dschungel von Befehlssatzerweiterungen aus, ähnlich wie SSE2 es jetzt (noch) ist.
