Probleme beim Kopieren eines Arrays

[pumuckl]

sone_logoff schrieb:

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

google mal nach "placement new"

[SeppJ]

sone_logoff schrieb:

Ich sehe keinen Unterschied bei

printf("HALLO WELT!");

und

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

Hier besteht ein ganz gewaltiger Unterschied, weil du printf missbrauchst.

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

verhält sich so wie das C-Gegenstück

fputs(stdout, "HALLO WELT!")

[Xin]

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.

Jaja, wir können auch selbst löten, jadajadablabla...

Es spricht übrigens überhaupt nichts gegen einige Assemblerkenntnisse - nirgendwo sonst lernt man besser erst zu denken, dann zu debuggen. Meine Assemblerzeit war vielleicht nicht sehr produktiv, aber sehr lehrreich.

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.

Da müsste ich den Quellcode sehen, um das beurteilen zu können.

Ich erzeuge auch Objekte mit Placement New, woher der Speicher kommt, auf dem ich das Objekt erzeuge ist dabei zweitrangig. Das ist aber trotzdem alles C++.

Wenn Dein Spezi auf dem Speicher kein Placement New aufruft, dann ist das aber kein calloc()-Problem.

gewinner schrieb:

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.

Nur wirst Du damit genau das Gegenteil erreichen.

Man lernt Programmieren nicht dadurch, dass man eine Liste von Geboten einhält, die besagen, was man tun solll, sondern eine Liste von Verboten erfährt. Wenn ich Leuten programmieren beibringe, konstruiere ich Beispiele, wo sie in die Falle tappen und Mist bauen, damit sie verstehen, was sie tun.

Man kann nur gut programmieren, wenn man das Verbotene nicht tut - eine Liste von Geboten schränkt die Leute oftmals mehr ein, als notwendig ist und wenn man dann mal an etwas ranmuss, für das man noch kein Gebot hat, baut man erstmal sorglos Mist.
Kennt man den Mist, den man baut, baut man eben was anderes.

----------------

pumuckl schrieb:

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.

Das muss auch nicht garantiert sein. malloc bliebt Teil von C++, ich zeigte nur auf, dass C++ selbst malloc ebenfalls benutzt. Hier reicht ein Positiv-Beispiel, welches Du gerade nochmal bestätigt hast.

pumuckl schrieb:

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.

Ich zähle bei c++.de nie zur Allgemeinheit, das habe ich inzwischen ja auch raus.

Typsicherheit ist so eine Sache... die Formatstrings haben den Nachteil, dass sie ausgeben, was man im Formatstring festgelegt hat, auch wenn man einen anderen Typ reinwirft. Aber damit haben die Formatstring auch den Vorteil, dass sie ausgeben, was man im Formatstring festgelegt hat, auch wenn man einen anderen Typ reinwirft.

pumuckl schrieb:

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.

Seit '94 programmiere ich jetzt C++... zum Debuggen nehme ich weiterhin printf().

printf() ist eine Möglichkeit. Und auch unter C++ bleibt es eine Möglichkeit, man hat lediglich nun eine weitere Möglichkeit, mit eigenen Vor- und Nachteilen.

Ebenfalls bearbeite ich Dateien bevorzugt mit fread und fwrite und fprintf. (Nicht scanf).
Und jetzt? Schlechter C++-Programmierer oder jemand, der sich die Möglichkeiten aus C++ so rausfischt, wie er sie braucht?

[Bashar]

Was ist das Problem, die Leute nicht anzulügen? Schreibt doch einfach "printf ist nicht zu empfehlen" statt "printf ist kein C++".

[SeppJ]

Xin schrieb:

Typsicherheit ist so eine Sache... die Formatstrings haben den Nachteil, dass sie ausgeben, was man im Formatstring festgelegt hat, auch wenn man einen anderen Typ reinwirft. Aber damit haben die Formatstring auch den Vorteil, dass sie ausgeben, was man im Formatstring festgelegt hat, auch wenn man einen anderen Typ reinwirft.

Das ist kein Vorteil. Du kannst das gleiche mit einem einfachen Cast typsicher erreichen. Hingegen sind gefühlte 50% der Fragen im C-Forum wegen falscher Formatspezifizierer.

Ebenfalls bearbeite ich Dateien bevorzugt mit fread und fwrite und fprintf. (Nicht scanf).
Und jetzt? Schlechter C++-Programmierer oder jemand, der sich die Möglichkeiten aus C++ so rausfischt, wie er sie braucht?

Was soll denn der Vorteil von fread und fwrite sein, die doch wirklich genau das gleiche machen wie bei den Streams? Dafür hast du den Nachteil, dich um die Datei selber kümmern zu müssen und du musst je nach Datenquelle eine andere Funktion wählen.

[gewinner]

Xin schrieb:

Wenn Dein Spezi auf dem Speicher kein Placement New aufruft, dann ist das aber kein calloc()-Problem.

der punkt ist doch der, man macht in der regel kein *alloc() in c++. es gibt sehr selten einen grund dafür. new[[]] existiert und deckt die allermeisten fälle ab. wenn man davon abweichen muss, muss es schon sehr speziell zugehen.
das gilt meines erachtens für alles, was in c geht und nun ein äquivalent in c++ hat. und das einem newbie schnellstens beizubringen ist in meinen augen wichtig. so bringt man ihn schnell mit den grundlegenden prinzipien in kontakt.

[Xin]

SeppJ schrieb:

Das ist kein Vorteil. Du kannst das gleiche mit einem einfachen Cast typsicher erreichen. Hingegen sind gefühlte 50% der Fragen im C-Forum wegen falscher Formatspezifizierer.

Ein Cast ist die Aufhebung der Typsicherheit. Dass man es dranschreibt ist sicherlich ein Vorteil, aber ein Cast bedeutet nicht, dass irgendwas typsicher wäre, sondern das Gegenteil.

Gerade beim Debuggen, will man aber auch nur mal eben schnell... und da regen mich schon die Formatstring-Errors moderner Compiler auf...

SeppJ schrieb:

Ebenfalls bearbeite ich Dateien bevorzugt mit fread und fwrite und fprintf. (Nicht scanf).
Und jetzt? Schlechter C++-Programmierer oder jemand, der sich die Möglichkeiten aus C++ so rausfischt, wie er sie braucht?

Was soll denn der Vorteil von fread und fwrite sein, die doch wirklich genau das gleiche machen wie bei den Streams? Dafür hast du den Nachteil, dich um die Datei selber kümmern zu müssen und du musst je nach Datenquelle eine andere Funktion wählen.

Ich finde die stdio hier deutlich handlicher.

gewinner schrieb:

Xin schrieb:

Wenn Dein Spezi auf dem Speicher kein Placement New aufruft, dann ist das aber kein calloc()-Problem.

der punkt ist doch der, man macht in der regel kein *alloc() in c++. es gibt sehr selten einen grund dafür. new[[]] existiert und deckt die allermeisten fälle ab. wenn man davon abweichen muss, muss es schon sehr speziell zugehen.
das gilt meines erachtens für alles, was in c geht und nun ein äquivalent in c++ hat. und das einem newbie schnellstens beizubringen ist in meinen augen wichtig. so bringt man ihn schnell mit den grundlegenden prinzipien in kontakt.

Das Recht der Gewohnheit ("in der Regel") sehe ich genauso, ein "grundlegendes Prinzip" sehe ich darin nicht.

Bring einem Newbie bei, was falsch ist und warum etwas falsch ist. Aber "das ist kein C++" ist a) falsch und b) unbegründet. Es entsteht ein Gebot und aus Geboten entstehen Gläubige und Programmierung ist keine Religion - auch wenn's in manchen Threads so aussieht.

Das ein Pattern, dass in der Regel auf eine gewisse Art formuliert wird (mit new) auch mit new formuliert werden sollte, damit es eben ein Pattern wird, dass jeder sofort lesen und auch ohne es wirklich zu lesen verstehen kann, ist eine Begründung.

Ein printf() sollte man aber auch als C++-Programmierer lesen können.

[hustbaer]

Ich finde auch als Programmierer sollte man versuchen sich exakt auszudrücken. Weil ich der Meinung bin dass das wichtig ist, Misverständnisse vermeidet etc.

Ich weiss dass ich da selbst recht oft ... diesbezüglich verbesserungswürdige Texte schreibe, aber OK, darum geht's (mir) jetzt nicht. Jeder macht Fehler.

