konstantes Array aus Strukturen

Sone

Kellerautomat schrieb:

Hacker uebertreibt mal wieder masslos

Wieso?
Ah, ich sehe was du meinst. sry

Btw: Nenn' mich nicht Hacker.

Th69

Hallo Phys1k3r,

lass dich nicht von Sone (früher Hacker) verwirren - er meint er wäre der tolle Hecht, weil er jetzt einen C++11 Compiler benutzt.

Es geht auch ganz einfach (so wie es schon unter C funktioniert hat):

const int COLORS[SIZE_OF_MY_COLORS] =
{
    { 0, 0, 0 },
    { 1, 1, 1 },
    { 0, 0, 1 },
    // ...
}

Noch ein Tipp:
du kannst auch SIZE_OF_MY_COLORS automatisch vom Compiler berechnen lassen:

enum myColor // Einzahl ist besser als Name (s.u.)
{
    BLACK, WHITE, BLUE, YELLOW, GREEN, PINK, ORANGE, LIGHTGREEN, CYAN, RED, GRAY, PURPLE,
    SIZE_OF_MY_COLORS
};

Nur für die Konvertierung eines Strings in das entsprechende 'enum' empfehle ich dir std::map zu benutzen:

#include <map>

std::map<const char*, myColors> myColorMap;

int main()
{
  myColorMap["black"] = BLACK;
  myColorMap["white"] = WHITE;
  // ...
}

Zugriff auf Map, s. http://www.cplusplus.com/reference/stl/map/find

(alternativ statt 'const char *' kannst du selbstverständlich auch 'std::string' benutzen)

Sone

Th69 schrieb:

lass dich nicht von Sone (früher Hacker) verwirren - er meint er wäre der tolle Hecht, weil er jetzt einen C++11 Compiler benutzt.

Sag mal bist du bescheuert oder was?

std::map<const char*, myColors) myColorMap;

Ich bin sicher, das ist eine einleuchtende Logik.
Wenn der Anfänger Templates schon nicht verstehen kann/will, brauchst du ihm nicht gleich einen STL-Container um die Ohren zu hauen, und ihn gleich damit zu konfrontieren. Dazu noch mit syntaktisch falscher Deklaration. Gleich kommt er wieder, weil sein Compiler kryptische Fehlermeldungen ausspuckt.
Andererseits, wenn schon ne map, dann wieso nicht gleich... std::(tr1::)array ?

<irony>

Neeeiin! Das geht doch mit C schon, wieso C++ verstehen wenn es auch mit C-Arrays geht!? Das hört sich nach kompliziertem Blödsinn an, denn Hacker versucht dich zu verwirren und entmutigen! Ja, benutz weiter deine C-"Äquivalente" and never change a running system!

Und schöne Bezeichner hast du dir da ausgedacht. Da kommt zuerst das oft für metasyntaktische Variablenidentifier genutzte präfix my , dass bestimmt in so gut wie jedem professionellem Projektcode vorkommt. Dann natürlich ohne Präfix die Enumeratoren BLACK , WHITE , usw. genial! Das mann eigentlich ein universales Präfix davorsetzt um Enumeratoren eindeutig als solche und als Enumeratoren einer bestimmten Enumeration zu identifizieren ist C++-Gefrickel und wird dazu auch nur von Anfängern gemacht. Und überhaupt: strongly-typed enumerations erwähnen tun auch nur Forentrolle, nöch?

Aber mal abgesehen davon ist dein Konzept einfach umwerfend. Zuerst die Tatsache, dass der mapped_type der map keinerlei Informationen enthält, die nicht schon der String hat. Also Redundanz pur, oder? Nein! Nach wie vor ein Geniestreich!
Dazu die Tatsache, dass die map erst in der main() befüllt wird! Was für eine Kohäsionsmaximierung!
Wieso nicht vorschlagen, dass C++11 dank aggregate/uniform-initialisation eine viel schönere Schreibweise bereitstellt?
Ohh, da haben wir schon wieder das Wort "C++" drinnen, und das wollen wir doch nicht. Also bloß weg damit.

</irony>

Edit: Ich merke schon, 90% von dem was ich geschrieben hab' ist Blödsinn.

otze

Sone schrieb:

Sag mal bist du bescheuert oder was?

Ich glaube, er ist nicht nur geistig gesund, sondern hat auch Ahnung.

