ich habe folgenden Code:

int    groesse=100;
double *data;

data = new double [groesse];

// Funktionsaufruf

delete[] data;

Angenommen, ich brauche im Verlauf des Programms ein Array, dass grösser als 100 ist, wie kann ich mein 'data' dann am besten vergrößern, so dass zu den ursprünglichen 100 Werten noch mehr Werte abgelegt werden können. Mit 'vector' will ich es aber nicht machen, sondern einfach das 'data' vergrößern.

Danke Euch.
V.K.

Ich will keinen Vektor, weil ich dachte, dass bei sehr hohen Datenmengen die Arbeit mit vectoren länger dauert. Nicht richtig?

Kannst du deine Vermutung begründen?

Die Vermutung basiert auf der Meinung von meinen Arbeitskollegen, die vectoren bei großen Datenmengen ablehnen, weil aufgrund des Listenaufbaus die Suche nach bestimmten Daten zu lange dauern würde.

Dann solltest du in Zukunft auf solche Meinungen (Meinungen, sie scheinen keine Fakten zu liefern) kritisch hinterfragen! Haben sie Performancetests gemacht? Nein! Haben sie sich den ISO-C++-Standard bzgl. std::vector durchgelesen? Nein! haben sie sich die Implementierung ihrer vector-Implementierung angeschaut? Nein!

Und dann stellen die so eine Behauptung auf? Einfach nur unprofessionell.

Lass dir gesagt sein, das ein Vector 100% die gleiche Performance wie ein rohes Array hat. Warum? Weil das der ISO-C++-Standard vorgibt. Lediglich eine nicht ISO-konforme Implementierung könnte hier langsamer sein. Aber das ist in der heutigen Zeit eher unwahrscheinlich, da ich mal davon ausgehe, das ihr eine vernünftige C++-Compiler-Suite einsetzt.

Dann solltest du in Zukunft auf solche Meinungen (Meinungen, sie scheinen keine Fakten zu liefern) kritisch hinterfragen! Haben sie Performancetests gemacht? Nein! Haben sie sich den ISO-C++-Standard bzgl. std::vector durchgelesen? Nein! haben sie sich die Implementierung ihrer vector-Implementierung angeschaut? Nein!

Ist mir irgendwie schon oft aufgefallen, grad bezüglich der STL, das dieser extremes Ausbremsen der Programme vorgeworfen wird. Und jedesmal ohne wirkliche Fakten zu nennen!

Die Vermutung basiert auf der Meinung von meinen Arbeitskollegen, die vectoren bei großen Datenmengen ablehnen, weil aufgrund des Listenaufbaus die Suche nach bestimmten Daten zu lange dauern würde.

Vom Suchverhalten sind beide genauso schlecht. Für eine Suche ist weder ein Array noch ein Vector (ist eigentlich immer ein Array, kümmert sich aber selbstständig um Speicherallokierung...) bei großen Datenmengen zu empfehlen. Dafür gibt es andere Container.

VerbalKint schrieb:

Die Vermutung basiert auf der Meinung von meinen Arbeitskollegen, die vectoren bei großen Datenmengen ablehnen, weil aufgrund des Listenaufbaus die Suche nach bestimmten Daten zu lange dauern würde.

Vom Suchverhalten sind beide genauso schlecht. Für eine Suche ist weder ein Array noch ein Vector (ist eigentlich immer ein Array, kümmert sich aber selbstständig um Speicherallokierung...) bei großen Datenmengen zu empfehlen. Dafür gibt es andere Container.

du nimmst mir die worte aus dem mund

ein array ist ein array und keine liste!

... und ein std::vector auch (hat zumindestens dessen Zugriffszeit).

Gruß,

Simon2.

...
Dann solltest du in Zukunft auf solche Meinungen (Meinungen, sie scheinen keine Fakten zu liefern) kritisch hinterfragen! Haben sie Performancetests gemacht? Nein! Haben sie sich den ISO-C++-Standard bzgl. std::vector durchgelesen? Nein! haben sie sich die Implementierung ihrer vector-Implementierung angeschaut? Nein!...

Ja - gaaanz so hart würde ich nicht mit ihm ins Gericht gehen. Immerhin hat er ganz klar hervorgehoben, dass es sich um eine Vermutung und eine Meinung (eines Kollegen) handelt. Das ist schon deutlich kritischer als einige Andere hier (Euch natürlich alle ausgenommen) auftreten und das alles als "FAKT" ( ) darstellen.

Und ehrlich gesagt: Ich schlage auch nicht alles selbst in Std nach, was camper, CStoll und Du hier posten. :p
=> Ich vertraue auch Meinungen Anderer (meistens solcher, denen ich mehr KnowHow zutraue) - und Ihr bestimmt auch hier und da.

Gruß,

Simon2.

Das Hauptproblem was zu der "angeblichen Inperformance" der STL fuehrt, ist doch das c-programmierer, oder C++ im C-Stil programmierer mit der STL "konfrontiert" werden und kaum Gelegenheit haben hinter die kulissen zu schauen. Und die Literatur oder andere sogenannte "Experten" tun ihr uebriges.
Wo wird denn schon unterschieden, ob nen C-array dynamisch oder statisch ist um es von nem Vector ersetzen zu lassen ? Neee wenn, dann wird gleich alles ersetzt, obwohl nen vector beim erzeugen nie die performance eines statischen arrays erreichen kann. Besonders bei den strings gilt das halt ... std::string mag zwar modern sein, aber gegen einen buffer fester groesse wie in C oft verwendet wird hat er keine chance.
Bestes beispiel aus der Praxis, der Performance Test der entwicklungsumgebungen in der CT damals, wo .Net gegen JavaRT und STL angetreten sind. Letzter Platz eindeutig - die STL. Jeder der bisserl von C++ und STL ahnung hatte brauchte sich ned wundern, weil so wie der Autor die STL verwendet hatte, tun das maximal blutige Umsteiger bei ihren ersten Gehversuchen
Auf die Kritik folgte dann halt der die Verteidigung, das durchaus da optimierungspotential vorhanden waer, aber man eben darauf Wert gelegt haette die Tools so zu verwenden wie man es in der Praxis meist taete
Naja dann brauchen wir uns doch nicht zu wundern ...

Ciao ...

Lass dir gesagt sein, das ein Vector 100% die gleiche Performance wie ein rohes Array hat. Warum? Weil das der ISO-C++-Standard vorgibt. Lediglich eine nicht ISO-konforme Implementierung könnte hier langsamer sein. Aber das ist in der heutigen Zeit eher unwahrscheinlich, da ich mal davon ausgehe, das ihr eine vernünftige C++-Compiler-Suite einsetzt.

Ziemlicher Unfug wird hier behauptet. Was der ISO-C++-Standard vorgibt und was technisch möglich ist sind zwei verschiedene paar Schuhe. Die Indexprüfung entfällt beim Zugriff auf ein rohes Array. Implizit findet eine Indexprüfung beim Zugriff auf einen Vector statt. Letzere Operation kostet Zeit. Es ist deshalb weder technisch und obendrein aus rein logischen Gründen unmöglich, dass man auf Vektordaten 100% genau so schnell zugreifen kann wie auf Arraydaten.
Es sei denn jemandem fällt eine Möglichkeit ein, mit der die implizite Indexprüfung NULL Taktzyklen dauert. Technisch unmöglich, und deshalb ist es unerheblich, was der ISO-C++-Standard in dieser Sache (angeblich) vorgibt.
Die Herren, die den ISO-C++-Standard erfunden haben, haben aber zweifellos genügend Ahnung von technischer Informatik. Folgerung: Es gibt eine solche Vorschrift im ISO-C++ Standard deshalb nicht. Es sei denn Phantasten wie Artchie hätten in dem Gremium das Sagen.

Implizit findet eine Indexprüfung beim Zugriff auf einen Vector statt.

Nein.

TechnischerFreak schrieb:

Implizit findet eine Indexprüfung beim Zugriff auf einen Vector statt.

Nein.

Es finden noch viel abenteuerliche Dinge als eine Indexprüfung statt. (Automatische) Speicheranforderung, wenn man außerhalb der Vectorgrenzen zugreifen möchte ist da nur ein Beispiel. Ganz ohne das Zutun und oft auch ohne das Wissen des Programmierers.

Aber jeder kann gerne ein geeignetes kleines Testprogramm, einmal mit dyn. Array- und alternativ mit Vector- Datenbehälter schreiben, in dem 100.000 mal eingefügt und 100.000 mal gelesen wird, und das stoppen. (ohne es jetzt probiert zu haben, aber mit dem Vector dauern diese Operationen dreimal so lange). Etwas Geduld, ...

reference
vector::operator[](size_type __n)
{ return *(begin() + __n); }

wo ist da auch nur ein check, der die performance beeinflusst? richtig: es gibt keinen.

Artchi schrieb:

Lass dir gesagt sein, das ein Vector 100% die gleiche Performance wie ein rohes Array hat. Warum? Weil das der ISO-C++-Standard vorgibt. Lediglich eine nicht ISO-konforme Implementierung könnte hier langsamer sein. Aber das ist in der heutigen Zeit eher unwahrscheinlich, da ich mal davon ausgehe, das ihr eine vernünftige C++-Compiler-Suite einsetzt.

Ziemlicher Unfug wird hier behauptet. Was der ISO-C++-Standard vorgibt und was technisch möglich ist sind zwei verschiedene paar Schuhe. Die Indexprüfung entfällt beim Zugriff auf ein rohes Array. Implizit findet eine Indexprüfung beim Zugriff auf einen Vector statt.

