Geht sowas eigentlich nicht einfacher?

enum names { Hans, Fritz, Karl, Jürgen };
const char* name[] = { "Hans", "Fritz", "Karl", "Jürgen" };
//
names name;
//
printName( names name )
{
    switch( name )
    {
        case( Hans ):
            cout << name[Hans] << endl;
            break;
        case( Fritz ):
            cout << name[Fritz] << endl;
            break;
        //etc..
    }
}

MfG SideWinder

enum names { Hans , Fritz, John };
char* nametext [] = { "Hans", "Fritz", "John" };

int main()
{
    std::cout << "Choose Name ( 0=Hans 1=Fritz 2=John )\n";
    int nameID = -1;

    while(nameID < 0 || nameID > 2)
    {
        std::cin >> nameID;
    }

    std::cout << nametext[nameID];

    return nameID

}

enum names { Hans, Fritz, Karl, Jürgen };
const char* name[] = { "Hans", "Fritz", "Karl", "Jürgen" };

...name[Hans]...

Das ist ziemlich unsicher, weil der Standard dem Compiler keine Vorgabe macht, welchen Wert unqualifizierte enums bekommen (nur dass sie eindeutig sind) ... wenn Du Pech hast, beginnt die nächste Compilerversion bei den enums mit 1 (oder 1000) oder sie nummeriert absteigend oder ..... => in jedem Fall .
Entweder qualifizierst Du die enums also, oder Du überlegst Dir einen anderen Weg.
Mal ganz abgesehen davon, dass das switch() (wie von SID gezeigt) eigentlich überflüssig ist, wenn Du danach sowieso via index zugreifst - ein

// BTW: lokaler Varname darf nicht auch "name" sein wie in Deinem Beispiel oben,
// sonst passiert nicht, was Du willst, weil der lokale name "name" den globalen verdeckt 
void printName( names searchedname ) { cout << name[searchedname]; }

reicht vollkommen

Du könntest die enums und Namen auch über "Pairs" oder eine map aneinanderbinden, aber das macht prinzipiell auch nichts Anderes (ist aber evtl. leichter erweiterbar).

Alternativ kannst Du natürlich einen "selbstreflektierenden enum-Typen" basteln (als Klasse, die sich exakt wie ein enum verhält (alle operatoren definiern) + "getStr()"-Methode), aber auch das ist ordentlich Arbeit und bringt neue Probleme mit sich (Daten nicht zur Compilezeit verfügbar; hat man wirklich alle Anwendungsmöglichkeiten von enums bedacht ? ; ...) ...

Ich denke: Prinzipell dürfen die Source-Strukturen (inklusive Variablennamen) zur Laufzeit keine Rolle mehr spielen, sondern man sollte den Zusammenhang fachlich sauber modellieren ... wenn man deswegen fachlich mit "Hans", "Fritz" und Co. arbeiten will/muß, muß man die Abbildung technisch sowieso irgendwie implementieren (z.B. über switch() oder map oder ....). Dass man bei einfacher Fachlichkeit (die 1:1 technisch umgesetzt werden kann) in Versuch gerät, die beiden zu vermischen, kann ich verstehen (passiert mir auch oft genug), ist aber prinzipiell trotzdem unsauber.
Stell' Dir einfach mal vor, "Hans" wird zukünftig nicht einfach mehr über ein enum repräsentiert werden können, sondern erst über die Kombination eines enums und eines "Freund-Flags" zuzuordnen .... spätestens dann kommst Du mit der engen Kopplung in Schwulitäten.

Gruß,

Simon2.

P.S.: Ich glaube, ich probiere zum Spaß mal mit den "selbstreflektierenden enums" herum .....

Das ist ziemlich unsicher, weil der Standard dem Compiler keine Vorgabe macht, welchen Wert unqualifizierte enums bekommen (nur dass sie eindeutig sind)

sag doch sowas nicht!
7.2.

Simon2 schrieb:

Das ist ziemlich unsicher, weil der Standard dem Compiler keine Vorgabe macht, welchen Wert unqualifizierte enums bekommen (nur dass sie eindeutig sind)

sag doch sowas nicht!
7.2.

Hab' ich das mit dem (vor99er) C-Standard verwechselt ? Muß ich mal nachsehen (hab' gerade keinen Standard griffbereit) .... war mir aber ziemlich sicher...

Naja, lesen macht schlau.

Gruß,

Simon2.

Schwulitäten

Simon2 schrieb:

Schwulitäten

Du bist doch sonst auch für alles offen ...

1310-Logik schrieb:

Simon2 schrieb:

Schwulitäten

Du bist doch sonst auch für alles offen ...

Ich hab auch kein Problem damit, über Schwulsein zu reden, ich habe ein Problem damit wenn "Schwulitäten" als Synonym für "Probleme", oder was auch immer der Author meinte, benutzt wird.

Ich hab auch kein Problem damit, über Schwulsein zu reden, ich habe ein Problem damit wenn "Schwulitäten" als Synonym für "Probleme", oder was auch immer der Author meinte, benutzt wird.

die verwendung des worts war völlig korrekt.
schwulitäten steht für kalamitäten.
http://www.google.de/search?hl=de&q=schwulitäten&btnG=Google-Suche&meta=

In dem Fall entschuldige ich mich, das Wort war mir in dem Zusammenhang nicht bekannt.
Trotzdem komisch, das "Schwul" mit "Schwierig/Schweisstreibend" in Verbindung gebracht wird, vielleicht mag ich deshalb das Wort nicht..

wenn ich http://www.wer-weiss-was.de/theme46/article298247.html glauben darf, ist schwulitäten mit bedrängnis in der bedeutung älter als schwul mit der sexuellen ausrichtung. vielleicht solltest du warme brüder nicht mehr schwul nenne, wenn du dort einen unangenehme verbindung in den wörtern spürst.

1310-Logik schrieb:

In dem Fall entschuldige ich mich, das Wort war mir in dem Zusammenhang nicht bekannt.
Trotzdem komisch, das "Schwul" mit "Schwierig/Schweisstreibend" in Verbindung gebracht wird, vielleicht mag ich deshalb das Wort nicht..

wenn ich http://www.wer-weiss-was.de/theme46/article298247.html glauben darf, ist schwulitäten mit bedrängnis in der bedeutung älter als schwul mit der sexuellen ausrichtung. vielleicht solltest du warme brüder nicht mehr schwul nenne, wenn du dort einen unangenehme verbindung in den wörtern spürst.

Ich hatte das Wort noch nie gern, hat sowas..ich mags einfach nicht.
Übrigens nenne ich meine warmen Brüder "Schwestern"