[linux-l] c fuer puristen

[Steffen Dettmer]

Hi,

drei Antworten in einer.

* Peter Ross wrote on Sat, Jul 21, 2007 at 13:25 +1000:
> Hi Steffen,
> 
> On Fri, 20 Jul 2007, Steffen Dettmer wrote:
> 
> > Ich muss mich in C mit Objektorientierung rumplagen; C++ macht das
> > automatisch. Es ist ein riesen Unterschied.
> 
> Natuerlich. Ich gehe auch lieber mit 'nem Schluessel als mit 'nem Hammer 
> in der Hand in mein Haus. Rein komme ich mit beiden;-)

ja, und dass hundertmal am Tag, dann passt's :)

> In den fruehen 90ern habe ich mal einen anderen "Objekt-C"-Ansatz 
> gesehen (Name leider entfallen), der ein paar "Objekt-Macros" definierte, 
> die vom Pre-Compiler in C uebersetzt wurden.
> 
> Vielleicht 'ne Idee fuer Dich?

so ungefähr funktioniert das auch; allerdings werden die Macros
automatisch erzeugt (source code generation - NICHT im GPL Sinne Source
code, bevor hier wieder ne Diskussion losrennt :) also .c und .h Dateien
werden von .pl und .pm erzeugt). Das ist dann immerhin schonmal ein
"Elektohammer".



* Olaf Radicke wrote on Sat, Jul 21, 2007 at 18:12 +0200:
> Der MOC von Qt macht es mit C++ heute noch so. Das vereinfacht nicht
> gerade den Build-Prozess und das Debuggen.

MOC sagt mir nichts, aber das "nicht gerade vereinfachen" sagt mir
was... Der generierte Code kann für Debugzwecke auch echte
Wrapperfunktionen (auf Wunsch mit logging) erzeugen, kann man dann ein
bisschen debuggen, aber bleibt natürlich ein Suchspiel (wer überschreibt
mich denn heute? :)).



* Peter Ross wrote on Sun, Jul 22, 2007 at 13:28 +1000:
> Meinst du die dynamische Laufzeitbindung?
> 
> Es ist doch geradezu toll, dass alle Applikationen, die eine Klasse
> nutzen, sofort von Veraenderungen dieser Klasse profitieren, ohne
> neukompiliert werden zu muessen.
> 
> Um sicherzustellen, dass eine Klasse auch die Methoden hat, die man
> erwartet, kann man deren Vorhandensein abpruefen.

witzigerweise geht sowas in den "C-Hammer-Lösung" (man friemt ja eh
direkt auf den Pointern rum, da kann man die auch ändern). Das nutze ich
für einen ganz speziellen Fall: wenn die Implementierung nicht-lokal
ist, kann über einen einfachen RPC Mechanismus über einen Proxy darauf
zu gegriffen werden. Der Proxy ist im Prinzip eine komplett geänderte
Instanz (insbesondere hat er andere Member). Das sieht in C brutal aus,
in Assembler geht's wohl schon wieder (lol), naja.

Jedenfalls ist das eine Fehlerquelle, weil man z.B. nicht richtig prüft
und will man eigentlich auch gar nicht.

Vielleicht eignet sich solch Superdynamik eher für Web und Gui-Kram, wo
man schnell was bastelt und morgen wegschmeisst, aber wenn es wirklich
funktionieren muss, möchte ich lieber, dass der Compiler so viel wie
möglich Fehler findet. Da sind die Fehlermeldungen auch oft besser :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.