[linux-l] Re: Function Pointer in C

[Rocco Rutte]

Hi,

* Steffen Dettmer [05-05-28 03:18:57 +0200] wrote:
>* Rocco Rutte wrote on Wed, May 18, 2005 at 20:00 +0000:

[...]

>Na ja, und dann stellt man fest, dass Dein C-Code ja eigentlich das
>gleiche ist, was Java macht, nur das Java "Luxus-Syntax" hat (und schon
>fast ein halbes C++ ist!) 

Moment. C wird ja gern mal als "Makroassembler" bezeichnet, hat aber 
IMHO einen Vorteil. Wenn ich das so schreibe, dann weiss ich woran ich 
bin. In C++ und Java weiss ich das nicht mehr. Bei Java nervt mich zum 
Beispiel die Garbage Collection ja nur, weil ich keinen Einfluss darauf 
habe, obwohl ich es besser weiss als der Compiler/die VM.

Wenn ich Sachen via Callbacks löse, dann weiss ich genau, dass der ganze 
Code zur Behandlung nur einmal da ist, also nur einmal im Speicher ist. 
Bei Java, zum Beispiel, habe ich keinen Einfluss darauf, wie die 
Vererbung organisiert wird. Wenn ich eine Klasse Foo von Bar ableite 
und Bar eine Instanzmethode foobar() hat, die vererbt wird, dann gibt es 
ja zwei Möglichkeiten: (1) sie wird nicht überschrieben und (2) sie wird 
überschrieben. Im Fall (1) brauche ich das Original nur 1x im Speicher, 
im Fall (2) jede Inkarnation nur einmal. Wie Java das jetzt organisiert  
und optimiert, weiss ich nicht; für C: wenn ich 10 verschiedene 
Instanzen der Klasse Foo benutze, dann brauche ich sowas wie 
Instanzmethoden nicht, weil die pro Inkarnation eh konstant sind, so 
dass sie auch nur einmal da sein müssen.

Was ich eigentlich nur sagen will, ist, dass ich in C in dem Bereich die 
Kontrolle darüber habe, nur die pro "Objekt" dynamischen Sachen wirklich 
dynamisch zu gestalten und den Rest halt statisch, "statisch" im Sinne 
von "einmal pro Programmlauf". 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) (es kann ja sein, dass der Compiler/die VM das 
wegoptimiert, auf das genutzte Minimum reduziert und dann ausführt; ich 
habe aber noch keine ausführlichere Doku dazu gefunden).

Wenn man sich zum Beispiel javadoc-ähnliche Programme anguckt und ihnen 
sagt, sie sollen bitte stets auch geerbte Methoden listen und dann das 
wirklich mal für ein Objekt macht, dann kommt da tonnenweise Zeugs 
alleine schon aus java.lang.Object. Plus dem, was im Vererbungsbaum noch 
dazwischen gemacht wird. Das "fertige" Objekt kann dann zwar relativ 
viele Sachen, die auch nur jeweils einmal implementiert wurden; es 
widerstrebt aber meinem Lieblingsansatz alles so minimal wie möglich zu 
halten.

>> Ich tendiere eher dazu, die generischsten EierLegendenWollmichSauen
>> haben zu wollen, quasi supereinfachübersichtlich und trotzdem sehr
>> mächtig. 

>dumme, einfach Module verwendet man öfter wieder. Ich hab lieber viele
>kleine dumme Bausteine. Wie oben die hash_map. Macht hashmap und nicht
>mehr. Kann man immer mal gebrauchen. Kann man ja beerben (in C natürlich
>bissel fummelig durch diese castereien).

ACK.

Eigentlich ist das casten ja "nur" hässlich, begegnet mir in Java aber 
auch regelmäßig und ist mir lieber als Templates/Generics, in denen es 
sich zwar schön einfach denken lässt, von denen ich aber in obigem Sinne 
wieder keine Ahnung habe...

>Na ja, hat alles so seine Vor- und Nachteile...

Das ist doch mal ein innovatives Schlusswort ;-)

  bye, Rocco
-- 
:wq!