std::map<const char*, myColors) myColorMap;
Ich bin sicher, das ist eine einleuchtende Logik.
Wenn der Anfänger Templates schon nicht verstehen kann/will, brauchst du ihm nicht gleich einen STL-Container um die Ohren zu hauen

Siehst du hier eine einfachere Lösung, ohne viel Aufwand,die das Problem des Threaderstellers löst? Komm, raus damit.
Ausserdem warst du es, der Template Programmierung ins Spiel brachte. Und zwar auf einem wesentlich höheren Anforderungsniveau als "einfach mal std::map verwenden".
//edit ich würde aber statt const char* wirklich std::string verwenden, sonst gibts komisches Verhalten. Oder nen anderen key-compare verwenden.

und ihn gleich damit zu konfrontieren. Dazu noch mit syntaktisch falscher Deklaration.

Als ob du dich niemals vertippt hättest. Lächerlich. Sogar für deine Maßstäbe.

Andererseits, wenn schon ne map, dann wieso nicht gleich... std::(tr1::)array ?

1. Weil array das Problem vor C++11 nicht so elegant löst wie ein C-array. Probier es aus. Zeig uns, wie du all diese Farben so kurz definierst, wie durch eine einfache verschachtelte Array-Definition.
2. Weil array vor C++11 bei keinem Compiler verfügbar sein muss (technical report != standard).

Der Rest ist einfach nur Schrott und ich hab aufgehört deinen Post nach ca 2 weiteren Sätzen zu lesen.

pumuckl

*räusper* contenance...

Wutz

Sone schrieb:

Am einfachsten ist eine Struktur mit Non-Type Template-Parametern...

Schwachfug, die eindeutige Fragestellung mit haufenweise Templatemüll zu beantworten.

Sone schrieb:

IrgendeinName schrieb:

Also ein solches Array (Statisches C-Array) wird glaub ich schon in der Compilezeit angelegt.

Ähm, NEIN.

Doch, wobei das originale "Array" des Fragers nur ein vermaledeites VLA Zeugs ist, und somit eben nicht zur Compilezeit arbeitet.

// Defines a color
struct color {
    float red;
    float green;
    float blue;
};

// Size of the Color Enum and Array
const int SIZE_OF_MY_COLORS=12;  // das ist nur eine Laufzeitkonstante, und keine zur Compilezeit bekannte

enum myColors{
    BLACK, WHITE, BLUE, YELLOW, GREEN, PINK, ORANGE, LIGHTGREEN, CYAN, RED, GRAY, PURPLE
};

// hier mal eine Implementierung deines angefragten Arrays
// versuche mal, so globales Zeugs zu minimieren, auch wenn es const ist und es dir zunächst plausibel erscheint
const color COLORS[]={
{1,2,3}, // BLACK
{4,5,6}, // WHITE
{7,8,9}, // BLUE
...
{1,1,1}  // PURPLE
};

int main()
{
...
size_t SIZE_OF_MY_COLORS=sizeof(COLORS)/sizeof(*COLORS);

Wutz

Phys1k3r schrieb:

Andere Frage, ich benutze Visual Studio 2008, hat das überhaupt eine c++11 Unterstützung?

Nein, aber zumindest TR1 kannst du für den Compiler mit dem Featurepack noch nachinstallieren, da ist dann auch ein tr1::array Typ dabei:
http://www.microsoft.com/en-us/download/details.aspx?id=6922

Wutz

Th69 schrieb:

Noch ein Tipp:
du kannst auch SIZE_OF_MY_COLORS automatisch vom Compiler berechnen lassen:
enum myColor // Einzahl ist besser als Name (s.u.)
{
    BLACK, WHITE, BLUE, YELLOW, GREEN, PINK, ORANGE, LIGHTGREEN, CYAN, RED, GRAY, PURPLE,
    SIZE_OF_MY_COLORS
};

Hübsch aber unrobust und somit für Anfänger ungeeignet.
Z.B. bei

enum myColor // Einzahl ist besser als Name (s.u.)
{
    BLACK=1, WHITE, BLUE, YELLOW, GREEN, PINK, ORANGE, LIGHTGREEN, CYAN, RED, GRAY, PURPLE,
    SIZE_OF_MY_COLORS
};

dürften nur sehr wenige Compiler warnen.

Phys1k3r

Hallo,
ich habe jetzt den Code von Wutz genommen, da er simpel ist und funktioniert.

Jedoch verstehe ich den Nutzen dieser Codezeile nicht:

size_t SIZE_OF_MY_COLORS=sizeof(COLORS)/sizeof(*COLORS);

Das mit std::map<const char*, myColors) myColorMap; werde ich vielleicht nutzen. Ich muss noch abwägen, ob ich den kompletten Code umschreibe und die Strings komplett herausnehme (was länger dauert, aber sicherlich schöner ist) oder ob ich Zeit spare und Strings weiter verwende.

