funktion , quadratisches mittel

hustbaer

BTW:
@5cript sagte in funktion , quadratisches mittel:

x.resize(n);

for(int i=0; i<n; i++)
{
    cout << i << " Wert: " << endl;
    cin >> x[i];
}

Das finde ich z.B. OK.

Wobei man auch i < x.size() statt i < n schreiben könnte. Das wäre vermutlich nochmal besser.

Bzw. falls man den Index nicht braucht dann gleich

x.resize(n);

for(auto& e : x)
    cin >> e;

5cript

@hustbaer sagte in funktion , quadratisches mittel:

Die Teile wo eingefügt (bzw. bei deiner Variante zugewiesen) wird. Von denen ist es schliesslich abhängig wie anfällig das ganze dafür ist bei Modifikationen kaputtzugehen.

0% Propability

std::vector <T> v(n)
std::fill(std::begin(v), std::end(v), [](*...*/){/*...*/});

std::vector <T> v(/*size of source*/)
std::copy(std::begin(source), std::end(source), std::begin(v));

std::vector <T> v(/*size of source*/);
std::transform(std::begin(source), std::end(source), std::begin(v), std::end(v), [](/*...*/){/*...*/});

std::vector <T> v(/*size of source*/);
// using boost zip_iterator for parallel iteration

...

@hustbaer sagte in funktion , quadratisches mittel:

Vorher Grösse ausrechnen und dann reinschreiben ist potentiell fehleranfällig, da man die Grösse dann an zwei Stellen im Code dupliziert hat

nö

EDIT: aarggghh, das passt nicht alles direkt aufs anfangsproblem, aber das steht oben ja schon von mir und hab ich abgehakt.

hustbaer

@5cript
Ja, deine Beispiele sind OK. Da wird aber auch nirgends vorher die Grösse ausgerechnet.

Glaub mir bitte, ich hab schon genug Fälle gesehen wo beknacktes Zeug stand wie

vec.resize(a - 1 + b * 2);

size_t i = 0;

for (size_t j = 1; j < a; j++)
    vec[i++] = ...;

for (size_t j = 0; j < b; j++) {
     vec[i++] = ...;
     vec[i++] = ...;
}

Sowas finde ich nicht OK.

Und dazwischen, also zwischen solchem Code und dem den du gezeigt hast gibt es halt eine Grauzone.

5cript

@hustbaer sagte in funktion , quadratisches mittel:

Glaub mir bitte, ich hab schon genug Fälle gesehen wo beknacktes Zeug stand wie
vec.resize(a - 1 + b * 2);

size_t i = 0;

for (size_t j = 1; j < a; j++)
    vec[i++] = ...;

for (size_t j = 0; j < b; j++) {
     vec[i++] = ...;
     vec[i++] = ...;
}

mildes igitt.
Hmmm. Unter den Umständen stimme ich dir zu.

hustbaer

Ich meine, du hast halt in diesem Thread geschrieben

Grundsätzlich: Wenn man die größe des vectors von anfang an kennt, dann in der größe erstellen oder resizen. Es tut nicht weh das immer zu machen.
Denn push_back bedeutet potentiell mehrere Vergrößerungen, sprich reallokationen.

(Emphasis by me)

Und das war mit zu allgemein/absolut formuliert. Wenn es einfach und sicher geht, klar, wieso nicht? Wenn es nicht einfach geht aber man sich die Arbeit mache es irgendwie kompliziert und sicher zu machen halte ich es für eine sinnlose Optimierung. Und wenn man es nicht sicher macht, dann ... ist es eben fehleranfällig.

Das ist alles.

5cript

@hustbaer sagte in funktion , quadratisches mittel:

Und das war mit zu allgemein/absolut formuliert.

@5cript sagte in funktion , quadratisches mittel:

mildes igitt.
Hmmm. Unter den Umständen stimme ich dir zu.

Ok. Jetzt haben wir wieder den gemeinsamen Faden gefunden.
Ja das war zu allgemein formuliert.
Im Kopf hatte ich was in meinen Beispielen zu lesen ist im Gegensatz zu:

std::vector v;
//v.reserve(/*size of source*/);
for (IterType i = begin; i != end; ++i)
{
    v.push_back(source[i]);
}

hustbaer

Ich hatte extra geschrieben "als allgemeiner Rat ist das denke ich schlecht"

wob

@5cript sagte in funktion , quadratisches mittel:

Und was ist bitte der Vorteil davon?
Man verliert doch dann das komplette interface.

Naja, ich habe viele Beispiele gesehen, wo eben die Größe am Anfang der Funktion bekannt ist und man dann eben nur Speicherplatz für eine feste Anzahl an Elementen braucht. In diesen Fällen braucht man keinen vector. Ich dachte, dass du auch auf solche Fälle hinauswillst. Wohl nicht.

5cript

@wob sagte in funktion , quadratisches mittel:

@5cript sagte in funktion , quadratisches mittel:

Und was ist bitte der Vorteil davon?
Man verliert doch dann das komplette interface.

Naja, ich habe viele Beispiele gesehen, wo eben die Größe am Anfang der Funktion bekannt ist und man dann eben nur Speicherplatz für eine feste Anzahl an Elementen braucht. In diesen Fällen braucht man keinen vector. Ich dachte, dass du auch auf solche Fälle hinauswillst. Wohl nicht.

ok

HarteWare

@5cript Ich wollte das jetzt nicht mega kritisieren... ich finde es nur immer interessant, verschiedene Ansätze zu verstehen. In dem Sinne war diese Diskussion dann doch produktiv

It0101

@wob sagte in funktion , quadratisches mittel:

@5cript sagte in funktion , quadratisches mittel:

Und was ist bitte der Vorteil davon?
Man verliert doch dann das komplette interface.

Naja, ich habe viele Beispiele gesehen, wo eben die Größe am Anfang der Funktion bekannt ist und man dann eben nur Speicherplatz für eine feste Anzahl an Elementen braucht. In diesen Fällen braucht man keinen vector. Ich dachte, dass du auch auf solche Fälle hinauswillst. Wohl nicht.

Klar. 10K Nutzdaten und dann sind 2 x 8Byte Overhead viel zuviel und man nimmt lieber eine ominöse Konstruktion aus unique_ptr ....

Tut mal nicht so, als wäre der Vector ein unglaublich teures und speicherintensives Gerät. Das ist er nicht ( bei richtiger Handhabung ).