Array-Inhalt direkt ausgeben / Variable Array-Größe

nwp3 schrieb:

Elemente verschieben geht nicht effizient in einem std::vector.
Stattdessen kannst du deine Schleife leicht abändern:

*snip*

Sieht aus wie der Anfang einer Korrelationsanalyse.

Hi,
danke für das Feedback.
Ich hab das jetzt glaube ich so ähnlich gemacht, nur ohne Hilfsfunktionen.
Hab einen Index von 0 bis vector.size() laufen lassen, mit der Unterbedingung
"if(vector[i] > Grenze)break;
{
Punkt = i;
}"

Das funktioniert so weit.
Ich hab jetzt beide Vektoren mit irgendwas gefüllt, Hauptsache die beiden Vektoren hab in der Nähe einigermaßen ähnliche Werte damit das überschaubar bleibt.
Der Inhalt vom 2. Vektor wird auch wunderbar so verschoben, dass der Wert, der als erstes den eingerichteten Grenzwert überschreitet unter dem im ersten Vektor liegt.

nwp3 schrieb:

Sieht aus wie der Anfang einer Korrelationsanalyse.

Das nicht

Nächster Schritt und worauf das wirklich am Ende raus laufen soll, und dabei brauch ich noch mal Tips^^:

Mein nächster Schritt ist jetzt das ganze für 2-dimensionale Vektoren zu erweitern um den Inhalt des zweiten Vektors nicht nur nach links oder rechts, sondern auch nach oben oder unten verschieben zu können.

Um dann am Ende (und da hab ich noch Null Ahnung) ein kleines Bild einlesen zu können, die Farbwerte pro Pixel in den Vektor schreiben zu können -> einen bestimmten Farbwert finden zu können -> ein zweites Bild einlesen zu können -> dort den Farbwert ebenfalls finden zu können -> die Pixel quasi verschieben und als neues Bild abspeichern zu können, in dem dann die gesuchte Farbe auf den gleichen Koordinaten liegt.

Ich vermute das geht am besten alles ganz anders und geschickter. Aber ich hoffe mal mein Weg funktioniert auch irgendwie.

Kellerautomat

Wutz schrieb:

VLA bieten für den Fehlerfall keine Auswertemöglichkeit.

Einen Stackoverflow kann man meines Wissens nach generell nicht sinnvoll behandeln, ob VLA oder nicht ist da voellig wurscht.

Wutz schrieb:

VLA lassen sich nicht initialisieren.

Das einzige, wofuer ich mir bisher VLAs gewuenscht habe, sind temporaere Buffer. Und die will ich sicherlich nicht initialisiert haben.

SeppJ

Kellerautomat schrieb:

Wutz schrieb:

VLA bieten für den Fehlerfall keine Auswertemöglichkeit.

Einen Stackoverflow kann man meines Wissens nach generell nicht sinnvoll behandeln, ob VLA oder nicht ist da voellig wurscht.

Eben nicht wurscht, denn ohne VLA würde der Stackoverflow nicht auftreten. Außer du reservierst stattdessen einfach ein riesiges statisches Array auf dem Stack, was aber einfach nur falsch wäre. Das heißt, durch das VLA baust du eine (nicht bloß rein theoretische) Quelle für einen unbehandelbaren Fehler in das Programm ein.

Ethon

Wutz schrieb:

Ethon schrieb:

VLAs Schroot? Wer erzählt soetwas?

U.a. ich.

Ok.

Wutz schrieb:

VLA ist was für Deppen.

Ok.

Wutz schrieb:

VLA bieten für den Fehlerfall keine Auswertemöglichkeit.

Ich programmiere keine Fehler.

Wutz schrieb:

VLA lassen sich nicht initialisieren.

Mir egal, ich schaffe soetwas auch ohne Syntax Sugar.

Wutz schrieb:

VLA ist C, und davon hast du dann eben keine Ahnung.

Ok.

Wutz schrieb:

VLA ist was für Deppen.

Ok.

Ethon

Eine viel größere Fehlerquelle als VLA im Bezug auf Stackoverflows ist übrigens Rekursion.
Rekursion ist für Deppen.

Bashar

Deine Mudda ist für Deppen.
Thread bitte nach Youtube verschieben.

Sone

Bashar schrieb:

Deine Mudda ist für Deppen.
Thread bitte nach Youtube verschieben.

Was ist denn mit dir los? Normalerweise sinkst du doch nicht so tief.

Bashar

Was willst du denn jetzt? Hätt ich noch 11!elf hinschreiben müssen? Ich hoffe doch mal, die Mehrheit versteht gewisse Stilmittel auch ohne explizite Erklärung.

Sone

Bashar schrieb:

Ich hoffe doch mal, die Mehrheit versteht gewisse Stilmittel auch ohne explizite Erklärung.

Ja, aber wozu brauchst du solche Stilmittel, frage ich mich...

SeppJ

Bitte stilistisch wieder auf Normalniveau zurück kehren (das ist niedrig genug, so wie es ist :p ) oder den Thread sterben lassen, wenn man der Diskussion nichts mehr hinzuzufügen hat.

Kellerautomat

SeppJ schrieb:

Eben nicht wurscht, denn ohne VLA würde der Stackoverflow nicht auftreten. Außer du reservierst stattdessen einfach ein riesiges statisches Array auf dem Stack, was aber einfach nur falsch wäre. Das heißt, durch das VLA baust du eine (nicht bloß rein theoretische) Quelle für einen unbehandelbaren Fehler in das Programm ein.

Das mache ich mit jeder lokalen Variable und jedem Funktionsaufruf genauso.

SeppJ

Kellerautomat schrieb:

Das mache ich mit jeder lokalen Variable und jedem Funktionsaufruf genauso.

Da weißt du aber, wie groß sie sind. Wenn du weißt, dass die Objekte extrem groß sind oder die Funktionsaufruftiefe sehr groß werden kann und du machst es trotzdem, würdest du das als einen Programmierfehler ansehen.

(D.h. ich habe nix dagegen, wenn du ein kleines VLA anlegst, dessen Größe von der Programmlogik her nicht sehr groß werden kann. Wild wird es, wenn die Größe ungeprüft aus Nutzereingaben kommt oder - was die logische Folge einer Überprüfung wäre - man anfängt, Alternativcode zu schreiben, der dann große Arrays auf den Heap legt)

Kellerautomat

Ich zaehle doch nicht die Variablen und Funktionsaufrufe in meinem Code. Zumal du auch nicht mal weisst, ob der Compiler da nicht einfach was wegoptimiert.
Weiters kann die Anzahl der Rekursionen vom Input abhaengen, das ist auch nur ein VLA im Prinzip. Sind deshalb die Algorithmen Mist?

SeppJ

Kellerautomat schrieb:

Ich zaehle doch nicht die Variablen und Funktionsaufrufe in meinem Code.

Nicht zählen, schätzen. Oder machst du das etwa nicht? Man legt eben einfach kein 100kB Objekt auf den Stack.

Sind deshalb die Algorithmen Mist?

Wenn sie einfach abstürzen: Klar ist das Mist! Das ist dann aber Schuld der Implementierung, nicht des Algorithmus.

Kellerautomat

SeppJ schrieb:

Nicht zählen, schätzen. Oder machst du das etwa nicht? Man legt eben einfach kein 100kB Objekt auf den Stack.

Noe, bei Klassen interessiert mich die Groesse i.d.R. nicht. Das groesste was ich wissentlich so auf den Stack lege sind Puffer, meist ein paar KB gross.

SeppJ schrieb:

Wenn sie einfach abstürzen: Klar ist das Mist! Das ist dann aber Schuld der Implementierung, nicht des Algorithmus.

Gibt es denn z.B. effizientes, iteratives parsen? Wie wuerdest du einen Recdesc Parser Overflow-Sicher machen?

SeppJ

Kellerautomat schrieb:

SeppJ schrieb:

Nicht zählen, schätzen. Oder machst du das etwa nicht? Man legt eben einfach kein 100kB Objekt auf den Stack.

Noe, bei Klassen interessiert mich die Groesse i.d.R. nicht. Das groesste was ich wissentlich so auf den Stack lege sind Puffer, meist ein paar KB gross.

Eben. Und was machste, wenn das VLA größer wäre?

if(size > 1000)
{
  vector<int> stuff(size);
  do(&stuff[0]);
}
else
{
  int stuff[size];
  do(stuff);
}

?

Wie wuerdest du einen Recdesc Parser Overflow-Sicher machen?

Für mich alleine: Wohl tatsächlich gar nicht. Aber für eine Software die ich veröffentlichen würde: Die kannst du doch nicht einfach so mit Stackoverflow abstürzen lassen!

otze

Kellerautomat schrieb:

Gibt es denn z.B. effizientes, iteratives parsen? Wie wuerdest du einen Recdesc Parser Overflow-Sicher machen?

Das ist ja ein Zeichen eines mistigen Algorithmus. RecDesc kann halt Abstürzen. Dann machst du halt LL1. Oder implementierst den RecDesc mit einem stack auf dem Heap.

Wutz

Kellerautomat schrieb:

Ich zaehle doch nicht die Variablen und Funktionsaufrufe in meinem Code.

Eben.
Und weil du das nicht weißt, kannst du auch nicht sicherstellen, dass dein Stack immer ausreicht.
Und außerdem ist auch nicht garantiert, dass du bei Stacküberlauf einen (Laufzeit)Fehler bekommst und das Programm abbricht; du kannst also deine Daten kaputt machen bzw. mit kaputten Daten weitermachen.
Das ist insbesondere unangenehm, wenn es gar nicht deine Daten sind.
Und außerdem sind VLA C und nicht C++.

Sone

Und außerdem sind VLA C und nicht C++.

Schon mal was von C++14 gehört? Oder worauf spielst du an?

SeppJ

Sone schrieb:

Und außerdem sind VLA C und nicht C++.

Schon mal was von C++14 gehört? Oder worauf spielst du an?

Auf den Status Quo? C++14 ist bisher noch ein Glänzen in den Augen der Standardkomission.