Probleme bei calloc - bei großen Feldern
-
Wutz schrieb:
Das ist eine Unsitte aus C++ übernommen, die da ständig rumcasten, weil sie keinen Überblick über ihre Vererbungshierarchie haben bzw. nie hatten; wenn sie denn überhaupt mal Vererbung benutzen.
So ein Quatsch. Das sind in C++ genau so die schlechten Programmierer wie in C. Klingt wie Java in C++, was du beschreibst.
seldon schrieb:
SeppJ schrieb:
Dem Programm steht sein gesamter Adressraum zur Verfügung, da ist nichts für das Betriebssystem reserviert. Windows reserviert sich 2 GB vom gesamten Arbeitsspeicher, das betrifft den für die einzelnen Prozesse verfügbaren Speicher aber nur indirekt.
Da irrst du dich. Steht übrigens in dem Link über /3GB auch vorne mit dabei. Das ist hier im Detail erklärt. Spoiler: Der Grund ist, dass der Kernel Zugriff auf den Userspace eines Prozesses hat/braucht.
Entweder reden wir gerade aneinander vorbei oder beide Links bestätigen genau das was ich sage, bis auf das kleine Detail, dass Prozessspeicher wohl auf 2 GB beschränkt ist, nicht 4GB.
In 32-bit Windows, the total available virtual address space is 2^32 bytes (4 gigabytes). Usually the lower 2 gigabytes are used for user space, and the upper 2 gigabytes are used for system space.
-
Wenn ich die Betonung mal anders setzen darf:
In 32-bit Windows, the total available virtual address space is 2^32 bytes (4 gigabytes). Usually the lower 2 gigabytes are used for user space, and the upper 2 gigabytes are used for system space.
...dass der virtuelle Adressraum auf einer 32-Bit-Plattform 4 Gigabyte groß ist, ist normal (weil 32-Bit-Zeiger). Das ist auch auf einem 32-Bit-Windows-Server mit 64 GB physikalischem Speicher und PAE so. Unter Windows ist per Default die Hälfte davon für das System reserviert, dem Prozess stehen also noch 2 GB zur Verfügung.
Das läuft unter Linux übrigens auch nicht anders, nur dass das System da per Default nur 1 GB reserviert. Es wäre auch anders nicht möglich, weil der Kernelcode mit dem Userspace umgehen können muss und es dort ausgesprochen unpraktisch wäre, wenn beispielsweise eine load-Instruction die Daten aus dem Userspace nicht lesen könnte, weil im TLB für die Adresse grad der Systemspeicher steht.
-
SeppJ schrieb:
So ein Quatsch. Das sind in C++ genau so die schlechten Programmierer wie in C. Klingt wie Java in C++, was du beschreibst.
Was genauso ein Quatsch ist.
Herrlich diese Sprachflames
-
µ schrieb:
SeppJ schrieb:
So ein Quatsch. Das sind in C++ genau so die schlechten Programmierer wie in C. Klingt wie Java in C++, was du beschreibst.
Was genauso ein Quatsch ist.
Herrlich diese Sprachflames
Ich bezog mich auf Wutz' Ansage von Vererbungshierarchien, die so kompliziert sind, dass der Programmierer selber nicht mehr durchblickt. Mag in Java normal sein (habe nicht genug Erfahrung in Java). Aber wenn man jemanden fragt, der das in C++ macht, ist die Rate hier im Forum 100%, dass er von Java kommt.
-
SeppJ schrieb:
Ich bezog mich auf Wutz' Ansage von Vererbungshierarchien, die so kompliziert sind, dass der Programmierer selber nicht mehr durchblickt. Mag in Java normal sein (habe nicht genug Erfahrung in Java). Aber wenn man jemanden fragt, der das in C++ macht, ist die Rate hier im Forum 100%, dass er von Java kommt.
Um genau zu sein hat er gesagt, dass ständig gecastet werden muss, weil der Programmierer keinen Überblick mehr hat. Und die Aussage ist eben auch für Java totaler Unsinn.
-
SeppJ schrieb:
Wutz schrieb:
Das ist eine Unsitte aus C++ übernommen, die da ständig rumcasten, weil sie keinen Überblick über ihre Vererbungshierarchie haben bzw. nie hatten; wenn sie denn überhaupt mal Vererbung benutzen.
So ein Quatsch.
Überhaupt kein Quatsch.
Gäbe es C++ mit der dortigen Unsitte, sich alles irgendwie zurechtzucasten und das dann auch noch als Typsicherheit zu verkaufen, nicht, würde kein Mensch in C darauf kommen, überhaupt irgendwelche Zeigercasts vorzunehmen.
-
Wutz schrieb:
SeppJ schrieb:
Wutz schrieb:
Das ist eine Unsitte aus C++ übernommen, die da ständig rumcasten, weil sie keinen Überblick über ihre Vererbungshierarchie haben bzw. nie hatten; wenn sie denn überhaupt mal Vererbung benutzen.
So ein Quatsch.
Überhaupt kein Quatsch.
Gäbe es C++ mit der dortigen Unsitte, sich alles irgendwie zurechtzucasten und das dann auch noch als Typsicherheit zu verkaufen, nicht, würde kein Mensch in C darauf kommen, überhaupt irgendwelche Zeigercasts vorzunehmen.Wegen der vielen Umsteiger von C++ auf C?
Das ist in C++ genau so Unsitte wie in C, aber es geht gewiss nicht von C++ aus.
-
Wutz schrieb:
Überhaupt kein Quatsch.
Gäbe es C++ mit der dortigen Unsitte, sich alles irgendwie zurechtzucasten und das dann auch noch als Typsicherheit zu verkaufen, nicht, würde kein Mensch in C darauf kommen, überhaupt irgendwelche Zeigercasts vorzunehmen.Du hast von C++ noch weniger Ahnung als von C, was?
In C++-Kreisen gilt Casten als Unsitte und die Verwendung besitzender nackter Zeiger als Steinigungsgrund. Wie du auf die Idee kommst, ausgerechnet Zeigercasts gehörten in C++ zum guten Ton, ist aus meiner Sicht nicht nachvollziehbar. Dagegen gibt es in C übrigens gelegentlich gute Gründe für Pointer-Punning -- hauptsächlich, weil man in C keine generischen Strukturen und keine Vererbung hat. In der Not frisst der Teufel halt Fliegen.
Was den konkreten Fall angeht: Ob man den Rückgabewert von malloc jetzt castet oder nicht, ist eigentlich Jacke wie Hose. Der Streit ist recht alt; die einen argumentieren, dass man den Code mit Cast sowohl durch einen C- als auch einen C++-Compiler jagen kann, was ggf. eine Portierung vereinfacht, die anderen bemäkelten zu der Zeit, dass der Cast eine gcc-Warnung verdeckte (wenn malloc benutzt wurde, ohne dass der zugehörige Header eingebunden war). Letzteres wurde zwischenzeitlich gefixt, also schlägt die Waage jetzt wohl eher in die Mit-Cast-ist-besser-Richtung, aber letztendlich ist das einer dieser heiligen Nerd-Kriege, in denen man es so oder so sehen kann und es im Endeffekt echt egal ist. Fehler kann man sich damit nicht einhandeln.
-
seldon schrieb:
Fehler kann man sich damit nicht einhandeln.
Wenn ich mir die nötige Zeit nähme, könnte ich dich auf dutzende Threads hier im Forum verweisen, bei denen der Cast den von dir beschriebenen Programmierfehler verdeckt hat, was dann zu Laufzeitfehlern führte.
-
Mit einem einigermaßen neuen gcc sollte die Warnung trotzdem kommen. Ich müsste jetzt nachkucken, wann genau die Änderung passiert ist; das älteste, was ich gerade zur Hand habe, ist gcc 4.6, und der macht das schon. Clang verhält sich genauso, und MSVC warnt unabhängig vom Cast nicht, wenn ich das richtig im Kopf habe (ich muss das prüfen, wenn ich wieder nen MSVC zur Hand habe). Damit sind die gängigsten Compiler abgedeckt. Wobei es die Dev-Cpp-Brigade nach wie vor kalt erwischt, das ist wohl richtig.
Wie dem auch sei, ich bin der Ansicht, dass dieser Streitpunkt wesentlich mehr Aufmerksamkeit kriegt, als er wirklich verdient. Kann man so oder so machen, hat beides Vor- und Nachteile, aber jeweils keine gravierenden. Wenn einem der halbe Zeiger bei der Zuweisung abgesäbelt wird, merkt man das ja recht schnell.
-
seldon schrieb:
und MSVC warnt unabhängig vom Cast nicht, wenn ich das richtig im Kopf habe
Aber ohne Cast ist der Fehler durch den Compiler diagnostizierbar. Als richtiger Fehler, nicht als Warnung! Der Compiler kann dann gar nicht weiter machen, so wie es sich bei einem klaren Fehler gehört. Das gilt nicht nur für Compiler, die ohnehin nicht warnen, sondern auch für solche, die beim durch den Cast verdeckten Fehler eine Warnung geben.
Also im Fall, dass man tatsächlich falsch programmiert hat, aber sinnlos castet:
-Neue GCC -> Warnung, falls aktiviert. Bei Ausführung Laufzeitfehler.
-Andere -> Keine Diagnostik. Laufzeitfehler
Wenn man falsch programmiert hat, aber nicht sinnlos castet:
-Alle -> Compilerfehler
Wenn man richtig programmiert hat und sinnlos castet:
-Die Stelle geht auch durch einen C++-Compiler
Wenn man richtig programmiert hat und nicht sinnlos castet:
-Compilerfehler in C++Wieso war der Cast noch einmal vorteilhaft oder wenigstens ohne Nachteile?
-
In C ist die Umwandlung int -> Pointer erlaubt. Gcc und clang werfen auch ohne Cast nur eine Warnung (Übrigens nicht über die Umwandlung int -> pointer). MSVC wird sich genau so verhalten. Von Vorteil ist der Cast bei
SeppJ schrieb:
Wenn man richtig programmiert hat und nicht sinnlos castet:
-Compilerfehler in C++...aber ich halte das für einen geringfügigen Vorteil, weil man solchen Code eigentlich nicht einem C++-Compiler geben will und der Fix, wenn man ihn wirklich mal so quetschen muss, trivial ist.
Wie gesagt, aus meiner Sicht ist es mehr oder weniger gleichgültig.
-
Also, die Verwendung eines 64 bit Compilers hat tatsächlich geholfen, wobei das Programm (es läuft jetzt) 11.91 GB Speicher benötigt.
Aber, es läuft auch auf meinem Netbook, welches nur 2 GB Speicher hat, ein 32 bit System und natürlich auch mit 32 bit kompiliert. Da swappt er halt ohne Ende.
Es gab aber noch einen zweiten Fehler (das sind die fiesesten Bugs). Der lag in der folgenden Routine. Der Pointer fpNode wurde nicht korrekt übergeben, obwohl ich den Fehler bisjetzt noch nicht gefunden habe - und es funktioniert auf genau diese Weise auch anders wo. Naja, hab die Routine dann umgeschrieben und bin das Problem umgangen.
Vielen Dank für die rege Teilnahme an der Frage.
-
CJens schrieb:
Also, die Verwendung eines 64 bit Compilers hat tatsächlich geholfen, wobei das Programm (es läuft jetzt) 11.91 GB Speicher benötigt.
11.91 GB Speicher?
Darf man fragen, was du da so machst?
