Void-Zeiger

groovemaster

ten schrieb:

na ich weiss nicht...
wenn schon typesicherheit, dann wenigstens konsequent. void* funzen nur in die eine richtung - unschön - doch irgendwie verständlich. aber 'nen leichten schock hat mir c++ mal damit verpasst:
int *a = (int*)1;
void *b = (void*)2;
if (a == b)
{
   ...
}
das compiliert!
noch nicht mal ein warning erscheint (beim msvc++)!

Und warum sollte das nicht kompilieren? Wie schon erwähnt, der Compiler kann einen Zeiger implizit nach void* umwandeln.

ten schrieb:

so ein code ist ganz offensichtlich ein programmierfehler

Tatsächlich? Woran siehst du das?

ten schrieb:

c++ juckt's aber nicht.

In C ist das übrigens genauso legal.

Niemand sagt, dass C++ absolute Typsicherheit hat. Wenn eine Sprache soweit low-level geht, wo zB Zeiger verwendet werden können, ist das vermutlich auch kaum machbar. Nur verhält sich C++ hier etwas strikter gegenüber C. Von kaputt kann keine Rede sein. Ende der Geschichte.

CStoll schrieb:

Wie er sagte, die Umwandlung von T* nach void* ist in C++ genauso erlaubt wie in C. Aber die umgekehrte Umwandlung (void* nach T*) ist in C++ nur mit einem expliziten Cast erlaubt (in C ist void*pv=...;int*pi=pv; zulässig, in C++ nicht).

PS: Der Cast in void_ptr = (int*)&wert; ist übrigens nicht nur unnötig, sondern sogar sinnlos - wenn du schon der Meinung bist, casten zu müssen, dann bitte in den gewünschten Zieltyp (&wert ist bereits ein int*).

Ja, mir kam das ganze auch irgendwie verwirrend vor, darum die Fragen.

Auf jeden Fall nochmal Dank an euch alle, habt mir sehr geholfen.

ten

CStoll schrieb:

Das einzige Problem von C++ ist sein Anspruch, halbwegs kompatibel zu C zu sein. Und da erklärt auch, daß solche Konstruktionen akzeptiert werden. Allerdings ist es auch (afaik) Absicht, daß du mit expliziten Casts das Typsystem durcheinanderbringen kannst...

mir geht's um den vergleich und nicht um die casts.
aber du sprichst es ja an: dieses 'halbwegs kompatibel' sein ist das problem.
entweder: "wir erweitern C um objektorientierte features, bleiben aber zu C 100%ig kompatibel"
oder: "wir machen eine komplett neue, objektorientierte programmiersprache, die auf C syntax basiert, verzichten aber sonst auf jegliche kompatiblität zu C"
beides wäre akzeptabel.
nicht aber: "wir versuchen 90% kompatibilität hinzubekommen, rsikieren dabei eine inkonsistente sprachdefinition und viel mehr undefiniertes verhalten als C sowieso schon hat"
'struppi & friends' haben einfach nicht zuende gedacht

groovemaster schrieb:

Ende der Geschichte.

hast ja recht. genug geflamed, sonst macht TactX noch zu...

feigling schrieb:

void_ptr = (int *)&wert;

