3. Programmieransatz für erstellung einer Menükarte

Programmieransatz für erstellung einer Menükarte

  • S

    So,

    ich glaube es funktioniert.

    #include <iostream>
#include <string>
#include <vector>

using namespace std;

int main() {

    enum fleisch {
        Rind, Schwein, Huhn, Ente, Seelachs, Krabben, Maxfleisch
    };

    enum gemuese {
        Paprika, Bambus, Sprossen, Bohnen, Zuckerschoten, Pilze, Maxgemuese
    };

    enum sosse {
        Suesssauer, Curry, Soja, Erdnuss, Maxsosse
    };

    char const * const Fleisch[] = {"Rind", "Schwein", "Huhn", "Ente", "Seelachs", "Krabben"};
    char const * const Gemuese[] = {"Paprika", "Bambus", "Sprossen", "Bohnen", "Zuckerschoten", "Pilze"};
    char const * const Sosse[] = {"Süßsauer", "Curry", "Soja", "Erdnuss"};

    for (int i = 0; i < Maxfleisch;) {
        //cout << Fleisch[0] << " ";
        for (int j = 0; j < Maxgemuese;) {
            //cout << Gemuese[j] << " ";
            for (int k = 0; k < Maxsosse;) {
                cout << Fleisch[i]<< " " << Gemuese[j] << " " << Sosse[k] << endl;

                if (k == Erdnuss){
                    j++;
                    cout << endl;
                   if (j== Pilze){
                    i++;
                }    
                }
                k++;
            }
        }
    }
    //cout << Fleisch[0] << " oder " << Fleisch[1] << "?\n";
}
    0
  • W

    .. ich glaube Du hast da noch die Beilage vergessen - oder?

    Übrigens lässt sich die Aufgabe auch mit zwei in einander geschachtelten Schleifen lösen. Unabhängig von der Anzahl der Teile aus denen ein Menü besteht - durch eine zusätzliche Indirektion:

    #include <iostream>

