Probleme beim Kopieren eines Arrays

SeppJ

Goldfish schrieb:

um klar zu machen, um welchen Fehler es geht, ich habe immerhin sehr lange gebraucht, um diesen zu finden.

daddy_felix schrieb:

Schreib es um. Ansonsten wirst du wesentlich mehr Zeit für das Debuggen von irgendwelchen Zugriffsfehlern verbringen

Xin

Goldfish schrieb:

Hallo, ich schreibe ein kleines Programm, mit C++/openGL, bei dem ich einige Arrays kopieren muss. Da ich noch recht neu im C++ Bereich bin, habe ich selbstverständlich ziemlich schlechten Code produziert und erreichte zum Ende hin einen Fehler, dessen Korrektur sehr viel Umschreibarbeit am Code gekostet hat. Nach stundenlanger Recherche hab ich endlich herausgefunden, wo der Fehler liegt, den ich vorher nicht identifizieren konnte, hab aber keine Ahnung, wie ich diesen bereinigen kann. Daher das folgende Codebeispiel, das genau den Fehler generiert, mit dem ich gerade kämpfe

Fehlermeldung:
Fehler 51 error C2039: 'difference_type': Ist kein Element von '`global namespace''
float * colors;
   colors = new float[1,1,3];

WTF!? ^^

Der Ausdruck 1,1,3 ist 1.
Hoffe ich. ^^ Das erste Element, glaube ich, oder das letzte Element, aber in jedem Fall bin ich mir sehr sicher, dass es nicht ist, was Du Dir wünschst

Schau dass Du Deine Daten so hältst, dass Du sie mit glColor3fv() direkt ziehen kannst, ohne dass Du sie vorher kopierst. Von std::vector sehe ich mich hier nicht wirklich überzeugt, erzeuge Dir lieber eine eigene Klasse, die drei Floats beinhaltet...

Mensch, dass hier niemand dem armen Jungen mal sagt, dass dieses [1,2,3] betont Bull*hit ist.....

Der Ausdruck 1,1,3 ist 1.

Nein. Wenn Du int* i = new int[1, 2, 3]; schreibst, hast Du Speicher für 3 Integer angefragt. Die Zahl ganz rechts ist der tatsächliche Wert, d.h. int[1, 1, 3] == int[3] und int[1, was, auch, immer, 10] == int[10].

Bei Benutzung von GCC und G++ kommt da auch eine Warnung raus, und die lautet:

warning: left operand of comma operator has no effect [-Wunused-value]

Goldfisch, dieses int* i = new int[1, 1, 3];... Benutze es niemals. Vergiss es und lösche dies aus Deinen Gedanken. Es ist mehr Schreibaufwand und ist von vorne rein totaler Mist, einfach nur aus dem Grund, weil es nix bewirkt.
Ich weiss nicht was Du damit versuchst (ich glaube Du versuchst mehrdimensionale Arrays hinzubekommen), aber das was Du da gerade machst ist schlechter (sehr schlechter) Codestil.

Wenn Du ein normales Array erstellen möchtest, bitte mit int x[10];
Wenn Du ein zweidimensionales Array erstellen möchtest, bitte mit int x[10][10]; (dann hast Du 10 * 10 = 100 Integer)

Aber x[1, 1, 2].... Wow.....

hustbaer

Minispiri schrieb:

Mensch, dass hier niemand dem armen Jungen mal sagt, dass dieses [1,2,3] betont Bull*hit ist.....

Wurde doch schon mehrfach gesagt. OK, eher angedeutet. Dass dabei niemals das rauskommen kann was der OP sich erwartet wurde auf jeden Fall schon geschrieben.

Minispiri schrieb:

Aber x[1, 1, 2].... Wow.....

Finde ich nicht so abwegig. Finde ich sogar sehr intuitiv. Das einzig doofe dabei ist dass es mit C++ halt nicht das macht was man sich erwartet wenn man es schreibt.
(Es sei denn man weiss was es wirklich macht, nur dann würde man es ja nicht schreiben)

redrew99

Goldfish schrieb:

printf("%f, %f, %f", col[0],col[1],col[2]);
kann mir einer sagen, wie ich das richtig stellen kann?
Wäre super. Danke im Voraus.

Das ist leider C, kein C++.
C und C++ mischen ist keine so gute Idee.
Nimm lieber das std::cout für C++.

Xin

redrew99 schrieb:

Goldfish schrieb:
printf("%f, %f, %f", col[0],col[1],col[2]);
Das ist leider C, kein C++.
C und C++ mischen ist keine so gute Idee.
Nimm lieber das std::cout für C++.

Die C-Funktionen funktionieren in C++ genauso und wenn sie tun, was sie sollen, dann spielt es auch keine Rolle, wenn man

cout << col[0] << ", " << col[1] << ", " << col[2];

statt

printf("%f, %f, %f", col[0],col[1],col[2]);

schreibt. Außer man möchte etwas mehr tippen, in den guten alten Zeiten wurde die Arbeit des Entwicklers ja auch in Kilobyte geschriebenen Code gemessen

redrew99

Der TE schrieb

Goldfish schrieb:

Da ich noch recht neu im C++ Bereich bin, habe ich selbstverständlich ziemlich schlechten Code produziert

Der TE möchte C++ programmieren, nicht C, ist außerdem Anfänger.
Vor diesem Hintergrund fände ich es falsch, nicht darauf hinzuweisen, daß printf nicht C++ ist.

Xin schrieb:

Die C-Funktionen funktionieren in C++ genauso und wenn sie tun, was sie sollen, dann spielt es auch keine Rolle, wenn man

Das stimmt zwar, suggeriert aber auch, daß printf und std::cout die gleichen Funktionen haben, was ja nun nicht stimmt. (Z.B. in Bezug auf die Überladung von Operatoren.)

Wenn man beide Sprachen nicht wirklich sehr gut beherrscht, was bei (uns) Anfängern der Fall sein dürfte, wird man mit der Mischung von C/C++, sobald die Programme etwas größer werden, nur noch schlechteren Code produzieren, als man das als Anfänger ohnehin schon tut.

Bashar

redrew99 schrieb:

Der TE möchte C++ programmieren, nicht C, ist außerdem Anfänger.
Vor diesem Hintergrund fände ich es falsch, nicht darauf hinzuweisen, daß printf nicht C++ ist.

Ist das so ein besonderes pädagogisches Konzept? Die Wahrheit ist ja manchmal ein bisschen kompliziert, aber trotzdem sollte auch ein Anfänger damit klarkommen.

redrew99

Bashar schrieb:

Ist das so ein besonderes pädagogisches Konzept? Die Wahrheit ist ja manchmal ein bisschen kompliziert, aber trotzdem sollte auch ein Anfänger damit klarkommen.

Zeig mir doch mal bitte ein gutes Lehrbuch für C++, z.B. sowas wie den Primer,
wo anstelle von std::cout printf() empfohlen wird.

Bis dahin...schönen Nabend noch

Xin

redrew99 schrieb:

Zeig mir doch mal bitte ein gutes Lehrbuch für C++, z.B. sowas wie den Primer,
wo anstelle von std::cout printf() empfohlen wird.

Da steckt (D)eine Wertung drin. Ein Buch kann nicht gut sein, wenn printf gezeigt wird.

Mit C++ wurde cout eingeführt und die Streams.
Das Streams-Konzept ist in C nicht möglich. <cstdio> ist allerdings weiterhin vorhanden und kein Kompatiblitätsheader, sondern legt printf in den Standard-Namensraum. In C ist es nicht möglich, printf im std-Namensraum zu rufen. std::printf() ist also kein C-Konstrukt.

