Jammer-Thread

[DerAlbi]

Das ist der Grund, warum OpenSource so kläglich scheitert. Es macht keinen Spaß es zu benutzen. Ohne Kommerzialisierungshintergrund fehlt der gesamte Schritt "was die kunden eigentlich wollen" in der Entwicklung. Die Leute checken das nicht: Benutzer wollen NICHT kompilieren und NICHT Fehler suchen und KEINE Einarbeitung. Ich will, dass es Funktioniert.

[Chromanoid]

Das ist bei Java aber anders. Da sind es mMn eher die fehlenden Geschäftsmodelle. Das ist bei C++&Co. natürlich auch ein Hauptgrund warum das so lästig ist. http://java.dzone.com/articles/open-sou ... -need-more fand ich ganz spannend.

Die Qualität von Open Source Bibliotheken im Java Bereich ist wirklich sehr überzeugend. Die Einfachheit Bibliotheken einzubinden ist genial. In der Hinsicht haben es Java Projekte viel einfacher zugänglich zu sein. Ich nehme an, das liegt an der ganzen Infrastruktur, die mir bei Java in der Hinsicht schlichtweg viel besser erscheint. Maven hat Welten bewegt.

[Ingrater]

Der Visual Studio Debugger ist manchmal echt nutzlos. Wenn eine Hardware-Exception im crt-deinit fliegt (also z.B. ein Nullpointer Zugriff in einem Destruktor einer globalen Variablen) hält er nicht an sondern das Programm stirbt einfach weg. Ohne Meldung, ohne alles, einfach tot, exit code 0. Wenn man sich dann wundert warum nur die Hälfte der Destruktoren aller globalen Variablen aufgerufen wird kann man ne Weile suchen...

[antisteo]

Das ist der Grund, warum OpenSource so kläglich scheitert. Es macht keinen Spaß es zu benutzen. Ohne Kommerzialisierungshintergrund fehlt der gesamte Schritt "was die kunden eigentlich wollen" in der Entwicklung. Die Leute checken das nicht: Benutzer wollen NICHT kompilieren und NICHT Fehler suchen und KEINE Einarbeitung. Ich will, dass es Funktioniert.

Bei Endnutzer-Produkten mag das sein (wobei da wiederum Distributoren wiederum das kommerzielle Rädchen im Getriebe sind), aber bei Entwickler-Bibliotheken sind die Benutzer gleichzeitig die Autoren. Es gab nur selten Fälle, wo ich keine einigermaßen gute Lib für eine Aufgabe gefunden habe. Und war das mal nicht der Fall, hat man eben seine Lib geschrieben oder die beste der schlechten Libs gefixt.

[Krishty]

Die Leute checken das nicht: Benutzer wollen NICHT kompilieren und NICHT Fehler suchen und KEINE Einarbeitung. Ich will, dass es Funktioniert.

Bei Endnutzer-Produkten mag das sein (wobei da wiederum Distributoren wiederum das kommerzielle Rädchen im Getriebe sind), aber bei Entwickler-Bibliotheken sind die Benutzer gleichzeitig die Autoren.

Die Entwickler sind Autoren ihrer Programme, nicht der Bibliotheken, die sie einbinden. Wenn ich eine Bibliothek erstmal "fixen" und dafür halbwegs verstehen muss, lasse ich den Scheiß und lade mir die nächste. Und am Ende lande ich dann bei boost, wo sowieso schon alles drin ist und man keine Pfade einstellen muss sondern einfach einen Header #includet und draufloskompiliert, und danach ist das Programm fünfundzwanzig Mal größer als vorher, aber es läuft. Wenn ich mir Schamgefühl und Schluckreflex abgewöhnt habe, liefere ich das aus. Wenn nicht, betrachte ich das als Proof of Concept, kopiere die nützlichen Stellen raus, befreie sie von dem nutzlosen Ballast, und liefere es *dann* aus. Aber cmake-basierter bau-selber-stell-selber-ein-check-selber-deine-fixes-ein-Müll verrottet so oder so.

