Article View: de.comp.lang.c++
Article #1579Re: Q: gcc 2.7.1: Aufruf einer Konstruktormethode aus einer anderen
From: Ullrich von Bassewitz
Date: Tue, 20 Feb 1996 13:57
Date: Tue, 20 Feb 1996 13:57
61 lines
3793 bytes
3793 bytes
Harald Fuchs (hf@colibri.de) wrote:
> > Stilistische Kritik an einem Programm ohne dessen Kenntnis
> > ist fast schon hellseherisch.
>
> Man braucht kein Hellseher zu sein, um zu wissen, daß 'char*' in einem
> sauberen C++-Programm nichts zu suchen hat.
Naja, ich muss zugeben, dass ich mit solchen Hinweisen auch oft etwas
Probleme habe. Natuerlich haben diese ab und zu ihre Berechtigung, das will
ich nicht abstreiten, aber die Regel sollte sein "lieber nicht" :-)
Und, um das gleich klarzustellen: In meinen C++ Programmen finden sich
char*'s ziemlich gleichberechtigt neben allen anderen Datentypen. Meine
Programme sollen eine bestimmte Aufgabe erfuellen, und wenn zur Umsetzung
eines Algorithmus char*'s notwendig und/oder besser geeignet sind als
strings, dann verwende ich eben diese, ohne darauf Ruecksicht zu nehmen,
was die Paepste der Heiligen Kirche zur Reinen Lehre(TM) dazu meinen. Und
ich lache jeden aus, der glaubt, mir anhand von irgendwelche Code-Fragmenten
die WAHRHEIT der C++ Entwicklung beibringen zu muessen (was nicht heisst,
dass ich nicht froh darum bin, wenn mich jemand auf einen Irrtum meinerseits
hinweist. Dazu gehoert aber mehr als nur ein "das macht man nicht weil es
der Reinen Lehre widerspricht").
Warum koennen wir uns nicht darauf einigen, dass C++ eine sehr grosse
Bandbreite hat und deshalb viele verschiedene Programmierstile moeglich
sind? Es kann sehr gute Gruende geben, eingebaute Datentypen zu verwenden,
oder ein bestimmtes Problem prozedural zu loesen - zumindest dann, wenn die
Problemstellung aus der Praxis stammt.
Oder, um's nochmal anders auszudruecken: Ich habe schon Code gesehen, den
Nikolaus Wirth geschrieben hat (steht zumindest so im Kommentar). Wenn ich
das als Beispiel fuer eine persoenliche Arbeit bei einer Einstellung gesehen
haette, dann waere es *kein* Pluspunkt fuer den Kandidaten gewesen (es war
auch keine besondere Katastrophe, aber eben nicht ueberzeugend). Das alleine
sollte schon zeigen, dass es eben unterschiedliche Anforderungen, je nach
Aufgabenstellung geben kann. Und was ein Expertenkomitee in dem 20
Professoren sitzen fuer das absolute Non Plus Ultra haelt kann in der Praxis
die absolute Katastrophe sein (Algol 68 ist ein solches Beispiel).
> Dietmar wollte mit seinen Randbemerkungen
> lediglich darauf hinweisen, daß Dein Beispiel u.a. schlechter Stil
> ist. Wenn Du das persönlich nimmst, meinetwegen - allerdings denk vor
> Deiner nächsten allergischen Reaktion bitte mal daran, was Dietmar
> ohne Bezahlung für die Sprache tut und was Du dafür tust.
Es liegt mit fern, hier Dietmar anzugreifen, auch wenn ich das nicht so
formuliert haette wie er es getan hat. Was mich viel mehr stoert ist Dein
Posting:
Was hat denn Dietmars Engagement fuer C++ mit seinem Verhalten gegenueber
bestimmten Personen zu tun? Warum ist es nicht mehr erlaubt, jemanden zu
kritisieren, weil dieser sich (wegen mir auch unentgeltlich) eine bestimmte
Arbeit aufgehalst hat? Das zeigt wohl am besten Deinen Argumentations-
notstand auf...
Gruss
Uz
--
Ullrich von Bassewitz uz@ibb.schwaben.com
Technical Details
Message-ID:
<BOP9B96C@wuschel.ibb.schwaben.com>Path:
arc1-ca.pugleaf.net!wuschel.ibb.schwaben.com!not-for-mailReferences:
<3120B25C.2650@fokus.gmd.de> <31229576.0@news.uni-konstanz.de> <pu91i3yvzc.fsf@themroc.colibri.de>Show Full Headers
Complete Article Headers
Newsgroups: de.comp.lang.c++ Path: arc1-ca.pugleaf.net!wuschel.ibb.schwaben.com!not-for-mail From: uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz) Subject: Re: Q: gcc 2.7.1: Aufruf einer Konstruktormethode aus einer anderen Date: 20 Feb 1996 13:57:54 GMT References: <3120B25C.2650@fokus.gmd.de> <31229576.0@news.uni-konstanz.de> <pu91i3yvzc.fsf@themroc.colibri.de> Message-ID: <BOP9B96C@wuschel.ibb.schwaben.com> Reply-To: uz@ibb.schwaben.com Organization: Ingenieurbuero von Bassewitz X-Newsreader: TIN [version 1.2 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit