Aha, lang ich ja sogar fast richtig. Neg. a hätten ja auch zu nem neg. Index geführt.
Positiv musst du nicht abfangen, da die Bedingung leicht negierbar ist.
Das man seinen Code für die Performance so formuliert hat, wie man es tat, bildet man sich aber auch nur ein, um sich selbst zu blendenEin paar Zeilen vorher setzt du ja z.B. jedes Arrayelement in einer Schleife auf Null.
...also,
Muss man glaub auf Null setzen oder? Nach dem new ist glaub nicht garantiert, dass Nullen drinstehen. Dass man sich selbst blendet, stimmt natürlich
Mit Naturgesetzen kann man nicht verhandeln. --Harald Lesch
Ein Atomkrieg würde die Menschheit auslöschen. Hätte aber auch Nachteile.
Das schon, aber da die Null als Double auch nur aus Nullen besteht, kann man memset nehmen, um das Array zu initialisieren.
Dazu aber gleich die Warnung, dass das in 99% wieder eine verfrühte Optimierung ist, gleich mit memset, memcpy, Pointern statt Arrayzugriffen[i] oder gleich Assembler zu hantieren. Aber da bin ich leider selber sehr anfällig
Aber hoffentlich nicht in C++!Zitat von Ramkhamhaeng
Da macht man besser sowas - Ganz ohne aufruf von new.
Code:#include <vector> std::vector<double> x(ARRAY_SIZE, 0.0) // nochmal neu initialisieren x.assign(ARRAY_SIZE, 0.0);
Civ4 PBEM: 235, 49, 60, 208, 259, 392 - tot, 22, 71, 90, 340 - vernichtet, 53, 132 - überlebt, 166, 294, 378 - gewonnen
Nach dem new bitte das delete nicht vergessen
Ich hatte gestern die freudige Begegnung mit einer hardwarenahen Programmierung mit floats. Die sind manchmal echt doof
Mit floats habe ich wenig zu tun, was ist denn daran doof?
Hat jemand von euch Erfahrung mit dem Bau von Hexkarten im Browser?
Planung war nodejs dafür zu nutzen.
Y Ddraig Goch ddyry cychwyn
Es stört mich nicht, was meine Minister sagen, - solange sie tun, was ich ihnen sage.
(Margaret Thatcher, brit. Politikerin)
Ich kann mir eine Welt vorstellen ohne Krieg, eine Welt ohne Hass. Und ich kann mir vorstellen, wie wir diese Welt angreifen, weil die Typen es niemals erwarten würden.
Twitch - Youtube - Facebook - Twitter
Findest du allgemein statische Typsysteme Mist oder explizit wie es Java macht?
Kann ich nicht bestätigen.Jetzt erst gesehen, aber: Ja, definitiv.
Wenn man dann einmal in der freien Wirtschaft arbeitet, merkt man, dass die Schnittmenge aus Uni und Leben nahezu null ist. Und auch an der bisherigen Diskussion hier merkt man das.
Statische Typsysteme finde ich nicht grundsätzlich schlecht. Dadurch können die meisten Tippfehler schon während der Kompilierung erkannt werden. Auch die Möglichkeit für Überladung von Funktion ist hilfreich, etwas was ich in Python vermisse (was aber auch bald eingeführt ist oder sogar schon in 3.4 drin ist).
Allerdings: Das statische Typsystem darf nicht nur für den Kompiler da sein. Denn der eigentliche Grund für ein statisches Typsystem ist nicht die Vermeidung von Tippfehlern des Programmierers (das ist eher ein Nebeneffekt), sondern das für die instanzierten Objekte genügend Speicherplatz hinterlegt werden kann. Das geht nun mal nicht, wenn nicht der Typ bekannt ist.
Da der Kompiler nicht raten kann, welchen Typ eine Variable im einzelnen haben soll, muss der Programmierer sie angeben. In erster Linie ist die Angabe der Typen nur für den Kompiler da.
Ein Nachteil eines statischen Typsystems besteht in der Schwierigkeit, generische Container zu erstellen. C++ verwendet dafür Templates, Java setzt auf Polymorphie.
Beides hat Nachteile.
Bei Templates hat man oft das Vergnügen, Seitenlange Fehlermeldungen (bezüglich der Kompilation) interpretieren zu müssen. Auch werden dadurch die Implementierung offen gelegt, was das Geheimnisprinzip verletzt. Anderer Nachteil ist das Kompilieren und Linken ansich. Durch die Art, wie Templates implementiert sind, kann sich die Kompilierungszeit und Linkzeit drastisch erhöhen, wenn man selbst keine geeigneten Gegenmaßnahmen ergreift, was nicht immer möglich ist. Und bei fremden Code schon gar nicht.
Der polymorphe Ansatz hat den Nachteil der fehlenden Typsicherheit. Grundsätzlich ist es so, dass Elemente eines Containers den allgemeinsten Typ haben (Object). Wenn man auf die Elemente zugreifen will, muss man einen Typecast machen, um das Element in den Typ umzuwandeln, von dem man glaubt, das das Element ihn hat. Muss aber nicht der Fall sein.
Java hat daraufhin Generics eingeführt, was eine höhere Typsicherheit gewährleistet. Problem an Generics ist wiederrum, das z.B. ArrayList<C> und ArrayList<D> (C und D seien irgendwelche verschiedene Klassen) den gleichen Typ haben. Dadurch ist eine Überladung von Methoden nicht möglich.
Bei Java und C++ merkt man eben, das die generische Komponente erst nachträglich eingeführt wurde, und nun muss man mit den Folgen leben.
Ein anderes Problem mit statischen Typsystemen liegt in der vielen Tipparbeit. Gerade Java tut sich hier negativ hervor. Der Einsatz von Generic kann grausam werden, besonders bei geschachtelten Generic. In C++ hat man wenigstens die Möglichkeit, neue Aliasnamen für Typausdrücke zu geben, selbst für Template-Typen. In Java hingegen tippt man sich die Finger blutig.
Auch die Inkompetenz des Javakompilers lässt einen den Kopf schütteln. Warum zum beispiel muss ich explizit
int x = 42;
schreiben? Das int ist eigentlich unnötig, da rechts des = ein Integer steht, könnte der Kompiler den Typ von x einfach herleiten.
Scala z.B. bietet Typinferenz, Haskell sowieso, und selbst in C++ ist das mittlerweile möglich. Nur der Java-Kompiler ist dumm.
Haskell ist da wirklich ganz gut, weil es Typinferenz und ein polymorphes Typsystem bietet. Beide Sachen machen ein statisches Typsystem viel benutzerfreundlicher.
Java hingegen ist einfach nur ein Beispiel, wie man es nicht machen sollte.
Nicht nur Tippfehler sondern insbesondere Refactoring ist etwas was ich nicht missen möchte
Da gebe ich dir recht. Deshalb sollte man versuchen dies möglichst zu vermeiden.
Natürlich könnte man es weglassen. Der Compiler würde es auch verstehen aber ich als Programmierer möchte auch wissen wo die Variable definiert wurde. Wer sagt mir denn in deinem Beispiel wo die Variable definiert wird? Ist es ein Klassenfeld, eine vererbte Variable, eine lokale Variable, ein Methodenparameter oder was denn nun? Wenn ich sowas sehe dann verschwende ich massig Zeit zurückzuverfolgen wo die Variable herkommt. Das empfinde ich als Hindernis.
Nur bedingt, es hängt viel davon ab wer programmiert und wie er es umsetzt. Das Java nicht perfekt ist, wissen eigentlich alle. Aber ich persönlich kenne keine perfekte Programmiersprache
BTW: irgendwie habe ich Bock mal wieder was mit Prolog zu machen
Das ist aber keine Errungenschaft des Typsystems, sondern des jeweiligen Editors.Nicht nur Tippfehler sondern insbesondere Refactoring ist etwas was ich nicht missen möchte
Kann man nur nicht immer.Da gebe ich dir recht. Deshalb sollte man versuchen dies möglichst zu vermeiden.
Es geht um unnötige Redundanz. Wenn ich beispielsweise schreibeNatürlich könnte man es weglassen. Der Compiler würde es auch verstehen aber ich als Programmierer möchte auch wissen wo die Variable definiert wurde. Wer sagt mir denn in deinem Beispiel wo die Variable definiert wird? Ist es ein Klassenfeld, eine vererbte Variable, eine lokale Variable, ein Methodenparameter oder was denn nun? Wenn ich sowas sehe dann verschwende ich massig Zeit zurückzuverfolgen wo die Variable herkommt. Das empfinde ich als Hindernis.
ArrayList<Integer> v = new ArrayList<Integer>();
dann ist das erste ArrayList<Integer> überflüssig.
Was hat denn der Typ damit zu tun, wo die Variable definiert wurde? Das Problem, das man im Code nicht sofort sieht, woher eine Variable stammt, hat nichts mit dem Typsystem zu tun. Man hat eigentlich keine Probleme, wenn man auf Attribute konsequent über this (Java) zugreift. In Python muss man das automatisch so machen. Methodenparameter wird es i. A. auch nicht soviele geben, als das man die Namen vergessen würde.
Auch ein Vorteil von Typinferenz: foreach-Schleifen. Es ist nicht nötig, den Typ der Laufvariable anzugeben, weil der ja hergeleitet werden kann.
Nur Java ist ziemlich weit weg von perfekt. Da ziehe ich C++ jederzeit vor. Python sowieso.Nur bedingt, es hängt viel davon ab wer programmiert und wie er es umsetzt. Das Java nicht perfekt ist, wissen eigentlich alle. Aber ich persönlich kenne keine perfekte Programmiersprache
Java hat im Vergleich zu C++ einiges besser gemacht. Aber auch vieles schlechter: Exception-Handling, Interfaces, keine Operatorüberladung, kaputtes Objektsystem usw.
Da muss ich nochmal einhaken.
Eine Vielzahl von Refactorings eines Editors basiert auf einem statischen Typsystem.
Vieles, wie Code-Redundanz, nimmt dir eine ordentliche IDE (Eclipse) ab. Deswegen sind es für mich untergeordnete Probleme.
Die anderen Sachen werden in den nächsten Releases aufgearbeitet (Interfaces) bzw. sind aufgearbeitet worden (Lambda-Expressions).
Letztlich bleibt es Geschmackssache. Ich finde es erstaunlich wie viele Programmiersprachen immer noch entstehen. Leider habe ich zuwenig Zeit mich mit den einzelnen näher zu beschäftigen. Allerdings besteht auch zur Zeit kein Bedarf bei mir überhaupt eine andere in Erwägung zu ziehen, da die auf die ich mich fokussiert habe alles mitbringt um ordentlich zu arbeiten.
Alleine das man jetzt in Interfaces Methoden implementieren kann ist schon eine große Verbesserungen. Lambda-Funktionen und Methoden-Referenzen erst recht.
Nur haben das andere Sprachen auch. Java muss noch viel nachholen. Wenn die mal anfangen, eine Typinferenz zu implementieren, dann wird Java interessanter. So bleibe ich lieber bei Python/C++ und Scala.
Gibt es jemanden, der an einem Civforum Programmierprojekt Interesse hätte?
Ich glaube es würde Spaß machen zusammen eine Kleinigkeit zu schreiben auch wenn es nur eine Schere, Stein, Papier KI ist.
Wie wäre es mit einem Projekt "KI-Verbesserung für Civ4/Civ4:Col"?
Berechtigungen
Zitieren
