Zitat von
Luckie:
Guck dir mal mein Tutorial an: http//delphitutorials.michael-puff.de
Hab ich schon, ist ein Teil meines Grundwissens, aber es behandelt einige Punkte leider sehr kurz.
Zitat von
Der_Unwissende:
Hierin liegt auch díe eigentliche Begründung für die Position von inherited. Das Create eines TObject hat die grundlegenden Dinge zu erledigen, es muss Speicher alloziert, diese Tabelle erzeugt und ein Verweis zurückgegeben werden. Vieles von dem Code bleibt aber verborgen, da es sehr spezifisch ist. Deshalb wirkt das Create nur leer, tatsächlich wird auch dort (natürlich) Code ausgeführt. Es macht natürlich für jede Klasse Sinn, dass man erst den nötigen Speicher alloziert usw. und erst dann weitermacht. Dass es auch ohne klappt hat nicht viel zu sagen, das kann auch von Fall zu Fall mal ordentlich nach hinten losgehen. Da gibt es dann eine
Access Violation.
Ein interessanter Ansatz, der erstmal etwas nachdenklich macht. Soll man auch eine leere Create aufrufen, weil die Create von TObject den Speicher reserviert? Damit hast du mich im ersten Moment wirklich etwas verwirrt und nachdenklich gemacht. Aber dann habe ich mich gefragt, ist es nicht die Aufgabe von constructor den Speicher zu reservieren? Es stimmt schon, der Create von TObject reserviert Speicher, aber muß man ihn deswegen aufrufen? Ich weiß nicht inwieweit das für den Vorgänger wichtig ist. Muß man es machen oder erledigt mein constructor alles, auch für den Vorfahr? Somit wäre das Aufrufen des Vorfahrs nicht nötig.
Du hast mit den virtuellen und statischen Methoden etwas dem Thema vorweg gegriffen. Auf das Thema wollte ich etwas später eingehen. Auch da habe ich Fragen, aber alles der Reihe nach, sonst kommen wir durcheinander. Allerdings kann man insoweit schon darüber diskutieren ob Create ohne overload das Create des Vorgängers ersetzt oder überschreibt. Ich bin zwar noch nicht soweit, aber dann würde sich wirklich die Frage stellen ob man immer inherited aufrufen sollte.