ZFX + Developia

Ich weiß ich krieg gleich wieder auf die Mütze, aber mich würde wirklich mal interessieren, was C++ Freunde mal abgesehen von Java als Abhängigkeit und Groovy als Sprache von Gradle halten. Für Java läuft das Buildsystem schon echt gut und ich benutze es recht gerne. Vielleicht hat ja jemand mal Lust das ganze mit seinem Projekt auszuprobieren: http://www.gradle.org/docs/current/user ... aries.html

BTW das Gradle für C++ ist noch nicht produktionsreif, aber der generelle Gradle Ansatz gefällt mir. Vielleicht hat ja der ein oder andere Spaß dran, das ganze mal auszuprobieren.

Ich benutze eigentlich für so ziemlich alles ganz gern Rake. Hat so weit ich das beurteilen kann einen ähnlichen Ansatz wie Gradle (regelbasiert, mächtige Hostsprache) ist aber komplett domänen-agnostisch. Damit hab ich unter anderem auch meine Diplomarbeit gebaut.

Zurück zum Jammern: Ich versuche seit gestern Abend ein Arch-Linux auf meinem Rechner zu installieren, scheitere aber irgendwie daran, dass der Bootloader rumspackt weil dämlicher Raid-Controller und Linux sich irgendwie beißen ...

Das Inlining von Visual C++ ist soooooo lächerlich. Ich habe in meinen String-Funktionen eine Indirektion hinzugefügt (A() ruft B() ruft C() statt A() ruft C()). Durch Inlining ist der Maschinentext exakt identisch. AUßER, dass nun eine Mathe-Funktion, die fünf Module weiter liegt und deren Aufrufer nicht im Entferntesten mit Strings hantieren, nun nicht mehr geinlinet wird. WTF?!

Haben die da eine Reserve an Inline-Aufrufen, und wenn die überschritten ist, wird nicht mehr geinlinet?!

Be careful when using std::string

TL;DR: std::string is responsible for almost half of all allocations in the Chrome browser process; please be careful how you use it!

In the course of optimizing SyzyASan performance, the Syzygy team discovered that nearly 25000 (!!) allocations are made for every keystroke in the Omnibox. We've since built some rudimentary memory profiling tools and have found a few issues: [...]

25.000 Allokation für Eingabe eines Buchstabens in Chromes Adresszeile. Unvorstellbar wie die zustandekommen, selbst wenn überall Strings kopiert werden.
Damit muss selbst Chrome ein gigantisches Fraktal von miserabelster Software sein. Und die Kommentare im Thread nehmen einem jeden Glauben an Softwareentwicklung. :-/

Ach, ihr mit euren überhöhten Ansprüchen. Seid doch froh, dass Chrome nicht in Java oder C# geschrieben ist!

Das erste kommerzielle Projekt, dem ich mich annehmen musste, führte übrigens eine sechsstellige Zahl Allokationen pro Mausbewegung durch. Irgendwie muss man doch rechtfertigen, den Kunden eine neue CPU kaufen zu lassen! Außerdem sind das alles Mikrooptimierungen, die sich nicht auszahlen. Darum war es auch nur um den Faktor 50 schneller, als ich fertig war.

Naja, Chrome hat da die Ausrede, dass es ein Rudel Datenbankanfragen stellen dürfte, wenn der Nutzer was in der Adressleiste eingibt. Aber gerade die sollten doch deutlich besser optimiert sein.

Allgemein sind das schon gute Gründe zum Jammern, finde ich.

Entschuldige; bei mir fehlte das Sarkasmus-Tag. Natürlich ist das für mich, der jede Allokation aus inneren Schleifen rauslutscht, eine einzige Katastrophe.

seit kurzem hab ich schwierigkeiten mit dem zfx board. wenn ich was posten will, flieg ich raus :( ... zur sicherheit kopiere ich inzwischen meine beiträge. (4ter versuch)

Bei mir hat es die ganzen Tage nichtmal ordentlich geladen (aber das war auch mit anderen Sites so)

AAh, ich dachte das wär nur bei mir so, ich benutz nämlich Opera :-)
Ja, der schmeißt einen irgendwie immer zwischendurch raus, ich hab Glück wenn ich mal auf "Vorschau" drücken kann ohne dass ich ausgeloggt werde. Ist aber bei mir schon länger so.

Das Laden der Seite (zfx.info) dauert bei mir auch voll lange, entweder der DNS call oder die Domain-Weiterleitung dauern ewig.
Direkt über die IP gehts nicht so leicht, das scheint der Admin verhindern zu wollen 8-)

Ich habe einen Game of Thrones "Welches Haus bist du?" Psychotest gemacht, und raus kam Haus Bolten. DAFUQ??

Also ich lese hier immer stündlich mit und habe weder mit Timeouts, noch mit 404s, nicht einmal mit Log-Outs zu kämpfen.

Ich habe es mit Mikroallokationen derart übertrieben, dass der 32-Bit-Page-Heap nicht mehr ausreicht. Ausgerechnet ich.

Mää schon 2015 ... wo is die Zeit geblieben?

Ist nach dem Preprozessor ca. 58.000 Zeilen lang (VS 2013).

Jetzt ratet mal wo std::shared_ptr wohnt.

Sorgen des Durchschnittsprogrammierers

Eigenes Framework, eigene CRT, eigene Windows-Header ftw!

1.2 s Kompilierzeit für ein komplettes Spiel, und der einzige fremde Header, der inkludiert wird, ist <stdarg.h> weil ich zu faul für eigenes va_list war :P

Die Windows-Header hab ich bei uns jetzt auch größtenteils rausgeworfen und die 2-3 Funktionen einfach selbst deklariert.
Ich bin doch nicht bereit 140k LOC zu includen für die zwei C Funktionen die ich brauche.

Gestern habe ich das mal im größeren Stil profiled und es scheint kaum einen Standard-Header zu geben, der nicht mindestens 50k reinzieht. <ostream>, <vector>, <map>, <string>, alle haben sie tierisch große Abhängigkeiten.

Und ich bin auch nicht sicher ob Precompiled Header da wirklich ne Lösung sind :(

Nur ein Übersetzungsmodul pro Projekt, das die einzelnen Implementierungen #includet, geht auch. Dann hat man die 140k Zeilen nur noch einmal zu viel.

Leider sind wir mittlerweile selbst bei trivialen Dateien bei ca. 16 sec bis die Binary fertig ist (ca. 10 sec compiling und 6 sec linking). Irgendwann macht das keinen Spaß mehr.

Die Probleme kenne ich nur zu gut. :roll:
"std::shared_ptr" darf für mich zwar ruhig schwer zu erreichen sein( :P ), aber ich kenne das Problem nur mit genug Dingen zu gut.
Bei mir trägt es damit auch im erheblichen Maße dazu bei, dass ich eigentlich empfehlenswerte Funktionen kaum einsetze. Bevor ich überhaupt nur einen Gedanken daran zu verschwende nach oben zu scrollen, eine Abhängigkeit mit 60k LoC hinzuzufügen, nur dass ich dann "std::move" oder "std::find_if" schreiben darf.

Wenn ich einen Wunsch in C++ frei hätte... ein neues Buildsystem ohne Includes.
Tipp-Zeit, Nerven und Compile-Zeit sparen.

Ist das Modulsystem nicht endlich standardisiert worden? GCC und Clang können es doch AFAIK schon.

Also mir wäre neu, dass GCC da schon etwas kann.
Es gibt wohl einen Vorschlagzu Module, bis jetzt gibt es im Standard aber nichts. Momentan wohl auch nicht in der Arbeitsversion von C++17.

Ich hoffe nur es kommt wenigstens in C++17. Bis dahin ist noch viel zu lange und soweit ich weiß gab es die Idee schon vor C++11 Zeiten, aber bis jetzt ist nichts daraus geworden.

Stimmt; es war nur Clang. Offenbar kommt es nicht in C++17, sondern ist in einen eigenen TR ausgelagert worden.

Sieh es mal so: Mit einem Übersetzungsmodul für ein ganzes Projekt musst du nicht mehr alles doppelt tippen, und wenn Module kommen, verteilst du halt alles in eigene Module.

Übrigens ist das C-Linksystem ein Hammer. Wer auf Methoden und Subklassen verzichten kann, wird damit schon heute glücklich. Einfach struct vor die fremde Datenstruktur und man braucht keine Header mehr. Davon kann C++ nur träumen.

Zum Linksystem: Scheiß auf Resource Files, einfach mit objcopy ne .data section mit meiner resource erstellen und direkt via pointer darauf zugreifen, weil dat ding einfach mit reingelinkt wird. echt schicke Sache ;)

Ansonsten dürfte C++ da echt mal was vertragen

Also es gibt auch Pläne zu C++17, siehe hier:
https://isocpp.org/std/status
http://meetingcpp.com/index.php/br/item ... -core.html

Ein Übersetzungsmodul pro Projekt ist für schwierig. Es gibt zum Beispiel einzelne Dateien mit für sich sehr hohen Compile-Zeiten. Ein Teil des Codes hat auch noch weitere große (Include)-Abhänigkeiten die man nicht vom Header aus überallhin verbreiten muss. Was ich auf jeden Fall mal jetzt aber mal ausprobieren will ist das Gruppieren von Dateien in Compile Units. Das könnte die Sache echt beschleunigen. Ich habe hier doch einige Dateien mit wenig Inhalt. Trotzdem nervig, dass man auch das noch von Hand machen muss.

In C kann man aber doch dann genauso wenig wie in C auf die Member der Struct zugreifen. Und alle Funktionendeklarationen müsste man auch von Hand kopieren. Das stelle ich mir außerdem gefährlich bei Änderungen vor. Ich weiß ja ehrlich gesagt nicht so ganz, was da so viel besser ist. ;-)

EDIT:
@MasterQ32
Mache ich inzwischen auch so ähnlich. Auch Shadercode von OpenGL und was so anfällt.
Ich erstelle die Objektdateien allerdings momentan mit NASM. (Ich habe mir dazu auch ein Custom Build Tool in Visual Studio eingerichtet)

MasterQ32 hat geschrieben:Zum Linksystem: Scheiß auf Resource Files, einfach mit objcopy ne .data section mit meiner resource erstellen und direkt via pointer darauf zugreifen, weil dat ding einfach mit reingelinkt wird. echt schicke Sache ;)

In einen anderen Abschnitt? Dann kann man redundante Daten doch gar nicht aliasen. Gimp hat eine Funktion, die ein Bild zu einem C-Header exportiert; damit werden die Dateien direkt in den Quelltext geschmissen :P Nur besser nicht mit VC öffnen, die Syntaxhervorhebung geht bei sowas in die Knie …

Spiele Programmierer hat geschrieben:Und alle Funktionendeklarationen müsste man auch von Hand kopieren. Das stelle ich mir außerdem gefährlich bei Änderungen vor.

Dann bekommt man ja unresolved external Symbols …

Ich habe nie ganz den Sinn dahinter verstanden, warum man vorher die Daten in eine gigantische C-Datei umwandelt, um sie dann erst nochmal zu kompilieren. Wahrscheinlich bei großen Dateien auch ein Problem. Da schiebe ich die binären Daten doch lieber direkt ins Zielformat ohne so einen Hack.

In C++ deklariere ich sie einfach als externes Symbol und bekomme einen Zeiger auf die Daten und deren Größe.

Dann bekommt man ja unresolved external Symbols …

Nicht in richtigem C-Code. Dort werden keine Überladungen unterstützt und die Parametertypen nicht ins Name Mangling integriert.

Der Sinn ist, die Abhängigkeiten in der Toolchain zu minimieren. Man hat einfach ein paar Sachen weniger, die auf anderen PCs schiefgehen können. Aber da hatte ich ja das Video mit dem LOC-Vergleich zwischen Vista und Visual Studio noch nicht gesehen :D

Und richtigen C-Code will hier ja niemand; klar. Wir wollen ja schließlich alle auch irgendwo mal Templates. Aber im Gegensatz zu C++, wo zum Aufruf von Foo::method() die gesamte Klassendefinition vorliegen muss, geht method(struct Foo *) ohne Definition von Foo. Da spart man wirklich und das kann man auch in C++. Man muss nur seinen Stil anpassen.

Dafür hat man in der Toolchain dann ein Tool das die Binärdaten in C-Code umwandelt. So den ganz großen Vorteil sehe ich nicht.

Also deine Methode überzeugt mich bisher nicht so. Freie Methoden bieten weniger Übersicht und keine bieten keine gute Auto-Vervollständigung.
Außerdem, wenn ich die Funktionsdeklarationen mitsamt der Klasse jetzt nicht mehr in den Header schreibe sondern überall direkt hineinkopiere, habe ich ja noch extremere Redundanz wie jetzt schon zwischen Header & Source.