Maximale Größe von std::vector

Dravere

holy shit! schrieb:

ist es denn nun tatsächlich so, dass ein std::vector auf meinen compiler nur 4 elemente speichern kann, wenn size_t eine größe von 4 hat?

Soll man auf sowas wirklich antworten? Naja, falls ein Noob über den Thread stolpert ...
Er meinte:

#include <limits>
#include <iostream>

#include <cstddef>

int main()
{
  std::cout << std::numeric_limits<std::size_t>::max()
            << std::endl;

  return 0;
}

Aber wie ich schon weiter vorne gepostet habe, hat std::size_t nix mit der maximalen Grösse des std::vector am Hut.

Grüssli

Dravere schrieb:

Bis du dann sowas hast:
#include <algorithm>

using namespace std;

int max(int lhs, int rhs)
{
  return lhs > rhs ? lhs : rhs;
}

int main()
{
  cout << max(4, 223) << endl;
  return 0;
}
Ups, der Kompiler weiss nicht welches max .
using namespace hebelt den Sinn von Namensräumen aus.

Hä? using namespace deswegen zu verteufeln ist ja wohl etwas weit hergeholt. Dann macht man halt das:

#include <algorithm>

using namespace std;

int max(int lhs, int rhs)
{
  return lhs > rhs ? lhs : rhs;
}

int main()
{
  cout << ::max(4, 223) << endl; // Globaler Scope! Und schon weiß der Compiler was genutzt werden soll
  return 0;
}

Im übrigen würde man aber max eh nicht im globalen Scope anlegen. Du hast doch selber eine Regel gebrochen, obwohl du auf eine andere plädierst. Mein max würde ich auch in meinem namespace anlegen, anstatt using namespace zu verteufeln.

Dravere schrieb:

Soll man auf sowas wirklich antworten?

Bulli schrieb:

Der Vector kann soviel Elemente verwalten, wie size_t auf deinem Compiler groß ist.

soll man sowas wirklich einfach stehen lassen?

Dravere

@Bulli,
Es ging doch nur darum aufzuzeigen, dass ein Namenskonflikt passieren kann. Ich wollte kein vollwertiges riesiges Konstrukt bauen, wo dann per Zufall ein Namenskonflikt entsteht. Es ist doch nur ein BEISPIEL.

Zudem verteufle ich es nicht. Ich rate nur zur Vorsicht. Herje.

@"nö du",
Da die Aussage sowieso falsch ist, ist es egal.

Grüssli

mowo*fs*

Wow. Das war aber ganz schön Off Topic.

Auf jeden Fall Danke an alle die was beigetragen haben.
Jetzt läuft das Programm. Ich war kurz davor std::deque zu verwenden,
da hab ich mir gedacht versuchs doch mal so:
Da ich ja am Anfang nicht weis wie groß der Vector wird habe ich ihn
immer für jeden Eintrag mir resize erweitert. Jetzt hab ich erst die
Zeilen in der Datei gezählt, die vectoren einmal angelegt und siehe da: Es geht!
Kostet mich aber 30 sec. mehr Laufzeit. Aber bei 2-5 Stunden läßt sich das verschmerzen

Ja, das ist eine sehr gute Lösung! Denn so wird der Speicher nicht unnötig fragmentiert, was ja vorher wohl tatsächlich mächtig freien Speicher verschwendete.

unskilled

Da ich ja am Anfang nicht weis wie groß der Vector wird habe ich ihn
immer für jeden Eintrag mir resize erweitert.

Aber dir ist klar, dass das unnötig war?!

Jetzt hab ich erst die Zeilen in der Datei gezählt, die vectoren einmal angelegt und siehe da: Es geht! Kostet mich aber 30 sec. mehr Laufzeit. Aber bei 2-5 Stunden läßt sich das verschmerzen

Das halt ich für nen Gerücht, dass es jz länger braucht, obwohl es nicht mehr aller x Einträge umkopieren muss...
btw: Im Release-Mode compiliert?

bb

mowo*fs*

es dauert definitiev länger.
Ich mess die Zeit mit:
time(&start);
...vectoren anlegen, datei einlesen...
time(&stop);
cout << stop-start << endl;
(was ich der einfachheit halber unterschlagen hab: in der datei
stehen die zeilen nicht einfach so sondern in sektionen unterteilt.
am anfang jeder sektion steht wie viele zeilen jetzt kommen.
Typischerweise einige tausend... also wird der wevtor nicht bei
jeder zeile vergrößert sondern immer in tausenderschritten)

macht ne differenzevon 30 sec.

ansonsten verwende ich den intel C++ Compiler 11 mit den Parametern:
icpc -openmp -parallel -fast main.cpp

Bin aber noch nicht so der Compilerexperte. Wenn jemand optionen kennt die die
Performance verbessern könnten... Her damit!

Nexus

mowo(fs) schrieb:

Wenn jemand optionen kennt die die
Performance verbessern könnten... Her damit!

Du könntest doch mal die einzelnen Containertypen ausprobieren.

Wenn es dir wirklich wichtig ist, kannst du auch mit einem Profiler untersuchen, wo sich die Performance-Flaschenhälse in deinem Programm befinden. Auf diese Weise kann sowieso besser optimiert werden als auf gut Glück.

mowo*fs*

profiler.... keine Ahnung was das ist.
Hast du Links/Howtos für mich?

volkard

tu mal brav push_back benutzen, um den vector zu füllen. und tu nutze nicht resize benutzen! das macht der push_back automatisch und viel besser als du.

und nur wenn das dann nicht klappt, weil du zu wenig speicher hast, dann steig um und benutze queue.

pumuckl

mowo(fs) schrieb:

profiler.... keine Ahnung was das ist.
Hast du Links/Howtos für mich?

http://lmgtfy.com/?q=profiler+C%2B%2B

mowo*fs*

pumuckl du bist mein held!
google. geniale seite! wie bin ich nur so lange ohne die ausgekommen?

Ne, mal im ernst: hat wer ne empfehlung für mich?
Linux Profiler für Intell C++ 11 & OpenMP?
Dann muß ich nicht erst 3 Seiten Google durchlesen.

drakon

Wie wäre es mit Valgrind?

http://valgrind.org/