|
|
|
|
|
|
|
|
|
|
|
|
|
|
ich benutze zum Kopieren richtig großer Datenmengen ja eher Sync-Tools wie rsync oder robocopy. So kann ich begonnene Durchläufe fortsetzen, wenn sie aus irgendeinem Grund abgebrochen sind.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Der Anwendungsfall, dass Geometrien nich unbedingt 2D und mit euklidscher Distanz sind? Das halte ich für ein Gerücht.
Auch lösen sie hier kein notwendigerweise "extrem simples" Problem. Und sie geben dir sogar Beispiele dafür.
Man mag vielleicht kritisieren dass Boost überhaupt Geometrie implementiert, aber wenn man's schon implementiert, dann doch bitte gescheit.
| |
Ack.
Tendentiell würde ich sogar sagen, dass nicht-euklidische Geometrien/Distanzen wichtiger ist als beliebige Dimensionen. Da aber letzteres einfach und ersteres nötig ist... kann man beides einbauen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
ich benutze zum Kopieren richtig großer Datenmengen ja eher Sync-Tools wie rsync oder robocopy. So kann ich begonnene Durchläufe fortsetzen, wenn sie aus irgendeinem Grund abgebrochen sind.
| |
Erstellt rsync nicht auch erst eine Liste aller Dateien bevor es anfängt etwas zu tun? Ich seh häufiger mal "file has vanished" Meldungen wenn ich z.B. Maildirs kopiere.
|
|
|
|
|
|
|
|
|
|
|
Interessant. Ich verwende in der Regel fuer gross Kopieroperationen einfach cp -ar oder rsync -aAX oder packe sogar vorher alles in ein Archiv. Es funktioniert einfach und zuverlaessig.
Ich war sogar mal im Quellcode der Coreutils und habe mich ueber den relativ grossen Umfang und Aufwand in cp gewundert. Angesichts der viele verschiedenen Faktoren ist da aber wohl schlichtweg der realen Komplexitaet geschuldet. Habe mich damals mit der Effizienz beim einfachen Kopieren beschaeftigt von Dateien mit C, C++ und Java beschaeftigt.
| |
I browsed the net for other peoples' experience with copying many files and quickly decided that cp would do the job nicely. | |
Made my day 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 12.09.2014 10:55]
|
|
|
|
|
|
|
|
|
die erde ist eine kugel, schon vergessen? anwendungsfälle += mapping
datenbanken benötigen distanzmaße für so ziemlich alles. anwendungsfälle += datenbanken
und ich wette es gibt noch viel mehr anwendungsfälle
das war mal wieder en typischer traxer.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von flying sheep am 12.09.2014 11:01]
|
|
|
|
|
|
|
|
|
C++ + Boost == Tracer mag es nicht 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von flying sheep
die erde ist eine kugel, schon vergessen? anwendungsfälle += mapping
das war mal wieder en typischer traxer.
| |
nein, dass war ein typischer "ihr" bei dem ihr nicht die essence versteht.
die versuchen ein problem zu erlegen, welches es so in kaum einer codebase gibt. wenn man wie z.b. im dem von dir angesprochenen fall einer DB solche berechnungen machen will, dann macht man das nicht über eine solche "generische" implementation, sondern über eine spezielle performante.
das gleiche gilt für fast alle fälle, in denen man mit diesen sachen rechnet.
der kram, den dieser code ausspuckt ist einfach hoffnungslos lahm und fehleranfällig. davon abgesehen verlangsamt eher die buildzeit eines projektes um mehrere 100%, weil die metaprogrammierung einfach mit das langsamste, was man beim kompilieren hat, überhaupt ist.
wenn ich solche sachen so poste, dann geht es mir bei den sachen in 99% der fälle nicht um die grundlegende idee, dass würde ich entsprechend schreiben, sondern um die art wie es umgesetzt wurde/wird. die wiederum ist in diesen fällen häufig so abstrus und konstruiert, dass es dafür einfach keine berechtigten gründe gibt. das ist hierbei eben genau der fall.
nutzt man diesen code, dann erreicht man damit sehr viele dinge:
- man macht den code viel unleserlicher als er vorher war (und als programmierer liebt man sowas doch einfach, wenn man den hinterher warten muss)
- man macht seinen compile vorgang wesentlich langsamer (auch auf schnellen rechnern)
- man macht seinen code fehleranfälliger
- etwaige compile meldungen können kaum noch nachvollzogen werden (die schönen 200 seitigen template compile error meldungen)
- man erreicht eine suboptimale runtime performance, weil man ja versucht mit einer kanone eine mücke zu erlegen (hat in der geschichte des programmierens nie positive resultate gebracht)
- macht den code nicht debugbar (ja, templates zu debuggen ist nicht so wirklich gut möglich, wenn diese andere templates "instanzieren")
alles in allem ist metaprogrammierung ein tool welches sehr vorsichtig und sperrlich eingesetzt werden sollte.
eine konkrete implementation ist einer generischen durch templates erstellten immer vorzuziehen. diese erlegt wenn "richtig" gemacht nämlich in einem zug alle oben genannten probleme und kann in aller regel sehr viel schneller geschrieben und verstanden werden.
---
merkt man langsam, dass ich aus dem alter raus bin, dass ich einfach nur code schreiben will und es mich nicht interessiert was danach damit passiert?
jeder der jetzt zu dem thema sage "traxer und boost... typisch" sollte sich mal selber fragen, ob er solchen code schonmal pflegen musste und ob das so eine tolle erfahrung war. ebenso solltet ihr euch mal fragen, ob ihr code, den ihr pflegen musstet/müsst, besser kurz und kaum nachvollziehbar oder ausführlicher und lesbar und damit verständlich sein soll.
ich habe mich für lieber etwas ausführlicher und dafür verständlich entschieden.
vielleicht hilft es euch dabei, wenn ihr mal über diese frage nachdenkt:
| | | ist code dafür da, vom menschen oder vom compiler gelesen zu werden? | |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Interessant. Ich verwende in der Regel fuer gross Kopieroperationen einfach cp -ar oder rsync -aAX oder packe sogar vorher alles in ein Archiv. Es funktioniert einfach und zuverlaessig.
Ich war sogar mal im Quellcode der Coreutils und habe mich ueber den relativ grossen Umfang und Aufwand in cp gewundert. Angesichts der viele verschiedenen Faktoren ist da aber wohl schlichtweg der realen Komplexitaet geschuldet. Habe mich damals mit der Effizienz beim einfachen Kopieren beschaeftigt von Dateien mit C, C++ und Java beschaeftigt.
| |
I browsed the net for other peoples' experience with copying many files and quickly decided that cp would do the job nicely. | |
Made my day
| |
Bei den GNU Coreutils hat mich eher gewundert, dass viele Programme nur wenig Code haben. ls hat iirc <1000 Zeilen, da hätte ich allein aufgrund der etlichen Optionen mehr erwartet, bspw.
|
|
|
|
|
|
|
|
|
|
|
|
Traxer, ich hab manchmal das Gefühl, dass du in einer Blase lebst, wo alles schön und perfomant und von Hand geschrieben wird und der Programmierer hingeht und Algorithmen immer selber schreibt (wegen der Effizienz) und eigene, perfekt zugeschnittene Datenstrukturen für alles baut.
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Bei den GNU Coreutils hat mich eher gewundert, dass viele Programme nur wenig Code haben. ls hat iirc <1000 Zeilen, da hätte ich allein aufgrund der etlichen Optionen mehr erwartet, bspw.
| |
Ist halt nicht so over-engineeret wie so manches C++-Gedöns.
|
|
|
|
|
|
|
|
|
|
Tja, dafür schreibe ich gerade eine schöne touch-friendly GUI in QML und kann transparent C++ und QML mischen.
#beatthis
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
ich benutze zum Kopieren richtig großer Datenmengen ja eher Sync-Tools wie rsync oder robocopy. So kann ich begonnene Durchläufe fortsetzen, wenn sie aus irgendeinem Grund abgebrochen sind.
| |
Ich hätte frei nach Bauchgefühl ebenfalls auf rsync gesetzt. Die Lektüre der manpage bzgl. Hardlinks hat mich aber eher verwirrt als alles andere, gerade in Bezug auf Unterbrech-/Fortsetzbarkeit. Naja, immerhin sind keine Daten flöten gegangen, von daher...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von ShinyDoofy am 12.09.2014 12:28]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Traxer, ich hab manchmal das Gefühl, dass du in einer Blase lebst, wo alles schön und perfomant und von Hand geschrieben wird und der Programmierer hingeht und Algorithmen immer selber schreibt (wegen der Effizienz) und eigene, perfekt zugeschnittene Datenstrukturen für alles baut.
| |
tue ich leider nicht.
ich versuche aber sehr dafür zu sorgen, dass code den ich verbrochen habe lesbar und wartbar ist, genauso wie sauber läuft und das tut was er soll.
gleichzeitig hoffe ich jedes mal darauf, wenn ich code vorgesetzt bekomme, dass die andere person das ebenso sieht. das ist leider bisher bei zu wenigen der fall.
ein schönes beispiel für nett zu lesenden code ist übrigens die UE4 oder auch, ob man es glauben will oder nicht, der NT kernel.
schön daran ist, dass man den code zu sehr grossen teilen komplett ohne doku lesen kann und alleine anhand von expressiven namen recht umfangreiche und/oder komplexe sachen nachvollziehen kann.
aus der sicht muss ich leider auch sagen, dass die meissten OSS codes einfach ziemlicher ranz sind, was die lesbarkeit angeht. man sieht hier halt leider sehr häufig, dass die leute einfach nur "spass" daran hatten irgendwie irgendwas zu verbrechen ohne dabei rücksicht darauf zu nehmen, dass andere das vielleicht mal irgendwann warten/nutzen müssen.
das ist der part wo dann hobbycoder und programmierer aufeinandertreffen.
nebenbei sehe ich mich inzwischen eher im 3. stadium der entwicklung des programmierers. (mal sehen, wer damit was anzufangen weiss)
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
nutzt man diesen code, dann erreicht man damit sehr viele dinge:
- man macht den code viel unleserlicher als er vorher war (und als programmierer liebt man sowas doch einfach, wenn man den hinterher warten muss)
- man macht seinen compile vorgang wesentlich langsamer (auch auf schnellen rechnern)
- man macht seinen code fehleranfälliger
- etwaige compile meldungen können kaum noch nachvollzogen werden (die schönen 200 seitigen template compile error meldungen)
- man erreicht eine suboptimale runtime performance, weil man ja versucht mit einer kanone eine mücke zu erlegen (hat in der geschichte des programmierens nie positive resultate gebracht)
- macht den code nicht debugbar (ja, templates zu debuggen ist nicht so wirklich gut möglich, wenn diese andere templates "instanzieren")
| |
Du wiederholst diese Argumente gerne und oft und ich habs mir bisher gespart zu widersprechen, aber nachdem ich gestern schon nicht an mich halten konnte:
Dass Metaprogrammierung Einzug erhalten hat in C++ ist meines Erachtens das beste was dieser Sprache überhaupt passieren konnte. Es ist damit endlich möglich einigermaßen generischen Code in dieser Sprache zu schreiben. Ja, die Art und Weise wie man ihn in C++ schreiben muss mag ein wenig nervig sein und ziemlich verbos, was dem Performanceansatz geschuldet ist, aber der hat ja auch seine Vorteile. Das wird sicherlich besser.
Metaprogrammierung in C++ ist anders als "normales" C++. Jemand der "normales" C++ lesen kann kann nicht unbedingt C++ mit Metaprogrammierung lesen. Hier spielen andere Paradigmen eine Rolle. Das macht den Code jedoch nicht per se unleserlich. Es ist aber ein gewisser Lernprozess nötig.
Im Gegenteil: Ich würde behaupten er wird sogar wesentlich leserlicher, weil er über Rauschen abstrahiert. Damit ist es möglich Code zu schreiben der einfach keine Bugs hat, weil man garnicht so viel Platz hat Bugs einzubauen. Außerdem zwingt diese Art der Programmierung den Programmierer dazu, sich echte Gedanken zu machen über die Frage, was er eigentlich erreichen will und macht es weniger erfolgreich einfach mal "drauf los zu programmieren". Finde ich eine gute Sache.
Ja, die Compiler sind noch etwas scheisse was die Fehlermeldungen angeht, aber mit Verweis auf ghc möchte ich betonen, dass das nicht so sein muss, hier müssen halt noch ein paar Jährchen Erfahrung eingeholt werden. Ja, das Debuggen ist entsprechend etwas schwieriger, aber da man weniger debuggen muss, ist das ja nun auch kein so großes Problem. An der Stelle möchte ich auf Eigen verweisen, bei dem ein bisschen Metaprogrammierung zum Einsatz kommt und dessen Code ich in der Benutzung nicht sonderlich unangenehm zu debuggen finde. Wie's in der Entwicklung ist weiß ich nicht, hab nicht dran rumgehackt.
Bleibt die Performence. Die "Compile Performence" überhaupt als eine Metrik zu verwenden um sich zu entscheiden welchen Code man schreibt halte ich für extrem fragwürdig, aber auch hier gilt, dass man einfach seltener kompilieren muss wenns tendentiell mit weniger Debugging funktioniert. Ich würde soweit gehen zu sagen, dass wenn die Zeit die das Kompilieren dauert den Arbeitsfluss wesentlich beeinträchtigt, dann ist mit hoher Wahrscheinlichkeit irgendwas am Arbeitsfluss verbesserungswürdig.
Was sich mir nicht so ganz erschließt ist warum ein Feature das zur Compilezeit relevant ist zur Laufzeit für schlechtere Performance sorgt. Schlaue Implementierungen werden die Gelegenheit offen lassen, kritischen Code spezialisiert zu implementieren und außerdem genauso wie bei Code ohne Metaprogrammierung generelle Performanceeinbußen vermeiden.
Heißt das jetzt, dass man alles generisch implementieren sollte? Natürlich nicht, denn es ist ein Werkzeug wie jedes andere (außer Regexes vielleicht, die ja universell einsetzbar sind). Aber man sieht an der Standardbibliothek wie viel eine Sprache gewinnen kann, wenn sie generische Bibliotheken besitzt.
| |
alles in allem ist metaprogrammierung ein tool welches sehr vorsichtig und sperrlich eingesetzt werden sollte.
| |
Bitte nicht.
---
Vielleicht ein echtes Argument gegen Metaprogrammierung in C++: Es ist noch ein Komplexitätsbaustein der den Einstieg nicht leichter macht. Das ist richtig und ein Problem. Spezifisch ein Problem von C++, das eine Sprache ist, die unerhört schwer erlernbar ist. Aber ich fürchte, dass wenn eine Sprache so viel Freiheit und Eigenverantwortlichkeit wie C++ bieten will, sie vergleichsweise kompliziert sein muss. Aber wahrscheinlich nicht so kompliziert wie C++.
|
|
|
|
|
|
|
|
|
|
|
außerdem haben sie ja häufige usecases abgekürzt, also könnte traxer auch einfach schreiben:
| |
| Code: |
model::d2::point_xy<int> p1(1, 1), p2(2, 2);
std::cout << "Distance p1-p2 is: " << distance(p1, p2) << std::endl; |
|
ich finde den quickstart-guide statt der design-rationale zu lesen einen erheblich nützlicheren ansatz, das ist nämlich eine viel performantere nutzung von programmierer-zeit. aber man könnte sich dann halt auch nicht drüber auslassen.
ich finde das hier halt nunmal keine komplizierte sache, da man den typedef ja nur einmal machen muss und dann wunderbar wiederbenutzen:
| |
| Code: |
typedef boost::geometry::model::point
<
double, 2, boost::geometry::cs::spherical_equatorial<boost::geometry::degree>
> spherical_point;
spherical_point amsterdam(4.90, 52.37);
spherical_point paris(2.35, 48.86);
double const earth_radius = 3959; // miles
std::cout << "Distance in miles: " << distance(amsterdam, paris) * earth_radius << std::endl; |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
aus der sicht muss ich leider auch sagen, dass die meissten OSS codes einfach ziemlicher ranz sind, was die lesbarkeit angeht. man sieht hier halt leider sehr häufig, dass die leute einfach nur "spass" daran hatten irgendwie irgendwas zu verbrechen ohne dabei rücksicht darauf zu nehmen, dass andere das vielleicht mal irgendwann warten/nutzen müssen.
das ist der part wo dann hobbycoder und programmierer aufeinandertreffen.
| |
Als wäre das in Firmen anders.
|
|
|
|
|
|
|
|
|
|
|
Außerdem ist Meta-C++ echt ziemlich mächtig, ein immer wieder gutes Beispiel ist das neue connect in Qt 5, was mittels Metaprogrammierung viele Arten von Laufzeitwarnung (etwa "Signal und Slot passen nicht") zu Compilezeitwarnung gewandelt hat.
Compilezeiten sehe ich lediglich bei TDD als Problem, aber das praktiziert aus diversen Gründen (nicht nur die längeren Compile-Run-Zyklen) kaum jemand bei C++.
|
|
|
|
|
|
|
|
|
|
|
|
Gibt's da ein gutes Tutorial, was mir binnen 10 Minuten erklärt, was Meta Programmierung in C++ ist und wie es geht? Ich scheine zu der Gruppe zu gehören, die das nicht kann und fühle mich jetzt schlecht.
|
|
|
|
|
|
|
|
|
|
|
Ein wenig fies an Metaprogrammierung in C++ ist, dass zum einen Metacode und normaler Code relativ stark durchmischt sind - was man aber trennen kann, wie es in der verlinkten Boost-Doku auch gemacht wird.
Mit Google findet man ein paar Uniskripte, C++-Metaprogrammierung (Hoffmann Gerhard) sieht gut aus, ist aber älter.
|
|
|
|
|
|
|
|
|
|
|
|
Kein Grund sich schlecht zu fühlen. Ein bisschen suchen empfielt "C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond", dessen Einleitung eigentlich ganz nett aussieht auf den ersten Blick. Ansonsten gibt der Wikiartikel auch eine sehr kurze Übersicht und es gibt das ein oder andere Tutorial.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Gibt's da ein gutes Tutorial, was mir binnen 10 Minuten erklärt, was Meta Programmierung in C++ ist und wie es geht? Ich scheine zu der Gruppe zu gehören, die das nicht kann und fühle mich jetzt schlecht.
| |
Du musst dich nicht schlecht fuehlen!
Ein gutes und sehr tief gehendes Buch zu C++ kann theoretisch erwaehnen, dass man mit C++ auch Metaprogrammierung betreiben kann und belaesst es dabei.
Metaprogrammierung und Template-Metaprogrammierung sind nur zufaellig in C++ eingezogen, als generische Programmierung mit Templates zur Sprache hinzugefuegt wurden. C++ ermoeglicht offiziell imperative, prozedural, modulare, objektorientierte (Vererbung und Polymophie) und generische (Templates) Programmierung. Durch letzteres ist indirekt auch die Metaprogrammierung an Bord gekommen, war so nicht gedacht, aber tut auch keinem weh.
Fragen wir mal den Spracherfinder?
Ich musste ernsthaft im Sprachstandard nachsehen um festzustellen, dass Metaprogammierung auch wirklich erwaehnt wird.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 12.09.2014 13:54]
|
|
|
|
|
|
|
|
|
Achso, das sind nur Templates.
|
|
|
|
|
|
|
|
|
|
|
Nein.
Templates selbst sind keine Funktionen oder Klassen. Stattdessen erzeugt der Compiler anhand der uebergebenen konkreten Typangaben erst die entsprechenden Funktionen und Klassen zur Compile-Time, diesen Prozess nennt man Instanzierung. Damit ist die generische Programmierung mit C++ und die Verwendung der Container und Ihrer Algorithmen moeglich. In meinen Augen ist die groesste Leistung von C++ womoeglich die Nutzung der generische Programmierung und nicht die Verbreitung der Objektorientierung.
Der entscheidende Zusammenhang ist, dass der Compiler hier zur Compile-Time los laeuft und erstmal anfaengt Code zu erzeugen. Und damit war dann, die Template-Metaprogrammierung moeglich, weil der Compiler zur Laufzeit arbeiten ausfuehren konnte, Compile-Time-Execution eben.
Die Template-Metaprogrammierung ist turingvollstaendig und damit kannst du Code bei der Kompilierung ausfuehren also compile-time execution. Es ist ziemlich verrueckte Scheisse. Dieser Absatz in der Wikipedia erklaert das noetigste fuer einen Ueberblick.
Mein Wissen ueber Template-Metaprogrammierung geht auch nicht viel tiefer, wobei in meiner Erinnerung die Codebeispiele in der Wikipedia frueher eingaengiger waren. Das heisst nicht, dass es mich nicht interessiert, nur die Metaprogrammierung vernuenftig betrachtet nicht wichtig.
Ich habe nicht vor mich in das Wortgefecht ueber und unter mir einzubinden. Fehler koennen gerne korrigiert werden.
Ein Hinweis zu Java:
Java implementiert generische Programmierung mit Generics voellig anders. Stattdessen werden die konktreten Typen nur gewrapped (Stichpunkt: Autoboxing). Generics aus Java haben technisch mit Templates aus C++ nichts zu tun! Demzufolge gibt es keine Metaprogrammieung mit Java. Und generische Programmierung macht mit Java auch wenig Spass, waehrend sich die generische Programmierung in C++ fuer mich auch immer schoen anfuehlt.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 12.09.2014 14:22]
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Es ist damit endlich möglich einigermaßen generischen Code in dieser Sprache zu schreiben.
| |
nicht die domäne von C++.
nimm eine sprache, bei der es sauber umgesetzt ist. eiffel z.b.
du verwendest einen hammer um dir die fingernägel zu schneiden.
| | Zitat von B0rG*
was dem Performanceansatz geschuldet ist, aber der hat ja auch seine Vorteile. Das wird sicherlich besser.
| |
haben wir ja die letzten 30 jahre gesehen, in wie weit sich das gebessert hat. gar nicht.
| | Zitat von B0rG*
Metaprogrammierung in C++ ist anders als "normales" C++. Jemand der "normales" C++ lesen kann kann nicht unbedingt C++ mit Metaprogrammierung lesen. Hier spielen andere Paradigmen eine Rolle. Das macht den Code jedoch nicht per se unleserlich. Es ist aber ein gewisser Lernprozess nötig.
| |
du bist nicht agil kompatibel. 
du musst als programmierer immer (!!!) davon ausgehen, dass leute mit weniger erfahrung deinen code lesen, verstehen und warten können. machst du das nicht, gehörst du nicht in den welt des programmierens (dem tipp part). (das trifft leider sehr viele der "programmierer")
| | Zitat von B0rG*
Im Gegenteil: Ich würde behaupten er wird sogar wesentlich leserlicher, weil er über Rauschen abstrahiert.
| |
und mehr boilerplate hinzufügt, als sonst je nötig gewesen wäre. als dämliches beispiel, schau dir nochmal das beispiel von der von mir verlinkten boost seite an. da sieht man wunderbar, wie man aus etwas einfach zu verstehendem etwas spagehttiähnliches macht. (das FSM möge mir vergeben. )
| | Zitat von B0rG*
Damit ist es möglich Code zu schreiben der einfach keine Bugs hat, weil man garnicht so viel Platz hat Bugs einzubauen.
| |
wenn du das wirklich glaubst und so nutzt, dann hoffe ich, dass dein code niemals seinen weg in irgendwas kritisches finden wird.
grundlage des programmierens: ES GIBT KEINEN BUGFREIEN CODE!
das einzige, was du mit templates in dem fall erreichst, ist dass die bugs versteckt vor sich hin leben.
| | Zitat von B0rG*
Außerdem zwingt diese Art der Programmierung den Programmierer dazu, sich echte Gedanken zu machen über die Frage, was er eigentlich erreichen will und macht es weniger erfolgreich einfach mal "drauf los zu programmieren". Finde ich eine gute Sache.
| |
dir ist schon klar, dass der sinn hinter generischer programmierung gerade der ist, dass du den kram für alles und nichts einsetzen kannst?
wenn du ein konkretes problem hast, dann lös es mit dem minimalsten aufwand und auf dem best möglichen weg.
alles andere führt nicht zum ziel. hab ich in der praxis schon ausprobiert, es macht die sachen schlechter nicht besser.
| | Zitat von B0rG*
Ja, die Compiler sind noch etwas scheisse was die Fehlermeldungen angeht
| |
richtig, seit dem es C++ und templates gibt. möchte ich betonen.
| | Zitat von B0rG*
hier müssen halt noch ein paar Jährchen Erfahrung eingeholt werden.
| |
weite 30?
dann kann ich es also noch nen jahr nutzen, bevor ich in rente.. oh wait, die gibts da ja nicht mehr...
| | Zitat von B0rG*
Ja, das Debuggen ist entsprechend etwas schwieriger, aber da man weniger debuggen muss, ist das ja nun auch kein so großes Problem.
| |
du hast schonmal in der realität an mehr als nem "hello world" gearbeitet?
sorry, aber debugging ist so dermassen essentiell, dass es da einfach keinen weg drum rum gibt, wenn das projekt umfangreicher wird.
andernfalls können wir ja auch alle wieder zu vim und gcc auf der konsole zurück, so ohne IDEs und co.
| | Zitat von B0rG*
Die "Compile Performence" überhaupt als eine Metrik zu verwenden um sich zu entscheiden welchen Code man schreibt halte ich für extrem fragwürdig
| |
wie schon gesagt, nicht agil kompatibel.
wenn meine software ca. 15 minuten auf einem 8 core system mit 16 GB RAM kompiliert, dann ist das sehr wohl ein gewisses kriterium.
irgendwann soll der kram nämlich noch mal fertig werden.
ich bin da bei weitem nicht der einzige, der einzige der das problem hat. frag mal leute bei epic, dice und co, wie lange die so für einen compile vorgang brauchen.
| | Zitat von B0rG*
aber auch hier gilt, dass man einfach seltener kompilieren muss wenns tendentiell mit weniger Debugging funktioniert.
| |
ich sage dir noch einmal aus der praxis heraus, dass diese aussage der grösste bullshit aller zeiten ist.
erzähl das bitte niemandem.
| | Zitat von B0rG*
Ich würde soweit gehen zu sagen, dass wenn die Zeit die das Kompilieren dauert den Arbeitsfluss wesentlich beeinträchtigt, dann ist mit hoher Wahrscheinlichkeit irgendwas am Arbeitsfluss verbesserungswürdig.
| |
richtig, ich brauch mehr hardware und weniger boilerplate, der das compilen verlangsamt. oh, waaiiit das bedeutet weniger templates.
so in der realität muss man leider mit endlichen ressourcen klar kommen.
dazu kommen dann halt agile herangehensweisen und nicht so ein müll wie das v-modell oder so.
schonmal was von XP gehört? ich meine übrigens nicht das von MS.
| | Zitat von B0rG*
Was sich mir nicht so ganz erschließt ist warum ein Feature das zur Compilezeit relevant ist zur Laufzeit für schlechtere Performance sorgt.
| |
weil das template zeugs immer erstmal in konkreten C++ code übersetzt wird, von da aus wird es in vielen fällen in ASM gewandelt, was dann effektiv übersetzt und gelinkt wird.
problem hier ist, dadurch das du generischen code gebaut hast, kann der compiler nur begrenzt optimieren, was zu schlechterer ressourcen nutzung führt. er muss an verschiedenen stellen zudem mehr als nur die gewollte menge code generieren was zu code bloat führt und dadurch zu mehr zeugs, was irgendwie bewegt werden will / muss.
im tollsten fall, der MS compiler ist das klasse drin, baut dir das teil da noch nen paar vtables mit ein und lässt dich fröhlich durch tabellen springen.
| | Zitat von B0rG*
Schlaue Implementierungen werden die Gelegenheit offen lassen, kritischen Code spezialisiert zu implementieren
| |
du, dafür müsste man den code recht ausgiebig debuggen und profilen können. das ist das, was du gerade noch sagtest, dass du das nicht haben willst und das das eines DER argumente für metaprogramming ist.
du findest die problemfälle nur, wenn du sie debuggen und profilen kannst. wenn dir der kram im vorfeld klar ist, dann gibt es keinen grund irgendwas in dem bereich via generischem code zu bauen.
nebenbei beherrscht nach wie vor nicht jeder compiler die spezialisierung von templates und auch nicht alle die spezialisierung von templates mit mehr als einem parameter.
mal ganz zu schweigen davon, dass einige fälle sich nicht so ohne weiteres spezialisieren lassen, wenn sie z.b. platformabhängig (nicht zwangsläufig auf die hardware bezogen) sind.
| | Zitat von B0rG*
Heißt das jetzt, dass man alles generisch implementieren sollte? Natürlich nicht, denn es ist ein Werkzeug wie jedes andere
| |
oh, erzähl das mal so verschiedenen leuten, die könnten glatt meinen das du komisch bist.
| | Zitat von B0rG*
(außer Regexes vielleicht, die ja universell einsetzbar sind)
| |
ich hoffe das war ironisch gemeint. |:
| | Zitat von B0rG*
Aber man sieht an der Standardbibliothek wie viel eine Sprache gewinnen kann, wenn sie generische Bibliotheken besitzt.
| |
man sieht an ihr auch, wie viele bugs man plötzlich in seinem programm findet, wenn man sie verwendet. ganz zu schweigen von tollen performanceeinbussen, weil leute metaprogramming anstelle von simplen generischen containern bauen wollten.
wie war das noch? ah richtig, wir zerlegen den string in seine einzelnen code points um ihn dann in einem baum zu speichern, weil damit kann man ja einige (ca. 0.5 % der realität) operationen beschleunigen.
oder auch, wir bauen einen vector, der bei jeder op erstmal speicher anfordert den vorhandenen kopiert, jedes objekt neu über einen copy konstruktor neu anlegt und dann den alten vernichtet.
wo war das noch gleich gut? oh, WAIT das ist ja alles STL!?
gut, dass das teil standardisiert ist... moment, dass war nur da interface, nicht die implementation.
falls irgendwer den kram sehen möchte -> dinkumware ist euer ziel. ihr wollt nicht wissen, was damit gebaut wurde und wird. es würde zu viel erklären.
| | Zitat von B0rG*
Spezifisch ein Problem von C++, das eine Sprache ist, die unerhört schwer erlernbar ist.
| |
das ist kein C++ spezifisches problem, dass ist ein soziales problem.
programmierer im allgemeinen denken nicht richtig. sie denken nur an ihren eigenen code, nicht an den rest der da noch so drum rum existiert.
was meinst du, warum so viele firmen in richtung agile methoden gehen? weil die projekte zu komplex werden, weil die wünsche sich während der entwicklung ändern, weil fehler (sowohl code, als auch planung) gefunden und entfernt werden müssen.
viele sind leider, häufig durch Unis, nicht mit der praxis vertraut und meinen sie können ihr zeugs aus der Uni so 1:1 in der praxis durchziehen. das funktioniert nicht!
die meissten leute dort machen ihr zeugs um was auf papier zu haben, nicht um das wirklich zu verstehen und sich den restlichen, den praxisteil, selber bei zu bringen.
die Unis lehren in fast allen fällen zeugs, was mitte der 90er aktuell war. wir sind inzwischen 20 jahre weiter. der kram ist, abgesehen von bestimmter theorie, überholt und irrelevant bis schlicht falsch.
(hier beende ich diesen teil des ausflugs mal, weil das zu weit vom thema ab geht. kurz gesagt, Unis und programmierung passen nicht zusammen, weil sich die eine seite zu schnell und die andere zu langsam bewegt. das ist ein soziales problem, können wir auch gerne noch mal drüber reden, aber besser bei nem realen treffen mit mehreren leuten, damit es spass macht.)
| | Zitat von B0rG*
Aber ich fürchte, dass wenn eine Sprache so viel Freiheit und Eigenverantwortlichkeit wie C++ bieten will, sie vergleichsweise kompliziert sein muss. Aber wahrscheinlich nicht so kompliziert wie C++.
| |
richtig, denn dann wären wir wieder bei C.
|
|
|
|
|
|
|
|
|
|
|
50 % Wahrheit und 50 % Mumfelgrumpfel.
Soll ich da jetzt ACK oder NAK drunter schreiben?!
--
Kennt hier jemand das qbs? Experimentelles Build-System (u.a. Qt Creator wird damit gebaut) auf Basis von QML, was keine Makefiles generiert, inhärent parallel arbeitet und Dependencies wesentlich besser versteht (verstehen soll). Klingt interessant. Oh, und ohne Subdirs.
| | | Qbs sees the project as whole and thus does not need to fork itself for subdirectories. Even if only a part of the project is built, the whole build graph is taken into consideration. The problems of recursive make (see [RMCH]) are no more. | |
Irgendwie nerven mich die gelegentlichen Build-Fehler ja schon mit Make/CMake/qmake, wenn man mehrere Subdirs/Projekte mit Abhängigkeiten untereinander hat.
-lasdasdfasd not found.
Ja du Spasti musst halt erst die Bibliotheken und dann die Anwendung bauen!
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 12.09.2014 14:15]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
50 % Wahrheit und 50 % Mumfelgrumpfel. | |
ja genau. das nervt mich jedes mal bei ihm.
offensichtliche unwahrheiten, und dann auch schwarz-weiß-denken wie
| | Zitat von Traxer
| | Zitat von B0rG*
Aber ich fürchte, dass wenn eine Sprache so viel Freiheit und Eigenverantwortlichkeit wie C++ bieten will, sie vergleichsweise kompliziert sein muss. Aber wahrscheinlich nicht so kompliziert wie C++. | |
richtig, denn dann wären wir wieder bei C. | |
ja genau, weil alles, was weniger kompliziert ist als ein moderner BMW mit bordcomputer gleich ein fahrrad ist. analoge autos, motorräder und mopeds existiern nicht.
|
|
|
|
|
|
|
|
|
|
|
Analoge Autos existieren ja wirklich nicht mehr... 
|
|
|
|
|
|
|
|
|
|
|
|
Hoffentlich kommt Seite 100 schnell und wir koennen ueber Counter-Strike:Global-Offensive reden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Analoge Autos existieren ja wirklich nicht mehr...
| |
du sprichst von nicht-servo-schaltung? ich hab kein auto, deshalb kamen mir solche gedanken nicht 
ich meinte nur ein auto, bei dem nix über einen zentralen computer läuft. mit handlötbarer lichtanlage und so
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |
|
