Seite 3 von 3 ErsteErste 123
Ergebnis 51 bis 67 von 67

Thema: Go-Statistik Programm

  1. #51
    Und der Tag wird gut...

    Veteran

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.065
    ngb:news Artikel
    1

    Re: Go-Statistik Programm

    Wäre definitiv gut, wenn du kommentieren würdest, Getter und Setter Prinzip sind mir bekannt, aber wenn je ausführlicher um so besser.

    Wenn du noch Entwicklerkommentare hinzufügen willst, wieso weßhalb dies und das, tu das ruhig auch - schaden kann es nicht.
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  2. #52
    Freier Denker

    (Threadstarter)


    Registriert seit
    Jul 2013
    Beiträge
    304

    Re: Go-Statistik Programm

    So. Alle bisherigen Methoden haben dann jetzt ein kleines Kommentar bekommen das kurz zusammenfasst, was diese Methode macht. Teilweise sind die Methoden auch nur vorsorglich geschrieben, weil es vermutlich Sinn macht diese später zu nutzen. Wann und wo wird sich zeigen. Wenn man sie nicht braucht sind sie nicht im Weg und sie waren schnell von der Hand geschrieben.
    Für diesen Beitrag bedankt sich theSplit

  3. #53
    Bot #0384479 Avatar von BurnerR
    Registriert seit
    Jul 2013
    Beiträge
    2.723

    Re: Go-Statistik Programm

    Klasse
    Ich verwende übrigens Clion von jetbrains, was CMake verwendet und habe daher zumindest rudimentäre Kenntnisse... .

  4. #54
    Und der Tag wird gut...

    Veteran

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.065
    ngb:news Artikel
    1

    Re: Go-Statistik Programm

    Dann bring dich mal ein @Burner, so lange es nicht die Toolchain bricht
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  5. #55
    Freier Denker

    (Threadstarter)


    Registriert seit
    Jul 2013
    Beiträge
    304

    Re: Go-Statistik Programm

    Zitat Zitat von BurnerR Beitrag anzeigen
    Clion von jetbrains
    Gerade mal überflogen. Sieht erstmal nicht schlecht aus. Schaue ich mir demnächst mal genauer an. Aber danke für den Tipp

  6. #56
    Bot #0384479 Avatar von BurnerR
    Registriert seit
    Jul 2013
    Beiträge
    2.723

    Re: Go-Statistik Programm

    Zitat Zitat von theSplit Beitrag anzeigen
    Dann bring dich mal ein @Burner, so lange es nicht die Toolchain bricht
    Vor übernächste Montag absolut und keinesfalls möglich, aber danach ist das durchaus realistisch .

  7. #57
    Freier Denker

    (Threadstarter)


    Registriert seit
    Jul 2013
    Beiträge
    304

    Re: Go-Statistik Programm

    Also aktueller Stand:
    Es gibt die vier, bisher erwähnten, Klassen: Coordinate, Turn, Group und Board.

    Ein paar Funktionen sind bisher nur Dummy-Funktionen, da ich mir noch keine Gedanken über die Logik gemacht habe, wie man beispielsweise Nachbaren einer Gruppe ermitteln will oder ähnliches.
    Diese sind relativ deutlich zu erkennen oder, falls sie vermutlich nur sehr kurs ausfallen würden, mit einem entsprechenden todo Kommentar versehen.

    Sonst sind alle Funktionen relativ einfach kommentiert. Wenn sich da jemand auch an Kommentaren beteiligen möchte, gerne. Ich schreibe die relativ simple runter, damit da überhaupt etwas dran steht. Das geht bestimmt auch besser.

    Und damit gehe ich dann auch mal in den "Feierabend".

  8. #58

    Re: Go-Statistik Programm

    Hey,
    verlinke doch das Github-Projekt im Startpost.
    Ggf. auch (dann für später) eine Art Versionsnotiz im Startpost, also: "TODO: ... DONE: ..." usw., dann ist das ganze besser überschaubar.
    Für diesen Beitrag bedankt sich Roin

  9. #59
    Freier Denker

    (Threadstarter)


    Registriert seit
    Jul 2013
    Beiträge
    304

    Re: Go-Statistik Programm

    @MingsPing:
    Ganz grob habe ich das mal gemacht. Bezüglich Grafischer Oberfläche und Statistiken muss sich erstmal jemand finden, der generell das machen möchte. Dann kann man die Aufgaben genauer auflisten und schauen, was wie zu tun ist.

    --- [2017-08-14 23:29 CEST] Automatisch zusammengeführter Beitrag ---

    Zitat Zitat von Roin Beitrag anzeigen
    • Coordinate Klasse um Funktion erweitern, die die eigenen Nachbarn ermitteln kann. Nachbarn sind nur horizontale oder vertikale Nachbarn.
      • Zu vorherigem Punkt: Möglicherweise sollte die Coordinate Klasse statisch die Grenzen des Spielfeldes kennen, damit nur valide Nachbarn ermittelt werden.
    Für wie sinnvoll haltet ihr das?
    Ich wollte jetzt mal in der Klasse Coordinate ein getNeighbours() schreiben. Vorerst lasse ich dabei einfach alle theoretischen Nachbarn zurückgeben. Allerdings wäre es dann im nächsten Schritt sinnvoll, dass man nur direkt valide Nachbarn zurück gibt. Oder?

  10. #60
    Und der Tag wird gut...

    Veteran

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.065
    ngb:news Artikel
    1

    Re: Go-Statistik Programm

    Zitat Zitat von Roin Beitrag anzeigen

    Für wie sinnvoll haltet ihr das?
    Ich wollte jetzt mal in der Klasse Coordinate ein getNeighbours() schreiben. Vorerst lasse ich dabei einfach alle theoretischen Nachbarn zurückgeben. Allerdings wäre es dann im nächsten Schritt sinnvoll, dass man nur direkt valide Nachbarn zurück gibt. Oder?
    Valide im Sinne von, wenn wir bei x = 0, y = 0 sind, geht es nur nach 1,0, 0,1, 1,1 - wenn du das mit Valide meinst, also sollte vielleicht schon eine Logik dahinter stecken, das wir nicht an -1, 0 einen Nachbarn haben können und uns innerhalb der Grenzen des Spielsfelds bewegen.

    Allerdings, vielleicht sollte man die "Board" (Spielfeld)-Klasse ansprechen, um die Dimensionen des Spielfeldes zu bekommen bzw. die Grenzen zu ermitteln.
    Spontan würde ich aber auch diese Prüfung in die "Coordinate" Klasse legen, da dort eben mit Koordinaten gearbeitet wird. Das Spielfeld müßte im Grunde ja nur seine Dimensionen bekanntgeben.

    Eine Frage zum Code habe ich aber auch gerade, ich gehe da gerade mal durch, was macht das hier?

    Code:
    1. Coordinate Coordinate::getBottomNeighbour()
    2. {
    3.     Coordinate bottomNeighbour(getX(), getY() + 1);
    4.    
    5.     return bottomNeighbour;
    Ich weiss wir fragen hier eine Koordinate ab die an "x" (aktuelle Coordinate) und "y + 1" liegt... ? (Bzw. wo im Code passiert das?)

    Aber ich glaube das geht nicht so einfach bzw. könnte das falsch sein?

    Sagen wir, das Spielfeld wäre 7 Felder breit und 7 Felder hoch "Array[7][7"], wenn ich (x, y!) "0,0" anspreche, entspricht das dem Feld auf 0,0 (links oben) - logisch, will ich jetzt aber das darunter liegende Element haben, liege ich doch bei "0, 1" - also dem Element auf Index x + (y * 6)... - oder?

    Was ich meine, das Array ist ja so aufgebaut (eindimensional):
    [
    0,1,2,3,4,5,6,
    7,8,9,10,11,12,13..,
    14,15...
    21...
    28....
    ..48]

    Also haben wir an der ersten Stelle "Links oben", die zweite Spielfeldreihe liegt doch dann aber bei Index 7 bis 12 ?

    Denkfehler?, oder muss ich mir die Spielfeld Klasse noch einmal anschauen, wie dort die Felder aufgebaut sind?
    Geändert von theSplit (17.08.17 um 20:12 Uhr)
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  11. #61

    Re: Go-Statistik Programm

    @theSplit
    Ich sehe auf GitHub kein 1-dim. Array, sondern min/max in 2-dim (x und y). Das passt problemlos mit Coordinate zusammen.


    Die Nachbar-Funktionalität ist aus meiner Sicht beim Board besser aufgehoben, weil nur gültige – im Rahmen des Spielbrett liegende – Nachbarn interessant sind. Aber von den Spielbrettdimensionen weiß Coordinate nichts. Wenn ihr’s so macht, wird Coordinate dann auch zu einem richtig hübschen, kleinen, schlanken, dummen, geradezu trivialen Datencontainer.

    … Hm, eigentlich wollte ich auf GitHub nur mal kurz reinschauen, und dann stand plötzlich die dumme Variante von Coordinate im Texteditor, so wie ich sie bauen würde. Dann kann ich jetzt auch ein paar Worte dazu schreiben.

    Der Übersicht halber alles direkt inline implementiert. Würde ich bei so einer Miniklasse vermutlich im Produktivcode genauso machen.

    Code (C++):
    1.  
    2. // file: Coordinate.hpp
    3.  
    4. class Coordinate {
    5. public:
    6.     Coordinate() = default;
    7.     Coordinate(int x, int y): m_x(x), m_y(y) {}
    8.  
    9.     int x() const { return m_x; }
    10.     int y() const { return m_y; }
    11.  
    12. private:
    13.     int m_x = 0;
    14.     int m_y = 0;
    15. }
    16.  
    17. inline bool operator==(const Coordinate& lhs, const Coordinate& rhs)
    18. {
    19.     return lhs.x() == rhs.x() && lhs.y() == rhs.y();
    20. }
    21.  
    22. inline bool operator!=(const Coordinate& lhs, const Coordinate& rhs)
    23. {
    24.     return not (lhs == rhs);
    25. }
    26.  

    • Ich fand’s in der GitHub-Variante einen sehr feinen Ansatz, Coordinate als value type, also immutable, anzulegen. Eine Koordinate ist ja nicht besonders viel mehr als ein Integer. Dass sie sich verhält wie ein eigebauter Fundamentaltyp, passt perfekt ins Bild. Unschönheit auf GitHub in der Hinsicht: die Getter und Neighbour-Funktionen sind nicht const, was sie aber sowieso und beim value type erst recht sein könnten und sollten. Non-const-Methoden machen für einen immutable Typen keinen Sinn.
    • Warum stehen da oben genau diese Konstruktoren? Der Custom-Ctor mit den beiden ints verhindert, dass der Compiler automatisch den parameterlosen Default-Ctor generiert. Das =default sagt dem Compiler ausdrücklich, dass er den doch generieren soll. Copy-/Move-Ctors und Copy-/Move-Assignment sind compilergeneriert. D.h. den manuellen Copy-Ctor wie auf GitHub brauchts nicht. Schaut mal weiter runter für die kompletten Regeln, wann welche Ctors/Zuweisungsoperatoren automatisch erzeugt werden.
    • Standardoperatoren kommen selten allein. Es bietet sich immer an, alle einer Gruppe zu implementieren, also z.B. operator==() und operator!=(). Sonst kommt man in so seltsame Situationen, dass c1 == c2 compiliert, c1 != c2 aber nicht.
    • Die meisten Operatoren implementiert man besser als freie Funktionen. Als Member wie auf GitHub ist jetzt definitiv, dass der erste Parameter eines Vergleichs ein Coordinate, und *nur* ein Coordinate, sein muss. Die freie Variante wie oben erlaubt für beide Parameter auch andere Typen, die implizit zu einem Coordinate konvertierbar sind.


    Code:
    horizontal: if you write ...
    vertical: the compiler generates ...
    
               none  dtor  copy ctor  copy op=  move ctor  move op=
    dtor       yes         yes        yes       yes        yes
    copy ctor  yes   yes              yes       no         no
    copy op=   yes   yes   yes                  no         no
    move ctor  yes   no    no         no                   no
    move op=   yes   no    no         no        no
    Was mir beim Drüberlesen auf GitHub sonst noch aufgefallen ist:

    • Da wird stdio.h includiert, obwohl weit und breit kein I/O zu sehen ist. Davon abgesehen ist’s ohne Not ein C-Header (in C++ heißt das Ding cstdio). Außerdem würde ich in einem C++-Programm tendenziell auch C++-I/O erwarten, also iostream.
    • Member mit __ anfangen zu lassen, ist potenziell gefährlich, weil solche Namen für die Implementierung (von Compiler und Standardlib) reserviert sind. Kann also, wenns blöd läuft, zu Namensclashes führen. Daumenregel: in Namen keine führenden Unterstriche und keine Mehrfachunterstriche.
    • Das *using std::vector;* im Header hat virale Wirkung auf alle Translation Units, die diesen Header einbinden. Sollte man vermeiden. Früher oder später clasht sowas mal böse.


    So. Puh. Lang geworden. Sorry, ist halt C++. Wenn ich da einmal in Fahrt bin … Wenn das zu viel Review vom Außenseiter war, dann bremst mich. Oder wenn ihr mehr davon wollt, sagts.
    Für diesen Beitrag bedanken sich BurnerR, MingsPing, theSplit, Roin

  12. #62
    Und der Tag wird gut...

    Veteran

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.065
    ngb:news Artikel
    1

    Re: Go-Statistik Programm

    Ich will mehr, aber ich verstehe nur die Hälfte, ich warte auf die Fragen von "fachlichen" Kollegen
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  13. #63
    Freier Denker

    (Threadstarter)


    Registriert seit
    Jul 2013
    Beiträge
    304

    Re: Go-Statistik Programm

    @Brother John:
    Man das war mal Feedback

    Zu dem ganzen "Wieso steht hier Construktor und wieso da nicht const" usw. Ganz einfach: Ich wusste es nicht besser Ich habe das nie professionell gelernt und mein Wissen mehr durch ausprobieren und googlen erweitert

    Mir gefällt das mit der kleinen Coordinate-Klasse recht gut. Probleme habe ich aber damit, dass beispielsweise eine Gruppe nicht ihre Nachbarn selbst ermitteln kann, da sie die Grenzen des Spielfeldes braucht. Daher dachte ich ja daran, dass die Coordinate die Grenzen lernt...
    Dass das Spielfeld Nachbarn einer Gruppe errechnen kann ist zwar machbar, aber irgendwo auch wieder unschön. Ich finde da sind die Grenzen, welche Aufgabe in welche Klasse fällt etwas schwammig.
    Ich implementiere aber deinen Vorschlag mal, da das alles gar nicht so schlecht klingt. Darfst da natürlich auch gerne selber was forken und commiten usw. Das muss ich nicht zwingend absegnen - also schon, aber erst wenn ich merge

    Deine Übersicht, was der Compiler wann erzeugt ist für mich noch ein wenig verwirrend aber vermutlich auch, weil ich mich damit nie wirklich beschäftigt habe.
    Code (C++):
    1. Coordinate(int x, int y): m_x(x), m_y(y) {}
    Diese Zeile finde ich übrigens ungewohnt. Ich wusste nicht, dass man Variablen auch so setzen kann...

    Das mit den Unterstrichen passe ich dann auch direkt mal an...

    Gerne mehr solche Reviews. Und auch gerne Commits

    --- [2017-08-17 23:32 CEST] Automatisch zusammengeführter Beitrag ---

    Kannst du vielleicht noch ein wenig kommentieren, wo ich genau überall Referenzen nutzen sollte und wo nicht?

    --- [2017-08-18 00:15 CEST] Automatisch zusammengeführter Beitrag ---

    Ich habe mal die meisten Änderungen eingepflegt, denke ich.
    Wie gesagt gerne mehr davon oder auch einfach was ändern und Pull-Requests senden...

    Wie vielleicht auffällt, habe ich für Board zum Beispiel auch die Construktoren angepasst, da dies ja deutlich kürzer ist und auch effizienter, denke ich.

    Noch eine allgemeine Frage: Was macht es, wenn ich einen Construktor oder so schreibe, der dem entspricht, den der Compiler basteln würde? Mache ich damit irgendwas kaputt? Ist das bad practise? Oder ist das einfach persönliche Präferenz?

  14. #64

    Re: Go-Statistik Programm

    Zitat Zitat von Roin Beitrag anzeigen
    Ich habe das nie professionell gelernt und mein Wissen mehr durch ausprobieren und googlen erweitert
    Das ist das Gute an der IT: Man muss es nicht offiziell gelernt haben, um damit seine Brötchen zu verdienen. Ich mach C++ jetzt seit 7 Jahren. Irgendwas muss wohl hängengeblieben sein.

    Zitat Zitat von Roin Beitrag anzeigen
    Mir gefällt das mit der kleinen Coordinate-Klasse recht gut. Probleme habe ich aber damit, dass beispielsweise eine Gruppe nicht ihre Nachbarn selbst ermitteln kann, da sie die Grenzen des Spielfeldes braucht. Daher dachte ich ja daran, dass die Coordinate die Grenzen lernt...
    Finde ich gar nicht wild, weil sowieso das Board die Liste der Gruppen verwaltet. Alle Nachbarfunktionen würde ich intuitiv zuerst dort suchen, weil dort alle nötigen Infos dafür gehalten werden.

    Zitat Zitat von Roin Beitrag anzeigen
    Code (C++):
    1. Coordinate(int x, int y): m_x(x), m_y(y) {}
    Diese Zeile finde ich übrigens ungewohnt. Ich wusste nicht, dass man Variablen auch so setzen kann...
    Ging mir am Anfang auch so. Sieht so anders aus als das, was man von C++-Initialisierungssyntax gewohnt ist. Das ist die Initialisierungsliste: der normale, empfehlenswerte Weg, im Ctor Member zu initialisieren. Ansonsten macht das der Compiler implizit. Wenn der Body des Ctors anfängt, hast du die Garantie, dass sämtliche Member default-initialisiert[1] sind. D.h. wenn du sie nicht nutzt, rennst du schnell in Doppel-Initialisierungen. Z.B.:

    [1] Vorsicht bei Fundamentaltypen (Integer & Co.) und einfachen, C-artigen Datenstructs: default-initialisiert heißt da: nicht initialisiert. Im Zweifel lieber die Initialisierung hinschreiben.

    Code (C++):
    1. class Bar { ... };
    2.  
    3. class Foo {
    4. public:
    5.     Foo();
    6. private:
    7.     Bar b;
    8. };
    9.  
    10. Foo::Foo()
    11. {
    12.     b = Bar();
    13. }
    Wenn du ein Foo instantiierst, wird ein Bar erzeugt, sofort wieder zerstört und nochmal erzeugt. Denn implizit steht da folgender Ctor:

    Code (C++):
    1. Foo::Foo() : b(Bar())
    2. {
    3.     b = Bar();
    4. }
    Noch eine Konsequenz: Wenn du einen Typen als Member hast, der keinen parameterlosen Default-Ctor hat, dann *musst* du den Member in der Initliste abhandeln. Ansonsten versucht der Compiler implizit den Default-Ctor zu verwenden und fällt dabei natürlich böse auf die Nase.

    Zitat Zitat von Roin Beitrag anzeigen
    Kannst du vielleicht noch ein wenig kommentieren, wo ich genau überall Referenzen nutzen sollte und wo nicht?
    Das sieht im Moment ziemlich gut aus. Grundsätzlich: Erstmal immer const&, ausgenommen Fundamentaltypen und ähnlich kleine Objekte. Deswegen finde ich’s vollkommen ok, Coordinate zu kopieren.

    Zitat Zitat von Roin Beitrag anzeigen
    Was macht es, wenn ich einen Construktor oder so schreibe, der dem entspricht, den der Compiler basteln würde? Mache ich damit irgendwas kaputt? Ist das bad practise? Oder ist das einfach persönliche Präferenz?
    Für *den* einen Ctor/Dtor/op= ist es erstmal egal. Ob der entspr. Binärcode entsteht, weil ihn der Compiler implizit erzeugt oder weil du das entspr. C++ ausdrücklich hingeschrieben hast, macht keinen Unterschied. Es kann aber passieren – siehe Tabelle – dass dir damit andere Ctor/op= nicht mehr implizit erzeugt werden. Und das kann evtl. Performance kosten oder im blödesten Fall sogar nicht mehr compilieren. Schau dir zu dem ganzen Thema mal The rule of three/five/zero an.
    Für diesen Beitrag bedankt sich Roin

  15. #65
    Freier Denker

    (Threadstarter)


    Registriert seit
    Jul 2013
    Beiträge
    304

    Re: Go-Statistik Programm

    @Brother John:
    Ich habe da geade noch zwei Fragen.
    Zum Einen: In der Tabelle sind alle möglichen Zusatz-Construkte erwähnt. Aber was ist denn der normale Costum Constructor in dem Fall? Gehört der in eine der genannten Kategorien oder ist das ein normaler Konstruktor, der von den Compiler-Regeln, die du erwähnt hast ausgeschlossen ist und da "nichts" mit zu tun hat?
    Und zum Anderen habe ich das gerade nicht mit der Doppelinitialisierung verstanden.

    Zitat Zitat von Brother John Beitrag anzeigen
    Wenn der Body des Ctors anfängt, hast du die Garantie, dass sämtliche Member default-initialisiert[1] sind. D.h. wenn du sie nicht nutzt, rennst du schnell in Doppel-Initialisierungen.
    Also soll ich immer alles mögliche in dieser Initializer-Liste hinschreiben oder lieber im eigentlichen Body meines Construktors oder wie?

    --- [2017-08-20 20:59 CEST] Automatisch zusammengeführter Beitrag ---

    Zitat Zitat von Brother John Beitrag anzeigen
    Alle Nachbarfunktionen würde ich intuitiv zuerst dort [im Board] suchen, weil dort alle nötigen Infos dafür gehalten werden.
    Das habe ich ja jetzt auch erstmal so gemacht.
    Findest du im aktuellen Repo denn noch mehr, was du als verbesserungswürdig erachtest?

    Zitat Zitat von Brother John Beitrag anzeigen
    Noch eine Konsequenz: Wenn du einen Typen als Member hast, der keinen parameterlosen Default-Ctor hat, dann *musst* du den Member in der Initliste abhandeln. Ansonsten versucht der Compiler implizit den Default-Ctor zu verwenden und fällt dabei natürlich böse auf die Nase.
    Guter Tipp. Das sollte ich vielleicht in dem einen oder anderen Projekt noch anpassen. Da ist es zwar durchkompiliert, aber vermutlich nur, weil der Compiler da etwas mitgedacht hat und überall alles mögliche zurechtgeschustert hat

    --- [2017-08-20 21:46 CEST] Automatisch zusammengeführter Beitrag ---

    Zitat Zitat von Brother John Beitrag anzeigen
    Grundsätzlich: Erstmal immer const&, ausgenommen Fundamentaltypen und ähnlich kleine Objekte.
    Dazu gerade noch ein hilfreicher Link, der auch noch zu zwei weiteren Erklärungen führt: https://stackoverflow.com/a/3141107/6486348
    Der hat mein Verständnis von den ganzen const-Konstellationen zumindest verbessert.

    --- [2017-08-21 00:48 CEST] Automatisch zusammengeführter Beitrag ---

    Leute ich habe ein Problem

    Ich wollte von meinen Commits die Emailadresse ändern. Da stand jetzt immer drin, wie mein laptop hieß und sowas. Irgendwas, was Netbeans aus meinem Netzwerknamen generiert hat.
    Also habe ich mit git rebase -i alle commits markiert, die ich editieren wollte und habe die dann bearbeitet und gepushed.

    Jetzt würde ich aber gerne alle vorherigen dadurch ersetzen. Jetzt habe ich nämlich statt ~ 35 Commits etwa 71 da drinstehen und die sind ja jetzt etwas "Mist"...
    Kann mir da jemand sagen, wie ich das sauber bearbeitet kriege? Ich steige durch git wohl nicht ausreichend durch

  16. #66

    Re: Go-Statistik Programm

    Zitat Zitat von Roin Beitrag anzeigen
    In der Tabelle sind alle möglichen Zusatz-Construkte erwähnt. Aber was ist denn der normale Costum Constructor in dem Fall? Gehört der in eine der genannten Kategorien oder ist das ein normaler Konstruktor, der von den Compiler-Regeln, die du erwähnt hast ausgeschlossen ist und da "nichts" mit zu tun hat?
    Genau so ist es. Das kam da oben wirklich nicht richtig rüber. Du kannst beliebig viele Ctors haben. Die Regeln aus der Tabelle beeinflusst das überhaupt nicht. Es kommt nur eine Regel dazu: Sobald du einen Custom-Ctor anlegst, wird der Default-Ctor nicht mehr implizit erzeugt. … Oh, und mit »Default-Ctor« ist immer der ohne Parameter gemeint: egal ob handgeschrieben oder vom Compiler erzeugt.

    Zitat Zitat von Roin
    Und zum Anderen habe ich das gerade nicht mit der Doppelinitialisierung verstanden.
    Bleiben wir bei dem Ctor von oben:
    Code (C++):
    1.  
    2. // Initliste könnte auch fehlen und wäre dann implizit.
    3. // Macht keinen Unterschied
    4. Foo::Foo() : b(Bar())
    5. {
    6.     b = Bar();
    7. }
    Wenn du ein Objekt instantiierst, passiert der Reihe nach folgendes:
    1. Speicher für das Objekt wird zugewiesen, entweder vom Stack oder – wenn mit new erzeugt – vom Heap.
    2. Die Initliste des Ctors wird abgearbeitet.
    3. Der Body des Ctors wird abgearbeitet.

    Bei Foo heißt das konkret:
    1. Los geht’s mit einem uninitialisierten Speicherblock, der für ein Foo groß genug ist.
    2. Im Rahmen der Initliste wird ein Bar-Objekt für den Member b erzeugt.
    3. Direkt anschließend kommt die Dopplung: Denn die Zeile im Body schmeißt das gerade erzeugte Bar-Objekt wieder weg, erzeugt ein neues und weist das dem Member b zu.

    Deswegen sollte, soweit das irgendwie geht, sämtliche Instantiierung in der Initliste passieren. Wenn du den Ctor-Body brauchst, um anschließend die Member noch weiter zu konfigurieren, das ist fein. Beispiel mit einem halbwegs realistischen Qt-Miniwidget, das ein Label und einen Button enthält. In der Initliste werden das Label- und Button-Objekt instantiiert und dann im Body verwendet; genau so wie du es in jeder anderen Funktion der Klasse auch tun würdest.
    Code (C++):
    1. MyWidget::MyWidget(QWidget* parent)
    2.     : QWidget(parent)
    3.     , m_label(new QLabel(this))
    4.     , m_okButton(new QPushButton(this))
    5. {
    6.     m_label->setAlignment(Qt::AlignRight);
    7.     m_okButton->setText("OK");
    8.     // ...
    9. }
    Zitat Zitat von Roin
    Dazu gerade noch ein hilfreicher Link, der auch noch zu zwei weiteren Erklärungen führt
    Feiner Link. Der bringt das echt gut auf den Punkt.


    Zitat Zitat von Roin
    Leute ich habe ein Problem
    [...]
    Kann mir da jemand sagen, wie ich das sauber bearbeitet kriege?
    »Professionelle Anarchie mit Roin. Heute: Wir zerstören ein Git-Repo.«

    Sobald Commits gepusht sind, ist normalerweise Ende mit editieren. Die sind jetzt in die Welt verteilt. Auch, wenn du sie bei dir gelöscht kriegst und pusht, können sie durch jemand anders wieder auftauchen, der sie gepullt hatte, von der Editieraktion nichts mitgekriegt hat und dann seinen Stand inkl. der ungewollten Commits wieder pusht.

    Dass *das* nicht passiert, würden wir bei den paar Leuten hier ja sicher noch hinkriegen. Aber wie du das Repo wieder sauber und die ungewollten Commits von Github wegkriegst, da bin ich auch nicht Git-Experte genug. Die Frage hier sieht ganz brauchbar aus. Oder, wenn es nichts macht, die bisherige Historie zu verlieren, die »Second Method« hier. Dann muss nur noch jeder seine Forks killen und neu klonen. … Könnte klappen.
    Geändert von Brother John (Gestern um 18:21 Uhr)

  17. #67
    Freier Denker

    (Threadstarter)


    Registriert seit
    Jul 2013
    Beiträge
    304

    Re: Go-Statistik Programm

    Zitat Zitat von Brother John Beitrag anzeigen
    »Professionelle Anarchie mit Roin. Heute: Wir zerstören ein Git-Repo.«
    Ich wollte halt eigentlich einfach nur meine Mailadresse ändern, damit da nicht so ein Schwachsinn drinsteht
    Ich glaube das wieder zu fixen ist jetzt zu aufwändig. Ich lasse das einfach so stehen. Nach dem Hirarchie-Baum war der rebase auch eher ein Branch und dann ein merging... Seltsam, aber was soll man machen

    ---

    Ich habe gerade wieder eine Menge programmiert.
    Da darf gerne wer rübergucken. Ich mache sicherlich einige ...Missgeschicke (Ich mache ja keine Fehler. Bin ja König, wie oben erwähnt...). Vielleicht kann da ja jemand was zu sagen, was ich da so alles fabriziert habe

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •