3. Konsolen Memorie

Konsolen Memorie

  • U
     

    //die auskommentierten header sind deprecated
#include <iostream>
#include <cmath> //<math.h>
#include <string> //<string.h>
#include <conio.h>
#include <dos.h>
#include <cstdio> //<stdio.h>

    hmm.. find ich ne so hübsch...

    Aufruf:

    #include <vector>
#include <iostream>

size_t pairs (0);
do
{
//goodbit, ignore, clear, ... kA ^^
std::cin >> pairs;
} while (pairs == 0);
std::vector <char> Karten = newCards <char> (paare, 'a');
//oder
std::vector <TMemoryBilderEnum> Karten = newCards <TMemoryBilderEnum> (paare, TMemoryBilderEnum::first);

    1.:

    #include <vector> //nen c++-array - das macht alles von allein und ist dynamisch ^^
#include <iterator> /*man kann auch die vectoren so wie arrays durchgehen, aber man kann sich auch einen zeiger nehmen,
den man immer auf das nächste element schiebt - welche Vorteile das hat, kannste ja selbst googlen, wenns dich interessiert
in Kürze: es ist schneller, eleganter und mit Hilfe von iteratoren übergibt man meistens Arrays in andere Funktionen, weil man dann nicht alles x-mal kopieren muss

iterator+n gibt uns einen zeiger, der genau n positionen weiter geschoben ist als n (der zeiger an sich wird aber nicht verändert)
++iterator lässt den iterator (von mir bis jz zeiger genannt) eine position weiter-"laufen"*/

template <class T> //T sollte hier der Karten-Typ sein - in deinem Fall char
  typename std::vector <T> newCards (const size_t &pairs, T startingvalue)
   {
    std::vector <T> Return (pairs*2); //ein array mit allen karten
    const std::vector <T>::const_iterator end (Return.end ()); //das ende des arrays - kein "richtiges" Element mehr
    for (std::vector <T>::iterator iter (Return.begin ()); iter != end; iter += 2, ++startingvalue)
    {
        *iter = startingvalue; //die aktuelle Position
        *(iter+1) = startingvalue; //und die nächste auch
    }
    std::random_shuffle (Return.begin (), end); //das Mischen
    return Return; //die Karten müssen ja auch wieder aus der Funktion rauskommen ^^
   }

    2.:

    #include <vector>
#include <iterator>

template <class T>
  typename std::vector <T> newCards (const size_t &pairs, T startingvalue)
   {
    std::vector <T> Return; //ein leeres array
    Return.reserver (pairs*2); //die größe reservieren - kann man auch weglassen, aber wenn du iwann ma lange weile hast und mit 99999999 paaren spielen willst... ^^
    for (size_t i (0); i != pairs; ++i, ++startingvalue)
    {
        Return.push_back (startingvalue);
        Return.push_back (startingvalue); //2 gleiche elemente werden an das array rangehangen
    }
    std::random_shuffle (Return.begin (), Return.end ()); //mischen
    return Return; //und die wiedergabe des arrays
   }

    Fänd ich schöner...
    Find schon die Idee an sich komisch, die Anzahl der Karten (und nicht der Paare) zu übergeben...

    Naja - aber den Zweck erfüllt "deine" Funktion ja auch - von daher...

    Hab erst danach dran gedacht, dass der OP das wahrscheinlich ne versteht - wollts dann au ne wieder wegmachen und deshalb hab ichs einfach ma probiert, zu erklären ^^

    bb

    edit:
    Außerdem solltest du von den globalen Variablen wegkommen und solltest es nicht so statisch machen...

    void spielfeld_ausgabe (const size_t &reihen, const size_t &spalten)
  { 
     cout << "\r\n"
       << "\r\n"
       << "\r\n";
     for (size_t spalte (0); spalte != spalten; ++spalte)
        {
           cout << "\t" << spalte;
        }
     cout << "\r\n";
     for (size_t reihe (0); reihe != reihen; ++reihe)
        {
           cout << reihe;
           for (size_t spalte (0); spalte != spalten; ++spalte)
              {
                 cout << "\t" << verdeckt[reihe*spalten+spalte];
              }
           cout << "\r\n";
        }
  }

    Ich hab dir mal die Ausgabe anders gemacht - allerdings nutzt die noch immer das globale Array 'verdeckt'... Das könntest du hier mit Iteratoren mit-übergeben, also so in etwa:

    //Aufruf:
spielfeld_ausgabe <char> (5, 3, verdeckt.begin (), verdeckt.end ()); //die kartenart von oben
//Fkt:
template <class T>
  void spielfeld_ausgabe (const size_t &reihen, const size_t &spalten, typename std::vector <T>::const_iterator begin, typename const std::vector <T>::const_iterator &end)
   {
//wie gehabt bis zu den schleifen
     for (size_t reihe (0); reihe != reihen; ++reihe)
        {
           cout << reihe;
           for (size_t spalte (0); spalte != spalten; ++begin)
              {
                 cout << "\t" << *begin;
              }
           cout << "\r\n";
        }
   }

    jz wars das aber wirklich erst mal ^^

    0
  • T

    Ich habe bewusst auf die STL verzeichtet, weil ich aufgrund des Codes des TO's annehmen muss, dass es ihn überfordern würde.

    0
  • U

    unskilled schrieb:

    Hab erst danach dran gedacht, dass der OP das wahrscheinlich ne versteht - wollts dann au ne wieder wegmachen und deshalb hab ichs einfach ma probiert, zu erklären ^^

    Aber anders hab ichs au nicht gelernt - iwo hat ma wer geschrieben, wie iwas tolles geht und dann sucht man halt, bis man alle funktionen im code bei google gefunden hat und weiß, was sie machen ;o)

    bb

    0
  • T

    Übrigens liegen die Karten hierbei immer nebeneinander:

    std::random_shuffle (Return.begin (), Return.end ()); //mischen

    PS: Bei Variante 2.
    PPS: Wieso übergibst Du primitive Typen als Referenz?

    0
  • U

    Übrigens liegen die Karten hierbei immer nebeneinander

    versteh ich nicht ><

    Wieso übergibst Du primitive Typen als Referenz?

    Weils auch nicht schadet - Compiler überlegt sich schon, ob er sie kopiert oder nicht... Wenn ers nicht will is auch gut - nur, damit er sich nicht so eingeengt und beschnitten fühlt 😉
    Nein - weil ich so was idR auch als template-parameter mache...
    Außerdem gehts dann schneller den Typ zu ändern - selbst, wenn dann auf einmal nen long long oder double oder was weiß ich statt size_t steht, würde der compiler es richtig machen und ich müsste dann nicht noch jedes ma überlegen, was ich machen würde ^^

    is halt ne angewohnheit - vll keine gute aber bis jz hatte ich noch keine probs damit.

    oder siehst du iwas, was dagegen spricht?

    bb

    0
  • N

    unskilled schrieb:

    Außerdem gehts dann schneller den Typ zu ändern - selbst, wenn dann auf einmal nen long long oder double oder was weiß ich statt size_t steht, würde der compiler es richtig machen und ich müsste dann nicht noch jedes ma überlegen, was ich machen würde ^^

    Wieso meinst du, könne man den Typ schneller ändern, wenn er als Referenz da steht (bei deinen Beispielen gehts ja nur um Änderungen zwischen primitiven Typen)? Oder hab ich dich falsch verstanden?

    0
  • T

    unskilled schrieb:

    Übrigens liegen die Karten hierbei immer nebeneinander

    versteh ich nicht ><

    Du mischt Deine Paare mit random_shuffle. Nicht die einzelnen Karten.

    unskilled schrieb:

    Wieso übergibst Du primitive Typen als Referenz?

    Weils auch nicht schadet - Compiler überlegt sich schon, ob er sie kopiert oder nicht... Wenn ers nicht will is auch gut - nur, damit er sich nicht so eingeengt und beschnitten fühlt 😉
    Nein - weil ich so was idR auch als template-parameter mache...
    Außerdem gehts dann schneller den Typ zu ändern - selbst, wenn dann auf einmal nen long long oder double oder was weiß ich statt size_t steht, würde der compiler es richtig machen und ich müsste dann nicht noch jedes ma überlegen, was ich machen würde ^^

    is halt ne angewohnheit - vll keine gute aber bis jz hatte ich noch keine probs damit.

    oder siehst du iwas, was dagegen spricht?

    bb

    Bist Du sicher, dass der Compiler sich aussuchen kann, ob er kopiert oder referenziert? Meines wissens ist der ref-Operator keine Empfehlung an den Compiler. Hast Du eine Quelle dafür?
    Dagegen spricht, dass Du bei jedem Zugriff eine Derefenzierung hast.

    0
  • U

    naja...

    //hpp:
void ShowBla (const size_t &toout);

//cpp:
void ShowBla (const size_t &toout)
{
std::cout << toout;
}

//=>ändern, weil size_t ne mehr gut genug ist...

//hpp:
void ShowBla (const long long &toout); //nur typ ändern

//cpp:
void ShowBla (const long long &toout) //nur typ ändern
{
std::cout << toout;
}

    und wenn man es ganz toll machen will, dann nimmt man ja statt size_t auch meiste std::vector::size_type oder wie au immer das genau ist - hab ich noch nie gemacht aber scho ab und an ma überlegt, es doch zu tun ^^
    und da würde dann die referenz wahrscheinlich schon sinn machen - obwohl es auf ner 64bit cpu wahrscheinlich au ne mehr lohnt, ne 64bit große variable als referenz zu übergeben... hmm...

    also dann nur noch das ändern ^^

    bb

    0
  • N

    unskilled schrieb:

    also dann nur noch das ändern ^^

    So hab ich das auch verstanden, aber ich hab mich gefragt, weil size_t schon fast ein elementarer Datentyp ist (teilweise ist er doch als unsigned int definiert?).

    Und für die Elementartypen kannst du dir (neben der entfallenden Dereferenzierung, die mir ein gutes Argument scheint) bei Übergaben als Kopie noch eine Menge Zeichen sparen 😉

    0
  • T

    unskilled schrieb:

    naja...

    //hpp:
void ShowBla (const size_t &toout);

//cpp:
void ShowBla (const size_t &toout)
{
std::cout << toout;
}

//=>ändern, weil size_t ne mehr gut genug ist...

//hpp:
void ShowBla (const long long &toout); //nur typ ändern

