ZFX + Developia

Verfasst: **15.03.2011, 15:27**

Chromanoid hat geschrieben:Falls du es noch nicht kennst: Bei https://www.dreamspark.com/ solltest du für andere Software auch mal vorbeischauen. Bei den Sachen klappt Freischaltung schon mit einer universitären Mail-Adresse. Visual Studio 2010 Prof. und Expression Studio Ultimate sind so für Studenten verfügbar.

Jo, da hab ich schon geguckt, aber die haben kein Win7. VC10 Prof hab ich hier schon. Bei MSDNAA hab ich auch geguckt, aber ich soll mich an den zuständigen in meiner Uni melden.

Verfasst: **15.03.2011, 15:59**

Da wacht man eines Morgens auf, und dachte, man sei bisher immer verrückt. Weil man häufig den IE verwendet. Oder weil einem die Sidebar in Chrome fehlt. Und nun innerhalb weniger Stunden ist alles normal! :)

Vielleicht werde ich auch irgendwann Erweiterungen für Chrome basteln. Erst einmal wurde mir wieder ein Riesenbrocken Arbeit in den Weg gelegt. Ich selber würde dann vielleicht sogar eine RSS-Sidebar wie im IE basteln wollen, aber ich glaube, dazu werde ich erst wieder im Rentenalter Zeit haben ...

Verfasst: **18.03.2011, 22:57**

Ich hasse

C++
wie C++ mit der Standardbibliothek verwoben ist
die Implementierung der Standardbibliothek
Die Windows-Header
wie die Windows-Header mit der Standardbibliothek verwoben sind

Ich kriege die verdammte CRT nicht aus meinem Programm, weil in ihr ::std::exception definiert ist, und davon erbt ::std::bad_alloc, und das ist die einzige Exception, die operator new werfen darf, und in derselben Datei ist auch Placement operator new definiert

Ich würde jetzt gern die ganze CRT und STL rausschmeißen, weil ich sie für nichts anderes als bad_alloc brauche, das ich selber besser implementiert kriege, aber dann kann ich keine Windows-/Direct3D-/sonstwas-Header mehr benutzen weil die alle aus mir unbekannten Gründen die STL #includen, und dann ist bad_alloc doppelt implementiert

Und wusstet ihr, dass man Placement operator new laut Sprachdefinition nicht überschreiben darf, sondern die Definiton der STL benutzen muss? Das ist mal saubere Trennung

Und was soll überhaupt diese what()-Methode in ::std::exception
Wer die in den Standard gequetscht hat kann doch nur völlig ahnungslos gewesen sein

Und das traurigste ist, dass C++ trotz diesem ganzen Kompatibilitäts- und Miskonzeptscheiß noch um Äonen schneller ist als die „modern“eren Sprachen

Ist doch alles so ein Schwachsinn

Nachtrag: Mal testweise Microsofts Header verstümmelt; mit eigener Exception-Hierarchie habe ich 1,5 KiB == 1,5 % weniger Programmdaten, 0,5 davon werden direkt wieder wettgemacht wenn ich __assume(nullptr != _Where); in Placement operator new einsetze weil dann pro Placement drei Befehle und ein bedingter Sprung entfallen und meine ganzen Container aggressiver geinlinet werden können. Hass

Verfasst: **18.03.2011, 23:57**

Krishty hat geschrieben:Ich hasse
C++

Er hat Jehova gesagt!

Verfasst: **19.03.2011, 11:37**

FULL ACK

Verfasst: **19.03.2011, 11:39**

Bin gerade passenderweise über das hier gestolpert und hängengeblieben: http://gigamonkeys.wordpress.com/2009/1 ... plus-plus/# (via c0de5157e).

Verfasst: **19.03.2011, 14:18**

Krishty hat geschrieben:Ich würde jetzt gern die ganze CRT und STL rausschmeißen, weil ich sie für nichts anderes als bad_alloc brauche, das ich selber besser implementiert kriege, aber dann kann ich keine Windows-/Direct3D-/sonstwas-Header mehr benutzen weil die alle aus mir unbekannten Gründen die STL #includen, und dann ist bad_alloc doppelt implementiert

Du kannst ja die Includeguards von den STL Headern selber vorher definieren. So musst du die offiziellen Header nicht anfassen.

Ciao
Helmut

Verfasst: **19.03.2011, 15:26**

Welche wären das denn? Die Header benutzen keine herkömmlichen Include-Guards sondern #pragma once. Es gibt jede Menge STL-spezifischer #defines, die aber nie konsistent gesetzt werden (entweder setzt sie Windows.h zu oft oder ich zu wenig) oder nur für verschiedene Klassen und Sub-Header gelten. Ich habe auch schon die CRT-#defines ausprobiert und nach entsprechender Dokumentation gesucht, aber für die STL scheint kein #define vorgesehen zu sein (weil man annimmt, dass sie sowieso immer eingebunden ist).

Verfasst: **19.03.2011, 15:42**

Kannst du dir nicht einfach deine eigene Mini-STL zusammenbasteln (-klauen) und den Include-Pfad entsprechend dorthin setzen? Dann kannst du modifizieren / implementieren was du brauchst (scheint ja nur ein winziges Subset des Standards zu sein), den Rest lässt du mit Attrappen ins Leere laufen, sofern die anderen Bibliotheken wirklich bis auf die Includes nicht weiter davon abhängen.

Verfasst: **19.03.2011, 16:16**

CodingCat hat geschrieben:Kannst du dir nicht einfach deine eigene Mini-STL zusammenbasteln (-klauen) und den Include-Pfad entsprechend dorthin setzen? Dann kannst du modifizieren / implementieren was du brauchst (scheint ja nur ein winziges Subset des Standards zu sein), den Rest lässt du mit Attrappen ins Leere laufen, sofern die anderen Bibliotheken wirklich bis auf die Includes nicht weiter davon abhängen.

Ja, darauf wird es wohl hinauslaufen. Die winzige Untermenge der CRT, die ich brauche, habe ich auch schon zu einem Großteil selber implementiert; warum also nicht das Cric Framework um STL-Basiskram erweitern … werde direkt anfangen, die Windows-Header auf Abhängigkeiten zu analysieren.

… ich muss allerdings zu meiner Schande eingestehen, dass ich noch Projekte habe, die mit der originalen STL laufen und die ich erst portieren müssen werde. Das wird u.U. ein ziemliches Massaker.

Verfasst: **19.03.2011, 20:07**

Versteh einer die Microcontroller...

Warum interessiert bei einem Atmega162 bei der einen Uart die Reiehenfolge der Initialisierung nicht und bei der anderen schon??????
Und an so nen Mist such ich nun schon seit Ewigkeiten hin...

Verfasst: **19.03.2011, 20:47**

C++: eh vector constructor iterator called unnecessarily – Status geändert von „Aktiv“ zu „Geschlossen (als nicht lösbar)“
Jaa, ist schon schwer, so eine for-Schleife. Meine Vermutung: Visual C++’ RAII-Konzept stammt noch aus 6.0-Zeiten und sie haben schlicht und einfach nicht die Möglichkeit, festzustellen, ob K’toren oder D’toren Exceptions schmeißen können (oder ob sie überhaupt etwas tun). Ich freue mich diesbezüglich schon auf ihre Implementierung von default- und delete-Funktionen in C++0x – das Schlimme ist ja, dass die selber nicht darunter leiden werden, sondern nur wieder irgendeinen Dreck hinhacken, unter dem wir dann leiden.

Verfasst: **20.03.2011, 01:40**

Wieder was gespart … manchmal komme ich mir verrückt vor

Code: Alles auswählen

// Bytecode of "sampleFromInterpolatedVertex" in the sprite shader's source code, compiled for "ps_5_0" with June
//	2010 SDK compiler on highest optimization level; all unneeded data stripped.
static builtIn::CUnsignedInteger1Byte const spritePixelShaderBytecode[] = {
	0x44, 0x58, 0x42, 0x43, 0x67, 0x43, 0xA6, 0xCD, 0x62, 0xDB, 0x62, 0xDD, 0xD0, 0xB6, 0xC3, 0xE1,
	0xB1, 0xB5, 0xC7, 0xF4, 0x01, 0x00, 0x00, 0x00, 0x40, 0x01, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
	0x2C, 0x00, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0xB8, 0x00, 0x00, 0x00, 0x49, 0x53, 0x47, 0x4E,
	0x50, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x0F, 0x00, 0x00, 0x00, 0x44, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00, 0x00, 0x53, 0x56, 0x5F, 0x50,
	0x6F, 0x73, 0x69, 0x74, 0x69, 0x6F, 0x6E, 0x00, 0x54, 0x65, 0x78, 0x63, 0x6F, 0x6F, 0x72, 0x64,
	0x00, 0xAB, 0xAB, 0xAB, 0x4F, 0x53, 0x47, 0x4E, 0x2C, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
	0x08, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x53, 0x56, 0x5F, 0x54,
	0x61, 0x72, 0x67, 0x65, 0x74, 0x00, 0xAB, 0xAB, 0x53, 0x48, 0x45, 0x58, 0x80, 0x00, 0x00, 0x00,
	0x50, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x6A, 0x08, 0x00, 0x01, 0x59, 0x00, 0x00, 0x04,
	0x46, 0x8E, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x5A, 0x00, 0x00, 0x03,
	0x00, 0x60, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x58, 0x18, 0x00, 0x04, 0x00, 0x70, 0x10, 0x00,
	0x01, 0x00, 0x00, 0x00, 0x55, 0x55, 0x00, 0x00, 0x62, 0x10, 0x00, 0x03, 0x32, 0x10, 0x10, 0x00,
	0x01, 0x00, 0x00, 0x00, 0x65, 0x00, 0x00, 0x03, 0xF2, 0x20, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x45, 0x00, 0x00, 0x8B, 0xC2, 0x00, 0x00, 0x80, 0x43, 0x55, 0x15, 0x00, 0xF2, 0x20, 0x10, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x46, 0x10, 0x10, 0x00, 0x01, 0x00, 0x00, 0x00, 0x46, 0x7E, 0x10, 0x00,
	0x01, 0x00, 0x00, 0x00, 0x00, 0x60, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x00, 0x00, 0x01
};
static_assert(320 == sizeof(spritePixelShaderBytecode), "sprite pixel shader bytecode incomplete");

(Verrückt nicht, weil ich die Shader vorkompiliere und ihren Bytecode statisch im Programm speichere; das mache ich schon seit Monaten – verrückt, weil ich diese Shader gerade eben tatsächlich noch optimiert habe damit der Bytecode 100 B kleiner wird.)

Verfasst: **20.03.2011, 19:57**

Mein Kram lässt sich 15 % besser packen, wenn ich von meinen Texturen die Dateierweiterung .ctx weglasse (und dann nur noch die vier Buchstaben, die ich zum Identifizieren des Inhalts nutze, als Dateierweiterung habe). Der Grund ist, dass Ultra7z die Kompressionsmethode nach Dateierweiterung aussucht – vorher wurden R8G8B8A8_UNORM_SRGB- und R8G8B8A8_SNORM-Texturen mit der gleichen Methode gepackt, aber ihr Kompressionscharakter ist so unterschiedlich, dass sie sich getrennt deutlich besser quetschen lassen. 15 % für vier Buchstaben – es sind immer die Details.

Verfasst: **20.03.2011, 20:06**

Ich würde gerne mal die Vision hinter deiner Engine und deinen Optimierungen kennen :) du hast doch bestimmt ein Spiel im Kopf oder?

Verfasst: **20.03.2011, 20:15**

Nein, da gibt es keine Vision außer einer kleinen, entropiefreien Insel bestmöglichen Programmtextes. Aber wenn ich (in geschätzten 15 Jahren) so weit bin, dass man tatsächlich was Spielbares implementieren kann, ziehe ich mit dir den Open Realtime Battle Simulator hoch.

Direkt weitergejammert:
http://www.heise.de/newsticker/meldung/ ... 11087.html
Java in der Raumfahrt … was soll schiefgehen? Etwa das nicht IEEE 754-konforme Hochpropagieren von Gleitkommafehlern zu Ausnahmen, das so schon eine Ariane zum Absturz gebracht hat?…

… wenn sie es auch noch in ihren Nuklearsprengköpfen verwenden bin ich hier aber sowas von weg

Verfasst: **20.03.2011, 21:00**

Wenn ich IEEE-754-Zahlen benutze, Mist baue und alle weiteren Berechnungen dadurch kaputt sind (oder eben einen best-effort service bieten), kriege ich keine Exceptions. Wenn ich Allokationen durchführe, Mist baue und alle weiteren Berechnungen dadurch kaputt sind, kriege ich bad_alloc. Und dann sag doch bitte einmal, warum Exceptions nun konsequent sind.

Verfasst: **20.03.2011, 22:08**

Krishty hat geschrieben:Open Realtime Battle Simulator

mein herz blutet immer noch, dass da kein projekt läuft :) ach wie schön wäre das :) c++ engine mit jvm anbindung für logik ^^

Verfasst: **20.03.2011, 22:32**

Er hat Java gesagt.

Verfasst: **20.03.2011, 22:36**

naja neben Java hätte man auch gleich noch Lisp (Clojure), Python, Ada, Ruby und Co. dabei. Da sollte eigentlich jeder was finden http://en.wikipedia.org/wiki/List_of_JVM_languages klar geht das auch mit mono, aber ich glaube die jvm geschichten sind etwas robuster, außerdem gibts für java einfach immer noch wesentlich mehr kram.

Verfasst: **20.03.2011, 22:56**

Krishty hat geschrieben:Java in der Raumfahrt … was soll schiefgehen? Etwa das nicht IEEE 754-konforme Hochpropagieren von Gleitkommafehlern zu Ausnahmen, das so schon eine Ariane zum Absturz gebracht hat?

java ist wenigstens wartbar und übersichtlich ^^

Verfasst: **20.03.2011, 23:04**

height = math.Fixpoint.add(heightGetter.getHeight().asMeasurable<LENGTH>(UNIT_METERS), mapTracer.getGroundHeight(positionLogger.getCurrentPosition()).asFixpoint().asMeasurable<LENGTH>(UNIT_METERS).inUnit(UNIT_FEET);

Verfasst: **21.03.2011, 00:55**

Ich finde das ist lesbar. Es ist zwar nicht kurz, aber übersichtlich und wartbar. Besser als chaos mit überladenen operatoren und komischen casts.

Verfasst: **21.03.2011, 11:57**

Verfasst: **21.03.2011, 12:00**

Verfasst: **21.03.2011, 14:42**

Trotz LTCG sind Release-Rebuilds bei mir viermal so schnell wie Debug-Builds; in erster Linie wegen der fehlenden Multi-CPU-Kompilierung. Wenn ich an Headern arbeite, teste ich deshalb immer nur an voll optimierten Builds und ärgere mich im Fehlerfall, weil keine assert()s gegriffen haben. Das ist doch scheiße.

Verfasst: **21.03.2011, 15:02**

Warum sollten Debug-Builds nicht parallel kompilierbar sein? Entweder habe ich Dich missverstanden oder Dir sind die ernsthaften Jammermöglichkeiten ausgegangen.

Verfasst: **21.03.2011, 15:06**

5>cl : Command line warning D9030: '/Gm' is incompatible with multiprocessing; ignoring /MP switch
Man kann nur entweder Multi-Processor Compilation oder Enable Minimal Rebuild haben :/
Aber wo du es schon ansprichst: Lohnt sich Enable Minimal Rebuild überhaupt noch oder kann man das MPC in Core i7-Zeiten bedenkenlos opfern?

Nachtrag: Ich bemerke schleichend, dass ich mir die Frage durchs Jammern bereits selber beantwortet habe -.-

Verfasst: **21.03.2011, 15:24**

Ich denke, Du kannst /Gm knicken. Bringt nicht mehr wirklich den Gewinn, wenn man dafür Parallel Build opfern muss.

Verfasst: **21.03.2011, 15:26**

Krishty hat geschrieben:Java in der Raumfahrt … was soll schiefgehen? Etwa das nicht IEEE 754-konforme Hochpropagieren von Gleitkommafehlern zu Ausnahmen, das so schon eine Ariane zum Absturz gebracht hat?…

Ariane 5 ist abgestürzt weil eine Pfeife bei der ESA aus Performance-Gründen das Exception-Handling von Ada deaktiviert hat und der Code kopflos von Ariane 4 übernommen wurde. Ohne dir zu nahe treten zu wollen, aber ich kenn hier auch jemanden der gern mit solchen schmutzigen Performance-Hacks hantiert... ;) Aber zugegeben, ist auch etwas anderes, das aus Interesse in 'nem Hobby-Projekt zutun als damit ein 300 Millionen Euro Spielzeug in die Luft zu blasen...

Aber auf Java möcht ich das auch nicht einfach sitzen lassen, die NASA arbeitet z.B. an einem Model-Checker für Java (http://javapathfinder.sourceforge.net/). Und Beweise in sicherheitskritischen Systemen sind immer so 'ne Sache. Eigentlich total wichtig und sinnvoll, aber praktisch normalerweise kaum sinnvoll durchführbar und da kommen Sprachen wie Java einem gegenüber C und Konsorten schon sehr entgegen.

ZFX + Developia

Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread