🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: de.comp.lang.c++
Article #1715

Re: Q: gcc 2.7.1: Aufruf einer Konstruktormethode aus einer anderen

#1715
From: Dietmar Kuehl
Date: Thu, 29 Feb 1996 01:40
97 lines
5877 bytes
Hi,

Watson (sayegh@fokus.gmd.de) wrote:
: Harald Fuchs wrote:
: > Ich denke, Eure Differenzen sind eine Sache des pers=F6nlichen
: > Backgrounds.  Dietmar scheint mir eher aus der Ecke zu kommen, in der
: > riesige Programmsysteme geschrieben und gewartet werden, und reagiert
: > deswegen eben leicht allergisch auf Write-Once-Programme.

Ich bin immernoch nur "Wissenschaftliche Hilfskraft" (HiWi:
HilfsWilly), also Student. Allerdings schreibe ich seit Jahren als
solcher nur Libraries und bekomme immer eins auf den Deckel, wenn ich
mal wieder gepfuscht habe (weil andere die Libraries benutzen
wollen/sollen und dann meine Fehler ausbaden). ... und warten muss ich
meinen Code (teilweise) auch (die Zeiten, wo ich anderer Studenten Code
warten musste, sind gluecklicherweise erstmal vorbei). Ich muss nicht
alles warten, weil ich vor 1 1/2 die Arbeitsgruppe gewechselt habe und
damit das [relative] grosse (~200kloc), schwer wartbare, von mir
geschriebene Teil abgegeben habe:  da traut sich auch niemand richtig
ran. Sowas will ich NIE wieder schreiben! Zeitdruck, ungegnuegende
Erfahrung, (radikal) wechselnde Anforderungen, keine vernuenftige
Library fuer Klassen a la STL und Restriktionen (keine Templates, keine
Mehrfachvererbung und noch ein paar mehr, um auf mehreren Compilern zu
funktionieren) waren ein Grund, warum der Code nicht so toll ist
(immerhin laeuft er weitestgehen, wenn auch zu langsam...).  Der andere
Grund waren nicht ausreichende Abstraktionen und relative starkes
Coupling zwischen den Komponenten (es ist schon stark gegenueber der
Vorgaengerversion reduziert...) . Dieser Background und die
Diskussionen in clc++ bzw.  clc++m haben mich davon ueberzeugt, dass
man besser "defensiv" programmiert:  viele Fehlerchecks und kapseln in
Klassen, die einen Teil der Probleme einfach abfedern (etwa
Pointerklassen, die auf Memory-Leaks achten bzw.  allgemeiner Klassen,
die auf Resourceleaks achten). Ausserdem halte ich "Decoupling" fuer
fundamental wichtig!

So, jetzt braucht ihr nicht mehr ueber meinen Background zu
spekulieren. Ob die Spekulationen bestaettigt wurden haengt z.B. davon
ab, was "riesig" gerade ist (allerdings denke ich nicht, dass 200kloc
"riesig" ist). Derzeit schreibe ich eher Code, der "poplig" genannt
werden sollte: Klein (rund 5kloc; aber das aendert sich aufgrund von
vielen Aenderungen kaum), kompakt, aber zum experimentieren gut
geeignet.

: was soll denn das heissen? Weisst Du, wer in dieser Gruppe
: welche "Programmsysteme" schreibt und wie gross diese sind? Wie
: gross sind denn Deine Programme? Glaubst Du, dass im universitaeren
: Bereich geschriebene Programme umfangreicher sind als kommerzielle?

An der Uni werden wohl kaum groesse Systeme geschriben als im
kommerziellen Bereich. Allerdings halte ich die groesse der Systeme
garnicht fuer so relevant, wenn es darum geht, mehr oder weniger
Abstraktionen zu verwenden: (Vorsicht, das folgende ist eine nicht
bewiesene Behauptung...) Es zahlt sich auch bei kleinen Systemen aus
(oder kostet nichts). Bei kleinen Programmen ist es in der Regel nicht
so schlimm, wenn da ein paar Fehler sind, weil man sie leicht
ausbessern kann. Aber auch da hilft es, sie von vorneherein zu
vermeiden.

: Im Uebrigen sind viele Programme, die auch Du vermutlich taeglich
: benutzt, in "Write-Once"-Code, soll heissen C, geschrieben,
: ohne dass sie deshalb unwartbar waeren. =

Man kann auch in C wartbar schreiben und sogar objekt-orientiert (auch
wenn viel Disziplin dazugehoert). Siehe etwas, wie Xt (X Toolkit)
implementiert ist: In C, aber objekt-orientiert (ohne
Mehrfachvererbung, aber mit einigen Konzepten, die in C++ nicht direkt
verwirklicht sind, wie "Class Constructors"; die muss man
simulieren...). Wartbarkeit laesst sich nicht an der Programmiersprache
festmachen (nur weil man in C++ schreibt, sind die Programme noch lange
nicht auch nur ein bischen besser). Da spielen viele Faktoren rein.
Explizite Abstraktionen (also solche, die sich auch in Form von Typen,
Funktionen, Klassen, oder ggf. wenigstens Kommentaren) im Programm
wiederfinden, gehoeren, IMHO, dazu.

: Wuerde mich freuen, wenn Du von der hypothetischen
: Einschaetzung der Diskussionspartner Abstand nehmen wuerdest,

Das sehe ich aehnlich. Auch wenn ich der Meinung bin, dass man es
leichter hat, Programme zu schreiben, wenn man Pointer einkapselt, bin
ich nicht der Meinung, dass man nicht auch (wartbare) Programme
schreiben kann, wenn man es nicht tut. ICH schaffe es halt nicht, ohne
die Pointer einzukapseln: Aber das ist MEIN Mangel an Disziplin. Wenn
ich bei anderen den Stil kritisiere meine ich allerdings NICHT, dass
ihnen dieselbe Disziplin fehlt, sondern lediglich, dass sie es sich,
meiner Meinung nach, zu schwer machen... (da ich es eben z.B. leichter
finde, Pointer einzukapseln).

: auch wenn Du offenbar auf den, offensichtlich recht kompe-
: tenten, Dietmar grosse Stuecke haeltst.

Danke :-) Ich hoffe meine "Kompetenz" leidet nicht zu sehr darunter,
dass ich "nur" Student bin und kein weiss der Geier was (Assi, Doc oder
gar Prof, oder so)...
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic
Technical Details
Message-ID: <4h306g$cto@news.BelWue.DE>
Path: arc1-ca.pugleaf.net!news.belwue.de!uzwil!kuehl
References: <3120B25C.2650@fokus.gmd.de> <31229576.0@news.uni-konstanz.de> <3132FC35.3CB5@fokus.gmd.de>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!news.belwue.de!uzwil!kuehl
From: kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl)
Newsgroups: de.comp.lang.c++
Subject: Re: Q: gcc 2.7.1: Aufruf einer Konstruktormethode aus einer anderen
Date: 29 Feb 1996 01:40:32 GMT
Organization: Fakultät für Mathematik und Informatik
Message-ID: <4h306g$cto@news.BelWue.DE>
References: <3120B25C.2650@fokus.gmd.de> <31229576.0@news.uni-konstanz.de> <3132FC35.3CB5@fokus.gmd.de>
Reply-To: dietmar.kuehl@uni-konstanz.de
NNTP-Posting-Host: uzwil.informatik.uni-konstanz.de
X-Newsreader: TIN [version 1.2 PL2]