Ein gutes C++-Lehrbuch sollte imho std::puts verwenden, um möglichst viel Komplexität aus dem Hello World-Programm zu nehmen, denn printf("Hello World\n") ist eigentlich auch in C ein fragwürdiges erstes Programm: der String ist eigentlich der Formatstring und was bedeutet eigentlich '\n', das könnte man mit puts() vermeiden.
Entsprechend darf gefragt werden - kann es überhaupt ein gutes Buch geben? Nichtmals C-Bücher beginnen mit puts().

Also... was ist schon gut?

hustbaer

@Alle die sich angesprochen fühlen
[rant]
Das andauernde "das ist kein C++ sondern C" geht mir schön langsam tierisch auf den Keks!
Wenn jemand VLAs verwendet, oder sonstige Dinge die in C++ nicht gehen, dann OK, bitte gerne darauf hinweisen dass das kein (standard) C++ ist.
Bloss wenn jemand printf/puts/... verwendet... WTF? Geht's noch? Klar ist printf C++, ob es euch nun gefällt oder nicht.

Von mir aus schreibt dass printf in C++ nicht "schön" ist, ihr das nicht machen würdet o.Ä. - alles OK. (Aber auch sowas bitte nur 1x, und dann nicht elendslange darauf rumreiten wenn der OP meint dass ihn das nicht interessiert.)

Den (falschen, polemischen, micht ankotzenden) Hinweis "das ist kein C++" könnt ihr euch aber sorgfältig dorthin montieren wo die Sonne nicht scheint.
[/rant]

@hustbaer: so sehr wie dich die hinweise nerven, so sehr sind die meckerer, die du kritisierst, von dem c/c++-gemisch genervt. wenn "wir" die ganzen noobs einfach machen lassen, dann lernen sie es womöglich nie. printf ist genauso überholt und flacsh wie malloc . und ein mehr oder weniger dezenter hinweis darauf -am besten so früh wie möglich- hilft demjenigen in so manch einem fall sicher, sich früh gedanken darüber zu machen, wo die unterschiede liegen.

wenn außer deinem keks niemand einen schaden davonträgt, ignoriere solche posts doch einfach. den newbs ist damit unter umständen geholfen und dir fällt kein zacken aus der krone. win-win.

hustbaer

@gewinner
Schlechten Stil mit einer Unwahrheit bekämpfen? Wirklich?

Die "Meckerer", wie du sie nennst, können ja ruhig ihre Meinung schreiben. Nur bitte nicht "ist kein C++", bei Sachen die ganz sicher doch "C++ sind".

gewinner schrieb:

hilft demjenigen in so manch einem fall sicher, sich früh gedanken darüber zu machen, wo die unterschiede liegen.

Meinst du wirklich dass viele Anfänger sich Gedanken machen werden, nur weil jmd. (meist ohne weitere Erklärung) schreibt "XYZ ist kein C++, verwende ABC stattdessen" (wobei das "verwende ABC stattdessen" auch gerne weggelassen wird).

TyRoXx

hustbaer schrieb:

Bloss wenn jemand printf/puts/... verwendet... WTF? Geht's noch? Klar ist printf C++, ob es euch nun gefällt oder nicht.

Nicht alles, was C++ ist, ist automatisch benutzbar. Gilt in C übrigens auch, siehe gets . Regst du dich auch auf, wenn jemand stattdessen fgets empfiehlt?

hustbaer schrieb:

Von mir aus schreibt dass printf in C++ nicht "schön" ist, ihr das nicht machen würdet o.Ä. - alles OK. (Aber auch sowas bitte nur 1x, und dann nicht elendslange darauf rumreiten wenn der OP meint dass ihn das nicht interessiert.)

Die C++-Streams sind nicht "schön". Aber sie sind relativ sicher, erweiterbar und lesbar. Über Letzteres kann man streiten, über das andere nicht.

hustbaer schrieb:

Den (falschen, polemischen, micht ankotzenden) Hinweis "das ist kein C++" könnt ihr euch aber sorgfältig dorthin montieren wo die Sonne nicht scheint.
[/rant]

