Zeiger , klassen und speicherverbrauch....
-
scheinbar bin ich zu dumm, da irgendetwas über methodpointer zu finden
ne halbe stunde suchen hat nix gebracht
-
member function
-
auch darutner hab ich gesucht, und auch wieder gabs nichts
//edit nu hab ich zwar was gefunden nach dem motto: "so sieht ein method-pointer aus", aber mehr gabs bisher immernoch nicht. Naja, und meine suche nach schlüsselwörtern wie vtable(virtual table) waren auch nicht von erfolg gekrönt,obwohl das ja direkt mit dem thema zusammenhängt...aber sowas muss doch im standard vorgeschrieben sein...nur wo
//edit überseh ich da was, oder fehlen so ziemlich alle technischen abschnitte?
oder gehören solche sachen wie linking oder zusammenfassen von übersetzungseinheiten nicht zu dem, was der standard den compilern vorschreibt?
-
otze schrieb:
//edit überseh ich da was, oder fehlen so ziemlich alle technischen abschnitte?
oder gehören solche sachen wie linking oder zusammenfassen von übersetzungseinheiten nicht zu dem, was der standard den compilern vorschreibt?Richtig, sowas ist der einzelnen Implementation überlassen.
-
trotzdem finde ich nirgendwo etwas, darüber, wie sich der compiler bei methodpointern verhalten soll-.-
-
Bashar schrieb:
otze schrieb:
//edit überseh ich da was, oder fehlen so ziemlich alle technischen abschnitte?
oder gehören solche sachen wie linking oder zusammenfassen von übersetzungseinheiten nicht zu dem, was der standard den compilern vorschreibt?Richtig, sowas ist der einzelnen Implementation überlassen.
otze schrieb:
trotzdem finde ich nirgendwo etwas, darüber, wie sich der compiler bei methodpointern verhalten soll-.-
Hä? Wieso "trotzdem"?
Hast du den Beitrag von Bashar gelesen und verstanden?Nochmal:
Der Grund warum du nix über vtables und co im Standard findest ist der, dass die konkrete Umsetzung solcher technischen Details den Compilerbauern überlassen ist. Der Standard schreibt nur vor, wie sich die Umsetzung verhalten muss.
-
trotzdem finde ich nirgendwo etwas, darüber, wie sich der compiler bei methodpointern verhalten soll-.-
Hä? Wieso "trotzdem"?
Hast du den Beitrag von Bashar gelesen und verstanden?Der Standard schreibt nur vor, wie sich die Umsetzung verhalten muss.
irgendwie meint quote 1 und quote 3 dasselbe, quote2 passt aber nicht ins bild.
-
otze schrieb:
trotzdem finde ich nirgendwo etwas, darüber, wie sich der compiler bei methodpointern verhalten soll-.-
Hä? Wieso "trotzdem"?
Hast du den Beitrag von Bashar gelesen und verstanden?Der Standard schreibt nur vor, wie sich die Umsetzung verhalten muss.
irgendwie meint quote 1 und quote 3 dasselbe, quote2 passt aber nicht ins bild.
Was wohl daran liegt, das das Wort "verhalten" mehrdeutig ist. Für mich hörte sich dein Beitrag so an, als würdest du nach Informationen für die Umsetzung von Methodenzeigern suchen (verhalten nach dem Motto: was muss ein Compiler tun, wenn er einen Methodenzeiger sieht) obwohl Bashar bereits darauf hindeutete, dass solche Infos im Standard nicht enthalten sind.
Im Standard steht nur sowas wie: "wenn du einen Methodenzeiger x und ein Objekt o über den Operator .* kombinierst, dann wird die Methode die x repräsentiert für das Objekt o aufgerufen." (so steht das da natürlich nicht). Der Standard beschreibt die Semantik von Methodenzeigern (die Geschichte mit der Contravariance, die Geschichte mit der throw-Spezifikation usw.).
Ich habe "verhalten" also im Sinne von "Wenn du x in C++ benutzt, dann muss y beobachtbar sein und z ist nicht erlaubt."
-
dann haben wir wohl aneinander vorbei geredet
aber trotzdem müssen solche aussagen, wie sie in dem von mir geposteten artikel angesprochen worden sind, in irgendeiner form im standard stehen, und wenn auch nur in der form: methodpointer dürfen nur auf klassen verwendet werden, die komplett bekannt sind,bzw umgekehrt. Und wenn nicht, was bedeuted in dem fall ein schweigen?
-
otze schrieb:
aber trotzdem müssen solche aussagen, wie sie in dem von mir geposteten artikel angesprochen worden sind, in irgendeiner form im standard stehen, und wenn auch nur in der form: methodpointer dürfen nur auf klassen verwendet werden, die komplett bekannt sind,bzw umgekehrt. Und wenn nicht, was bedeuted in dem fall ein schweigen?
Den Artikel habe ich noch nicht gelesen, aber die Geschichte mit den incomplete types steht im Standard:
Nach 8.3.3/2 reicht für die Deklaration/Definition eines Methodenzeigers ein "incomplete type".
D.h.class X; typedef int (X::*p)(); p i = 0;ist legales C++.
Für den Aufruf brauchst du einen vollständigen Typen, da du ein Objekt brauchst bzw. im Falle eines Zeigers diesen dereferenzierst. Für einen Ausdruck wie &X::eineMethode brauchst du ebenfalls einen vollständigen Typen.
-
ahjo, danke für die stelle
dann hatte der artikel ja recht, und ich hab (ausnahmsweise) keine unwahrheiten verbreitet
-
Und wie funktioniert das dann intern? Derselbe Typ hat einmal eine Größe von 16 und einmal von 4, wie geht der Compiler damit um?
-
Ich bin jetzt gerade völlig verwirrt.
James Kanze schreibt hier, dass folgender Code legal ist:class X ; void f( X* pc , void (X::*pmf)() ) { (pc->*pmf)() ; }Comeau übersetzt das auch klaglos.
Nach meiner Interpretation von 5.5/3 ist das aber illegal. Kann mir das mal einer erklären?
-
Ich interpretiere den Standard auch so. Wobei ich da ehrlich gesagt wenig Interpretationsspielraum sehe, er sagt ja eindeutig, dass in A->*B B ein Memberzeiger einer vollständig definierten Klasse sein muss.