Probleme bei calloc - bei großen Feldern



  • 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.


  • Mod

    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.


  • Mod

    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.


  • Mod

    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?


Anmelden zum Antworten