Ist mir egal, ich mach das weiterhin. Ich kann es sogar begründen.
Das heutige C++11 hat nichts mehr mit C mit Klassen zu tun, die Kompatibilitäts-Header sind obsolet. Man würde sie entfernen, wenn es keinen alten Code gäbe, der sie (oder sogar die .h s) erwartet. Dass die Funktionen in std liegen, hat nur mit Einheitlichkeit zu tun. Man soll nicht überlegen müssen, ob es time oder std::time heißt, falls man doch mal eine alte Funktion benötigt.

Schon klar, du reitest auf den Worten herum. Ersetzte in Gedanken einfach in Zukunft "das ist kein C++" durch "das ist kein C++-Stil".

hustbaer

TyRoXx schrieb:

hustbaer schrieb:

Bloss wenn jemand printf/puts/... verwendet... WTF? Geht's noch? Klar ist printf C++, ob es euch nun gefällt oder nicht.

Nicht alles, was C++ ist, ist automatisch benutzbar. Gilt in C übrigens auch, siehe gets . Regst du dich auch auf, wenn jemand stattdessen fgets empfiehlt?

printf ist wunderbar benutzbar. Du willst jetzt hoffentlich nicht wirklich printf mit gets vergleichen?

TyRoXx schrieb:

hustbaer schrieb:

Von mir aus schreibt dass printf in C++ nicht "schön" ist, ihr das nicht machen würdet o.Ä. - alles OK. (Aber auch sowas bitte nur 1x, und dann nicht elendslange darauf rumreiten wenn der OP meint dass ihn das nicht interessiert.)

Die C++-Streams sind nicht "schön". Aber sie sind relativ sicher, erweiterbar und lesbar. Über Letzteres kann man streiten, über das andere nicht.

Mehr oder weniger korrekt, dafür wundrbar am Ziel vorbei.
Es geht mir auch nicht um printf im Speziellen, sondern allgemein um die falsche und mMn. auch sinnfreie Äusserung "das ist kein C++".

TyRoXx schrieb:

Schon klar, du reitest auf den Worten herum. Ersetzte in Gedanken einfach in Zukunft "das ist kein C++" durch "das ist kein C++-Stil".

Es geht nicht um Worte, sondern darum dass sich Leute berufen fühlen faktisch falsche absolut formulierte Aussagen zu machen. Muss das sein?

"Das ist scheisse" wäre formal eine faktische Aussage, semantisch aber eine Meinungsäusserung, und als solche OK.
"Das ist kein C++" ist allerdings formal wie auch semantisch eine faktische Aussage, und zwar eine falsche, und daher einfach nur Müll.

ps: ich ersetze schon lange "das ist kein C++" durch "ich bin ein Idiot der meint andere belehren zu müssen". Hilft bloss nicht viel.

Xin

gewinner schrieb:

wenn "wir" die ganzen noobs einfach machen lassen, dann lernen sie es womöglich nie. printf ist genauso überholt und flacsh wie malloc .

Dazu dezent der Hinweis, dass sich operator new ( size_t ) Speicher mit malloc besorgt, wie cout Funktionen aus cstdio verwendet.

Die c-Header sind Teil von C++, sie sind auch Teil des Fundamentes.
cout bietet Vorteile, printf bietet andere Vorteile. Es gibt auch keine Probleme mit der Mischung beider Varianten in einem Programm und ich bin sicher, dass "sie" in der Lage sind, mit der Zeit mehr als ein Ein-/Ausgabekonzept kennen zu lernen, schließlich ist eine GUI schlussendlich auch nur ein neues Ein-/Ausgabekonzept und das schaffen die meisten früher, als es mir lieb ist.

gewinner schrieb:

und ein mehr oder weniger dezenter hinweis darauf -am besten so früh wie möglich- hilft demjenigen in so manch einem fall sicher, sich früh gedanken darüber zu machen, wo die unterschiede liegen.

Die versteht ein Einsteiger sowieso nicht, denn dafür muss man beides kennen und verstehen, was sich die Sprachentwickler dabei gedacht haben.

gewinner schrieb:

wenn außer deinem keks niemand einen schaden davonträgt, ignoriere solche posts doch einfach. den newbs ist damit unter umständen geholfen und dir fällt kein zacken aus der krone. win-win.

Den Newbies wird imho nicht geholfen, denn sie bekommen einen Text ausgegeben und die "Profis" erklären ihnen dann (unbegründet), dass was sie da machen falsch ist. Wer soll das verstehen? Der Text steht da (Erfolgserlebnis) und die "Profis" schütteln nur den Kopf.
Lass ihnen doch einfach das Erfolgserlebnis, früher oder später werden sie cout entdecken, spätestens, wenn Du eine Frage mit cout im Quelltext beantwortest.

Xin schrieb:

Dazu dezent der Hinweis, dass sich operator new ( size_t ) Speicher mit malloc besorgt, wie cout Funktionen aus cstdio verwendet.

dann lass uns doch alles in assembler schreiben, weil die rtl ruft ja auch in assembler geschriebene routinen auf.

ich habe erst neulich mehrere stunden damit verbracht, einen bug in 300 kloc c++-code zu jagen, der hin und wieder einen absturz verursachte. die ursache war, dass ein c++-objekt von einem spezi mit calloc erzeugt wurde. und wie oft ich schon crashes aufgrund falscher formatstrings fixen durfte, zähle ich schon gar nicht mehr. wenn man solche späße einem einzigen kollegen durch zurechtweisung von tausend noobs ersparen kann, hat es sich doch schon gelohnt, hustbaer auf den sack zu gehen.

Ich sehe keinen Unterschied bei

printf("HALLO WELT!");

und

std::cout << "HALLO WELT!";

.

gewinner schrieb:

Xin schrieb:

Dazu dezent der Hinweis, dass sich operator new ( size_t ) Speicher mit malloc besorgt, wie cout Funktionen aus cstdio verwendet.

dann lass uns doch alles in assembler schreiben, weil die rtl ruft ja auch in assembler geschriebene routinen auf.

Blödsinn. Das ist keine Argumentation.

gewinner schrieb:

ich habe erst neulich mehrere stunden damit verbracht, einen bug in 300 kloc c++-code zu jagen, der hin und wieder einen absturz verursachte. die ursache war, dass ein c++-objekt von einem spezi mit calloc erzeugt wurde. und wie oft ich schon crashes aufgrund falscher formatstrings fixen durfte, zähle ich schon gar nicht mehr. wenn man solche späße einem einzigen kollegen durch zurechtweisung von tausend noobs ersparen kann, hat es sich doch schon gelohnt, hustbaer auf den sack zu gehen.

Näh, das kommt nur davon das dein spezi ganz offensichtlich falsch programmiert hat.
Das hat nix mit calloc zu tun, auch wenn man wohl den new -Operator verwenden sollte.

Nebenbei bemerkt, frag ich mich, wie man überhaupt für nicht-PODs mit calloc trotzdem den Konstruktor aufrufen kann, bzw. spezifisch die Initialisierungsliste.

pumuckl

Xin schrieb:

Dazu dezent der Hinweis, dass sich operator new ( size_t ) Speicher mit malloc besorgt

Wo steht das denn? Ich weiß dass die Lib vom VS das so macht, aber garantiert ist das nirgendwo.

Dass hier oft an printf etc. herumgemäkelt wird liegt m.E. hauptsächlich an den bekannten Problemen bzgl Typsicherheit etc. Eben aus den gleichen Gründen, warum es allgemein als schlechter Stil angesehen wird. Natürlich ist printf C++ (sonst würde der Compiler es wohl nicht schlucken) - ma will Anfänger nur stärker davon abschrecken, weils ihnen wirklich viele Probleme erspart, wenn sie sich erstmal mit den etwas klobigeren Streams beschäftigen.

Siehs als "das darfst du nicht" vs. "Du, das finde ich jetzt aber nicht ok..."