Nein

Letzere Operation kostet Zeit. Es ist deshalb weder technisch und obendrein aus rein logischen Gründen unmöglich, dass man auf Vektordaten 100% genau so schnell zugreifen kann wie auf Arraydaten.
Es sei denn jemandem fällt eine Möglichkeit ein, mit der die implizite Indexprüfung NULL Taktzyklen dauert. Technisch unmöglich, und deshalb ist es unerheblich, was der ISO-C++-Standard in dieser Sache (angeblich) vorgibt.
Die Herren, die den ISO-C++-Standard erfunden haben, haben aber zweifellos genügend Ahnung von technischer Informatik.

Nein

Folgerung: Es gibt eine solche Vorschrift im ISO-C++ Standard deshalb nicht. Es sei denn Phantasten wie Artchie hätten in dem Gremium das Sagen.

Koffer

Es finden noch viel abenteuerliche Dinge als eine Indexprüfung statt. (Automatische) Speicheranforderung, wenn man außerhalb der Vectorgrenzen zugreifen möchte ist da nur ein Beispiel. Ganz ohne das Zutun und oft auch ohne das Wissen des Programmierers.

Diese Behauptung ist in der Tat der Brüller des Tages!

Simon2 schrieb:

...Immerhin hat er [VerbalKint AnmdVerf] ganz klar hervorgehoben, dass es sich um eine Vermutung und eine Meinung (eines Kollegen) handelt. Das ist schon deutlich kritischer als einige Andere hier (Euch natürlich alle ausgenommen) auftreten und das alles als "FAKT" ( ) darstellen...

Also von mir nochmal ein explizites Lob an VerbalKint, der weiß und klar äußert, wo er Ahnung hat und wo nicht.

Gruß,

Simon2.

LordJaxom schrieb:

TechnischerFreak schrieb:

Implizit findet eine Indexprüfung beim Zugriff auf einen Vector statt.

Nein.

Es finden noch viel abenteuerliche Dinge als eine Indexprüfung statt. (Automatische) Speicheranforderung, wenn man außerhalb der Vectorgrenzen zugreifen möchte ist da nur ein Beispiel. Ganz ohne das Zutun und oft auch ohne das Wissen des Programmierers.

Aber jeder kann gerne ein geeignetes kleines Testprogramm, einmal mit dyn. Array- und alternativ mit Vector- Datenbehälter schreiben, in dem 100.000 mal eingefügt und 100.000 mal gelesen wird, und das stoppen. (ohne es jetzt probiert zu haben, aber mit dem Vector dauern diese Operationen dreimal so lange). Etwas Geduld, ...

Du solltest mal 2 Dinge tun: zum einen den Standard lesen und zum anderen genau das, was Du vorschlägst.

Der opertor[] von std::vector macht keine Indexprüfung und vergrössert auch nicht automatisch den Speicher. Das macht die std::map. Das hast Du vielleicht verwechselt.

Der vollständigkeit halber habe ich 2 kleine Testprogramme geschrieben. Das Ergebnis ist, daß der std::vector genausso schnell ist, wie das array. Hier meine Programme (und immer schön mit -O2 übersetzen, wenn Geschwindigkeit getestet wird):

#include <iostream>

const unsigned N = 1000000;

int main(int argc, char* argv[])
{
  try
  {
    int a[N];
    for (unsigned n = 0; n < 10; ++n)
    {
      for (int i = 0; i < N; ++i)
        a[i] = i;
      int sum = 0;
      for (int i = 0; i < N; ++i)
        sum += a[i];
      std::cout << sum << std::endl;
    }
  }
  catch (const std::exception& e)
  {
    std::cerr << e.what() << std::endl;
  }
}

#include <iostream>
#include <vector>

const unsigned N = 1000000;

int main(int argc, char* argv[])
{
  try
  {
    std::vector<int> a(N);
    for (unsigned n = 0; n < 10; ++n)
    {
      for (int i = 0; i < N; ++i)
        a[i] = i;
      int sum = 0;
      for (int i = 0; i < N; ++i)
        sum += a[i];
      std::cout << sum << std::endl;
    }
  }
  catch (const std::exception& e)
  {
    std::cerr << e.what() << std::endl;
  }
}

PS: man kann es natürlich auch so ausdrücken, wie LordJaxom

Mit dem GCC 4.1 (-O3) auf Linux kann ich seine Beobachtung bestätigen. Da sind die beiden Testprogramme aber auf die Nanosekunde gleich schnell (über Durchschnitt natürlich).

Mit dem MSVC++ 8.0 (Release) ist die Vector-Implementierung im Schnitt 15% langsamer als die Array-Implementierung. Von Faktor zwei oder gar drei ist hier jedoch überhaupt nichts zu sehen.