dort kannst du das (int weglassen, bzw solltest es sogar, weil der Compiler daraus

void_ptr = (void *)(int *)&wert;

machen müsste, anstatt direkt

void_ptr = (void *)&wert;

In der Zeile wird einfach der Pointer void_ptr auf die Adresse von der Variable "wert" gesetzt.

In der Zeile *(int *)void_ptr = 100; passiert folgendes:

Da du einen void Pointer nicht dereferenzieren kannst, also auf seinen Wert zugreifen kannst, musst du casten. Daher castet du einmal nach (int und dereferenzierst dann mit dem *. Auf diese Weise kannst du auf den Wert an der Speicherstelle zugreifen und diesen auf 100 setzen. *void_ptr würde nicht funktionieren.

Ich hoffe, dass dir das etwas hilfreich war.

Auch nochmal danke für Deinen Beitrag. Hat viel gebracht. Habe noch mal eine Frage: Wo kann man im einzelnen nachschauen wie der Compiler bestimmte Anweisungen umsetzt ? (z.b. wie Du oben erwähntest void_ptr = &wert ===> void_ptr = (void *)&wert ). Das wird ja standardisiert sein. Und es interessiert mich.

ten schrieb:

hast ja recht. genug geflamed, sonst macht TactX noch zu...

groovemaster

ten schrieb:

entweder: "wir erweitern C um objektorientierte features, bleiben aber zu C 100%ig kompatibel"
oder: "wir machen eine komplett neue, objektorientierte programmiersprache, die auf C syntax basiert, verzichten aber sonst auf jegliche kompatiblität zu C"
beides wäre akzeptabel.
nicht aber: "wir versuchen 90% kompatibilität hinzubekommen, rsikieren dabei eine inkonsistente sprachdefinition und viel mehr undefiniertes verhalten als C sowieso schon hat"
'struppi & friends' haben einfach nicht zuende gedacht

Nein, dem ist nicht so. C++ erhebt überhaupt keinen Anspruch, zu C kompatibel sein zu wollen. Aufgrund der gemeinsamen Basis gibt es aber nunmal Gemeinsamkeiten. Früher oder später werden diese wegfallen, sofern man es für sinnvoll hält.
Und das Thema mit void* hat auch nichts mit Kompatibilität zu tun. Es ist einfach so, dass eine Umwandlung nach void* kein Sicherheitsrisiko darstellt. Es gibt keine void Objekte, und damit ist ein Dereferenzieren auch nicht möglich. Deshalb ist dies implizit erlaubt. Eine Umwandlung von void* hingegen stellt ein Sicherheitsrisiko dar, und somit wird einem ein Cast abverlangt. Diese Lösung ist jedenfalls sinnvoll, und keinesfalls weniger plausibel als etwas anderes.

ten

groovemaster schrieb:

Nein, dem ist nicht so. C++ erhebt überhaupt keinen Anspruch, zu C kompatibel sein zu wollen.

nein, überhaupt nicht
dann guck doch mal in's ISO/IEC 14882, insbesondere anhang C.

groovemaster

Und was genau soll ich mir da angucken?

ten

groovemaster schrieb:

Und was genau soll ich mir da angucken?

hast du es als pdf?
such nach 'compatibility', dann wirste fündig.

groovemaster

Schon klar. Nur was genau soll ich mir dort anschauen? Aus Anhang C sollte doch mehr als deutlich hervorgehen, dass es Unterschiede gibt. Und dass C++ nicht um jeden Preis Gemeinsamkeiten nur wegen der Kompatibilität beibehält. Natürlich wirft man nicht einfach alles grundlos über den Haufen. Aber wenn Änderungen für sinnvoll erachtet werden, dann werden diese auch gemacht. C spielt dabei keine Rolle. Auch im kommenden Standard wird die eine oder andere Inkompatibilität vermutlich hinzukommen, zB das Schlüsselwort auto.

ten

groovemaster schrieb:

Natürlich wirft man nicht einfach alles grundlos über den Haufen.

richtig, das tun sie nicht, aber *gerade das* beschert uns hier threads wie 'ich muss den rückgabewert von malloc doch casten, weil ich sonst 'nen compile error bekomme'. wieso gibt's überhaupt malloc in c++? geh' ins c++ forum und poste einen quelltext mit 'malloc' drin - das erste was du zu lesen bekommst ist 'meckermecker, malloc benutzt man aber nicht in c++, dafür gibt's new blubberblubb...'

die ganze ISO/IEC 14882 spec. ist gespickt mit hinweisen wie 'SEE ALSO: ISO C subclause blahblah...'. das zeigt ja nun mehr als deutlich wieviel C noch in c++ steckt. ...aber wie viele C-programme kann man wohl durch C++-compiler schicken ohne mit errors und warnings überhäuft zu werden? fast keines!
ich bin wahrlich kein linux-fan, aber in einer sache stimme ich mit linus t. völlig überein: 'c++ just sucks. sorry, but it does!'

btw: die sprache 'java' (ich meine nur die programmiersprache, nicht die plattform) hätte es niemals gegeben, wenn die erfinder von c++ nicht so einen obermist gebaut hätten...

@TactX: sorry, ich hab' mal wieder getrollflamed. kann verstehen wenn du das jetzt löschst oder zensierst

CStoll

ten schrieb:

groovemaster schrieb:

Natürlich wirft man nicht einfach alles grundlos über den Haufen.

richtig, das tun sie nicht, aber *gerade das* beschert uns hier threads wie 'ich muss den rückgabewert von malloc doch casten, weil ich sonst 'nen compile error bekomme'. wieso gibt's überhaupt malloc in c++? geh' ins c++ forum und poste einen quelltext mit 'malloc' drin - das erste was du zu lesen bekommst ist 'meckermecker, malloc benutzt man aber nicht in c++, dafür gibt's new blubberblubb...'

malloc() gibt es in C++, weil die Erfinder die komplette C Standardbibliothek übernommen haben. Allerdings gehört es dort zu den Punkten, die man unter "sowas gibt's auch noch" einordnen würde (genau wie z.B. printf() oder die ganzen str...()-Funktionen) - und vielleicht hast du mal irgendwo einen guten Grund, new nicht zu verwenden (es gibt nicht viele, aber Ausnahmen bestätigen die Regel).

ten

CStoll schrieb:

...und vielleicht hast du mal irgendwo einen guten Grund, new nicht zu verwenden (es gibt nicht viele, aber Ausnahmen bestätigen die Regel).

kennst du ein beispiel, bei dem 'malloc' einen vorteil gegenüber 'new' in c++ hat?
mir fällt gerade nur ein, dass man es brauchen könnte, wenn man mit 'realloc' den speicherblock später vergrössern will, aber selbst dafür bietet c++ ja andere möglichkeiten (std::vector o.ä.).

CStoll

malloc() kannst du am besten dort verwenden, wo du wirklich auf Bit-Level mit deinen Daten zu tun hast^*:
-> wenn du global den operator new überladen hast (z.B. ganz praktisch auf der Suche nach Memory-Leaks), muß der intern auf malloc() zugreifen.
-> malloc() ist mitunter etwas schneller bei der Speicheranforderung (keine Ctor-Aufrufe)
-> die Zusammenarbeit mit realloc() hast du ja schon erwähnt.

^* sobald du von ausgewachsenen C++ Objekten redest, kannst du es sowieso in die Tonne treten

LordJaxom

ten schrieb:

btw: die sprache 'java' (ich meine nur die programmiersprache, nicht die plattform) hätte es niemals gegeben, wenn die erfinder von c++ nicht so einen obermist gebaut hätten...

<Ironie>Eine Welt ohne Garbage Collector, welch wundervolle Vorstellung. Bjarne, hättest Du C++ doch bloss vernünftig gemacht, dann wäre diese Vorstellung nun wahr</Ironie>

groovemaster

ten schrieb:

richtig, das tun sie nicht, aber *gerade das* beschert uns hier threads wie 'ich muss den rückgabewert von malloc doch casten, weil ich sonst 'nen compile error bekomme'. wieso gibt's überhaupt malloc in c++? geh' ins c++ forum und poste einen quelltext mit 'malloc' drin - das erste was du zu lesen bekommst ist 'meckermecker, malloc benutzt man aber nicht in c++, dafür gibt's new blubberblubb...'

Genau. Und das Problem hierbei ist?

ten schrieb:

die ganze ISO/IEC 14882 spec. ist gespickt mit hinweisen wie 'SEE ALSO: ISO C subclause blahblah...'. das zeigt ja nun mehr als deutlich wieviel C noch in c++ steckt. ...aber wie viele C-programme kann man wohl durch C++-compiler schicken ohne mit errors und warnings überhäuft zu werden? fast keines!

Wer C Programme durch einen C++ Compiler jagt, sollte sich ein anderes Hobby suchen. Und was du damit sagen willst, wird mir trotzdem nicht klar.

ten schrieb:

ich bin wahrlich kein linux-fan, aber in einer sache stimme ich mit linus t. völlig überein: 'c++ just sucks. sorry, but it does!'

Was ja durchaus dein Recht ist. Es bleibt trotzdem subjektiv und damit irrelevant. Meiner Meinung nach müsste C++ an einigen Stellen grundlegend geändert werden. Nur ist das natürlich nicht einfach ohne weiteres machbar, da sonst ziemlich viel Code obsolet werden würde (die gleiche Meinung habe ich übrigens auch von C). Deshalb aber C++ grundlegend in Frage zu stellen, ist falsch. Sowas zeigt eigentlich nur eines, entweder man ist ignorant oder kann mit der Komplexität nicht umgehen. Beides sind wiederum subjektive Defizite und haben nicht konkret etwas mit einer Programmiersprache zu tun.

ten schrieb:

btw: die sprache 'java' (ich meine nur die programmiersprache, nicht die plattform) hätte es niemals gegeben, wenn die erfinder von c++ nicht so einen obermist gebaut hätten...

Sehr unwahrscheinlich. Java wurde vermutlich entwickelt, weil wieder mal jemand glaubte, man könnte es besser oder die Welt braucht dieses oder jenes Feature. Sowas gibt's halt immer mal wieder. Sieht man ja auch an D. Da wollte jemand das beste aus C++ und Java vereinen. Die Sprache hat zwar auch teilweise eine bessere Usability, nur bringt sie im Grunde absolut nichts neues. Wer kommt wohl als nächstes und glaubt, er könnte D besser machen?

ten

groovemaster schrieb:

ten schrieb:

richtig, das tun sie nicht, aber *gerade das* beschert uns hier threads wie 'ich muss den rückgabewert von malloc doch casten, weil ich sonst 'nen compile error bekomme'. wieso gibt's überhaupt malloc in c++? geh' ins c++ forum und poste einen quelltext mit 'malloc' drin - das erste was du zu lesen bekommst ist 'meckermecker, malloc benutzt man aber nicht in c++, dafür gibt's new blubberblubb...'

Genau. Und das Problem hierbei ist?

das gleiche problem, das dich dazu veranlasst hat, die zweite zeile in deine
signatur zu schreiben

groovemaster schrieb:

Wer C Programme durch einen C++ Compiler jagt, sollte sich ein anderes Hobby suchen. Und was du damit sagen willst, wird mir trotzdem nicht klar.

guckst du ein paar postings weiter oben..

groovemaster schrieb:

ten schrieb:

ich bin wahrlich kein linux-fan, aber in einer sache stimme ich mit linus t. völlig überein: 'c++ just sucks. sorry, but it does!'

Was ja durchaus dein Recht ist. Es bleibt trotzdem subjektiv und damit irrelevant.

subjektiv ja, irrelevant vielleicht in bezug auf das fortbestehen des universums, aber nicht irrelevant für unsere unterhaltung...