int main() 
{
    using namespace std;
    // jedes Array muss am Ende einen Nullptr enthalten, um das Array-Ende unabhängig von der Art des Arrays zu erkennen.
    char const * const Fleisch[] = {"Rind", "Schwein", "Huhn", "Ente", "Seelachs", "Krabben", nullptr };
    char const * const Gemuese[] = {"Paprika", "Bambus", "Sprossen", "Bohnen", "Zuckerschoten", "Pilze", nullptr };
    char const * const Sosse[] = {"Süßsauer", "Curry", "Soja", "Erdnuss", nullptr };
    char const * const Beilage[] = {"Reis", "Nudeln", nullptr };

    const size_t N = 4; // Menue besteht aus 4 Teilen
    char const* const* basis[N]; // Zeiger auf konstante Zeiger auf konstanten Text
    basis[0] = Fleisch;
    basis[1] = Gemuese;
    basis[2] = Sosse;
    basis[3] = Beilage;

    char const* const* gericht[N];
    for( size_t i=0; i<N; ++i )
        gericht[i] = basis[i];

    bool weiter;
    do
    {
        // --   Ausgeben des aktuellen Gerichts
        for( size_t i=0; i<N; ++i )
            cout << (i>0? " + ": "") << *gericht[i];
        cout << endl;

        // --   Übergang zum nächsten Gericht
        weiter = false;
        for( size_t i=0; i<N; ++i )
        {
            if( *++gericht[i] != nullptr )
            {
                weiter = true;
                break;
            }
            gericht[i] = basis[i];
        }
    }
    while( weiter );
}

    Gruß
    Werner

    0
  • M

    Die erinnerung schrieb:

    Oder gleich schon der Typ std::string

    Hab nur den letzten Beitrag gelesen und das ist mir auch gleich aufgefallen. Warum char*? Vor allem von Werner Salomon hätt ich das jetzt nicht unbedingt erwartet.

    0
  • C

    Mechanics schrieb:

    Warum char*?

    Welchen Vorteil sollte std::string hier denn bringen?
    Eine Ente ist eine Ente ist eine Ente. Alles hart codiert.
    char const * const ist hier doch der natürliche Typ - oder übersehe ich etwas?

    0
  • ?

    Caligulaminus schrieb:

    Mechanics schrieb:

    Warum char*?

    Welchen Vorteil sollte std::string hier denn bringen?

    1. string ist der typ für zeichenketten, char* ist ein zeiger. (konsistenz)
    2. wenn er die zutaten verketten möchte (ich sage nicht dass er das wirklich will, es geht um den hypothetischen fall), dann kann er das mit std::string ganz intuitiv tun.
    3. mehr typen-sicherheit.
    4. einfacher zu lesen (siehe das array aus c-strings in werner's code, finde ich nicht wirklich einfach zu lesen...).

    0
  • C

    asdfasdf schrieb:

    Caligulaminus schrieb:

    Mechanics schrieb:

    Warum char*?

    Welchen Vorteil sollte std::string hier denn bringen?

    1. string ist der typ für zeichenketten, char* ist ein zeiger. (konsistenz)
    2. wenn er die zutaten verketten möchte (ich sage nicht dass er das wirklich will, es geht um den hypothetischen fall), dann kann er das mit std::string ganz intuitiv tun.
    3. mehr typen-sicherheit.
    4. einfacher zu lesen (siehe das array aus c-strings in werner's code, finde ich nicht wirklich einfach zu lesen...).

    1. char* ist ein Zeiger, std::string ist drei Zeiger.
      2. PaprikaCurry? BambusSchwein?
      3. Könntest Du elaborieren?
      4. Einfacher zu lesen als was?
    0
  • ?

    Caligulaminus schrieb:

    asdfasdf schrieb:

    Caligulaminus schrieb:

    Mechanics schrieb:

    Warum char*?

    Welchen Vorteil sollte std::string hier denn bringen?

    1. string ist der typ für zeichenketten, char* ist ein zeiger. (konsistenz)
    2. wenn er die zutaten verketten möchte (ich sage nicht dass er das wirklich will, es geht um den hypothetischen fall), dann kann er das mit std::string ganz intuitiv tun.
    3. mehr typen-sicherheit.
    4. einfacher zu lesen (siehe das array aus c-strings in werner's code, finde ich nicht wirklich einfach zu lesen...).

    1. char* ist ein Zeiger, std::string ist drei Zeiger.
      2. PaprikaCurry? BambusSchwein?
      3. Könntest Du elaborieren?
      4. Einfacher zu lesen als was?

    1. falsch, std::string ist eine klasse, kein zeiger und auch keine drei zeiger. (wie er intern aufgebaut ist ist implementierungsabhängig und irrelevant, da der nutzer dies nie zu gesicht bekommt)
    2. Huhn mit Nudeln? zwischen den zutaten ein wort einzufügen ist ja nicht schwierig.
    3. mit c-strings geht die ganze zeigerarithmetik die mit std::strings nicht geht.
    4. die ganzen nullptr-terminierten arrays von char-zeigern und die arrays von zeigern auf zeiger (weil array-to-pointer-decay) sind für mich unleserlicher als das äquivalent mit std::array und std::string.

    0
  • D

    Ich will mich jetzt hier nicht einmischen, aber std hat nicht umsonst eine (relativ) mächtige string Klasse eingebaut. Sie zu verwenden ist einfach einfacher!

    0
  • ?

    std::string = veränderbarer String mit eingebautem Memory-Management(-Overhead).
    const char* = Konstanter String ohne Memory-Management(-Overhead).

    Wer mit Zeichenkettenliteralen arbeitet, sollte daher const char* verwenden. Damit kriegt man sogar Typsicherheit, da const .

    0
  • B

    Wenn man die Operationen von std::string nicht braucht, braucht man auch std::string nicht. Das std::string der natürliche Typ für Strings ist, ist auch offensichtlich falsch, dann wären String-Literale vom Typ std::string. Sie sind aber konstante char-Arrays.

    0
  • C

    asdfasdf schrieb:

    [...]

    1. Wie std::string intern... ist tatsächlich irrelevant, da ich es hier nicht brauche, daher benutze ich es nicht. KISS.
    2. std::cout << int << std::string << char* << std::complex; Wie gesagt, ich kann den Vorteil nicht erkennen.
    3. Zeigerarithmetik brauche ich hier sicher nicht.
    4. Du müßtest mir immer noch zeigen, wie Du das gegebene mit std::string leserlicher hinschreibst als Werners/meine Variante. Ich habe noch nicht kapiert, wie Du das genau meinst.

    0
Anmelden zum Antworten