[linux-l] Re: Function Pointer in C

Oliver Bandel oliver at first.in-berlin.de
Mi Jun 15 12:06:38 CEST 2005


On Wed, Jun 15, 2005 at 07:47:44AM +0000, Rocco Rutte wrote:
> Hi,
> 
> * Steffen Dettmer [05-06-15 00:36:23 +0200] wrote:
> >* Rocco Rutte wrote on Sat, May 28, 2005 at 07:05 +0000:
> 
> >>In Java ist mein nicht-praktikabler Denksatz daher meist auch, Klassen
> >>nur als Wrapper für dynamische Daten zu nutzen und anderswo Funktionen
> >>darauf stets "static" zu deklarieren ("static" im Java Sinn) 
> 
> >(ja, der ist in C++ der gleiche)
> 
> >Das static nimmt ja nur das implizite "this" weg, also der erste
> >Parameter. Dafür musst Du sicherlich irgendeine Referenz auf die
> >eigentlichen Daten übergeben, summa sumarum das gleiche.
> 
> Jein, bzw. ich weiss es nicht. Es gibt zum Beispiel die Methode 
> toString() aus Object. Wenn ich jetzt ein beliebiges Objekt erzeuge und 
> die Methode nicht überschreibe, dann weiss ich nicht wie das intern 
> organisiert wird. Werden dann immer die Implementierungen der 
> Superklassen per Pointer genommen oder wird vom toString()-Code eine 
> Kopie erzeugt und in den Speicher meiner Klasse eingefügt so dass die 
> gleiche Methode toString() für alle Instanzen separat verfügbar ist? Ich 
> weiss, dass das etwas verwirrend klingt, weshalb es mir vielleicht auch 
> noch niemand richtig erklären konnte. ;-)

Du meinst wohl sowas, wie COW bei Unix-/Linux-Prozessen.
Bzw., Du meinst, daß dies möglicherweise NICHT so implementiert ist.

Ich denke mal, das ist Abhängig von der Implemwntation.
Also: Hersteller X macht es anders als Hersteller Y und bei GNU-Compilern/-
Laufzeitumgebungen wird es vielleicht wieder anders gemacht.

Eigentlich soll man sich um sowas ja garnicht kümmern.

> Und weil ich es bisher immernoch nicht weiss, mache ich immer "static".  
> Ich muss dann zwar Sachen übergeben, weiss aber, dass alle Methoden pro 
> Laufzeit genau einmal im Speicher sind und nicht bei jedem Objekt neu 
> generiert werden.

Naja, solange nicht wirklich Probleme auftauchen, sollte man immer
die abstrakteste/flexibelste Weise aussuchen.
Wenn Du aber nicht static nimmst und dann feststellst, daß Dein
Programm massiv viel Speicher frisst, dann kannste das ja immernoch
ändern - da, wo sinnvoll.

ist denke ich mal ähnlich, wie mit Geschwindigkeits-Optimierungen:
Die kommen immer erst zum Schluß, wenn es tats. zu langsam ist,
schliesslich muß die SW erst mal laufen. Was nützt ein schneller Code,
der nichts brauchbarses produziert? (...weil fehlerhaft, oder die
Entwicklung noch drei Jahre dauert...)
Erst mal sauber zum laufen kriegen, und dann - sofern vorhanden - die
Bottlenecks ausmerzen.

(Damit ist aber nicht gemeint, daß man nicht schon vorher umsichtig
programmiert und mit Flaschenhälsen und bekannten Problemverursachern
nur so um sich werfen sollte.)



> 
> Streng genommen macht es eigentlich gar keinen Sinn, dass man ein neues 
> Objekt vollständig zusammenbaut, indem man ihm alle nicht-geänderten 
> Methoden aus den übergeordneten Klassen als Implementierung mitgibt, 

eben

> aber...

wer weiß, woran der Bibliotheksentwickler gedacht hat, als er eigentlich
die Gedanken beim Code haben sollte... oder woran derjenige, der das
Konzept entwickelt hat, gedacht (oder NICHT gedacht) hat... ;-)

Ciao,
   Oliver



Mehr Informationen über die Mailingliste linux-l