malloc und casten?

[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

[Irgendwer]

Shade Of Mine schrieb:

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

Dass man nicht von Base* zu Dervied* implicit casten kann ist ja auch etwas anderes. Erstens kann ich wenn ich ein Base* habe mittels virtuellen Funktionen das Dervied beinflussen ohne genaues darüber zu wissen, mit void* kann ich das nicht. Ich kann sicher downcasten mittels dynamic_cast, void* scheitert hier wieder einmal.

Daraus schlussfolgere ich, dass man die Typeidentifikation selbst programmieren muss und da der Compiler diese natürlich nicht verstehen kann, kann er mir auch nicht helfen. Ob nun

void*a;
int *b = a;

oder

void*a;
int *b = (int*)a; //oder die static_cast Version

ändert ja ganz und gar nichts wenn a nicht auf einen int zeigt. Ob impicit oder explicit hier ist ja nur eine Syntaxfrage.

Desweiteren, wieso soll man void* benutzen wenn man sichere OOP will? Allein die Tatsache void* zu benutzen gibt jeder Art der Typesicherheit doch bereits einen Fußtritt. Kommt es da wirklich noch auf solchen Syntaxmakup an?

Lass mich die Frage mal etwas anders formulieren : Was ist der konkreten Vorteil einer expliciten Konvertirung eines void* der so gewaltig ist, dass sie den Bruch der Rückwärtskompatibilität rechtfertigt?

net schrieb:

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

Wenn er aber C verwenden will? Ich meine was hilft es eine Warnung auszugeben wo kein ungewollter Irrtum vorliegen kann (ich geht mal davon aus, dass der Programierer kein Anfänger ist), der Programmier würde sie eh ignorieren oder gar abschalten. Eine automatische Meldung beim Projektleiter fände ich da schon etwas sinnvoller.

net schrieb:

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

Falsch, C lässt den Programmierer einfach machen und startet nicht den Versuch ihm bei Sachen wie OOP zu helfen wenn er sich denn helfen lassen will. C ist immer recht lowlevel, C++ so lowlevel wie der Programmierer will.

net schrieb:

ich 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

Dann benutz du mal C Schnittstellen mit Makros in ASM, in den allermeisten Fällen kein Problem mit C++. Zusammenlinken ist einfach, benutzen ist da schon was anderes.

[net 0]

Irgendwer schrieb:

net schrieb:

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

Falsch, C lässt den Programmierer einfach machen und startet nicht den Versuch ihm bei Sachen wie OOP zu helfen wenn er sich denn helfen lassen will. C ist immer recht lowlevel, C++ so lowlevel wie der Programmierer will.

huch, das haste falsch verstanden. ich meinte damit den ersten satz, also das 'c++ den programmierer nicht zu seinem glück zwingt' ist bei 'c' mehr der fall als bei 'c++'.