malloc und casten?

net 0

supertux schrieb:

Vertexwahn schrieb:

was kann passiern wenn ich nicht caste?

nichts. In C bruchst du nicht zu casten, das tut C alleine.

und wenn man's trotzdem macht stört's auch nicht...

Vertexwahn

In C braucht man nicht zu casten, in C++ schon, aber du bist im C Forum und deshalb behandeln wir nur den C Fall.

In C braucht man nicht casten? hä? kann ich mir dann generel so sachen wie

int x = 9;
char y = (char)x;

sparen?

Shade Of Mine

In C muss man natürlich auch casten. Aber nicht einen void* in einen anderen Zeiger. void* lassen sich in alles implizit umwandeln.

Und natürlich stört es, wenn man den cast bei malloc macht, weil dadurch Fehler entstehen können.

wurde schon sooft besprochen.

Daniel E.

net schrieb:

supertux schrieb:

Vertexwahn schrieb:

was kann passiern wenn ich nicht caste?

nichts. In C bruchst du nicht zu casten, das tut C alleine.

und wenn man's trotzdem macht stört's auch nicht...

Aber hallo, und wie:

/* Dateianfang */
int main(void) {
    int *p = malloc(sizeof *p);
}
/* dateiende */

Das gibt beim Übersetzen eine Fehlermeldung.

/* Dateianfang */
int main(void) {
    int *p = (int*)malloc(sizeof *p);
}

hingegen oftmals nicht. Darum ist es idR nicht sonderlich schlau, mallocs zu casten.

supertux

Vertexwahn schrieb:

In C braucht man nicht zu casten, in C++ schon, aber du bist im C Forum und deshalb behandeln wir nur den C Fall.

In C braucht man nicht casten? hä? kann ich mir dann generel so sachen wie
int x = 9;
char y = (char)x;
sparen?

ja, das kannst du, wobei bei deinem Code ist es egal, ob du

int x = 9;
char y = (char)x;

oder

int x = 9;
char y = x;

hast, y speicher den ASCII Code 9 und nicht '0'+9 (meistens 57)

supertux

Daniel E. schrieb:

/* Dateianfang */
int main(void) {
    int *p = malloc(sizeof *p);
}
/* dateiende */
Das gibt beim Übersetzen eine Fehlermeldung.

das stimmt gar nicht. Ein C Compiler bringt da nicht mal eine Warnung.

Shade Of Mine

supertux schrieb:

Ein C Compiler bringt da nicht mal eine Warnung.

sollte er aber, weil int nach int* keine alltägliche konvertierung ist

supertux

und wieso sagst du

Aber nicht einen void* in einen anderen Zeiger. void* lassen sich in alles implizit umwandeln.

Shade Of Mine

supertux schrieb:

und wieso sagst du

Wenn es keinen Prototypen für eine Funktion gibt, dann wird int als rückgabetyp angenommen.

sprich: der Compiler kennt malloc nicht, nimmt also folgenden prototypen an:

malloc();

was ja gleichbedeutend mit
int malloc();
ist

supertux

Shade Of Mine schrieb:

supertux schrieb:

und wieso sagst du

Wenn es keinen Prototypen für eine Funktion gibt, dann wird int als rückgabetyp angenommen.

sprich: der Compiler kennt malloc nicht, nimmt also folgenden prototypen an:

malloc();

was ja gleichbedeutend mit
int malloc();
ist

boah shit, du hast Recht, ich hab darauf nicht geachtet, dass dort kein #include <stdlib.h> stand. Wenn das so ist, dann nehme ich meine Komentare zurück. Klar, ohne stdlib.h bekomme ich 2 Warnungen.

@Daniel: sorry, hab nicht ganz aufgepasst.

groovemaster

Vertexwahn schrieb:

Daniel E. schrieb:

Nein. Das ist sinnlos (und evtl gefährlich, weil Du damit u.U. Fehler verdeckst) und nur dazu da um ordentliche C-Programme rückwärtskompatibel zu irgendwelchen veralteten Programmiersprachen wie C++ zu machen.

also in C++ ist es erforderlich?

Nein, ist es nicht, da man in C++ kein malloc, sondern new verwendet.

supertux

groovemaster schrieb:

Nein, ist es nicht, da man in C++ kein malloc, sondern new verwendet.

[klugscheißen]Im Falle void* malloc(size_t) hast du Recht, aber nicht im Allgemeinen mit void* Funktionen.[/klugscheißen]

pointercrash**

supertux schrieb:

groovemaster schrieb:

Nein, ist es nicht, da man in C++ kein malloc, sondern new verwendet.

[klugscheißen]Im Falle void* malloc(size_t) hast du Recht, aber nicht im Allgemeinen mit void* Funktionen.[/klugscheißen]

Ist wie ein Witz, wo ich die Pointe nicht begreife. Sie quälen mich wie Blähungen beim Lauschen im Kammerkonzert.
Mag mich ein Klugscheißertagsetzer aufklären, wo der Gimmick lag?

supertux

pointercrash() schrieb:

Mag mich ein Klugscheißertagsetzer aufklären, wo der Gimmick lag?

In C brauchst du (void*) in einen anderen Pointer nicht zu casten. D.h, wenn du hast void* foo(); dann kann man so machen: int *x = foo(); oder char* x=foo(); us, d.h. void* Pointer lassen sich in alles implizit umwandeln. In C++ ist dies nicht der Fall, wäre void* foo() eine C++ Funktion, so müsste

int* x = (int*) foo();
// oder
char* x = (char*) foo();

Vertexwahn hat aber gesagt "also in C++ ist es erforderlich?" und hat sich eher auf auf die Ausgabe von malloc bezieht. Nur malloc sollte man mit C++ nicht benutzen, dafür gibt es den new Operator. Alles klar?

pointercrash**

Aah - ja, jetzt klar

Hab' von C++ bislang die Finger gelassen, deswegen wohl mein "memory hole". Man wird auch durch's Mitlesen (hoffentlich) täglich schlauer

Danke, S-Tux

net 0

supertux schrieb:

In C++ ist dies nicht der Fall, wäre void* foo() eine C++ Funktion, so müsste
int* x = (int*) foo();
// oder
char* x = (char*) foo();

naja, der echte c++ fan würde aber eher diese komischen 'c++ casts' verwenden

char* x = xxx_cast<char*>(foo());

Nur malloc sollte man mit C++ nicht benutzen, dafür gibt es den new Operator.

wieso kann man es denn aber sollte nicht? wenn man glück hat, hat man sogar 2 speicherverwaltungen zur verfügung (falls 'new' kein verstecktes 'malloc' ist)
ungefähr so:

...
int *p = new int;
if (p == NULL) 
  p = (int*)malloc(sizeof(int)); // zweiter versuch

groovemaster

net schrieb:

Nur malloc sollte man mit C++ nicht benutzen, dafür gibt es den new Operator.

wieso kann man es denn aber sollte nicht?

Weil new nunmal für Speicherreservierung in C++ vorgesehen ist. Dass es malloc trotzdem gibt, hat einfach was mit Abwärtskompatibilität zu tun. malloc ist höchstens für Leute interessant, die Operator new überladen.

net schrieb:

wenn man glück hat, hat man sogar 2 speicherverwaltungen zur verfügung (falls 'new' kein verstecktes 'malloc' ist)
ungefähr so:
...
int *p = new int;
if (p == NULL) 
  p = (int*)malloc(sizeof(int)); // zweiter versuch

Ist natürlich absoluter Käse. Erstens wird malloc sowieso nie aufgerufen, da ein Fehlschlagen von new eine Exception wirft. Dann musst du schon nothrow verwenden. Und zweitens, wenn du trotzdem schaffst das zum Laufen zu bekommen, dann verrat mir doch mal, wie du den Speicher wieder freigeben willst. Du weisst schon, zu new gehört delete und zu malloc gehört free.

net 0

groovemaster schrieb:

Dass es malloc trotzdem gibt, hat einfach was mit Abwärtskompatibilität zu tun.

ok, aber andererseits schluckt ein c++-compiler nicht alles, was für 'c' normal ist. da, finde ich, sollte c++ entweder jeden gültigen c-code fressen oder (ganz konsequent) nur seine eigenen konstrukte akzeptieren. so wie es ist, ist es nix halbes und nix ganzes.

groovemaster schrieb:

net schrieb:
wenn man glück hat, hat man sogar 2 speicherverwaltungen zur verfügung (falls 'new' kein verstecktes 'malloc' ist)
ungefähr so:
...
int *p = new int;
if (p == NULL) 
  p = (int*)malloc(sizeof(int)); // zweiter versuch
Ist natürlich absoluter Käse. Erstens wird malloc sowieso nie aufgerufen, da ein Fehlschlagen von new eine Exception wirft. Dann musst du schon nothrow verwenden.

hey, das sollte kein absolut narrensicherer quelltext sein, den man nur zu copy-und-pasten braucht, sondern nur verdeutlichen wie ich das meinte.

groovemaster schrieb:

Und zweitens, wenn du trotzdem schaffst das zum Laufen zu bekommen, dann verrat mir doch mal, wie du den Speicher wieder freigeben willst. Du weisst schon, zu new gehört delete und zu malloc gehört free.

ja, das ist mir auch im nachhinein aufgefallen. man muss schon irgendwo vermerken von welchem heap der pointer kommt.

Shade Of Mine

net schrieb:

ok, aber andererseits schluckt ein c++-compiler nicht alles, was für 'c' normal ist. da, finde ich, sollte c++ entweder jeden gültigen c-code fressen oder (ganz konsequent) nur seine eigenen konstrukte akzeptieren. so wie es ist, ist es nix halbes und nix ganzes.

Stimmt. Es ist absolut katastrophal wie es ist. Es hat C++ kein bisschen genützt 95% kompatibel zu C zu sein und es ist absolut unmöglich eine C Anwendung langsam auf C++ umzustellen.

Es ist verdammt gut so wie es ist.

net 0

Shade Of Mine schrieb:

Es ist verdammt gut so wie es ist.

ach quatsch, das hätten sie besser machen können. z.b. durch compilerschalter (ollen c-code akzeptieren? -> ja/nein). so wie's ist, bereitet es vielen kopfschmerzen. das sieht man ja ständig hier...