konstantes Array aus Strukturen

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.

Kellerautomat

Sag doch einfach mal konkret, was dir fehlt, dann kann man darueber diskutieren. Dieses duemmliche gebrabbel bringt niemanden weiter.

otze

Wutz schrieb:

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

du sprichst wahrscheinlich auf das fehlen einer direkten Existenzfunktion an. Aber das ist in den meisten Fällen bei einer map nicht das, was man will. In den allermeisten Fällen will man ja nicht nur wissen, ob das Element mit dem Schlüssel existiert, sondern das Element, bzw den damit assoziierten Wert, in dem Fall auch gleich haben. Semantishc hätte ich eine solche Existenzfunktion bei dem Set erwartet, kann aber auch aus der Sichtweise des Sets als Schlüssel-Wertpaar mit intrinsischen Schlüssel damit leben, dass die Funktion nicht existiert.

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

Ich möchte ja nicht immer nur den einen Schlüssel haben, sondern über eine Untermenge iterieren können, die durch zwei Schlüssel definiert ist. Anwendungen dafür gibt es zu hauf.

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).

Warum sollten Multisets ein Widerspruch in sich sein? Den Begriff gibt es in der Mathematik seit dne 70er Jahren, das Konzept ist auch bekannt als bag:
http://en.wikipedia.org/wiki/Multiset
Zudem verweis eich erneut auf das set/multiset als Map für intrinsische Schlüssel-Wertpaare.

Ich fürchte, da verrennst du dich gerade etwas.

Wutz

otze schrieb:

du sprichst wahrscheinlich auf das fehlen einer direkten Existenzfunktion an. Aber das ist in den meisten Fällen bei einer map nicht das, was man will.

Das ist aber die originale Frage hier gewesen.

otze schrieb:

In den allermeisten Fällen will man ja nicht nur wissen, ob das Element mit dem Schlüssel existiert, sondern das Element, bzw den damit assoziierten Wert, in dem Fall auch gleich haben.

Natürlich. Aber auch das kann die std::map (erst recht) nicht leisten. Nichts anderes habe ich gesagt, als ich von Basis/Elementarfunktionalitäten die in einen Standard gehören sprach.

otze schrieb:

Semantishc hätte ich eine solche Existenzfunktion bei dem Set erwartet,

Die Key-Folge einer map ist immer ein Set, aber auch beim Set gibts diese Elementarfunktion nicht, stattdessen muss man ein neues Objekt(!) Iterator bzw. bei equal_range sogar ein Paar Iteratoren neu definieren, nur um festzustellen, ob eine map/set einen unique Key nun enthält oder nicht, wobei das equal_range-it-Pair auch wieder redundant ist, da wegen des unique keys einer map der range immer gleich 1 ist. Das ist Sinnfreiheit pur, fehleranfällig und per se inperformant.
Ganz schlimm sieht es bei key_comp aus, mit dem man auch nach einem Key suchen kann; nachdem man mühsam ein neues Objekt hierfür erzeugen muss, kann man von dem noch nicht mal mehr auf den value referenzieren und muss doch wieder auf die map rückbeziehen.

otze schrieb:

Ich möchte ja nicht immer nur den einen Schlüssel haben, sondern über eine Untermenge iterieren können, die durch zwei Schlüssel definiert ist.

Nicht immer, aber meistens, siehe deine eigene Argumentation oben, zumal dieses Iterieren zwischen 2 Keys eine Sortierung dieser voraussetzt, und diese ständig aktuell zu halten, ist wiederum per se inperformant weil überhaupt nicht nötig für die Standardanwendungsfälle einer map/set. (die Key-Indizierung passiert meistens über Hashes und die sind nunmal üblicherweise nicht so sortiert wie ihre Basiswerte, d.h. um die definierte std::map Sortierung sicherzustellen, muss jedesmal (bei jedem Update in der map) die komplette Key-Folge durchsortiert werden).
Die verschämt mit TR1 nachgereichten unordered_map/set zeigen wie es gehen kann, sind aber bekanntlich eben nicht C++98 und somit nicht überall verfügbar.

camper

Wutz schrieb:

Die Key-Folge einer map ist immer ein Set, aber auch beim Set gibts diese Elementarfunktion nicht, stattdessen muss man ein neues Objekt(!) Iterator bzw. bei equal_range sogar ein Paar Iteratoren neu definieren, nur um festzustellen, ob eine map/set einen unique Key nun enthält oder nicht, wobei das equal_range-it-Pair auch wieder redundant ist, da wegen des unique keys einer map der range immer gleich 1 ist. Das ist Sinnfreiheit pur, fehleranfällig und per se inperformant.

Das ist nur dann inperformant, wenn es eine Methode gibt, sets/maps zu durchsuchen, ohne einen Iterator (oder etwas äquivalentes) zu verwenden. Ich kann mir keine Implementation vorstellen, bei der das der Fall wäre.
Abgesehen davon hindert dich ja nichts, eine contains-Funktionalität nachzurüsten.