🚀 go-pugleaf

Hallo, Freunde guten C++-Stils!

Zur allgemeinen Freude will ich nun doch noch
mal was zum Thema beitragen. Dietmar kritisierte
hauptsaechlich zwei Dinge:

- dass ich einen char* in meinem Beispiel
  verwendet habe und
- dass mein Parameter 'string' hiess.

Ich gebe voellig frank und frei zu, dass die
Verwendung von char* _in_einem_bestimmten_Zusammenhang_
nicht sehr schoen ist. Ich habe aber keinen bestimmten
Zusammenhang dargestellt, sondern eben nur ein
Beispiel. (Don't try this at home :-)
IMHO ist auch char* nur eine Klasse wie jede andere
auch (grosser Widerspruch, internationale Verwicklungen :-).

Wie ich bereits erwaehnte, benutze ich *keine* Parameternamen,
die lediglich den davor stehenden Datentyp wiederholen,
ohnehin nicht. Allerdings scheue ich mich keineswegs
davor, in Standard-Headerfiles verwendete Identifier
neu zu besetzen. Da Programmcode ohnehin nur in einem
definierten Kontext gueltig ist, kann ich auch die Bedingung
"darf nicht strclass.h #includen" definieren. Eine saubere
Definition ergibt i.d.R. ein sauberes Programm.

Dietmar wrote:
> Ich halte die technischen Newsgroups, zu denen ich trotz der zahllosen
> "Off-Topic" Artikel de.clc++ zaehle, fuer ein Diskussiosforum und nicht
> fuer eine kostenlose Hotline. Daher werde ich auch in Zukunft
> stilistische Verbesserungsvorschlaege machen, auch oder gerade wenn
> diese von einigen als kontrovers angesehen werden.  Wem das nicht
> passt, dem empfehle ich, sich mit dem "Author Kill" des Newsreaders
> vertraut zu machen bzw. sich tatsaechlich eine Hotline zu
> organisieren...
Natuerlich ist eine Newsgroup nicht nur Hotline. Dennoch
sollten sich Diskussionen vielleicht auf den beschriebenen
Zusammenhang konzentrieren. Ich haette auf Dietmars Posting
auch eine Diskussion ueber seinen Newsreader beginnen koennen,
der keine Mails versenden kann ;-) (Schade!)

> Allerdings nur sehr, sehr selten ausserhalb von irgendwelchen Klassen!
> Als allererstes sei auf die potentiellen Speicherloecher hingewiesen.
> Man kann zwar, mit ausreichend Disziplin, die meisten vermeiden solange
> das Programm auf keinen ausordentlichen Fall ('exception') laeuft, aber
> sobald man irgendwo eine Exception wirft, ist in den allermeisten
> Faellen alles zu spaet: Der Code ist eben nicht mit sovielen
> 'try/catch' Paaren versehen, dass man jedes Stueckchen Speicher einzeln
> freigeben kann. Hierbei helfen Klassen wie 'string' bzw. 'vector' oder
> aehnliche:  Sie sorgen dafuer, dass keine Speicherloecher entstehen,
> auch wenn eine Exception geworfen wurde.
Warum sollten Klassen so definiert werden, dass sie auf 
alle moeglichen Anforderungen reagieren koennen? Ich will 
z.B. gar keine Exceptions in diesem Kontext benutzen.
Ich will gar nicht, dass in meiner Klasse der Speicher-
bereich des char* verwaltet wird. Mein Ziel war es nur,
dass neben einer String-Klasse AUCH ein char* zur
Initialisierung dienen kann (Dies koennte z.B. das 
Ergebnis von getenv() sein). 

> Ein weiteres Argument, das mehr in richtung der "reinen Lehre" geht,
> ist, dass man die Abstraktionen, die man verwendet, beim Namen nennt:
> 'char*' ist eine Repraesentation, keine Abstraktion. Ein 'char*' kann
> z.B. sein:
> - eine Repraesentation eines String (sofern man zusaetzliche
>   Konventionen verwendet: '0x0' als Stringende Markierung).
> - eine Repraesentation eines 'String-Iterator'
> - ein Array von sehr kleine, aber sehr vielen, ganzzahligen Objekten
> Ein 'string' ist eine Abstraktion: Eine Sequenz von Zeichen, die als
> String interpretiert wird. Wer Behauptet, dass solche Abstraktionen
> generell ueberfluessig sind, hat noch nie ein typisches Programm
> weiterpflegen muessen:  undokumentiert und gewachsen. Die Abstraktionen
> moegen im Kopf des urspruenglichen Programmierers sein, aber sie
> spiegeln sich oft eben nicht im Programm wider.

Hier scheinen sich die Begriffe Abstraktion und Repraesentation
zu verheddern. Die Abstraktion findet auf Definitions-, nicht
auf Engineeringebene statt. Wie schoen sie dann repraesentiert
wird, ist dann zwar eine Diskussion wert, aber eben auch etwas
anderes. Man beachte: Definition != Programmierung.

[Dietmars wiederholte Kritik an einem exemplarischen Parameternamen
 weggeschnippelt]

[Dietmars wiederholte Kritik an der exportierten Verwendung von
 char* in einer sinnlosen Beispielklasse auch weggeschnipptelt]

> Mein Artikel war in keiner Weise persoenlich gemeint (ich kenne den
> Autor meines Wissens nach nicht; da ich in Berlin studiert habe koennte
> es sein, dass ich ihn doch, aber nicht namentlich, kenne). Ich habe
> lediglich den Stil seines Beispiels kritisiert. Wenn es als Kritik an
> der Person aufgefasst wurde, so tut es mir leid, denn das war nicht
> mein Ziel.
Dietmar,

der Ton macht die Musik. Davon, dass Du JETZT sagst, dass 
Du Dein Posting nicht persoenlich meintest, aendert sich Dein
vorher angeschlagener Ton nicht (obwohl er nicht schlimm war,
aber eben doch persoenlich). Ich denke, dass jeder Informatiker,
der "etwas auf sich haelt", stilistische Kritik persoenlich
nimmt. Da sollte man in seinen Aussagen Vorsicht walten
lassen... (Das war uebrigens persoenlich gemeint).

> Was die Kritik bezueglich des Strings anbelangt: Man muss schon
> Hellseher sein, um zu wissen, dass die Klasse 'string' nicht
> angebracht ist. Nicht umgekehrt! Der entscheidene Vorteil von C++
> gegenueber Sprachen wie C ist, dass man mit Abstraktionen programmieren
> kann. C++ wie C zu benutzen bringt keinen Vorteil.
Wie bereits erwaehnt: Abstraktion findet zunaechst auf Definitions-
ebene statt. Die Abbildung eines OO-Systems kann selbstverstaendlich
auch nach C erfolgen (obwohl's wahrscheinlich gruselig aussieht).

> Im uebrigen interessiert mich eigentlich viel mehr, welche Gruende es
> fuer eine Deklaration wie 'char *string' geben koennte. Vielleicht kann
> mich irgendjemand darueber aufklaeren. Allerdings sollte damit
> gerechnet werden, dass ich womoeglich eine Follow-Up poste, in dem ich
> die angefuehrten Argumente versuche zu entkraeften...
Siehe oben...

Viele Gruesse,

Euer Andreas "Watson" Sayegh 
(Damit Dietmar meinen Namen nicht mehr in "DDR" setzen muss :-)