Und was die Geschäftsmodelle angeht: Das ist eine schöne Erklärung, warum bestimmten kommerzielle aber kostenlose Projekte Open-Source-Projekten die Kunden abziehen. Geschäftsmodelle sorgen aber NICHT dafür, dass Bibliothken anwenderfreundlicher werden, sondern dafür, dass Bibliotheken mehr Geld aus Anwendern rausquetschen indem sie sie mit exzentrischen Abhängigkeiten zu Tode knuddeln wenn man sie einmal eingebunden hat. Da sehe ich keinen Mehrwert für die Menschheit.

END_RANT

[Chromanoid]

Geschäftsmodelle sorgen aber NICHT dafür, dass Bibliothken anwenderfreundlicher werden, sondern dafür, dass Bibliotheken mehr Geld aus Anwendern rausquetschen indem sie sie mit exzentrischen Abhängigkeiten zu Tode knuddeln wenn man sie einmal eingebunden hat. Da sehe ich keinen Mehrwert für die Menschheit.

Naja, irgend wovon müssen die Leute, die wirklich an den Bibliotheken arbeiten, schließlich leben, oder? Zumindest in der Jetztzeit in der eigentlich noch gilt, wer kein Geld verdient, soll auch nicht essen, kann ich mir kaum größere Projekte ohne finanzielle Unterstützung vorstellen. Neben Vendor-Lockins gibt es bei Open Source ja auch noch den Ansatz, alles so schwer benutzbar zu machen, dass man sich mindestens irgendein Buch, einen Experten oder eine Schulung kaufen muss. Da sind mir neue Geschäftsmodelle lieber, die irgendwie ohne solche Tricks auskommen.

[Jonathan]

Das ist bei Java aber anders. Da sind es mMn eher die fehlenden Geschäftsmodelle. Das ist bei C++&Co. natürlich auch ein Hauptgrund warum das so lästig ist. http://java.dzone.com/articles/open-sou ... -need-more fand ich ganz spannend.

Die Qualität von Open Source Bibliotheken im Java Bereich ist wirklich sehr überzeugend. Die Einfachheit Bibliotheken einzubinden ist genial. In der Hinsicht haben es Java Projekte viel einfacher zugänglich zu sein. Ich nehme an, das liegt an der ganzen Infrastruktur, die mir bei Java in der Hinsicht schlichtweg viel besser erscheint. Maven hat Welten bewegt.

Also meiner Meinung nach gehört schlicht alles was bei C++ mit kompilieren zu tun hat auf den Müll geschmissen und entsorgt. Ich meine, bei Java (ich habe echt nicht viel damit gemacht, aber meiner Erfahrung nach) lädst du dir eine Bibliothek als *.jar, kopierst sie in einen Standard Ordner, schreibst im Code irgendein "use Mylib" und die Sache läuft. Achja und es kompiliert in 2 Sekunden. SOWAS bräuchte C++.

Ich meine, alleine dass man so viele Targets hat. Debug/Release, 32/64bit, in allen Kombinationen. Und das ist das mindeste. Und dann liefert irgendein dämliches Projekt wieder Build-Files aus, bei denen alle 4 dll's exakt gleich heißen. Das man heute irgendetwas anderes als OS-Code überhaupt noch dynamisch linkt ist doch schon grober Unfug (Sowohl meiner Festplatte als auch meiner DSL Leitung ist es egal, ob die exe jetzt 10 oder 100MB hat, alleine schon weil die Assets eh 4GB groß sind. Aber unerklärliche Crashs, weil ne falsche DLL geladen wurde, die nerven tierisch). Wieso kann man nicht, keine Ahnung, irgend so eine Art zwischen Code generieren, den der Compiler dann ganz am Ende für deine Einstellung (Debug/Release, 32/64bit) zu ner .exe linkt? Wieso müssen Header inkludiert werden, so dass die Compilierzeit exponentiell steigt? Wieso muss ich eine Bibliothek inkludieren und linken, und wieso muss ich ständig für beides Pfade irgendwo einstellen?
Mit Sicherheit gibt es jetzt tausend kleine Detail-Probleme, aber es stecken doch wirklich helle Köpfe hinter C++, die müssen doch im Stande sein, eine vernünftige Lösung zu finden. Es kann doch absolut niemand mit der C++-Welt in der wir leben zufrieden sein. Wenn ich nur überlege, wie viele Stunden Arbeitszeit täglich verschwendet werden, weil wieder irgendein Mist nicht kompiliert, das ist doch kein Zustand.

C++ als Sprache finde ich geil. Man kann so viele so tolle und so elegante Dinge damit machen. Alleine die Möglichkeit, derartig viele Dinge garantieren zu können, und der Compiler schon viele Fehler finden kann, wenn man vernünftig programmiert hat, sind einfach genial. Aber sobald man mit dem Schreiben fertig ist und man seine Anwendung haben möchte, ist C++ eine absolute Qual und ich habe noch keine Sprache gesehen, die dieses Problem schlechter löst. Und das ist doch einfach nur traurig.

END_RANT

nope, in diesem Thread werde ich niemals aufhören zu meckern :D Nicht bis all meine Forderungen erfüllt werden, und bis dahin werde ich stündlich meine Unschuldige CPU in einen SEGFAULT laufen lassen.

[Spiele Programmierer]

Ingesamt kann ich da eigentlich fast zu stimmen. :!:

den der Compiler dann ganz am Ende für deine Einstellung (Debug/Release, 32/64bit) zu ner .exe linkt?

So eine Art Zwischencode hast du bei LLVM/Clang. Debug/Release sollte da schon gehen, aber mit plattformübergreifenden Zwischencode wird es schwierig. Dafür gibt es eine einfache traurige Antwort: Präprozessor
Aber auch zum Beispiel "sizeof(T*)" ist unterschiedlich.

Ich glaube übrigens, das statisches Linken häufig sogar die Größe insgesamt deutlich reduzieren könnte.
Durch Optimierungen, also zum Beispiel auch das Entfernen von ungenutzten Funktionen, wäre die große Exe meistens wahrscheinlich viel kleiner als die Summe aller Dlls. LGPL ist da häufig noch ein Problem.

[Krishty]

Visual C++ mit Link-time Code Generation erzeugt ebenfalls eine Zwischenrepräsentation, die dann beim Linken zu Maschinenbefehlen konvertiert (und optimiert) wird. Das ist der Grund, warum die temporären Dateien mit LTCG häufig viele hundert Megabytes groß sind. Das ist dann aber natürlich Closed Source und nicht so dynamisch wie LLVM-Assembly.

Man schafft es auch leider nicht, alles zwischen 32- und 64-Bit zu abstrahieren. Das Exception Handling ist z.B. unter Windows komplett anders. Und es gibt in CPUs nunmal noch andere Arten von Exception Handling als das von C++.

[Chromanoid]

Ich meine, bei Java (ich habe echt nicht viel damit gemacht, aber meiner Erfahrung nach) lädst du dir eine Bibliothek als *.jar, kopierst sie in einen Standard Ordner, schreibst im Code irgendein "use Mylib" und die Sache läuft. Achja und es kompiliert in 2 Sekunden. SOWAS bräuchte C++.

Naja, selbst runterladen muss man das eigentlich auch nicht mehr. Nur um mal zu zeigen wie bequem das geht:

Man lege in einem Ordner eine Datei namens build.gradle an:

Code: Alles auswählen

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

Und dann kann man, sofern die IDE Gradle unterstützt, mit den o.g. Dependencies loslegen. Sourcen, Doku und transitivie Abhängigkeiten werden automatisch runtergeladen.

Maven Central ist (mit rund 96000 Artefakten) wohl das größte öffentliche Artefakt-Repository, man kann sich aber auch beliebige andere Repositories konfigurieren.

Bei Java hat man natürlich trotzdem noch Probleme, wenn verschiedene Abhängigkeiten andere untereinander inkompatible Abhängigkeiten benötigen, aber da gibt's ja Lösungen für.

Gruselig an der Geschichte ist, wie schnell man sich da irgendwelche Abhängigkeiten ins Projekt holt. Aber das ist wohl eher eine Frage der Disziplin.

Damit man am Ende nicht alles was man nicht benutzt trotzdem ausliefert, gibt's Tools wie Proguard, die alles unbenutzte rausschmeißen - das klappt offensichtlich nur richtig, wenn man keine Klassen anhand von String-Namen instantiiert. Solche Tools gibt's bei Gradle übrigens als Plugins und können wie normale Abhängigkeiten deklarativ automatisch über ein Artefakt-Repository in den Build-Prozess eingebunden werden.

[dot]

Ich versteh ehrlich gesagt nicht, was alle am Buildprozess von C++ immer auszusetzen finden. Ja, er ist komplexer als das, was man in den sog. "modernen" Sprachen antrifft. Aber das ist doch gerade, was die Sprache C++ auch ausmacht. Mit der Komplexität kommt ein wesentlich mächtigeres Werkzeug. Die Flexibilität, die der "C++ Buildprozess" (der Standard gibt dazu btw. nichts vor) einem bietet, finde ich bei keiner anderen Sprache, zumindest keiner mit einem simpleren Buildprozess. "With great power comes great responsibility" und so...

[Spiele Programmierer]

Ich versteh ehrlich gesagt nicht, was alle am Buildprozess von C++ immer auszusetzen finden.

Das ist sehr einfach: Ich brauche in C++ Stunden eine Lib einzubinden. In C# geht es in 1er Minute.
Um mein C++ Projekt zu kompilieren brauche ich 3 Minuten, um mein C# Projekt zu kompilieren sind es 3 Sekunden.

Das Problem ist wahrscheinlich gerade auch, dass "der Standard" nichts dazu sagt. C++ selbst mag nicht für alles all zu viel dafür können, aber die Sprache ist nun mal der Leidtragende, bzw. der Programmierer, der in der Sprache entwickelt. Meiner Meinung nach fehlt einfach ein einheitliches Buildsystem für alle Compiler. Und Module.

Ich bin übrigens auch der Meinung, dass C++ zu komplex ist. Ich behaupte, es wäre möglich eine Sprache zu konstruieren, die die selbe oder höhere Mächtigkeit besitzt, allerdings weniger gesprächig oder unlogisch ist. Tatsächlich gibt es viele Ansätze in diese Richtung, leider meistens noch unreif oder wieder mit gravierenden Einschränkungen(zb. Garbage Collector) die aber nichts mit den Vereinfachungen zu tun haben, die ich mir wünschen würde.

[Chromanoid]

Ich versteh ehrlich gesagt nicht, was alle am Buildprozess von C++ immer auszusetzen finden. Ja, er ist komplexer als das, was man in den sog. "modernen" Sprachen antrifft. Aber das ist doch gerade, was die Sprache C++ auch ausmacht. Mit der Komplexität kommt ein wesentlich mächtigeres Werkzeug. Die Flexibilität, die der "C++ Buildprozess" (der Standard gibt dazu btw. nichts vor) einem bietet, finde ich bei keiner anderen Sprache, zumindest keiner mit einem simpleren Buildprozess. "With great power comes great responsibility" und so...

Was verstehst Du hier unter Flexibilität? Komplexität hat nicht unbedingt was mit Mächtigkeit zu tun. Ein Buildprozess ist doch viel mehr als nur ein ausführbares/einbindbares Artefakt zu erzeugen: Reproduzierbarkeit, Dependency Management, Tests, Ressourcenverarbeitung, Distributionserzeugung, Releasevorgang und Versionskontrolle, Codeanalyse usw. Ich baue fast gar nichts mit C++-Toolchains, aber ich glaube, zumindest an der Stelle kann sich C++ eine Scheibe vom Java-Umfeld abschneiden.

[TDK]

Es ist nicht die Sprache, es ist auch nicht das Build-System.
Es sind die Leute dahinter, die es absichtlich falsch anwenden, oder Unerfahrene, oder die, die es unbedingt besser wissen.

Kein Verständnis, weil:
1x für Visual Studio egal-wie-alt-oder-neu und 1x für das Mac-System.
1x für x64, 1x für Alteingesessene x86er
1x DLL, 1x Statisch und Mini-Bibliotheken auch gleich als include-cpp auf Definition
und leicht umzusetzen.

So funktionieren mMn muss-Geld-bringen oder gute Bibliotheken.
Da interessiert der Hauptmarkt und nicht das xy-Sonderproblem.

[Chromanoid]

Es ist nicht die Sprache, es ist auch nicht das Build-System. Es sind die Leute dahinter, die es absichtlich falsch anwenden, oder Unerfahrene, oder die, die es unbedingt besser wissen.

Sprachen und Build-Systeme werden für Menschen gemacht. Wenn Menschen an Software scheitern, dann liegt das zu einem großen Teil auch an der Software, weil sie schlichtweg ihr Ziel verfehlt.

[kimmi]

Ich versteh ehrlich gesagt nicht, was alle am Buildprozess von C++ immer auszusetzen finden.

Das ist sehr einfach: Ich brauche in C++ Stunden eine Lib einzubinden. In C# geht es in 1er Minute.
Um mein C++ Projekt zu kompilieren brauche ich 3 Minuten, um mein C# Projekt zu kompilieren sind es 3 Sekunden.

Das Problem ist wahrscheinlich gerade auch, dass "der Standard" nichts dazu sagt. C++ selbst mag nicht für alles all zu viel dafür können, aber die Sprache ist nun mal der Leidtragende, bzw. der Programmierer, der in der Sprache entwickelt. Meiner Meinung nach fehlt einfach ein einheitliches Buildsystem für alle Compiler. Und Module.

Ich bin übrigens auch der Meinung, dass C++ zu komplex ist. Ich behaupte, es wäre möglich eine Sprache zu konstruieren, die die selbe oder höhere Mächtigkeit besitzt, allerdings weniger gesprächig oder unlogisch ist. Tatsächlich gibt es viele Ansätze in diese Richtung, leider meistens noch unreif oder wieder mit gravierenden Einschränkungen(zb. Garbage Collector) die aber nichts mit den Vereinfachungen zu tun haben, die ich mir wünschen würde.

Ich benutze C++ auf Embedded-Geräten und hasse den berg von Optionen, die Komplexität des Builds da etc. .

Allerdings spiel gerade auf dem Bereich C++ dort dann auch seine Stärken aus: Immerhin kann man mit dem komplexen Build Probleme umgehen, die ein kaputtes BSP ausgelöst hat.

Für normale Anwendungen wäre ein normales "Maven" für C++ aber toll :).

Gruß Kimmi

[Schrompf]

Assimp - Boolsche Operationen für den IFC-Loader. Wir ähm... nähern uns dem Endergebnis.

[Schrompf]

Hab mir mal so ne Art Explosionsdarstellung gebastelt, indem ich einfach den Mesh vor der Clipping-Operation neben das Ergebnis kopiert habe. Das ergibt eine Kaskade von Zwischenergebnissen, bei denen man genau erkennen kann, ab wo der Wahnsinn einsetzt. Und siehe: das Problem entsteht an der Stelle, wo irgendwelche Punkte, Kanten oder Flächen ganz knapp auf den jeweiligen Schnittkanten oder Schnittebenen liegen. My personal descend into madness:

[Krishty]

Erinnert mich an meine CAD-Zeiten :) Viel Spaß, das wird die Hölle. Ich persönlich attackiere sowas nur noch mit verlustfreier Integermathematik auf eng begrenzten Räumen, aber das ist noch viel tieferer Abstieg in den Wahnsinn.

[Schrompf]

Und *eigentlich* gäb's das auch schon fertig und von Leuten, die mehr Ahnung als ich haben. Nur darf ich das der Lizenz wegen nicht benutzen. Und die schon integrierte ClipperLib arbeitet zwar mit Integern und sehr stabil, aber arbeitet nur in 2D und scheitert demzufolge an Polygonen, die senkrecht auf dem Bounding Polygon stehen.

Alles Mist :-(

[Sternmull]

Vor rund 10 Jahren hab ich mich auch mal an CSG-Operationen versucht. Das hat im Grunde auch super funktioniert... bis eben auf die Stellen an denen die begrenzte Präzision der Gleitkommazahlen dazu geführt hat das es das eben nicht mehr tut :D Damals hab ich das halbherzig damit bekämpft das ich solche Situationen festgestellt hab und die Operanden dann minimalst zufällig verschoben/gedreht hab bis es erfolgreich durchlief. Letzten Endes hab ich das Projekt dann aber verworfen weil ich keinen praktikablen Weg zu einer vernünftigen Lösung gefunden hab.

Aber mit dem Problem stehst du nicht allein da. Die guten alten Quake- und Unreal-Leveleditoren hatten in vielen Situationen auch immer ihre Probleme wenn sie die boolschen Operationen über ihre BSP-Trees auszuführten. 3D-Max hat das auch Ewigkeiten nicht gelöst bekommen und hat am Ende eine externe Bibliothek eingekauft. Blender verwendet "carve", aber die steht unter der GPL und hat damit wohl das von dir erwähnte Lizenz-Problem.

[Krishty]

Ich habe die gesamte Visual-C++-Runtime in meinem Projekt überflüssig gemacht. Bis auf pow(), das habe ich noch nicht selber implementiert. Und natürlich ist das der komplizierteste Brocken Mathematik, den man in der Standardbibliothek findet.

Un’ nu’? Eine Woche hinsetzen, eigenes pow() implementieren, und den Sieg feiern? Hätte ich früher sofort gemacht. Aber ich wollte mich eigentlich bessern und produktiver werden. Also mit anderen Sachen weitermachen und die CRT drinlassen, nur für die eine Referenz? Wäre das Kapitulation oder Gnade? :(

[Schrompf]

Kann man das Problem nicht googeln? Im alten Quake2-Code nachschauen, wie die das implementiert haben?

[Krishty]

Doch, es gibt eine fertige Implementierung auf Apple Open Source. Nur bin ich nicht unbedingt die Art Mensch, die das rüberkopiert und damit zufrieden ist (ganz ab von der Lizenz). Und das ist auch nicht gerade wenig Code, und kein einfacher, also viel Platz für Probleme.

Wie gigantisch komplex das Ding ist, zeigt die statische CRT: pow() ist in der 64-Bit-Version 5,7 KiB groß. MEHR ALS EINE GANZE MOTHERFUCKING SPEICHERKACHEL AN BEFEHLEN. Die Konstanten für die Polynome noch NICHT mitgezählt. Damit ist es die fünftgrößte Funktion in meiner ganzen Exe; nur ein paar Bytes hinter der Enumeration aller Joysticks und Gamepads! Ob ich mir sowas wirklich aufbürden soll?

Als ich mein eigenes cos() geschrieben habe, hatte Visual C++ schon ein völlig nonsensiges jmp __ImageBase eingefügt. Falls jemand nicht versteht, was das bedeutet: Ich auch nicht. Das springt einfach zum Anfang der EXE-Datei, interpretiert ihn als Maschinentext, und crasht damit ziemlich schnell. WTF. Das ist kein gutes Omen.

[Chromanoid]

Meine Lieblingsquelle für Nachrichten aus der MMO-Gaming-Szene ist eingestellt worden :( das weiß ich zwar schon länger, aber eben habe ich mal wieder aus Gewohnheit auf das Lesezeichen geklickt...
http://massively.joystiq.com

[Krishty]

Mein Programm verbraucht mit statisch eingebundener CRT 20–50 % mehr Speicher als mit CRT-DLL. Wtf, schon wieder. Dabei benutze ich komplett eigene Speicherverwaltung. Eine ganze Woche lang habe ich den Arbeitssatz optimiert, bis auf einzelne Allokationen, und dann sowas. Es ist doch wirklich zum kotzen.

[Helmut]

Ich musste gerade auch die Visual-C++-Runtime doch wieder in eine DLL einbinden, weil diese anscheinend für v-tables benötigt werden. Irgendwie schade, zumal die DLL per Hook in jeden Prozess geladen wird.

[Krishty]

warning: unreferenced label 'https'

Denkt mal drüber nach m[

[xq]

@^ Find ich schön :)

[Krishty]

Copy-Paste ist kaputt. Systemweit. Ich kann kopieren, aber nirgends mehr irgendwas einfügen. Drag'n'Drop mit STRG klappt noch. WTF WTF WTF

Ich darf jetzt aaaaalles schließen und speichern (inklusive angefangener Blog-Posts) und neustarten und es in 15 min nochmal versuchen. WIE KANN SOWAS KAPUTTGEHEN