SeppJ

Phys1k3r schrieb:

Jedoch verstehe ich den Nutzen dieser Codezeile nicht:
size_t SIZE_OF_MY_COLORS=sizeof(COLORS)/sizeof(*COLORS);

Das ist die Gesamtgröße des Arrays geteilt durch die Größe des ersten Elementes, also die Anzahl der Elemente im Array.

Arrays zerfallen beim kleinsten Anzeichen von Gefahr zu einem Zeiger auf ihr erstes Element, sogenannter array to pointer decay (Man darf aber nie den Fehler machen, anzunehmen, Arrays und Pointer wären das gleiche!). Daher ist sizeof(*COLORS) ausgeschrieben das gleiche wie sizeof(*&COLORS[0]) . Hingegen ist sizeof(COLORS) eine der wenigen Ausnahmen vom array decay und man erhält die Größe des gesamten Arrays. Insgesamt ist das ein Standardweg, um die Elementzahl eines Arrays zur Compilezeit zu ermitteln, ohne dass man dessen Länge oder Typ kennen braucht.

Achtung: Das geht natürlich nicht, wenn man nur einen Zeiger auf ein Array vorliegen hat. Dann würde man mit sizeof die Größe des Zeigers erhalten. In C++ stellt sich diese Problematik aber in der Regel gar nicht erst, siehe dieser Thread.

Phys1k3r

Hallo,
das mit den Maps funktioniert soweit auch ganz gut.

Es ist eigentlich ziemlich simpel und ich denke, ich werde das vorerst so lassen.

std::map<std::string, int> myColorMap;

Eine Frage habe ich noch, welche Exception wird geworfen, wenn die Map den String nicht finden kann.

Ich würde das gerne mit try und catch abfangen.

Die c++ Reference schreibt etwas von einem Iterator, was mich nicht direkt weiterbringt.

EDIT: Habe gerade herausgefunden, dass überhaupt keine Exception geworfen wird..
Naja, erstmal weiter googlen und hoffen, dass hier noch eine einfache Antwort kommt

EDIT 2:
habe mir jetzt so einen Code zusammengebastelt:

Kann man das so durchgehen lassen?

// This is just for test issues
		std::string string =  "pfgurple";

		if(myColorMap.find(string) != myColorMap.end() )
			cout << "black ==> " << myColorMap.find(string)->second << endl;
		else
			cout << "ColorString was not found in colorMap" << endl;

Warum wurde der Link zum Buch immer noch von keinem Mod entfernt? So wird er nur weiter dupliziert (schon 4 Posts mittlerweile)...

SeppJ

zerärgert schrieb:

Warum wurde der Link zum Buch immer noch von keinem Mod entfernt? So wird er nur weiter dupliziert (schon 4 Posts mittlerweile)...

Immer mit der Ruhe, ein alter Mann ist kein ~~D-Zug~~ Wikipedia-Löschadmin.

Der Offtopicteil und alle Links zweifelhafter Legalität sollten nun vollständig entfernt sein.

Sone

Phys1k3r schrieb:

EDIT 2:
habe mir jetzt so einen Code zusammengebastelt:

Kann man das so durchgehen lassen?

// This is just for test issues
		std::string string =  "pfgurple";

		if(myColorMap.find(string) != myColorMap.end() )
			cout << "black ==> " << myColorMap.find(string)->second << endl;
		else
			cout << "ColorString was not found in colorMap" << endl;

Ja, das geht wunderbar. Allerdings ist es ein kleines bisschen ineffizient, weil du zwei mal den selben String suchst, den du doch schon beim ersten mal gefunden hast, mach es in Zukunft lieber so:

std::map<char const*, myColor>::const_iterator iter = myColorMap.find(string); ///Tja, hättest du einen C++11-kompatiblen Compiler, könntest du einfach auto benutzen :p
if(iter != myColorMap.end() )
        cout << "black ==> " << iter->second << endl;
else
        //..

Sone

SeppJ schrieb:

zerärgert schrieb:

Warum wurde der Link zum Buch immer noch von keinem Mod entfernt? So wird er nur weiter dupliziert (schon 4 Posts mittlerweile)...

Immer mit der Ruhe, ein alter Mann ist kein ~~D-Zug~~ Wikipedia-Löschadmin.

???
Ich dachte du bist 30?

SeppJ

Sone schrieb:

SeppJ schrieb:

zerärgert schrieb:

Warum wurde der Link zum Buch immer noch von keinem Mod entfernt? So wird er nur weiter dupliziert (schon 4 Posts mittlerweile)...

Immer mit der Ruhe, ein alter Mann ist kein ~~D-Zug~~ Wikipedia-Löschadmin.

???
Ich dachte du bist 30?

Werd mal 30 und dann beurteile das nochmal

Sone

SeppJ schrieb:

Sone schrieb:

SeppJ schrieb:

zerärgert schrieb:

Warum wurde der Link zum Buch immer noch von keinem Mod entfernt? So wird er nur weiter dupliziert (schon 4 Posts mittlerweile)...

Immer mit der Ruhe, ein alter Mann ist kein ~~D-Zug~~ Wikipedia-Löschadmin.

???
Ich dachte du bist 30?

Werd mal 30 und dann beurteile das nochmal

Ich weiß nicht, ob du mir jetzt Leid tun sollst

Wutz

Phys1k3r schrieb:

Die c++ Reference schreibt etwas von einem Iterator, was mich nicht direkt weiterbringt.

Tja, dass dich das nicht weiterbringt liegt am verkorksten Design von C++ map.
Es ist wirklich sinnfrei, einen Iterator zum Suchen nach dem unique(!) Key einer Map zu missbrauchen. Ein Iterator ist zum Iterieren da, kann aber bei Sucherfolg hier nicht weiter iterieren, da der Key ja unique ist.
Vernünftige Sprachen bieten deshalb für solcherlei simpler Basisfunktionalität entsprechende eigene Konstrukte an (also ohne Umweg über Iteratoren), und haben auch gar nicht erst solchen C++ Nonsens wie multimap (wo der Iterator evtl. sinnvoll einzusetzen wäre) oder gar multiset (ein Widerspruch in sich).

Kellerautomat

Wutz schrieb:

Tja, dass dich das nicht weiterbringt liegt am verkorksten Design von C++ map.

Ne. Das liegt daran, dass er die STL nicht kennt. Exceptions sind fuer unerwartete Ausnahmefaelle da. Dass das Element nicht vorhanden ist, ist wohl erwartet, oder?

Wutz schrieb:

Es ist wirklich sinnfrei, einen Iterator zum Suchen nach dem unique(!) Key einer Map zu missbrauchen.

Es ist wirklich sinnfrei, Speicherplatz auf dem c-plusplus.net-Server fuer deinen Post zu missbrauchen. :p

Wutz schrieb:

Ein Iterator ist zum Iterieren da, kann aber bei Sucherfolg hier nicht weiter iterieren, da der Key ja unique ist.

Klar kannst du mit einem Iterator "weiteriterieren". Und was du mit "da der Key ja unique ist" meinst, ist mir gaenzlich ein Raetsel.

Wutz schrieb:

Vernünftige Sprachen bieten deshalb für solcherlei simpler Basisfunktionalität entsprechende eigene Konstrukte an (also ohne Umweg über Iteratoren)

Dann zeig mir doch mal diese eigenen Konstrukte. Und bitte komm mir jetzt nicht mit Java/C#.

Wutz schrieb:

, und haben auch gar nicht erst solchen C++ Nonsens wie multimap (wo der Iterator evtl. sinnvoll einzusetzen wäre)

Nonsens?
Weil du keinen Anwendungsfall kennst, ist multimap also Nonsesns, hab ich das richtig verstanden? :p

Wutz schrieb:

oder gar multiset (ein Widerspruch in sich).

Weil?

Wutz

Kellerautomat schrieb:

Und was du mit "da der Key ja unique ist" meinst, ist mir gaenzlich ein Raetsel.

oder gar multiset (ein Widerspruch in sich).
Weil?

Weil du keine Ahnung hast, wovon du redest. map/set sind grundlegende Datenstrukturen, und zu solchen grundlegenden Datenstrukturen gehören elementare Funktionalitäten in einen Standard, aber das kannst du mit deinem zusammengegoogelten Halbwissen natürlich nicht wissen und versuchst es, mit naiver Dummdreistigkeit zuzudecken.