Was ich nicht mehr OK finde, ist sowas zum Prinzip zu erheben. Und das auch noch ohne guten Grund.

Ich habe hier noch kein einziges Argument gelesen warum es als (falsche) faktische Aussage formuliert sein muss. Einige von euch haben den Teil einfach ganz ignoriert, und dort wo darauf eingegangen wurde was es nach dem Motto "na und, reg dich halt nicht auf, is ja egal". Aber kein einziges Argument dafür.

Argument dagegen (falls ich es wirklich schreiben muss): falsch ist halt einfach falsch.

[adgafafafafafesafesa]

Gemäß der C++ Norm ist ::std::printf() nur dann C++, wenn die "<cstdio>" mit eingebunden wurde, nicht aber die "<stdio.h>" Ob Goldfish dies getan hat, wissen wir nicht. Da er aber schonmal C programmiert hat, davon also mehr Ahnung als von C++ hat, wird er höchstwahrscheinlich auch die "<stdio.h>" eingebunden haben.

Trotz der Tatsache, daß ::std::printf() als Bestandteil der "<cstdio>" auf dem Papier Bestandteil der C++-Norm sein soll, heißt das noch lange nicht, daß das auch tatsächlich der Fall ist.

Denn dann müßte ::std::printf() voll integriert sein in den kompletten Rest der C++-Norm, was aber nicht der Fall ist.

Ein gutes Beispiel dafür ist folgender Code:

template <typename T>
void output(const T& pX)
{
    std::cout << pX << std::endl;
}

Die Vertreter der "::std::printf() ist C++"-Fraktion können ja mal spaßeshalber versuchen, diesen Code mit ::std::printf() zu schreiben. Viel Glück.

[Bashar]

adgafafafafafesafesa schrieb:

Trotz der Tatsache, daß ::std::printf() als Bestandteil der "<cstdio>" auf dem Papier Bestandteil der C++-Norm sein soll, heißt das noch lange nicht, daß das auch tatsächlich der Fall ist.

Das was du abschätzig Papier nennst, IST C++. Was kann denn darüber hinaus noch "tatsächlich der Fall" sein?

[camper]

adgafafafafafesafesa schrieb:

Trotz der Tatsache, daß ::std::printf() als Bestandteil der "<cstdio>" auf dem Papier Bestandteil der C++-Norm sein soll, heißt das noch lange nicht, daß das auch tatsächlich der Fall ist.

Denn dann müßte ::std::printf() voll integriert sein in den kompletten Rest der C++-Norm, was aber nicht der Fall ist.

Offenbar sind "Bestandteil der C++-Norm" und "voll integriert in der C++-Norm" für dich verschiedene Dinge, sonst ist das bloss ein Zirkelschluss.
Kannst du das erläutern?

[adgafafafafafesaf]

camper schrieb:

Offenbar sind "Bestandteil der C++-Norm" und "voll integriert in der C++-Norm" für dich verschiedene Dinge,

Nur dann, wenn das, was auf dem Papier steht, in der Praxis nicht oder nur sehr schwer umsetzbar ist.

[Goldfish]

Also, nachdem ich jetzt noch mein 2. Thema hier hatte und zusätzlich noch jemand durch meinen Code verwirrt war udn dazu noch ein Thema eröffnete weip ich mittlerweile, was schief gelaufen ist. Dass der ,-Operator solche Auswirkungen hatte, war mir nicht bewusst. Ich hatte mir da auch nichts bei gedacht, da die Syntax bei C# funktioniert ^^ (ja ich weiß, dass man das nicht miteinander vergleichen sollte)
Und so wie es aussieht, muss ich dummerweise, fast mein ganzes Programm umschreiben, das eigentlich schon funktioniert hatte, bis auf den einen Punkt, dass sich die Werte nicht mehr anpassen ließen... echt frustrierend sowas.
Aber Grund ist eigentlich, dass ich in ca. einem Jahr wohl meine Diplomarbeit mit dem Zeug schreiben muss und entsprechend wollte ich jetzt schonmal Programme schreiben um mögliche böse Fehler wie den jetzt schon vorher zu entdecken.

Danke an euch alle ^^