Thou shall not cast malloc (Du sollst malloc nicht casten)

Es wird immer wieder gemacht. Es wird immer wieder erzählt, dass man es nicht machen soll. Es passiert trotzdem immer wieder. Deshalb...

STOP IT!

Shade Of Mine

Mit C99 hat sich das problem eh geloest...

c.rackwitz

Shade Of Mine schrieb:

Mit C99 hat sich das problem eh geloest...

das heisst?

Es bleibt auch mit C99 sinnlos und unschön. Ganz egal wie intelligent Compiler gerne wären. Es gibt schlicht keinen sinnvollen(*) Grund malloc zu casten.

(*) Ein C++-Compiler ist kein Grund.

Shade Of Mine

klar ists unnoetig. aber *BUMM* machen tuts bei c99 nicht mehr.

hellihjb

wenn man einfach alles verbietet was zu fehler fuehren koennte, nennt man das "java" - is' aber auch nix

Shade Of Mine

hellihjb schrieb:

wenn man einfach alles verbietet was zu fehler fuehren koennte, nennt man das "java" - is' aber auch nix

das hat damit aber echt nix zu tun.

das casten von malloc (oder eigentlich von jeder funktion die nen void* liefert) ist sinnlos. es bringt einem nix.

und vor C99 konnte es toedlich sein. toedlich im sinne von: anwendung mach BUMM und PENG und KRACH und ZACK oder liefert einfach nur falsche daten.

keine dieser situationen ist erstrebenswert.

deshalb: nicht malloc casten.
ist ne gute regel.

mein kritikpunkt war eher, dass dieser post 7 jahre zu spaet kommt :p und es mittlerweile eigentlich kein problem mehr ist, sondern nur noch sinnlos.

in c89 oder k&r ist so ein cast toedlich gewesen, jetzt ist er nur doof und stinkt und so...

und es hat schon seinen sinn wenn man manche sachen verbietet - dieses "man braucht keine prototypen fuer funktionen" ding hat viele bugs produziert...

net 0

TactX schrieb:

Thou shall not cast malloc...

Thou shalt not bitch and moan about null-and-void stuff

Elektronix

TactX schrieb:

Es bleibt auch mit C99 sinnlos und unschön. Ganz egal wie intelligent Compiler gerne wären. Es gibt schlicht keinen sinnvollen(*) Grund malloc zu casten.

(*) Ein C++-Compiler ist kein Grund.

Merkwürdig. Ich nutze Borland C++ und der akzeptiert malloc nur mit casting. Vielleicht eine Ausnahme, die die Regel bestätigt?

Elektronix schrieb:

TactX schrieb:

Es bleibt auch mit C99 sinnlos und unschön. Ganz egal wie intelligent Compiler gerne wären. Es gibt schlicht keinen sinnvollen(*) Grund malloc zu casten.

(*) Ein C++-Compiler ist kein Grund.

Merkwürdig. Ich nutze Borland C++ und der akzeptiert malloc nur mit casting. Vielleicht eine Ausnahme, die die Regel bestätigt?

Nein, aber C++ hat ein strengeres Typsystem als C und daher ist der Cast bei einem C++ Compiler notwendig.

Elektronix

Dann ist das hier

TactX schrieb:

(*) Ein C++-Compiler ist kein Grund.

falsch.

@Nachtheld
Danke für die Auskunft.

THX 1138

Elektronix schrieb:

Dann ist das hier

TactX schrieb:

(*) Ein C++-Compiler ist kein Grund.

falsch.

Nein das heisst einfach "Thou shall use a C compiler."

Elektronix schrieb:

Dann ist das hier

TactX schrieb:

(*) Ein C++-Compiler ist kein Grund.

falsch.

Nein. TactX wollte vermutlich darauf hinaus, dass ein C Programmierer mit der Erwartung/Befürchtung programmieren könnte, dass seine Quellcodes eines Tages von einem C++ Compiler werden würden. Dann denkt der sich: Oi oi oi, bau ich doch lieber gleich die Casts ein, denn der C++ Compiler haut sonst lauter Fehler raus.

Eher wollte ich darauf hinaus, dass viele Leute einen C++-Compiler für C verwenden, ohne zu wissen, dass das dann nicht C ist.

Shade Of Mine

wenn man den c code dann in c++ verwenden muss, gibts ja auch ne nette loesung mit templates, die ging in etwa so:

struct void_ptr {
  void* ptr;
  template<typename T>
  operator T*() {
    return (T*)ptr;
  }

  void_ptr(void* ptr)
  : ptr(ptr)
  {}
};

#define malloc old_malloc

void_ptr malloc(size_t size) {
  return void_ptr(old_malloc(size));
}

da spart man sich dann den code durchzugehen...

wobei man ja eigentlich auch in einem projekt teilweise den c compiler und teilweise den c++ compiler verwenden...

CStoll

#define malloc old_malloc

void_ptr malloc(size_t size) {
  return void_ptr(old_malloc(size));
}

Ich glaube, damit drehst du dich im Kreis (der Präprozessor nennt deine Funktion um in old_malloc - und die ruft sich anschließend selber wieder auf).

Aber in C++ verwendet man ja auch new/delete für die Speicherverwaltung

Shade Of Mine

CStoll schrieb:

Ich glaube, damit drehst du dich im Kreis (der Präprozessor nennt deine Funktion um in old_malloc - und die ruft sich anschließend selber wieder auf).

Stimmt. Dann muss man eben

void_ptr cpp_malloc(size_t size) {
  return void_ptr(malloc(size));
}

#define malloc cpp_malloc

machen.

Aber in C++ verwendet man ja auch new/delete für die Speicherverwaltung

ja ist klar. du hast 100.000 zeilen C code und tust da als erstes mal alle mallocs gegen new tauschen...

Aber nein. Nimm doch einfach Tools wie awk, sed und lass die für dich arbeiten. Außerdem laufen noch die ganzen Ausgaben der Tools am Bildschirm und du siehst super-beschäftigt aus

CStoll

Shade Of Mine schrieb:

Aber in C++ verwendet man ja auch new/delete für die Speicherverwaltung

ja ist klar. du hast 100.000 zeilen C code und tust da als erstes mal alle mallocs gegen new tauschen...

Ganz bestimmt (oder noch besser - ich entscheide mich gleich, ob ich C oder C++ verwenden will und wähle mir meine Werkzeuge dazu passend aus, anstatt so etwas zusammenzuflicken.

Shade Of Mine

CStoll schrieb:

Ganz bestimmt (oder noch besser - ich entscheide mich gleich, ob ich C oder C++ verwenden will und wähle mir meine Werkzeuge dazu passend aus, anstatt so etwas zusammenzuflicken.

wenn ich es vorher weiss ists ja kein thema - aber wenn du den code migrieren musst, dann sind das die kleinen tricks die dir erstmal ne woche arbeit sparen...