//cpp:
void ShowBla (const long long &toout) //nur typ ändern
{
std::cout << toout;
}

    Wozu brauchts da eine Referenz? 😕 Meinst Du, das long long ist so groß, dass es sich lohnt?
    Wenn man den Parameter innerhalb der Funktion mehrfach benutzt (womöglich auch noch in einer Schleife) würde ich eher auf die Dereferenzierungen verzichten.

    0
  • U

    das war nicht an dich sondern an nexus....

    bei long long (64bit) ist es (vermutlich ^^) besser, nur einen pointer kopieren zu müssen, weil der ja (auf 32bit cpus) nur 32bit ist - und dann mit dem weitergearbeitet wird...

    muss dich denke noch lang nicht interessieren...
    aber kannst ja ma nach referenzen suchen um zu wissen, wozu die da sind...
    solltest im forum au genug finden:

    grob - sie sind genau so, wie pointer, nur sicherer, cpp-iger und können nicht NULL sein...

    bb

    0
  • N

    unskilled schrieb:

    bei long long (64bit) ist es (vermutlich ^^) besser, nur einen pointer kopieren zu müssen, weil der ja (auf 32bit cpus) nur 32bit ist

    Und wie soll sein Wertebereich dann grösser sein als der eines ints ?

    unskilled schrieb:

    muss dich denke noch lang nicht interessieren...
    aber kannst ja ma nach referenzen suchen um zu wissen, wozu die da sind...
    solltest im forum au genug finden:

    grob - sie sind genau so, wie pointer, nur sicherer, cpp-iger und können nicht NULL sein...

    Das Konzept der Referenzen ist mir übrigens durchaus bekannt. 🙄

    0
  • U

    oh - sry...
    ich war jz davon ausgegangen, dass der OP das gefragt hatte... ich les beim nächsten ma besser - versprochen 🙄

    Und wie soll sein Wertebereich dann grösser sein als der eines ints?

    rhetorische frage?

    2^32 < 2^62

    warum das passieren kann: kein plan... ich hab ja nur gesagt: für den fall, dass....
    außerdem wird kein compiler der welt (zumindest die relevanten) nen int wirklich als referenz übergeben - von daher kommt es aufs gleiche raus, ob ich nu

    const size_t bla
    oder size_t bla
    oder const size_t &bla

    schreib - an der geschwindigkeit änder das gar nix...

    bb

    0
  • N

    unskilled schrieb:

    rhetorische frage?

    2^32 < 2^62

    Sorry, ich habe dich falsch verstanden und das "der" auf dein "long long (64bit)" bezogen: 😉

    unskilled schrieb:

    bei long long (64bit) ist es (vermutlich ^^) besser, nur einen pointer kopieren zu müssen, weil der ja (auf 32bit cpus) nur 32bit ist

    unskilled schrieb:

    außerdem wird kein compiler der welt (zumindest die relevanten) nen int wirklich als referenz übergeben

    Bist du dir da sicher, ob der Compiler das auch optimiert? Vor allem, wenn durch die Dereferenzierungen mehr Zeitverluste als durch die Kopie entstehen?

    0
  • U

    Nexus schrieb:

    unskilled schrieb:

    bei long long (64bit) ist es (vermutlich ^^) besser, nur einen pointer kopieren zu müssen, weil der ja (auf 32bit cpus) nur 32bit ist

    sry, mein fehler ^^

    Nexus schrieb:

    unskilled schrieb:

    außerdem wird kein compiler der welt (zumindest die relevanten) nen int wirklich als referenz übergeben

    Bist du dir da sicher, ob der Compiler das auch optimiert? Vor allem, wenn durch die Dereferenzierungen mehr Zeitverluste als durch die Kopie entstehen?

    Hmmm.. Wüsste jetzt zwar nicht, wie ich das rausfinden soll aber dachte gelesen zu haben, dass der Compiler da immer selbst entscheidet (genau wie bei inline) - solange der Copy-CTor einfach genug ist oder das Element kleiner ist, als die Registergröße sollte er es nicht referenzieren sondern kopieren - belehrt mich (bitte 🤡 ) eines besseren, wenn ich falsch liege.

    bb

    0
  • T

    Nein, die Benutzung des Referenzoperators ist eine klare Anweisung und keine Empfehlung. Es wird mit Sicherheit keine Kopie erzeugt.

    0
  • U

    hmm... verdammt - ich weiß nich ma, nach was ich da suchen soll - aber ich bin mir sicehr, das ma iwo gelesen zu haben : <

    wenn ichs find, dann post ich es noch - wenn nich, dann haste wo recht 😕 ^^

    0
  • N

    unskilled schrieb:

    aber ich bin mir sicehr, das ma iwo gelesen zu haben

    Naja, nicht jede Quelle ist zuverlässig. Ich hab z.B. schon sehr oft void main() in Büchern und Tutorials gesehen.

    0
  • U

    Guter Vergleich >< Hab auch gerad überdurchschnittlich (für meine Verhätlnisse) lange gegoogelt und nix gefunden, was meine Vermutung rechtfertigen würde...

    naja... bye

    0
  • N

    Du musst meine Antwort nicht gleich persönlich auffassen. Sie war nämlich kein Vorwurf, sondern nur die (eigentlich überflüssige) Feststellung, dass man nicht alles, was man irgendwo liest, auch so anwenden könne...

    Und: Es ist mir klar, dass die Diskussion hier nicht mit void main() zu vergleichen ist, es ging mir auch mehr ums Prinzip.

    0
Anmelden zum Antworten