Includes scheinen nicht richtig zu funktionieren (unerkärlicher Fehler!)

[Th69]

Ein bitset unterstützt nicht den Kleiner-Operator (<), daher kannst du diesen wohl nicht in einer map als Key angeben, s.a. http://www.cplusplus.com/reference/stl/bitset

Evtl. könntest du selber der map als dritten Parameter eine Vergleichsfunktion anbieten (welche auf Basis von to_ulong zwei bitsets vergleicht).

[Die erinnerung]

Wie sähe der Aufruf von map dann aus?

[Dravere]

Die erinnerung schrieb:

Also meinst du im Prinzip, dass ich alle includes in eine eigene Header-Datei-stecken soll und die in alle anderen Datein includen?

Nein? Ich habe nichts annähernd in der Richtung gesagt...

Die erinnerung schrieb:

Wie sähe der Aufruf von map dann aus?

Aufruf? Du meinst Deklaration/Definition?
std::map hat einen dritten Templateparameter, welcher dazu genutzt werden kann, einen Funktortyp zu übergeben. Standardmässig ist das die Klasse less<T> , welche den operator < verwendet. Du könntest daher diese Klasse für dein bitset spezialisieren oder, was ich eher empfehlen würde, einen eigenen Funktor schreiben.

Zum Beispiel:

struct Bit25Comparator
{
  bool operator ()(Bit25 const& lhs, Bit25 const& rhs) const
  {
    // ... mach hier deinen Vergleich und gib das Ergebnis zurück
  }
};

typedef std::map<Bit25, Block_Container, Bit25Comparator> World;

Grüssli

[Die erinnerung]

Ich habs jetzt anders gelöst:

Mit unordered_map !

Ist im Prinzip das gleiche, wie map, nur, dass hier nichts sortiert wird!

[Dravere]

Die erinnerung schrieb:

Ist im Prinzip das gleiche, wie map, nur, dass hier nichts sortiert wird!

Aja? Das ist mir neu.

Im übrigen funktioniert dies nur, weil es in C++11 eine Spezialisierung von std::hash für std::bitset gibt. Auch std::unordered_map hat einen dritten Templateparameter wie std::map .

Ich habe langsam das Gefühl, du umschiffst all deine Unkenntnisse und behebst dies mit sehr fragwürdigen Methoden. Vielleicht solltest du eher mal versuchen, dein Wissen aufzupeppen.

Grüssli

[Die erinnerung]

Dravere schrieb:

Ich habe langsam das Gefühl, du umschiffst all deine Unkenntnisse und behebst dies mit sehr fragwürdigen Methoden.

Wer umschifft den nicht seine Unkenntnisse?

Ich weiß ja nichtmal, wonach ich suchen soll!

Aber unordered_map ist, denke ich, für mein Problem besser, da ich hier teilweise bis zu 16 Mio. (fast 17) Elemente speichern können muss, und kein Bedarf herrscht, die sortiert zu haben.

Falls meine Meinung hier falsch sein sollte, kläre mich bitte auf!

[Dravere]

Die erinnerung schrieb:

Wer umschifft den nicht seine Unkenntnisse?

So gut wie alle? Wenn ich etwas nicht weiss, dann informiere ich mich darüber. Sonst wähle ich womöglich eine ungünstige oder gar schlechte Lösung aus. Und vor allem bilde ich mich nie weiter und werde diese Unkenntnis immer haben.

Die erinnerung schrieb:

Ich weiß ja nichtmal, wonach ich suchen soll!

Dann frag! Dazu ist das Forum ja da! Wir haben hier schon einige Begriffe genannt, nach welchen du suchen kannst und sonst darfst du ja gerne nachfragen, falls du zu etwas wirklich nichts findest.

Die erinnerung schrieb:

Aber unordered_map ist, denke ich, für mein Problem besser, da ich hier teilweise bis zu 16 Mio. (fast 17) Elemente speichern können muss, und kein Bedarf herrscht, die sortiert zu haben.

Das kommt ganz auf den Problemfall und die Implementierung von std::map und std::unordered_map an. Dass std::map die Elemente nach einem Schlüssel sortiert, ist einfach nur ein Nebenprodukt davon, wie die Elemente abgelegt werden. Ich setze oft std::map ein und benötige es nicht, dass die Elemente sortiert sind.

Grüssli

[Die erinnerung]

Wie ja schon gesagt:

Das sollen bis zu 16 Mio. Elemente rein. Und wenn dann bei jedes neues Element erstmal frisch ein sortiert werden muss, dauert das dann doch recht lange.

Deshalb bin ich in diesem Fall für unordered_map.

[Millionen Elemente]

16 Mio. Elemente?
Und dann Quelltext, von dem der Autor nicht genau weiss was abgeht?

Mutig, mutig.

Okay, diese 16 Mio.Elemente schreibst du in die Map. Und wozu? Sollen die wieder ausgelesen werden? In einem Rutsch? Nach bestimmten Kriterien?

[seldon]

Erstens: Wenn ein neues Element in eine std::map eingeügt wird, muss deshalb nicht die gesamte Map neu sortiert werden. Es muss nicht mal der Inhalt der Map hin- und hergeschoben werden. In der Regel steckt hinter std::map ein RB-Baum; von dessen Laufzeitverhalten kannst du also ausgehen.

Zweitens: Hashmaps (eine solche ist unordered_map) können eine Menge Performance bringen, im Umgang mit ihnen ist aber einige Vorsicht geboten. Wenn du nicht weißt, wie eine Hashmap funktioniert, lass die Finger davon. Lass insbesondere dann die Finger davon, wenn die Daten aus einer nicht vertrauenswürdigen Quelle kommen und/oder du nicht überblicken kannst, wie die Verteilung deiner Schlüsselwerte vermutlich aussieht. Wer solche Bedenken beiseite schiebt, macht sich verwundbar.

[Die erinnerung]

Nein, ich brauch das für ein Spiel. Die Map besteht halt aus bis zu 16 Mio. Elementen/Blöcken.

Und da brauche ich eine effiziente Verwaltung. Die Elemente füge ich selbst ein und ich verwalte sie auch.

[f.-th.]

Ein Spiel?
Sind das diese Dinger mit 23,546 Frames/Minute

Wenn nicht, musst du, glaube ich, deine Programmierfähigkeiten noch deutlich updaten

[Die erinnerung]

Wieso?
Also ich verstehe den Sinn deiner Antwort nicht!