Article View: de.comp.lang.c++
Article #1715Re: Q: gcc 2.7.1: Aufruf einer Konstruktormethode aus einer anderen
From: Dietmar Kuehl
Date: Thu, 29 Feb 1996 01:40
Date: Thu, 29 Feb 1996 01:40
97 lines
5877 bytes
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!kuehlReferences:
<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]