Zeiger , klassen und speicherverbrauch....
-
es gibt noch den unknown zeiger, der ist sehr groß. verwendet wird er hier:
class Foo;//über die Klasse ist nichts bekannt class Bar{ typedef int (Foo::*MP)();//der standard schreibt vor, dass das möglich ist MP Foobar; //... };Foobar ist in dem fall je nach compiler bis zu 20Byte groß.
is aber wie gesagt compilerabhängig, gibt compiler, die den zeiger auf 8Byte zusammenquetschen können...hab mal kurz gesucht, so machts der g++ in etwa:
struct { union { FunctionPointer m_funcadr; // always even int m_vtable_index_2; // = vindex*2+1, always odd }; int m_delta; };
-
otze schrieb:
es gibt noch den unknown zeiger, der ist sehr groß. verwendet wird er hier:
class Foo;//über die Klasse ist nichts bekannt class Bar{ typedef int (Foo::*MP)();//der standard schreibt vor, dass das möglich ist MP Foobar; //... };Wieso unknown-Zeiger? Wo hast du das denn her? Siehts für mich wie ein ganz normaler Memberfunktionszeiger aus.
hab mal kurz gesucht, so machts der g++ in etwa:
struct { union { FunctionPointer m_funcadr; // always even int m_vtable_index_2; // = vindex*2+1, always odd }; int m_delta; };Netter Trick, das niederwertigste Bit als Typetag zu «missbrauchen»
-
@Bashar intern wird er aber unknown zeiger genannt, da der compiler zwischen single,multi und virtual vererbung unterscheidet. Kennt er die Klasse nicht, so fällt er auf eine unknown version zurück.
-
Das wär aber blöd, weil dann Zeiger aus zwei unterschiedlichen Übersetzungseinheiten, nur in einer davon sei Foos Definition bekannt, inkompatibel wären.
-
nein, die werden automatisch konvertiert, der unknown zeiger ist nicht umsonst so groß. er kann jeden anderen methodpointer aufnehmen.
-
Wie soll das mit einem statischen Typsystem gehen? Die ÜE weiss doch nichts über die andere.
-
frag nicht mich, frag die compilerbauer. der standard schreibts so vor. ende
-
Chapter&Verse, please.
-
ka, du hast du den standard.
ich les mich nur durch quellen, die sich auf den standard beziehen
atm is das diese quelle:
http://www.codeproject.com/cpp/FastDelegate.asp
-
In der Quelle steht zwar, dass der MS das so macht (WIE ist mir immer noch unklar), aber nicht, dass der Standard das vorschreibt.
-
Gelöscht.
-
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?