3. std::vector mit Anfangswerten füllen

std::vector mit Anfangswerten füllen

  • ?

    Wie füllt man denn einen Vektor mit Anfangswerten? Angenommen ich hätte einen vector<int> und ich würde gerne fünf Zahlen als Anfangswerte reinschreiben. Muss ich dann ernsthaft jedes Element mit .push_back(zahl) reinschreiben? Da gibt es doch sicherlich eine elegantere Möglichkeit.

    0
  • ?

    wenns die gleiche zahl ist, dann std::vector<int> gf(anzahl,zahl)
    sonst auf den nächsten standrad warten.

    0
  • ?

    auf das nächste standrad waren, mein ich. 😃

    0
  • N

    Du kannst Boost.Assign nutzen:

    #include <boost/assign/list_of.hpp>

int main()
{
    std::vector<int> Vec = boost::assign::list_of(4)(5)(7)(3)(2);
}
    0
  • ?

    Boost.Assign sieht nach dem aus, was ich schmerzlich vermisse. Danke.

    0
  • N

    Boost ist sowieso unheimlich praktisch und mächtig. Schau doch mal bei http://www.boost.org/doc/libs/1_37_0 nach...

    0
  • R

    Vielleicht nicht schön aber funktionstüchtig:

    int startWerte[] = { 1, 2, 6, 2, 9, 3 };

std::vector< int > vec( startWerte, startWerte + sizeof( startWerte ) / sizeof( int ) );
    0
  • D

    och schrieb:

    Boost.Assign sieht nach dem aus, was ich schmerzlich vermisse. Danke.

    Hmm. Normalerweise hat man aber solche Werte, die in einen Container gehören ja auch nicht hard-gecodet. (Mache ich eigentlich nie, ausser kurz zu Testzwecken). Man lädt das eher irgendwo raus. (XML, Textdatei, binär, Datenbanken usw.)

    0
  • N

    rean schrieb:

    Vielleicht nicht schön [...]

    Damit hast du nur unnötige Duplizierung. Zudem ist dein Beispiel schlechter wartbar, da beispielsweise an drei Stellen int vorkommt. Wieso, wenns auch mit Boost.Assign geht? Das einzige Argument dafür wäre, aus irgendeinem Grund kein Boost einsetzen zu wollen (wobei man sich dann um diesen Grund streiten kann)...

    drakon schrieb:

    Hmm. Normalerweise hat man aber solche Werte, die in einen Container gehören ja auch nicht hard-gecodet. (Mache ich eigentlich nie, ausser kurz zu Testzwecken). Man lädt das eher irgendwo raus. (XML, Textdatei, binär, Datenbanken usw.)

    Das hatte ich aber auch schon. Halt eine Art Datenbank, die fest im Programm verankert ist (beispielsweise bei Spielen Daten über Gegner etc.).

    0
  • D

    Nexus schrieb:

    drakon schrieb:

    Hmm. Normalerweise hat man aber solche Werte, die in einen Container gehören ja auch nicht hard-gecodet. (Mache ich eigentlich nie, ausser kurz zu Testzwecken). Man lädt das eher irgendwo raus. (XML, Textdatei, binär, Datenbanken usw.)

    Das hatte ich aber auch schon. Halt eine Art Datenbank, die fest im Programm verankert ist (beispielsweise bei Spielen Daten über Gegner etc.).

    Naja. Da machst du lieber eine externe Datei, denn, wenn du ein wenig mit den Werten spielen willst ist das sehr mühsam da kleine Einstellungen zu machen und dann wegen dem Neu builden. 😉

    0
  • B

    drakon schrieb:

    Naja. Da machst du lieber eine externe Datei, denn, wenn du ein wenig mit den Werten spielen willst ist das sehr mühsam da kleine Einstellungen zu machen und dann wegen dem Neu builden. 😉

    So pauschal würde ich das nicht sagen. Im Normalfall liegen solche hartkodierten Werte in einer cpp-Datei, die Zeit zum Neukompilieren ist also fast Null. Und solche Daten auszulagern fügt dem ganzen relativ viel Komplexität hinzu, die oft nicht gerechtfertigt ist: Was ist, wenn die Datei nicht geladen werden kann, ein falsches Format hat usw? Zudem gibt's ja ab und an mal auch wirklich statische Daten, die wirklich nie verändert werden müssen.

    0
  • U

    Badestrand schrieb:

    drakon schrieb:

    Naja. Da machst du lieber eine externe Datei, denn, wenn du ein wenig mit den Werten spielen willst ist das sehr mühsam da kleine Einstellungen zu machen und dann wegen dem Neu builden. 😉

    So pauschal würde ich das nicht sagen. Im Normalfall liegen solche hartkodierten Werte in einer cpp-Datei, die Zeit zum Neukompilieren ist also fast Null.

    Man muss aber zumindest erst mal neu compilieren...

    Badestrand schrieb:

    Und solche Daten auszulagern fügt dem ganzen relativ viel Komplexität hinzu, die oft nicht gerechtfertigt ist: Was ist, wenn die Datei nicht geladen werden kann, ein falsches Format hat usw?

    Jopp - da ist was dran, aber ne exception reicht da ja - und dann gibt man halt aus, dass das programm neu installiert werden sollte, weil jmd die dateien (falsch) verändert hat..

    Badestrand schrieb:

    Zudem gibt's ja ab und an mal auch wirklich statische Daten, die wirklich nie verändert werden müssen.

    Jopp - aber mir fällt da 1. nich so viel ein und 2. gar nix wo man nen array bräuchte ^^

    Aber alles in Allem kommt es halt doch darauf an, welche Daten wann und wo etc...

    bb

    0
  • D

    Badestrand schrieb:

    drakon schrieb:

    Naja. Da machst du lieber eine externe Datei, denn, wenn du ein wenig mit den Werten spielen willst ist das sehr mühsam da kleine Einstellungen zu machen und dann wegen dem Neu builden. 😉

    So pauschal würde ich das nicht sagen. Im Normalfall liegen solche hartkodierten Werte in einer cpp-Datei, die Zeit zum Neukompilieren ist also fast Null. Und solche Daten auszulagern fügt dem ganzen relativ viel Komplexität hinzu, die oft nicht gerechtfertigt ist: Was ist, wenn die Datei nicht geladen werden kann, ein falsches Format hat usw? Zudem gibt's ja ab und an mal auch wirklich statische Daten, die wirklich nie verändert werden müssen.

    Ja, wenn sie wirklich nie veränder werden müssen, dann ist das OK, dazu gehören aber Spielerdaten bestimmt nicht. Und selbst "konstante" Daten können sich in einem Spiel einmal verändern. Irgendwann möchte ich die Gravitation vielleicht andersrt haben, als normal usw. Ich persönlich brauche praktisch keine Daten, die es wirklich rechtfertigen, dass ich sie im Code einbette.

    0
  • B

    Eigentlich geht's mir auch mehr um das Kriterium, wie man bestimmt, wann bestimmte Sachen ausgelagert werden sollen. Dafür gibt's ja in der Regel zwei Kriterien: Einmal, ob's für den/die Entwickler besser (in welcher Form auch immer) ist und zum Zweiten, ob die Auslagerung für den Endnutzer besser ist. Man sollte also nicht nur nach Kompilierzeiten urteilen (was du sicher nicht tust, es war aber dein einziges Argument in dem Post, vier über diesem).

    0
  • D

    Badestrand schrieb:

    Eigentlich geht's mir auch mehr um das Kriterium, wie man bestimmt, wann bestimmte Sachen ausgelagert werden sollen. Dafür gibt's ja in der Regel zwei Kriterien: Einmal, ob's für den/die Entwickler besser (in welcher Form auch immer) ist und zum Zweiten, ob die Auslagerung für den Endnutzer besser ist. Man sollte also nicht nur nach Kompilierzeiten urteilen (was du sicher nicht tust, es war aber dein einziges Argument in dem Post, vier über diesem).

    Wie meinst du das, ob es besser für den Endnutzer ist? - Er wird davon ja nichts zu spüren bekommen. Klar, sollte man seine Werte am Ende, bei der Auslieferung nicht zugänglich für jeden machen, aber dafür gibt es ja verschieden Methode, um das zu verhindern. Ein ein verschlüsseltes Archiv packen, Resource Dateien oder, was man auch machen kann am Ende die Werte in den Code einfügen. Wenn man sich auf das vorbereitet hat, ist das auch eine kurze Sache.

    0
  • B

    drakon schrieb:

    Wie meinst du das, ob es besser für den Endnutzer ist? - Er wird davon ja nichts zu spüren bekommen.

    Bei Spielen z.B. ist die Auslagerung für die Endnutzer sinnvoll, Modder können dann daran herumpfuschen. Manche Geo-Simulations-Software erlaubt damit Änderungen von (eigentlich fixen) Parametern. Ansonsten ist alles besser für den Endnutzer, was weniger RAM/HDD verbraucht, weniger fragmentiert oder was weiß ich.

    Drakon schrieb:

    In ein verschlüsseltes Archiv packen, Resource Dateien oder, was man auch machen kann am Ende die Werte in den Code einfügen. Wenn man sich auf das vorbereitet hat, ist das auch eine kurze Sache.

    Ich will Auslagerung auf keinen Fall verteufeln, so ist's nicht. Es muss halt sinnvoll sein und möglichst wenig Angriffsfläche für Fehler bieten.

    0
  • N

    Ich würde auch sagen, es kommt auf den Fall drauf an. Zudem ist es auch ein wenig Geschmackssache. 😉

    Bei Spielerdaten kann eine Einbettung im Code meiner Ansicht nach schon gerechtfertigt sein (kommt halt drauf an, was). Solche Daten sollten sich eigentlich nur ändern, wenn eine neue Version fällig ist, und da muss man sowieso Diverses neu schreiben und neu kompilieren, sodass diese Änderung kaum ins Gewicht fällt.

    0
Anmelden zum Antworten