malloc und casten?

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

[net 0]

Shade Of Mine schrieb:

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.

nö, ein dokument reicht. um mal beim thema zu bleiben: z.b. diese c-style casts sind ja in c++ ersetzt wurden durch 'xxx_cast<neuer_typ>...'. es ist doch blöd, dass man das einfach ignorieren kann (hab' grad mal probiert, weder -ansi, -pedandic, -Wall, keiner bewegt gcc dazu ein warning auszuspucken, wenn man c-casts verwendet) ...oder z.b. printf() ist auch verpönt unter c++ codern. trotzdem geht's (und ist sogar bequemer zu nutzen als 'cout')

Shade Of Mine schrieb:

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.

naja, aber viele mixen einfach c und c++ code. teilweise aus unwissenheit oder weil's einfacher ist das zu tun. aber vielleicht ist das ja beabsichtigt?

Shade Of Mine schrieb:

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.

eigentlich sind es meistens 2 compiler. einer der nur c kann und einer der c++ und die c-altlasten beherschen muss.

[Shade Of Mine]

@Irgendwer:
natürlich typsicherheit, weil ein cast void* zu T* quasi eine art downcast ist, jeder T* ist irgendwie auch ein void*, deshalb geht diese richtung problemlos.

@net:
wenn man die C casts verbieten würde, wäre die abwärtskompatibilität nahezu 0.

jedem compiler steht es frei bei der verwendung zu warnen. tun sie aber nicht, weil es meistens nicht sinnvoll ist dafür eine warnung auszugeben.

dass printf bequemer als cout ist, ist lächerlich.
printf ist super, weil es mächtig ist. aber leicht zu verwenden? wie gebe ich einen long double aus. was wenn int unsigned ist, etc. man muss immer den typen der variablen kennen. das nenne ich nicht einfach.

dass mixen von C und C++ ist ja genau das worum es geht: das hat C++ so beliebt gemacht.

und ich wage echt zu bezweifeln dass ein C++ compiler ganz unabhängig von dem mitgelieferten C compiler ist.

da mir das jetzt zu lächerlich wird beende ich das ganze jetzt aber wirklich.

[Irgendwer]

net schrieb:

nö, ein dokument reicht. um mal beim thema zu bleiben: z.b. diese c-style casts sind ja in c++ ersetzt wurden durch 'xxx_cast<neuer_typ>...'. es ist doch blöd, dass man das einfach ignorieren kann (hab' grad mal probiert, weder -ansi, -pedandic, -Wall, keiner bewegt gcc dazu ein warning auszuspucken, wenn man c-casts verwendet) ...oder z.b. printf() ist auch verpönt unter c++ codern. trotzdem geht's

Was würde es denn bringen da eine Warnung auszugeben?

Anders als andere Sprachen versucht C++ gar nicht den Programmier zu seinem Glück zu zwingen. C++ versucht nur dem Programmier da auf die Finger zu klatschen wo höchswahscheinlich ein ungewollter Fehler von Seiten des Programmiers vorliegt.

Ich halte es für unwahrscheinlich, dass jemand cout meint und printf schreibt.

Desweiteren würden dann Warnungen für korrekten C Code in einer gemischten Datei auftreten.

net schrieb:

(und ist sogar bequemer zu nutzen als 'cout')

Wenn du es sagst dann wird es wohl so sein.

net schrieb:

eigentlich sind es meistens 2 compiler. einer der nur c kann und einer der c++ und die c-altlasten beherschen muss.

Beim GCC ist ein Kinderspiel eine *.c Datei mit einer .cpp Datei zu einer ausführbaren Datei zusammen zu linken. Wer C und C++ in einer Datei will der muss halt einen void in dieser Datei casten.

[net 0]

Irgendwer schrieb:

Was würde es denn bringen da eine Warnung auszugeben?

na es würde den c++ coder darauf hinweisen, dass er 'c' verwendet, wo er eigentlich nicht sollte.

Irgendwer schrieb:

Anders als andere Sprachen versucht C++ gar nicht den Programmier zu seinem Glück zu zwingen. C++ versucht nur dem Programmier da auf die Finger zu klatschen wo höchswahscheinlich ein ungewollter Fehler von Seiten des Programmiers vorliegt.

ja, aber das ist bei 'c' ja noch ausgeprägter. dafür gibt's ja auch tools zur statischen code-analyse wie z.b. 'lint' o.ä.

Irgendwer schrieb:

Desweiteren würden dann Warnungen für korrekten C Code in einer gemischten Datei auftreten.

ich fände das gut.

Irgendwer schrieb:

net schrieb:

(und ist sogar bequemer zu nutzen als 'cout')

Wenn du es sagst dann wird es wohl so sein.

also ich finde 'printf' praktischer. ist halt ansichtssache.

Irgendwer schrieb:

net schrieb:

eigentlich sind es meistens 2 compiler. einer der nur c kann und einer der c++ und die c-altlasten beherschen muss.

Beim GCC ist ein Kinderspiel eine *.c Datei mit einer *.cpp Datei zu einer ausführbaren Datei zusammen zu linken.

zusammen linken kannste alles mögliche, asm, c, fortran... sofern die compiler passende object-files erzeugen. das ist keine frage des quellcodes