malloc und casten?

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

[Shade Of Mine]

net schrieb:

ach quatsch, das hätten sie besser machen können. z.b. durch compilerschalter (ollen c-code akzeptieren? -> ja/nein).

Sowas hätte echt mal jemand erfinden müssen. Echt doof, dass es keinen Compiler gibt der sowas kann

Kennst du den Unterschied zwischen dem Standard und einem Compiler?

[net 0]

Shade Of Mine schrieb:

[
Kennst du den Unterschied zwischen dem Standard und einem Compiler?

beide gibt's umsonst im internet.
ach, nee, du meinst es bestimmt so:
- compiler = gut
- standard = böse

[Gast]

Shade Of Mine schrieb:

Kennst du den Unterschied zwischen dem Standard und einem Compiler?

Der Standard gibt klare Regeln vor, welche der Compiler bricht...

[Shade Of Mine]

ich komme mir verarscht vor
und weigere mich hieran weiter zu beteiligen. recherchiert lieber mal ordentlich bevor ihr etwas sagt

[net 0]

Shade Of Mine schrieb:

ich komme mir verarscht vor

ach menno, nicht gleich beleidigt sein
was hast du denn für eine antwort erwartet auf deine frage:

Shade Of Mine schrieb:

Kennst du den Unterschied zwischen dem Standard und einem Compiler

...auch wenn ich nicht zu den leuten gehöre, die die standards als allabendliche bettlektüre benutzen.

[Shade Of Mine]

das hätten sie besser machen können. z.b. durch compilerschalter

Und sowas soll jetzt im standard festgelegt werden?

diese compilerschalter gibt es meistens, nennt sich compiler spezifische erweiterungen.

sowas in einem standard fest zulegen ist blödsinn, weil du dadurch auf einmal 2 standards definierst: den C++ standard und den c++ 100% kompatibel zu C standard. wäre wohl etwas ungut.

die sachen in denen c++ die kompatibilität bricht sind relativ unbedeutend. mal abgesehen davon, dass C und C++ in einer datei mischen sowieso selten der Fall ist. Wenn man von C auf C++ umsteigt, dann schreibt man einfach die neue funktionalität in C++. so dass man teils C und teils C++ hat. dank der compiler die beides können ist das kein problem. und da man compilererweiterungen einschalten kann, ist C und C++ in einer datei zu mischen kein technisches sondern eher mehr ein design problem.

tatsache ist aber, dass C++ von dieser kompatibilität extrem profitiert hat. besser machen kann man es immer, aber so wie es ist, kann es nicht schlecht sein, wenn es C++ zu dem gemacht hat, was es ist.

[Irgendwer]

Allerdings um ehrlich zu sein sehe ich nicht was es für einen Vorteil bringt die implicite Konvertirung von void* zu verbannen.

Typesicherheit ist ja wohl ein schwachsinniges Argument. Ich meine wer void* benutzt der hat sich davon ja eh schon lange verabschiedet und dann was bringt eine explizite Konvertirung an zusätzlicher Typesicherheit? Wenn der Compiler nicht was worauf ein Pointer zeigt dann kann er nicht helfen und eine explicite Konvertirung ändert gar nichts daran.

[Swordfish]

Shade schrieb:

...in denen c++ die kompatibilität bricht sind relativ unbedeutend. mal abgesehen davon, dass C und C++ in einer datei mischen sowieso selten der Fall ist. Wenn man von C auf C++ umsteigt, da...

Wenn derjenige nicht gerade Swordfish ist...

(Ich konnt's mir nicht verkneifen)