🚀 go-pugleaf

In article <3120B25C.2650@fokus.gmd.de> Watson <sayegh@fokus.gmd.de> writes:

   wie kann ich ich eine Konstruktormethode aus
   einer anderen Konstruktormethode aufrufen, 
   ohne dass gleich ein neues Objekt instanziiert
   wird?

   Beispiel:

   class C {
	   C() { 
		   ...
		   C(tmpnam(NULL));	// das ist falsch,
					   // so weit bin ich schon :-)
		   ...
	   }

	   C(char *string) {
		   ...
	   }
   }

Nein, die einzige Moeglichkeit die ich sehe ist eine private 'init' Funktion
oder etwas gleichwertiges.

        Enno

Watson (sayegh@fokus.gmd.de) wrote:
> wie kann ich ich eine Konstruktormethode aus
> einer anderen Konstruktormethode aufrufen, 
> ohne dass gleich ein neues Objekt instanziiert
> wird?

Indem Du eine ganz normale Funktion daraus machst, die von Deinem Konstruktor
aufgerufen wird. Diese Funktion (ich nenne sowas normalweise immer Init)
kannst Du nach Belieben auch von sonstwo aufrufen.

Ein Konstruktor ist nun mal dazu da, ein Objekt zu konstruieren. Wenn Du
sagst, Du willst den Konstruktor aufrufen, ohne ein Objekt zu konstruieren,
dann ist das wie wenn Du ein Auto willst, das aber nicht fahren soll :-)

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

Hi,
Watson (sayegh@fokus.gmd.de) wrote:
: wie kann ich ich eine Konstruktormethode aus
: einer anderen Konstruktormethode aufrufen, 
: ohne dass gleich ein neues Objekt instanziiert
: wird?

Die Antwort zu der Frage ist einfach: Garnicht. Wenn Du unbedingt die
DWP Referenz haben willst, suche ich sie raus. Sonst verzichte ich
darauf...

Was tun also? Zwei Wege schaffen abhilfe. In dem Fall, den Du skizziert
hast, benutzt Du einfach ein Default-Argument:

  class C
  {
    //...
    C(string const &str = string(tmpnam(NULL)))
    {
      //...
    }
  };

Die Andere Moeglichkeit, ist eine 'initialize()' Methode zu
implementieren, die die eigentliche Initialisierung macht. Diese kann
von allen Konstruktoren aufgerufen werden. Damit sie wirklich nur von
den Konstruktoren aufgerufen wird, sollte sie 'private' sein.

Noch zwei Bemerkungen zu Deinem Beispiel:

: 	C(char *string) {
          ^^^^^^^^^^^^
Das ist *GANZ* schlecht:

1. Pointer, auch 'char'-Pointer, haben in C++ eigentlich nichts mehr
   verloren und man braucht sie nur SEHR selten ausserhalb von Klassen
   zu verwenden. Insbesondere fuer einen String braucht man sich nicht
   zu verwenden, dafuer gibt es die Standard-Klasse 'string' (bzw.
   'basic_string<...>'). Das fuehrt gleich zur zweiten Bemerkung:

2. Es gibt eine Standard-Klasse 'string'. Damit ist der Name 'string'
   reserviert und es ist nicht definiert, was passiert, wenn man
   'string' trotzdem fuer etwas anderes verwendet. Also laesst man es
   besser bleiben, auch wenn es auf den meisten Compilern kein Problem
   damit gibt.

: Antwort bitte - auch - als PM, Danke,

Kann mein Newsreader nicht. Und eh ich Aufwand mache oder gar meinen
Newsreader wechsel, lass ich es bleiben :-)
--
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

Dietmar Kuehl wrote:
> Die Andere Moeglichkeit, ist eine 'initialize()' Methode zu
> implementieren, [...]

Meine Frage war ja nicht: kann ich eine andere Methode
implementieren und diese benutzen? (natuerlich kann ich
das :-) Eine von mir erwartete Antwort waere NEIN oder
JA, UND ZWAR SO: gewesen. (Tatsaechlich habe ich uebrigens
ein private init()-Methode geschrieben.)

> Noch zwei Bemerkungen zu Deinem Beispiel:
> 
> :       C(char *string) {
>           ^^^^^^^^^^^^
> Das ist *GANZ* schlecht:

Stilistische Kritik an einem Programm ohne dessen Kenntnis
ist fast schon hellseherisch.

> 1. Pointer, auch 'char'-Pointer, haben in C++ eigentlich nichts mehr
>    verloren und man braucht sie nur SEHR selten ausserhalb von Klassen
>    zu verwenden. Insbesondere fuer einen String braucht man sich nicht
>    zu verwenden, dafuer gibt es die Standard-Klasse 'string' (bzw.
>    'basic_string<...>'). 

char* sind voellig normale und zugelassene Datentypen/Klassen.
Die Verwendung ist anwendungsspezifisch, die Behauptung, man solle
sie nicht verwenden, ist absurd. Das fuehrt nun MICH gleich zum
2. Punkt: Offenbar scheint es sich durchzusetzen, sich ueber
die Bloedheit von gezeigten Beispielen aufzuregen, als waeren
dies Programme. Eigentlich sollen sie aber nur DAS PROBLEM 
ILLUSTRIEREN.

Ich schreibe auch keine Klassen, die nur auch zwei Konstruktoren
bestehen, das waere albern. 

> 2. Es gibt eine Standard-Klasse 'string'. Damit ist der Name 'string'
>    reserviert und es ist nicht definiert, was passiert, wenn man
>    'string' trotzdem fuer etwas anderes verwendet. Also laesst man es
>    besser bleiben, auch wenn es auf den meisten Compilern kein Problem
>    damit gibt.

Und weiter:
Die Benutzung eines Klassennamens als Identifier ist solange zu-
laessig, wie ich die betreffende Klasse nicht in meiner Quelldatei
definiere, d. h. was juckt mich, ob in irgendwelchen Headerfiles
Klassen definiert werden, deren Name zufaellig mit dem ueberein-
stimmt, den ich einem Parameter einer Methode gegeben habe. 'string'
ist KEIN Schluesselwort. Ausserdem ist sehr wohl definiert,
was passiert, wenn ich einen Klassennamen als Identifier verwende.

ABER: Ich wuerde einen Parameter ohnehin kaum 'string' nennen,
da der Datentyp ja schon davor (char*) spezifiziert ist. Geeigneter
scheint mir die Darstellung seiner Funktion zu sein, wie etwa

C(char *hostName);

Erschwerend kommt hinzu, dass man in der Klassendefinition ohnehin
keine Namen braucht...
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

Watson <sayegh@fokus.gmd.de> writes:

> Meine Frage war ja nicht: kann ich eine andere Methode
> implementieren und diese benutzen? (natuerlich kann ich
> das :-) Eine von mir erwartete Antwort waere NEIN oder
> JA, UND ZWAR SO: gewesen. (Tatsaechlich habe ich uebrigens
> ein private init()-Methode geschrieben.)

Ich zitiere aus Dietmars Followup:

> Die Antwort zu der Frage ist einfach: Garnicht.

Wenn Dir Dietmars Freundlichkeit, gleich noch Alternativen
aufzuzeigen, nicht paßt, so überlies die entprechenden Passagen doch
einfach. 

>> Noch zwei Bemerkungen zu Deinem Beispiel:
>> 
>> :       C(char *string) {
>> ^^^^^^^^^^^^
>> Das ist *GANZ* schlecht:

> 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.

> Die Verwendung ist anwendungsspezifisch, die Behauptung, man solle
> sie nicht verwenden, ist absurd.

Richtig - aber das hat Dietmar auch gar nicht behauptet.  Es geht
lediglich darum, daß man _im Normalfall_ die Klasse "string" verwenden
sollte, um mit Strings zu arbeiten.

> Das fuehrt nun MICH gleich zum
> 2. Punkt: Offenbar scheint es sich durchzusetzen, sich ueber
> die Bloedheit von gezeigten Beispielen aufzuregen, als waeren
> dies Programme. Eigentlich sollen sie aber nur DAS PROBLEM 
> ILLUSTRIEREN.

Inwiefern dient die Verwendung von 'char*' statt 'string' der
Illustration von Strings?

>> 2. Es gibt eine Standard-Klasse 'string'. Damit ist der Name 'string'
>> reserviert und es ist nicht definiert, was passiert, wenn man
>> 'string' trotzdem fuer etwas anderes verwendet. Also laesst man es
>> besser bleiben, auch wenn es auf den meisten Compilern kein Problem
>> damit gibt.

> Und weiter:
> Die Benutzung eines Klassennamens als Identifier ist solange zu-
> laessig, wie ich die betreffende Klasse nicht in meiner Quelldatei
> definiere...

Richtig.  Allerdings hat Dietmar auch nicht behauptet, das wäre unzulässig.

> d. h. was juckt mich, ob in irgendwelchen Headerfiles
> Klassen definiert werden, deren Name zufaellig mit dem ueberein-
> stimmt, den ich einem Parameter einer Methode gegeben habe.

Dummerweise handelt es sich nicht um "irgendwelche", sondern um
Standard-Header-Files.  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.

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

Hi,

Ullrich von Bassewitz (uz@wuschel.ibb.schwaben.com) wrote:
: 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" :-)

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...

: 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").

Ich bin sicherlich niemand, der auf einer einzigen, mehr oder minder
richtigen Loesung beharrt! Auch bin ich der Meinung, dass 'char*' ihre
Daseinsberechtigung haben, wie auch andere 'built-in arrays'.
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.
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.

: 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.

Es ist zeifelsfrei richtig, dass es dafuer gute Gruende gibt, aber
nenne mir bitte einen, der 'char *string' rechtfertigen koennte! Die
Abstraktion wird aus dem (schlechtgewaehlten) Namen der Variablen und
nicht aus dem Typ klar! Dafuer gibt, IMHO, absolut keinen Grund!
Unabhaengig davon, ist der Name 'string' nach wie vor ganz besonders
schlecht gewaehlt, da er zufaellig der Name einer Standardklasse ist.
Wenn diese Klasse dann doch mal verwendet werden soll, ist man erstmal
damit beschaeftigt, diesen Namen zu aendern (OK, mit Namespaces ist er
in einem anderen Namespace, aber ich vermute dass 'using std;' zwar
schlecht, aber gaengig sein wird).

C++ bietet eine grosse Bandbreite und es wird fuer die gesamte
Bandbreite auch Anwendungen geben. Allerdings sind einige Bereiche der
gebotenen Bandbreite eher in Ansnahmefaellen brauchbar. Dazu gehoeren
'char*' (und 'built-in arrays') ausserhalb von Objekten.  Dennoch
werden sie dermassen haeufig verwendet, dass man der Meinung sein
koennte, alle Programme haben mit solchen Ausnahmefaellen zu tun. Das
stimmt aber eben nicht.

[Kommentar zu "reinen Lehre" entfernt, da er mir durchaus angebracht
erscheint. Allerdings fuehle ich mich NICHT als Vertreter irgendeiner
"reinen Lehre"!]

: Was hat denn Dietmars Engagement fuer C++ mit seinem Verhalten gegenueber
: bestimmten Personen zu tun?

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.

: Warum ist es nicht mehr erlaubt, jemanden zu
: kritisieren, weil dieser sich (wegen mir auch unentgeltlich) eine bestimmte
: Arbeit aufgehalst hat?

Man darf mich selbstverstaendlich kritisieren. Ich habe damit kein
Problem. Allerdings sehe ich die Kritik von "Watson" als ziemlich
daneben an: Es ist wunderschoen, dass er sich mit einer
'init()'-Methode zu helfen weiss, aber das hier ist nicht die Hotline,
wo die Frage spezifisch fuer ihn beantwortet wird, sondern eine
Newsgroup. Die Antwort interessiert womoeglich auch andere Leute, ggf.
um eine Loesung fuer ein Problem zu haben, dass in Zukunft vielleicht
auftritt.
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.

Dieser Artikel ist ebenfalls nicht persoenlich. Ich wollte nur
darlegen, warum ich den Programmierstil von Watson kritisiert habe und
dass ich auch weiterhin den Programmierstil von Beispielen kritisieren
werde: Wer bereits in Beispielen Code schreibt, der mir merkwuerdig
erscheint, der tut das mit hoher Wahrscheinlichkeit auch in seinen
richtigen Programmen. Darueberhinus wird diese Newsgroup womoeglich von
Leuten gelesen, die C++ lernen moechten. Daher halte ich es gradezu
fuer nicht zulaessig, meiner Meinung nach schlecten Stil unkommentiert
zu lassen.

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...
--
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

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 :-)

Hoppla, kleiner Fehler im vorangegangenen Artikel:

Watson wrote:
> Wie ich bereits erwaehnte, benutze ich *keine* Parameternamen,
> die lediglich den davor stehenden Datentyp wiederholen,
> ohnehin nicht.

Jaja, die doppelte Verneinung: Man streiche das "keine" oder
das "ohnehin nicht" :-)
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

Dietmar Kuehl (kuehl@uzwil.informatik.uni-konstanz.de) 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...

Wie ich geschrieben habe (ich hoffe das kam raus) hat mich der Artikel von
Harald Fuchs viel mehr gestoert als Deiner, vor allem wegen seines Arguments
"schaut mal den Dieter an, was der fuer C++ tut, und dann kommt einer und
will ihn kritisieren". (Wenn ich mal neugierig fragen darf: Was tust Du
ueberhaupt fuer C++? Ich gebe ehrlich zu, dass ich keine Ahnung habe. Ich
gebe auch zu, dass ich nichts fuer C++ tue, ausser es eben zu benutzen...)

Trotzdem denke ich immer noch, dass Deine "Stilhinweise" falsch sind. Sie
moegen in einer bestimmten Umgebung richtig sein, aber eben nur dort.

> Als allererstes sei auf die potentiellen Speicherloecher hingewiesen.
[...]

char* verursachen dabei nicht mehr Probleme als dynamische Objekte, vor
allem deshalb, weil char* nicht unbedingt dynamischen Speicher impliziert.
D.h. das Problem ist kein spezifisches Problem von Zeigern auf chars und
damit auch *kein* Grund zur Kritik an diesen.

Ausserdem steht es jedem frei Exceptions zu verwenden oder nicht (derzeit
duerfte die Mehrzahl der Programmierer exceptions nicht oder nicht
regelmaessig verwenden, schon alleine wegen der mangelnden Verfuegbarkeit).

Was Du sagt trifft also auf ein bestimmtes Umfeld zu. Dieses Umfeld mag bei
Dir zutreffend sein, das gilt jedoch keinesfalls allgemein und ist schon gar
kein Grund, Kritik an ein paar Zeilen Beispielcode zu ueben, bei denen Du
das Umfeld ueberhaupt nicht kennst.

> Ein weiteres Argument, das mehr in richtung der "reinen Lehre" geht,
> ist, dass man die Abstraktionen, die man verwendet, beim Namen nennt:

Und was ist mit "unsigned Counter"? Laut Deiner Argumentation ist das dann
ploetzlich auch nicht mehr zulaessig, weil "unsigned" eine Repraesentation
ist ("Counter" waere die Abstraktion).

Dieses Argument halte ich fuer noch schwaecher als das erste (das man
zumindest in einem bestimmten Bereich als zutreffend bezeichnen konnte).

> Es ist zeifelsfrei richtig, dass es dafuer gute Gruende gibt, aber
> nenne mir bitte einen, der 'char *string' rechtfertigen koennte! Die
> Abstraktion wird aus dem (schlechtgewaehlten) Namen der Variablen und
> nicht aus dem Typ klar! Dafuer gibt, IMHO, absolut keinen Grund!

Dass Du keinen Grund erkennen kannst liegt daran, dass es sich eben nur um
ein paar Zeilen Code gehandelt hat (und deshalb ist IMHO Kritik aufgrund von
ein paar Zeilen auch recht schwierig). Ich kenne das gesamte Programm
natuerlich auch nicht, aber ich kann aus dem Stegreif einen ganzen Stall
moeglicher Gruende fuer das char* liefern:

  * Low-Level Code
  * Interface mit anderen Sprachen (C z.B.)
  * Performance (class string ist um *Klassen* langsamer als eine Uebergabe
    eines Parameters als char*).
  * Bestimmte Repraesentation notwendig (z.B. Zeiger auf Shared Memory,
    Objekte im Shared Memory gehen naemlich nicht bzw. nicht portabel).
  * usw.

Wohlgemerkt: Ich weiss nicht ob es einer dieser Gruende ist. Aber jeder
einzelne dieser Gruende kann eine Verwendung von char*'s rechtfertigen.

Bleibt der Name der Variable: 

> Wenn diese Klasse dann doch mal verwendet werden soll, ist man erstmal
> damit beschaeftigt, diesen Namen zu aendern (OK, mit Namespaces ist er
> in einem anderen Namespace, aber ich vermute dass 'using std;' zwar
> schlecht, aber gaengig sein wird).

Wie Du wahrscheinlich auch weisst residieren die Namen fuer Typen und die
von Variablen in unterschiedlichen Namespaces (die Low-Level Erklaerung ist:
Der Compiler hat unterschiedliche Symboltabellen fuer die Namen von Typen
und Variablen. Das ist wegen der C Kompatibilitaet notwendig).
D.h. entgegen Deiner Behauptung gibt es keinerlei(!) Konflikte wenn Typnamen
als Variablennamen verwendet werden (vorausgesetzt natuerlich, man braucht
nicht den Namen des Typs zusaetzlich zu dem der Variablen, wovon hier nicht
auszugehen ist).

Wer's nicht glaubt, der soll einfach das folgende Programm durch seinen
Lieblingscompiler laufen lassen:

        class Lalle { public: int I; };

        Lalle A (Lalle Lalle)
        {
            return Lalle;
        }

        int main ()
        {
            Lalle B;
            A (B);
            return 0;
        }


Es gibt die von Dir an die Wand gemalten Probleme mit dem Namen also definitiv
nicht. Dazu kommen noch mehr Punkte:

  * Vielleicht ist die Verwendung der Standard C++ Bibliothekt ueberhaupt
    nicht geplant, weisst Du's?
  * Namespaces (die genauso wie Exceptions zum neuen C++ Standard gehoeren)
    loesen das Problem ein fuer alle mal.

> : Was hat denn Dietmars Engagement fuer C++ mit seinem Verhalten gegenueber
> : bestimmten Personen zu tun?
>
> 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.

Ich habe das auch nicht als Kritik an Dir gemeint, sondern als Kritik an
Harald Fuchs. Trotzdem sind Hinweise zum Programmierstil praktisch *immer*
eine persoenliche Sache, ganz einfach deshalb, weil Programmierstil eine
persoenliche Sache ist. D.h. bei solchen Hinweisen gehst Du immer das Risiko
ein, dass es jemand persoenlich nimmt. Und, wie ich oben ausgefuehrt habe
halten Deine Sachargumente lange nicht das, was sie versprechen.

> : Warum ist es nicht mehr erlaubt, jemanden zu
> : kritisieren, weil dieser sich (wegen mir auch unentgeltlich) eine bestimmte
> : Arbeit aufgehalst hat?
>
> Man darf mich selbstverstaendlich kritisieren. Ich habe damit kein

Nimms nicht zu hart, auch das war nicht als Kritik an Dir gedacht :-)

> C++ wie C zu benutzen bringt keinen Vorteil.

Auch hier: Widerspruch! Schon alleine die strengere Typpruefung, typesafe
Linkage usw. machen viele Vorteile von C++ gegenueber C aus, auch dann, wenn
ich keine einzige Klasse verwende, sondern weiterhin prozedural
programmiere. Natuerlich kann ich nur einen Bruchteil der Vorteile von C++
nutzen, aber die Aussage, so wie Du sie hinstellst ist auf jeden Fall
falsch.

> Dieser Artikel ist ebenfalls nicht persoenlich. Ich wollte nur
> darlegen, warum ich den Programmierstil von Watson kritisiert habe und
> dass ich auch weiterhin den Programmierstil von Beispielen kritisieren
> werde: Wer bereits in Beispielen Code schreibt, der mir merkwuerdig
> erscheint, der tut das mit hoher Wahrscheinlichkeit auch in seinen
> richtigen Programmen. Darueberhinus wird diese Newsgroup womoeglich von
> Leuten gelesen, die C++ lernen moechten. Daher halte ich es gradezu
> fuer nicht zulaessig, meiner Meinung nach schlecten Stil unkommentiert
> zu lassen.

Soweit ok, nur musst Du dann auch damit rechnen, dass Kritik an Dir bzw.
Deinen Argumenten kommt. Bisher, muss ich ehrlich sagen, waren letztere fuer
mich nicht sehr ueberzeugend - aber vielleicht kommt ja noch mehr :-)

> 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...

Gruende habe ich oben genug aufgefuehrt, ich warte jetzt mal auf Deinen
Followup :-)

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

Hi,

Ullrich von Bassewitz (uz@wuschel.ibb.schwaben.com) wrote:
: Wenn ich mal neugierig fragen darf: Was tust Du
: ueberhaupt fuer C++? Ich gebe ehrlich zu, dass ich keine Ahnung habe.

Ich vermute, dass Harald Fuchs mit meinem Engagement fuer C++ meinte,
dass ich einer von sieben Moderatoren von comp.lang.c++.moderated bin
(Robert Martin, James Kanze, Dominique De Vitto, David Vandevoorde,
Herb Sutter und Howard Harkness sind die anderen). Ich wollte schon
letztens erwaehnen, dass ich mir diese Arbeit "aufgehalst" habe, um die
Qualitaet in clc++ zu verbessern, was uns, soweit ich das beurteilen
kann, auch gelungen ist. Ein aehnliches Engagement waere hier
eigentlich auch angesagt (aber nicht von mir: eine Newsgroup reicht).
Allerdings weiss ich nicht, ob es sich wirklich lohnen wuerde.  Wir
haben jetzt in clc++m etwa ein fuenftel soviele Artikel wie clc++ hatte
bevor es moderiert wurde. Das wuerde hier auf 2-3 Artikel pro Tag
hinauslaufen.

Vielleicht ist das nicht die beste Gelegenheit, aber da wir schon bei
der Sache sind: IMHO lohnt es sich in clc++m reinzugucken. Vieles, was
hier geposted wird, wuerde dort abgelehnt werden: Environment
Specifics, Off-Topics, FAQs, Flames... Dafuer gibt es Antworten (oft
sehr schnell, da wir uns mit dem moderieren ziemlich beeilen) zu fast
allen Fragen, die geposted werden.

: Trotzdem denke ich immer noch, dass Deine "Stilhinweise" falsch sind. Sie
: moegen in einer bestimmten Umgebung richtig sein, aber eben nur dort.

Die meisten der Stilhinweise, die ich abgebe, stammen nicht nur von
mir. Sie sind allerdings womoeglich in der Tat auf eine bestimmte
Umgebung abgestimmt: Programmeteile, die sich kein Resourceleak leisten
koennen und die ueber laengere Zeit verwendet werden sollen. Darunter
fallen z.B. alle Libraries (ich programmiere seit Jahren "nur"
Libraries, keine vollstaendigen Programme von Testprogrammen
abgesehen). Ein guter Teil der Diskussionen in clc++m und comp.std.c++
geht genau darum. ...  und Klassen sind, IMHO, "Units of Reuse". Also
haben sie ein "anstaendiges" Interface zu haben. Ob ich derzeit
Exceptions benutze oder nicht, ist dabei vollkommen irrelevant: Da
davon auszugehen ist, dass genau der selbe Code auch noch in ein paar
Jahren verwendet wird, bin ich gut beraten, ihn jetzt schon darauf
vorzubereiten, mit Exceptions zu arbeiten (auch wenn der Code noch
geaendert wird: entweder wird er vollstaendig weggeworfen oder nur
unwesentlich geaendert; ersteres ist je nach Umfang und allgemeiner
Qualitaet eher unwahrscheinlich).

: > Als allererstes sei auf die potentiellen Speicherloecher hingewiesen.
: [...]

: char* verursachen dabei nicht mehr Probleme als dynamische Objekte, vor
: allem deshalb, weil char* nicht unbedingt dynamischen Speicher impliziert.
: D.h. das Problem ist kein spezifisches Problem von Zeigern auf chars und
: damit auch *kein* Grund zur Kritik an diesen.

Gerade vorhin habe ich Scott Meyers' "More Effective C++" erhalten.
Hier ein kurzes Zitat (Item 9, "Use destructors to prevent resource
leaks", erster Satz): "Say good-bye to pointers. ...". Diese Aussage
wird zwar noch etwas relativiert, zielt  aber in die Richtung dessen,
was mich gestoert hat: Pointers, egal welcher Art, sind
Implementationsdetails, die in eine Klasse gehoeren. Das betrifft nicht
nur 'char*', sondern ALLE Pointer. Das Resourceleak-Problem kommt
zusaetzlich hinzu...

: Ausserdem steht es jedem frei Exceptions zu verwenden oder nicht (derzeit
: duerfte die Mehrzahl der Programmierer exceptions nicht oder nicht
: regelmaessig verwenden, schon alleine wegen der mangelnden Verfuegbarkeit).

Ich empfehle (ohne es persoenlich zu meinen), das dann 'new(nothrow)
....' anstelle von 'new ....' verwendet wird: 'operator new(size_t)'
darf nach ISO C++ Standard (coming soon to you...) Exceptions werfen:
Dies duerfte die mit Abstand prominenteste Stelle sein, wo sich mit dem
Standard die Regel unangenehm zu den Regeln im ARM aendern (die
Geschichte mit dem 'for-scope' ist dagegen nur laestig). Ab wann
Compiler damit tatsaechlich anfangen (und wann das tatsaechlich ein
Problem ist; um Code mit derartigen Problemen zu testen muss ich immer
mein Resourcelimit drastisch runtersetzen: bei > 100MB virtuellem
Speicher klappt Speicher anlegen eigentlich immer), ist ziemlich
unbestimmt.

Vielleicht sollte ich in der Tat davon absehen, meine grundsaetzliche
Paranoia gegenueber allem Code, der sich in extrem Faellen womoeglich
daneben benimmt, zu verbreiten. Persoenlich habe ich jedoch nach wie
vor ein ungutes Gefuehl bei jedem Pointer, den ich ausserhalb einer
Klasse sehe (die Diskussionen um 'auto_ptr' sensibilisieren halt doch
etwas...). Ich werde versuchen, mich in Zukunft auf "Meine persoenliche
Abneigung gegen Pointer ausserhalb von Klassen ist ja ausreichend
bekannt..." zu beschraenken.

: Und was ist mit "unsigned Counter"? Laut Deiner Argumentation ist das dann
: ploetzlich auch nicht mehr zulaessig, weil "unsigned" eine Repraesentation
: ist ("Counter" waere die Abstraktion).

Erscheint dir das als so abwegig? Siehe etwa 'size_t' (normalerweise
ein typedef fuer 'unsigned long int'). Zugegebenermassen verwende ich
oft 'int' direkt, aber nur dann, wenn ich mir ziemlich sicher bin, dass
'int' adaequat ist.  Ansonsten kommt man mit einem 'typedef' besser
aus: Man kann es z.B. an einer Stelle aendern, anstelle das man es
ueberall aendert, wo es auftritt. Es mag uebertrieben klingen, aber:
Ja, ich halte 'Counter counter' fuer vernuenftig. Wenn man mit
Templates arbeitet, bleibt einem oft eh nicht viel anderes uebrig...

[Ich wollte gerade erwaehnen, dass es irgendwelche Gruende gibt, 'int'
anstatt 'unsigned int' zu verwenden, aber ich finde die Referenz nicht
(schade). Wenn unbedingtes Interesse besteht, suche ich aber spezifisch
dannach...]

: Dieses Argument halte ich fuer noch schwaecher als das erste (das man
: zumindest in einem bestimmten Bereich als zutreffend bezeichnen konnte).

Es erscheint mir eher eine Geschmacksfrage zu sein... Ich halte es fuer
ausreichend schlagkraeftig. Insbesondere, da ich schon in Programmen
nach den Abstraktionen gesucht habe. Und: Mir hilft es selbst, wenn ich
mir die Abstraktionen selbst klar mache und sie, anhand des Typs, auch
konsistent verwende.

:   * Performance (class string ist um *Klassen* langsamer als eine Uebergabe
:     eines Parameters als char*).

Die anderen Gruende moegen ihr Berechtigung haben (ich stehe halt
darauf alle Pointer einzupacken...). Das interessiert mich aber: Hast
Du dazu Messungen. Ist ein 'string const &' bzw. ggf. ein 'string &'
WIRKLICH langsamer als ein 'char*'? Auf welchen Compilern/Platformen?
Stepanov hat einen Benchmark fuer die "Kosten von Abstraktion" gebaut,
bei dem z.B. g++ auf SUNs recht gut abschneidet. Was mich interessiert,
ist ob die Abstraktion 'string' wirklich "teuer" (*Klassen* langsamer)
ist. Wenn Du einen Performance-Tests dafuer hast, lasse ich ihn gerne
auf den mir zugaenglichen Platformen (diverse UNIX Derivate meist mit
g++; teilweise aber auch kommerzielle Compiler) laufen.

: Wie Du wahrscheinlich auch weisst residieren die Namen fuer Typen und die
: von Variablen in unterschiedlichen Namespaces (die Low-Level Erklaerung ist:
: Der Compiler hat unterschiedliche Symboltabellen fuer die Namen von Typen
: und Variablen. Das ist wegen der C Kompatibilitaet notwendig).
: D.h. entgegen Deiner Behauptung gibt es keinerlei(!) Konflikte wenn Typnamen
: als Variablennamen verwendet werden (vorausgesetzt natuerlich, man braucht
: nicht den Namen des Typs zusaetzlich zu dem der Variablen, wovon hier nicht
: auszugehen ist).

Hm. Mir scheint, ich bin mal wieder 100% im Off... So ein
Anfaengerpatzer. Aber in der Tat: Typnamen kollidieren nicht mit den
Namen anderer Objekte (kommt daher die Notwendigkeit fuer 'typename' in
Templates: Um zwischen zwei gleichen Namen, einem Typnamen und einem Objektname,
unterscheiden zu koennen? Koennte glatt sein...).

: Ich habe das auch nicht als Kritik an Dir gemeint, sondern als Kritik an
: Harald Fuchs. Trotzdem sind Hinweise zum Programmierstil praktisch *immer*
: eine persoenliche Sache, ganz einfach deshalb, weil Programmierstil eine
: persoenliche Sache ist. D.h. bei solchen Hinweisen gehst Du immer das Risiko
: ein, dass es jemand persoenlich nimmt. Und, wie ich oben ausgefuehrt habe
: halten Deine Sachargumente lange nicht das, was sie versprechen.

Ich werde mir mehr Muehe geben...

: Nimms nicht zu hart, auch das war nicht als Kritik an Dir gedacht :-)

Oh, mein Ego laesst sich mit sowas eh nicht so leicht ankratzen.  Ich
habe aus der bisherigen Diskussion gelernt ('nen bischen C++, 'nen
bischen, wie ich mich verhalten sollte). Insofern war die Kritik
konstruktiv und gegen die habe ich garnichts :-)

: > C++ wie C zu benutzen bringt keinen Vorteil.

: Auch hier: Widerspruch! Schon alleine die strengere Typpruefung, typesafe
: Linkage usw. machen viele Vorteile von C++ gegenueber C aus, auch dann, wenn
: ich keine einzige Klasse verwende, sondern weiterhin prozedural
: programmiere. Natuerlich kann ich nur einen Bruchteil der Vorteile von C++
: nutzen, aber die Aussage, so wie Du sie hinstellst ist auf jeden Fall
: falsch.

Stimmt. Ich empfehle den Leuten, die unbedingt C vor C++ lernen wollen
eigentlich auch immer, dass sie wenigstens einen C++ Compiler nehmen
sollen. Also: C++ wie C zu benutzen bringt nur geringen Vorteil.

: Soweit ok, nur musst Du dann auch damit rechnen, dass Kritik an Dir bzw.
: Deinen Argumenten kommt. Bisher, muss ich ehrlich sagen, waren letztere fuer
: mich nicht sehr ueberzeugend - aber vielleicht kommt ja noch mehr :-)

Kritik stoert mich eigentlichlich nicht... Was meine Argumente anbelangt, stimme
ich Dir zu, dass sie nicht weltbewegend sind :-( In meinem Kopf spukt halt eine
grundsaetzliche "Pointer ausserhalb von Klassen"-Phobie: Um jeden Pointer laesst
sich eine Klasse packen, die

- den Pointer initializiert (naja, ist auch nicht weltbewegend, aber
  ich bin halt leicht vergesslich...)
- aussagt, was der Pointer repraesentiert (das siehst Du leider nicht als Grund)
- die mit dem Pointer assoziierten Resourcen bei Bedarf freigibt,
  transferiert, dupliziert,... (ist in der Tat nur wirklich wichtig,
  wenn Exceptions in der Gegend rumfliegen).

Solche Klassen, als Template inline implementiert, kosten entweder
nichts oder sehr wenig.  Speziell bei Strings hat die Abstraktion
'string' noch die Vorteile, dass die Objekte leichter modifizierbar
werden, sich leichter vergleichen lassen und einige Operationen
potentiell schneller sind. In Zukunft kommen auch noch einige
Konversionen hinzu (z.B. 'string' <-> 'vector<char>'), die
Template-Members verwenden.

: > 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...

: Gruende habe ich oben genug aufgefuehrt, ich warte jetzt mal auf Deinen
: Followup :-)

Hier die Gruende:
:   * Low-Level Code

Egal auf welchem Level programmiert wird: Eine Abstraktion inklusive
passendem Schutz macht sehr schnell Sinn. Es ist richtig, dass 'string'
da oft nicht hilft, aber es war ja nach einem Sinn fuer 'char *string'
gefragt: Es soll ein String repraesentiert werden. Da ist nichts so
Low-Level dran.

:   * Interface mit anderen Sprachen (C z.B.)

Vielleicht. Andreas sprach z.B. von 'getenv()' (in einem Follow-Up).
Allerdings kann man sowas auch gleich in einem 'string' verschwinden
lassen und mit 'string::data()' wieder zum Vorschein kommen lassen.

:   * Performance (class string ist um *Klassen* langsamer als eine Uebergabe
:     eines Parameters als char*).

Es hat niemand gesagt, dass der 'string' per value uebergeben werden
soll: Dafuer gibt es Referenzen. Falls die Uebergabe per Referenz
wirklich langsamer ist (ich habe keinen Test gemacht) koennte dieses
Argument ziehen. Allerdings nur dann, wenn reichlich von den Objekten
konstruiert werden sollen...

:   * Bestimmte Repraesentation notwendig (z.B. Zeiger auf Shared Memory,
:     Objekte im Shared Memory gehen naemlich nicht bzw. nicht portabel).

Da sich der ISO C++ Standard nicht ueber Shared Memory auslaesst, ist
ALLES unportable. ... und ich lege Dir trotzdem problemlos bestimmte
Objekte in Shared Memory an (placement-new laesst gruessen).  Ausserdem
gibt es keinen Grund nicht eine Klasse zu bauen, die die Zugriffe auf
das Shared Memory Objekt einkapselt und durch einen 'char*'
repraesentiert wird (i.e. "class ShmObj { private: char *shm_mem; ...};"):
Wenn das eh unportable ist, dann kann man den unportablen Code
wenigstens in einem Punkt konzentrieren.

Wenn ich mir das so angucke, dann finde ich, dass meine Argumente fuer
mich ausreichen, Pointer aller Art nicht frei rumfliegen zu lassen:
Mann kann sie immer einpacken. Allerdings sehe ich ein, dass davon
nicht jeder so ohne weiteres zu ueberzeugen ist: Wir drehen uns im
Kreis. Vermutlich sind mir einfach eine ganze Reihe von Details
unbewusst im Sinn geblieben, die ich in Diskussionen in clc++, csc++
oder clc++m aufgeschnappt habe. Vielleicht ist es auch wirklich das
Umfeld in dem ich programmiere (derzeit bastel ich an einem "Toolkit
for Graph Algorithms", das in die Richtung von STL fuer Graphen geht:
da benutze ich einfach nur in Klassen Pointer, wenn ueberhaupt).

Auf jeden Fall werde ich mich bemuehen, in Zukunft meine Kritik besser
zu motivieren (seitdem ich was auf den Deckel bekommen habe, weil ich
eine abfaellige Bemerkung ueber "PC based operating systems" gemacht
habe, lasse ich das auch besser bleiben...).

Vielleicht sollten wir ueber etwas fundierteres diskutieren... Was
haelst Du z.B. von meinen Vorschlag (in einem anderen Thread), DOCH
einen Konstruktor aus einem anderen aufzurufen :-) Ziemlich nutzlos,
aber ist es wenigstens portable? Aus clc++m habe ich dazu [noch] nichts
gehoert... (und dabei gucke ich schon die ganze Zeit nach neu
eintreffenden Artikeln zum Moderieren: das ist der Vorteil. Ich sehe
einige Artikel viel frueher!  Teilweise dauert es 24h eh der Artikel
wieder zurueckverteilt ist, nachdem ich ihn moderiert bei
'netlab.cs.rpi.edu' ins Newssystem eingespeist habe).
--
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

Nun noch etwas (nur zum Spass, sonst fuer nix :-):

class charPointer {
    char *value;
    public:
    charPointer(char *aValue) {
        value = aValue;
    }
    operator char*() {
        return value;
    }
    charPointer& operator =(char* aValue) {
        value = aValue;
        return *this;
    }
    char& operator[](int i) {
        return value[i];
    }
};

Keine ueble Sache, was ;-)?
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

Hi,

abgesehen davon, dass die Klasse ziemlich albern ist (aber ich hab es
ja gradezu provoziert), gibt es dazu trotzdem eine kleine (nicht
persoenliche) Anmerkung:

Watson (sayegh@fokus.gmd.de) wrote:

: class charPointer {
:     char *value;
:     public:
:     charPointer(char *aValue) {
:         value = aValue;
:     }

Bei einem einfachen Member, wie 'char*' macht es vermutlich, ob des
Optimierers, keinen echten Unterschied, aber bei komplizierteren Membern
sollte man auf jeden Fall eine 'mem-initializer-list' verwenden, also
den Konstruktor folgendermassen schreiben:

      charPointer(char *aValue):
	value(aValue)
      {
      }

Das verhindert, dass der Member erst konstruiert wird (mit dem
Default-Konstruktor, den es oft genug ohnehin nicht gibt, so dass das
sowieso nicht geht) und dann gleich wieder mit einem neuen Wert (per
Assignment-Operator) ueberschrieben wird. Stattdessen wird direkt eine
Kopie des Arguments mittels Copy-Konstruktor angelegt. Diese Methode
funktioniert nur in dem eher seltenen Fall nicht, dass es keinen
Copy-Konstruktor gibt. Dann ist aber auch unwahrscheinlich, dass es
eine Default-Konstruktor UND einen Assignment-Operator gibt (denn dann
koennte man ja den Copy-Konstruktor so implementieren wie den
Default-Konstruktor mit einem nachgeschalteten Assignment).

... und gleich noch was relativ neues aus dem Standard: Fuer den Fall,
dass man eine etwaige Exception bei der Konstruktion eines Members in
der 'mem-initializer-list' abfangen will, kann man das so schreiben:

      charPointer(char *aValue)
	try
	{
	  : value(a_value)
	  {
	  }
	}
	catch (...)
	{
	}

Das geht aber nur fuer Konstruktoren (und ich bin mir nicht sicher, ob
der ':' vor oder nach dem 'try' hingehoert...).

:     operator char*() {
:         return value;
:     }
:     charPointer& operator =(char* aValue) {
:         value = aValue;
:         return *this;
:     }
:     char& operator[](int i) {
:         return value[i];
:     }
: };

: Keine ueble Sache, was ;-)?

Schliesslich, hier ein Template, dass man in den passenden Faellen als
"Smarter Pointer" (smart ist es naemlich nicht...) benutzen kann (ich
meine das durchaus ernst):

  template <class T>
  class UnmanagedPointer
  {
  private:
    T *i_res;
  public:
    explicit UnmanagedPointer(T *res = 0): i_res(res) {}
    // The generated copy ctor, assignment, and dtor are suitable

    T    *operator-> () const      { return i_res; }
    T    &operator[] (int i) const { return i_res[i]; }
    T    &operator* () const       { return *i_res; }
    T    *get() const              { return i_res; }
    T    *release()                { T *rc = i_res; i_res = 0; return rc; }
    void reset(T* res = 0)         { i_res = res; }
  };

Abgesehen davon, dass durch die Klasse (im Code) deutlich gemacht wird,
dass man sich um den Pointer nicht zu kuemmern braucht, kann man einen
'UnmanagedPointer' ueberall dort verwenden, wo man einen 'auto_ptr'
oder eine vergleichbare Klasse verwenden kann (sofern die Polymorphie
mittels Templates und nicht mittels Vererbung gemacht wird).  Daneben
hat diese Klasse, etwa gegenueber einem 'raw pointer' (und der Klasse
'charPointer') noch den Vorteil, dass sie nicht an der 'integral
promotion' teilnimmt, man kann also z.B. nicht "aus Versehen" schreiben

  f(UnmanagedPointer<char> &ptr)
  {
    if (ptr) // geht nicht
      ...
  }

sondern muss schon entweder '*ptr' oder 'ptr->get()' (je nachdem ob man
anhand des Wertes oder des Zeigers entscheiden will) schreiben. Auch
das Vermeiden von impliziten Konversion ist vermutlich ein Aspekt, den
viele nur als vermeintlichen Vorteil sehen werden. Aber immerhin hat es
das Standardisierungs-Kommittee fuer noetig befunden, 'explicit'
einzufuehren, damit man bestimmte Konversion verhindern kann bzw. man
muss die Konversion eben explizit fordern (durch einen passenden
Konstruktoraufruf).

Aber nichts fuer ungut. Vielleicht schafft ihr es ja doch noch
irgendwann mich zu ueberzeugen. Allerdings denke ich derzeit, dass es
besser waere, ihr wuerdet euch ueberzeugen lassen (klar, sonst waere
ich ja dumm, mich nicht von euch ueberzeugen zu lassen...). ... und
fuer den Fall, dass ich anfange der Meinung zu sein, dass frei
rumfliegende Pointer 'ne tolle Sache sind, brauche ich wohl nur mal
kurz mit James Kanze (man gucke sich einfach sein Artikel zum Thema
'auto_ptr' etc. an) darueber zu diskutieren, dann ist der Anfall wohl
wieder vorbei :-)
--
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

In message <pu91i3yvzc.fsf@themroc.colibri.de> - hf@colibri.de (Harald Fuchs)
w
rites:

>Man braucht kein Hellseher zu sein, um zu wissen, dass 'char*' in einem
>sauberen C++-Programm nichts zu suchen hat.

Mist... das C++ Buch, das ich vor einer Woche kaufte (bin neu in C++), macht
regen Gebrauch von char* :-(

Da haett ich jetzt gleich eine Frage dazu. Verzeiht, wenn sie nicht zum Thema
passt. Wie uebergebe ich denn einen String als Argument einer Funktion? Mein
Buchautor beschreibt das so:

#include<string.h>

void f(char* s) {
	char a[50];
	strcpy(a, s);
};

int main() {
  f("Das ist ein String");
  return 0;
}

Ich hab das zwar auch nicht fuer eine elegante Loesung gehalten, hab aber
leider nix anderes gefunden. Kennt bei dieser Gelegenheit jemand ein *gutes*
C++ Buch, welches *sauberes* C++ Programmieren beibringt? Meins ist "Das
grosse Buch zu C++" von Data Becker. War das einzige im Kaufhaus, und bereits
das zweite Uebungsbeispiel hab ich eleganter als der Autor geloest...

Dank und frohes Programmieren,

Thomas Beck, tombeck@usemail.com

=================================================================
Summer's day, as she passed away. Birds were singing in the
summer sky; then came the rain, and once again, a tear fell
from her mother's eye...
=================================================================

Dietmar Kuehl wrote:
> Bei einem einfachen Member, wie 'char*' macht es vermutlich, ob des
> Optimierers, keinen echten Unterschied, aber bei komplizierteren Membern
> sollte man auf jeden Fall eine 'mem-initializer-list' verwenden, also
> den Konstruktor folgendermassen schreiben:
> 
>       charPointer(char *aValue):
>         value(aValue)
>       {
>       }
Das ist mal ein konstruktiver Vorschlag :-)

[Lehrreiches weggeschnippelt]

> ... und gleich noch was relativ neues aus dem Standard: Fuer den Fall,
> dass man eine etwaige Exception bei der Konstruktion eines Members in
> der 'mem-initializer-list' abfangen will, kann man das so schreiben:
> 
>       charPointer(char *aValue)
>         try
>         {
>           : value(a_value)
>           {
>           }
>         }
>         catch (...)
>         {
>         }

Abgesehen vom Nutzen der Exceptions muss ich Dir leider
sagen, dass sie ein aesthetischer Fauxpas sind:

versucheMalObDasGeht {
  Arbeit();
} WennNaemlichNicht {
  kannJaGarNixGegenTun();
  sageWasUebles();
  terminiere();
}

Ich ziehe da allemal noch das klassische assert()
vor. Ein Konstruktor darf IMHO gar nicht fehlschlagen,
ausser im Falle aeusserer Fehler (zu wenig Speicher
etc.). Da aber im Fall von externen Fehlerursachen
sowieso nichts behoben werden kann, kann man auch 
genausogut bereits im Konstruktor abbrechen (z.B.
mit assert()).
Nichtsdestotrotz ist die abenteuerliche Schreib-
weise zum Abfangen von Exceptions aus abgeleiteten
Konstrukturoen natuerlich ein Grund zum Schmunzeln,
wie auch:

this->~bla();
this= new blubber();

zur Herstellung von Dr. Mabuse-Objekten :-)
IMHO wird C++ gerade so erweitert, dass irgendwann
jede beliebige Zeichenfolge irgendeine Semantik
hat, das ist nicht sehr schoen.


>   template <class T>
>   class UnmanagedPointer
>   {
>   private:
>     T *i_res;
>   public:
>     explicit UnmanagedPointer(T *res = 0): i_res(res) {}
>     // The generated copy ctor, assignment, and dtor are suitable
> 
>     T    *operator-> () const      { return i_res; }
>     T    &operator[] (int i) const { return i_res[i]; }
>     T    &operator* () const       { return *i_res; }
>     T    *get() const              { return i_res; }
>     T    *release()                { T *rc = i_res; i_res = 0; return rc; }
>     void reset(T* res = 0)         { i_res = res; }
>   };

Das wollte ich eigentlich ausdruecken ;-)
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

Hi,

Watson (sayegh@fokus.gmd.de) wrote:
: Das ist mal ein konstruktiver Vorschlag :-)

Endlich mal was, was gefaellt :-)

: Dietmar Kuehl wrote:
: > ... und gleich noch was relativ neues aus dem Standard: Fuer den Fall,
: > dass man eine etwaige Exception bei der Konstruktion eines Members in
: > der 'mem-initializer-list' abfangen will, kann man das so schreiben:
: > 
: >       charPointer(char *aValue)
: >         try
: >         {
: >           : value(a_value)
: >           {
: >           }
: >         }
: >         catch (...)
: >         {
: >         }

: Abgesehen vom Nutzen der Exceptions muss ich Dir leider
: sagen, dass sie ein aesthetischer Fauxpas sind:

: versucheMalObDasGeht {
:   Arbeit();
: } WennNaemlichNicht {
:   kannJaGarNixGegenTun();
:   sageWasUebles();
:   terminiere();
: }

: Ich ziehe da allemal noch das klassische assert()
: vor. Ein Konstruktor darf IMHO gar nicht fehlschlagen,
: ausser im Falle aeusserer Fehler (zu wenig Speicher
: etc.). Da aber im Fall von externen Fehlerursachen
: sowieso nichts behoben werden kann, kann man auch 
: genausogut bereits im Konstruktor abbrechen (z.B.
: mit assert()).

Ich hoffe, dass ich nie in die Verlegenheit komme, in ein Flugzeug zu
steigen, dessen Autopilot von Dir oder jemandem mit einer aehnlichen
Einstellung programiert wurde:  Das Programm mag zwar toll sein und
z.B. automatisch einen Rundflug fliegen, aber wenn beim Aufruf der
Rundflugprozedur zuwenig Speicher da ist, entschliesst sich das
Programm NICHT, einfach weiterzufliegen (eben ohne Rundflug), sondern
schaltet einfach mal ab.
Ein solches Verhalten mag im wissenschaftlichen Bereich (die GMD ist ja
kein industrielles Unternehmen) angemessen sein (die Tests steigen halt
mit 'ner Fehlermeldung aus), sind aber sonst in der Regel
katastrophal:  Wenn kein Speicher da ist, muss man allzu oft dafuer
sorgen, dass es trotzdem weitergeht. Exceptions sind genau dafuer gut,
dass man anstatt einem 'assert()' eine solche wirft: Wenn sie nicht
irgendwo gefangen wird, dann ist halt 'terminate()' faellig. Aber es
gibt Situationen, und zwar ausreichend viele und ich denke sogar die
Mehrzahl, in denen man eben schlimmstenfalls darauf verzichten kann,
einen bestimmten Teil des Programms auszufuehren.
Als Beispiel kann man sich einen interaktiven fuer sonstwas (Text,
Grafik, Audio,...) vorstellen, dass eine Modification-History
mitfuehrt. Wenn ein neues Element eingefuegt wird und kein Platz mehr
da ist (d.h. der entsprechende Konstruktor wirft eine Exception), dann
kann man ja die Modification-History etwas aufraeumen oder Teile
auslagern.

: Nichtsdestotrotz ist die abenteuerliche Schreib-
: weise zum Abfangen von Exceptions aus abgeleiteten
: Konstrukturoen natuerlich ein Grund zum Schmunzeln,
: wie auch:

: this->~bla();
: this= new blubber();

... was nicht geht (in meinem "Konstruktor"-Artikel habe ich eine
Sequenz 'this->~T(); new(this) T()' verwendet):  'this' (in einer
Methode von 'T')  ist deklariert als 'this *const'. In einer 'const'
Methode ist es als 'this const *const' deklariert. Die Deklarationen
von 'this' sind natuerlich implizit. Man konnte irgendwann (CFront-1.0
oder so) zu 'this' zuweisen. Das geht schon lange nicht mehr.
--
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

Hi,

Thomas Beck (tombeck@usemail.com) wrote:
: In message <pu91i3yvzc.fsf@themroc.colibri.de> - hf@colibri.de (Harald Fuchs)
: writes:

: >Man braucht kein Hellseher zu sein, um zu wissen, dass 'char*' in einem
: >sauberen C++-Programm nichts zu suchen hat.

: Mist... das C++ Buch, das ich vor einer Woche kaufte (bin neu in C++), macht
: regen Gebrauch von char* :-(

Das ist nicht weiter verwunderlich: Die meisten Buecher ueber C++
benutzen froh und munter Pointer und built-in Arrays, grade so, als
wenn das der beste Programmierstil ist, den es gibt (das ist vermutlich
auch einer der Gruende, warum ich hier mit meiner Anti-Pointer Meinung
ziemlich alleine dastehe). Das hat, soweit ich es sehe, im wesentlichen
zwei Gruende: 1. haben sich die Leute noch nicht abgewoehnt C zu
programmieren und 2. gibt es noch nicht lange gute (teilweise sogar
ueberlegene) Alternativen. DIE Alternative zu built-in Arrays sind STL
Vektoren. STL (Standard Template Library) ist der breiteren
Oeffentlichkeit (aeh, dem C++ Standardisierungs-Kommittee) erst seit
November '93 bekannt. Dem Normalverbraucher und Buchautor ist STL eher
weniger lange oder immernoch nicht bekannt (fuer diejenigen, die
dringenden Nachholbedarf empfinden:  "STL Tutorial and Reference
Guide", D.R.Musser and A.Saini, Addison-Wesley, ist eine sehr gute
Einfuehrung in STL von zwei kompetenten Autoren: Musser ist Co-Autor
der HP STL Implementation und hat die Grundlagen fuer "Generic
Programming" gelegt, Saini ist Autor der ersten kommerziellen STL
Implementation: Modena STL).

Die Alternative zu 'char*' (zumindest fuer den gaengigen Gebrauch als
String) gibt es dagegen schon laenger (siehe etwa Plauger's "The
(Draft) Standard C++ Library", Prentice Hall): Die Klasse 'string'.
Deren Aufbau hat sich allerdings noch geandert (ist deutlich flexibler
geworden, indem noch mit Templates rumhantiert wird). Haken an 'string'
(und auch an STL) ist leider, dass es noch nicht in allen
Compiler/Libraries enthalten ist (derzeit sind die meisten Compiler
noch nicht in der Lage, alle C++ Features zu unterstuetzen, die fuer
STL noetig sind...). Aber es gibt beides (die Klasse 'string' und STL)
in verschiedenen Varianten kostenlos im Netz (sie C++ FAQ und libg++)
oder, falls man Wert darauf legt was zu bezahlen, von kommerziellen
Anbietern (etwa ObjectSpace und Modena).

: Da haett ich jetzt gleich eine Frage dazu. Verzeiht, wenn sie nicht zum Thema
: passt. Wie uebergebe ich denn einen String als Argument einer Funktion? Mein
: Buchautor beschreibt das so:

: #include<string.h>

: void f(char* s) {
: 	char a[50];
: 	strcpy(a, s);
: };

: int main() {
:   f("Das ist ein String");
:   return 0;
: }

Sieht man davon ab, dass '#include <string.h>' kein Standard C++ ist
(die Standard-Variante '#include <cstring>' wird aber derzeit von kaum
einem Compiler unterstuetzt), dann ist das ungefaehr das, was die
meisten wohl auch machen werden (abgesehen von 'const' Modifiern). Mit
'string' sieht das selbe Beispiel etwa so aus (compilierbar z.B. mit
gcc-2.7.2 und libg++-2.7.1):

  // The following line would read '#include <bastring.h>' with some
  // compilers/libraries...
  #include <string>

  void f(string const &s)
  {
    string a(s);
    //...?
  }

  int main()
  {
    f("Das ist ein String");
    return 0;
  }

(Immerhin hat der Autor es geschafft, das nicht-portable 'void main()'
zu vermeiden. Das erscheint mir derzeit fuer eine ziemliche Leistung:
In ca. 50% der Artikel, die 'main' enthalten ist es eine Funktion, die
'void', also nichts, liefert).

: Ich hab das zwar auch nicht fuer eine elegante Loesung gehalten, hab aber
: leider nix anderes gefunden. Kennt bei dieser Gelegenheit jemand ein *gutes*
: C++ Buch, welches *sauberes* C++ Programmieren beibringt? Meins ist "Das
: grosse Buch zu C++" von Data Becker. War das einzige im Kaufhaus, und bereits
: das zweite Uebungsbeispiel hab ich eleganter als der Autor geloest...

Wenn irgendjemand ein C++ Tutorial kennt, dass 'vector' anstatt
built-in Arrays und 'string' anstatt 'char*' oder 'char const *'
verwendet, dann waere ich an sowas auch sehr interessiert (ich kann
zwar C++ programmieren, bin aber an einem guten C++ Buch zum
weiterempfehlen interessiert). Derzeit ist mir kein C++ (Einfuehrung-)
Buch bekannt, dass ich fuer vernuenftig halte (ein Indiz, dass meine
Meinung nicht brauchbar ist? Ich denke nicht: Ich kenne kein C++
Tutorial, dass STL verwendet. Die Leute sind einfach noch nicht up to
date. STL ist einfach noch zu neu). Grundsaetzlich wuerde ich uebrigens
eher unter den englischen Buechern gucken: Da es davon mehr gibt, ist
die Wahrscheinlichkeit hoeher, dass was vernuenftiges darunter ist. Das
Buch von Lippman wird uebrigens recht haeufig empfohlen. Allerdings
habe ich es selbst nicht gelesen (es erfuellt sicher nicht die
Kriterien, die ich stellen wuerde, um es auf jeden Fall
weiterzuempfehlen).

Auf jeden Fall reicht ein Buch ueber C++ nicht aus, um mit C++ vertraut
zu werden.  Dazu sind noch eine Reihe weiterer Buecher noetig. Wenn
Bedarf besteht, kann ich eine kommentierte Liste von Buechern, die ich
fuer empfehlenswert halte, posten.
--
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

Dietmar Kuehl wrote:
Hi,

> : Dietmar Kuehl wrote:
> Ich hoffe, dass ich nie in die Verlegenheit komme, in ein Flugzeug zu
> steigen, dessen Autopilot von Dir oder jemandem mit einer aehnlichen
> Einstellung programiert wurde:  Das Programm mag zwar toll sein und
> z.B. automatisch einen Rundflug fliegen, aber wenn beim Aufruf der
> Rundflugprozedur zuwenig Speicher da ist, entschliesst sich das
> Programm NICHT, einfach weiterzufliegen (eben ohne Rundflug), sondern
> schaltet einfach mal ab.

Du hast natuerlich recht, dass im Flugzeug-Fall die Fehlerbehandlung
nicht in "assertion failed at..." und anschliessendem Absturz 
bestehen darf. assert() sollte deshalb
nur bei echten Programmfehlern verwendet werden, um zu verhindern, dass
man diese durch Toleranz ewig mitschleppt und das undefinierte Verhalten
dann an anderer Stelle potenziert zuschlaegt. 

> Ein solches Verhalten mag im wissenschaftlichen Bereich (die GMD ist ja
> kein industrielles Unternehmen) angemessen sein (die Tests steigen halt
> mit 'ner Fehlermeldung aus), sind aber sonst in der Regel
> katastrophal:  Wenn kein Speicher da ist, muss man allzu oft dafuer
> sorgen, dass es trotzdem weitergeht. Exceptions sind genau dafuer gut,

Meine Karriere bei der GMD ist noch relativ kurz, vorher war ich
in Software-Unternehmen. Genau dort habe ich auch die Meinung
kultiviert, dass programmierte Toleranz gegebenueber Programmierfehlern 
nur zu laxer Qualitaetssicherung und schwerer Auffindbarkeit von
Fehlerursachen fuehrt

Im Uebrigen gibt's ja noch -D_NDEBUG, um alle assert()-Anweisungen
zu disablen.

Dass Speicheralloziierung fehlschlaegt, das wissen wir alle ;-), liegt
hauptsaechlich daran, dass vorher der Heap korrumpiert wurde. Und
solche Fehler sollten nicht verschleppt werden.
Wenn der Heap erst einmal zerstoert ist, gibt's i.d.R. keinen Speicher
mehr, und dann geht es eben nicht weiter. Sicherungssysteme dieser
Art muessen ausserhalb des Programms liegen.
Und sollte der Heap in Ordnung sein und der Speicherplatz nur voll:
Ich moechte natuerlich auch kein Flugzeug betreten, in dem mit Haupt-
speicher gegeizt wurde.

> dass man anstatt einem 'assert()' eine solche wirft: Wenn sie nicht
> irgendwo gefangen wird, dann ist halt 'terminate()' faellig. Aber es
> gibt Situationen, und zwar ausreichend viele und ich denke sogar die
> Mehrzahl, in denen man eben schlimmstenfalls darauf verzichten kann,
> einen bestimmten Teil des Programms auszufuehren.
> Als Beispiel kann man sich einen interaktiven fuer sonstwas (Text,
> Grafik, Audio,...) vorstellen, dass eine Modification-History
> mitfuehrt. Wenn ein neues Element eingefuegt wird und kein Platz mehr
> da ist (d.h. der entsprechende Konstruktor wirft eine Exception), dann
> kann man ja die Modification-History etwas aufraeumen oder Teile
> auslagern.

Uebrigens habe ich auch sehr lange Zeit eine "tolerante" Fehler-
behandlung verteidigt, mit recht aehnlichen Argumenten. Ein weit
verbreiteter Irrtum ist IMHO, dass Programmierfehler unerwartete
Zustaende eines Programms seien. Es gibt natuerlich definierte
Zustaende, die ein Programmierer nur nicht bedacht hat, die aber
im Rahmen seines Designs sichtbar sind. Diese Dinge sind meiner
Meinung nach zu tolerieren. Andere, wie etwa Zerstoerung des
Heaps, sind reine Programmschwaechen, und die sollten sofort
waehrend des Tests angezeigt werden.

Schliesslich finde ich, dass bei der Programmierung von
Steuerungssystemen von Flugzeugen und eine ueberzeugendere
Fehlertoleranz und -kompensation her muss als "der Programmierer
hat uns versichert, alle Exceptions abgefangen und behandelt
zu haben". Ich wuerde mal - statistisch fragwuerdig und
voellig unwissenschaftlich - behaupten, dass bei einem solchen System
10% Steuerung und 90% Kontrolle der Steuerung und Kontrolle der
Kontrolle der Steuerung sind.

> ... was nicht geht (in meinem "Konstruktor"-Artikel habe ich eine
> Sequenz 'this->~T(); new(this) T()' verwendet):  'this' (in einer
> Methode von 'T')  ist deklariert als 'this *const'. In einer 'const'
> Methode ist es als 'this const *const' deklariert. Die Deklarationen
> von 'this' sind natuerlich implizit. Man konnte irgendwann (CFront-1.0
> oder so) zu 'this' zuweisen. Das geht schon lange nicht mehr.
Da hast Du sicher recht, habe da nicht sehr detailgetreu geschrieben...

Mein Hauptkritikpunkt an Exceptions war ja auch aesthetischer
Natur ;-) Saehen sie besser aus, wuerde ich assert() auch nicht
mehr benutzen.
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

Watson <sayegh@fokus.gmd.de> writes:

> Mein Hauptkritikpunkt an Exceptions war ja auch aesthetischer
> Natur ;-) Saehen sie besser aus, wuerde ich assert() auch nicht
> mehr benutzen.

Meiner Ansicht nach sind Exceptions *keine* Alternative zu
Exceptions.  Ich benutze assert()s, um mich vor mir selbst und meiner
eigenen Dummheit zu schützen: assert()s stehen für Dinge, die von der
Logik her unmöglich passieren können, und sind Hinweise darauf, sich
bei der Weiterentwicklung des Programms darüber Gedanken zu machen, ob
diese Annahme auch wirklich zutreffend sind.  Exceptions sind eher ein
Mittel zum Transfer der Kontrolle in _unwahrscheinlichen_, aber eben
doch gelegentlich auftretenden Fällen.

Auch wenn Du Exceptions nicht magst: Du hast keine Chance, ihnen zu
entgehen.  Jedes nichttriviale Programm verwendet Libraries, und diese
Libraries verwenden zunehmend Exceptions.  Das hat fundamentale
Einflüsse auch auf Deinen Programmcode: Konstrukte wie

     alloc_resource ();
     some_func ();
     free_resource ();

sind neuerdings gefährlich, weil some_func() (oder eine davon aufgerufene
Funktion) eine Exception auslösen kann.  Dadurch wird diesem
unschuldig aussehenden Programmstück die Kontrolle unter dem A****
weggezogen.  free_resource() wird wider Erwarten nicht aufgerufen, und
schon hat Dein Programm ein Leck.

Pointer außerhalb von Klassen sind ein gutes Beispiel für derartigen
"gefährlichen" Code.  Ich will Dir gern zugestehen, daß bei
Wegwerfprogrammen die Verwendung von sicheren Alternativen nicht
unbedingt erforderlich ist, aber nachdem in dieser Gruppe offenbar
auch viele totale Anfänger mitlesen, sollte man diesen Leuten nicht
suggerieren, daß dies die "normale" Art sei, die Sprache zu
verwenden.  Korrigierende Hinweise erscheinen mir da durchaus
angebracht - insbesondere dann, wenn die sicheren Alternativen auch
noch einfacher zu verwenden sind.

tombeck schrieb am Do, den 22.02.96:

> Da haett ich jetzt gleich eine Frage dazu. Verzeiht, wenn sie nicht
> zum Thema passt. Wie uebergebe ich denn einen String als Argument
> einer Funktion? Mein Buchautor beschreibt das so:
> 
> #include<string.h>
> 
> void f(char* s) {
> 	char a[50];
> 	strcpy(a, s);
> };
> 
> int main() {
>   f("Das ist ein String");
>   return 0;
> }

Also zum einen ist  das  kein  C++,  denn  sonst  waere  f ja als Klasse
definiert worden, z.B. mit

class f 
 {
 	public:
		f (char *s);
 }

und dann den Konstruktor mit:

void f::f (char *s)
 {
	char a[50];
 	strcpy(a, s);
 }

und dann in main z.B.:

int main
 {
 	f 	myF ("mit diesem String wird nur Unsinn getrieben.");
	return 0;
 }

Aber zu Deiner Frage:  einen String im Sinne von Elementen des Datentyps
char uebergibst Du als Zeiger, also als char*, in Elementfunktionen, die
den String nicht aendern besser noch als const char*.

> Ich hab das zwar auch nicht fuer eine elegante Loesung gehalten, hab
> aber leider nix anderes gefunden. Kennt bei dieser Gelegenheit jemand
> ein *gutes* C++ Buch, welches *sauberes* C++ Programmieren beibringt?

Ja, es heisst 'Objektorientiertes Programmieren in C++' und ist von Nico
Josuttis (der schreibt auch ab und an hier im Brett :-))

> Meins ist "Das grosse Buch zu C++" von Data Becker. War das einzige
> im Kaufhaus, und bereits das zweite Uebungsbeispiel hab ich eleganter
> als der Autor geloest... 

Wundert mich ueberhaupt nicht; die Buecker von Data Drecker haben in der
Regel nicht mal Brennwert ...

        LIO

[Vorsicht, lang (leider)]

Ich versuche mal, die ganze Diskussion ueber Stilhinweise auf einen
Meta-Level zu heben, weil das rumgemache in Details IMHO recht wenig bringt.
Das kann ich mir natuerlich trotzdem nicht verkneifen, aber erstmal etwas
allgemeiner.

Also:
Wenn ich jemandem Hinweise geben will, wie er etwas besser machen kann, dann
gibt es zwei Moeglichkeiten:

  a. Entweder ich mache es anders, weil ich es eben anders mache. Dann kann
     ich das schreiben, es bleibt aber jedem selber ueberlassen, was er
     macht.

  b. Oder es gibt tatsaechlich echte, nachweisbare Gruende dafuer, warum man
     etwas so und nicht anders machen sollte.

Dein Hinweis in einem anderen Thread, dass "void main()" eine sehr unkluge
Deklaration ist faellt eindeutig unter letzteres. Was ist aber mit Deinen
Stilhinweisen?

IMHO fallen diese eindeutig unter a., sollten also etwas anders formuliert
werden. Es sei denn, Du kannst tatsaechlich nachweisen (und nicht nur durch
Behauptungen), dass durch Verwendung Deiner Hinweise "bessere" Programme
entstehen (besser soll hier heissen: schneller fertiggestellt [Kosten],
fehlerfreier [Kosten] und besser wartbar [Kosten]). Das Problem ist doch,
dass jeder Prophet einer neuen Sprache oder auch nur Stilrichtung behauptet,
dass dadurch "bessere" Programme entstuenden - die meisten koennen das aber
nicht nachweisen.
Solange kein solcher Nachweis existiert faellt das alles unter a. und man
kann verschiedener Meinung darueber sein. Gibt es tatsaechliche, echte
Gruende, dann faellt es unter b. und es waere fuer jeden Programmierer sehr
klug, die Hinweise zu beruecksichtigen (natuerlich ist es oft nicht so
eindeutig, aber man kann sich ja bemuehen).

Deine Aussage war: "char*" ist schlecht, die Verwendung dieses Konstrukts
erzeugt "schlechte" Programme (exakter: Programme, die nach den oben
aufgestellten Kritieren schlechter sind, als ein Programm, das "char*" nicht
verwendet).

Ist das tatsaechlich so? Mir ist keine Untersuchung in dieser Richtung
bekannt - aber heben wir das ganze mal auf einen etwas hoeheren Level: Wenn
dem so waere, dann muessten ja C++ Programme generell "besser" (im oben
definierten Sinne) sein, als C Programme, weil in C Programmen eben
grundsaetzlich "char*" verwendet wird, in C++ Programmen dagegen in vielen
Faellen nicht.

D.h. man koennte sich auch fragen: Sind C++ Programme bessere Programme? Und
hier heisst - sowohl nach den Untersuchungen die ich kenne, als auch meiner
persoenlichen Erfahrung nach - die Antwort eindeutig: NEIN.

Persoenliche Erfahrung: Meine Projekte in C oder Pascal haben weder eine
erhoehte Fehlerhaeufigkeit, noch eine schlechtere Wartbarkeit als meine C++
Programme. Es faellt mir in C++ etwas leichter, grosse Projekte zu managen,
weil die Hilfsmittel der Sprache zur Modularisierung besser sind, der Re-Use
Faktor ist bei C++ geringfuegig besser, aber das war's auch schon. Bei
meinen Assembler-Programmen ist es dagegen eindeutig, dass ich ca. um den
Faktor 2 mehr Fehler mache und dass die Erstellung wesentlich laenger
dauert.

Untersuchungen: Wer mir hier gerade einfaellt ist DeMarco, der in einem
Kommentar ueber seine "Kriegsspiele fuer Programmierer" (gemeint ist eine
Art Programmierwettbewerb) schreibt, es gaebe *keine* Korrelation zwischen
der Qualitaet der Loesung und der Wahl der Programmiersprache. Kann sich
jemand vorstellen, der Linux-Kernel waere besser (im oben definierten Sinne),
wenn er nicht in C, sondern in C++ geschrieben waere? Ich nicht (trotz aller
char* und void*).

Deine Argumentation in allen Ehren, aber ein bischen habe ich auch das
Gefuehl, Du bist etwas in den Grenzen der Sprache befangen. Wenn Speicher
Leaks tatsaechlich ein echtes Problem bei einer Applikation darstellen (und,
entgegen landlaeufiger Meinung sind sie das in vielen Faellen nicht), warum
nimmst Du nicht einfach einen Garbage Collector? Dann bist Du ohne viel
Rumgemache alle Sorgen los, und vor allem: Du bist sie wirklich komplett
los, auch dann, wenn Deine Klassen (die ja mit Pointern handeln) Fehler
enthalten. Und ja, es gibt inzwischen Loesungen, die bis auf wenigen Code
portabel und soweit ich weiss auch echtzeitfaehig sind. Fuer das Problem
Speicher Leaks heisst die adaequate Loesung nun eben mal GC, auch wenn C++
von sich aus keine GC anbietet.

Nicht, dass ich Deine Hinweise nicht interessant finde, aber Du solltest sie
IMHO nicht so als absolut gueltig darstellen. Es ist Deine Meinung, weiter
nichts. Wenn Du natuerlich Argumente hast wie "Laut einer Untersuchung von
Prof. Dr. Dr. F. Bar sinkt die Lebenserwartung von Programmierern bei
Verwendung von char* wesentlich", dann fallen Deine Hinweise eben unter b.
(aber sonst nicht :-).

Und weil ich gerade schon mehr in's Detail gegangen bin, auch das noch:

> [Ich wollte gerade erwaehnen, dass es irgendwelche Gruende gibt, 'int'
> anstatt 'unsigned int' zu verwenden, aber ich finde die Referenz nicht
> (schade). Wenn unbedingtes Interesse besteht, suche ich aber spezifisch
> dannach...]

Meiner Erfahrung nach ist es Unfug, (signed) int zu verwenden bei Variablen,
die per Definitionem eigentlich keine negative Zahlen enthalten sollten. Ein
Beispiel aus einem etwas laenger zurueckliegenden Projekt:

Es war bei uns im Team Vereinbarung, dass Funktionen ihre Parameter und die
Werte, mit denen sie arbeiten, zuerst komplett auf Gueltigkeit pruefen,
damit Fehler so frueh wie moeglich bemerkt werden. Ich hatte eine Funktion
geschrieben, die mit einer Variable namens "IndexPulse" gearbeitet hat, das
war die Anzahl von Pulsen, die eine Scheibe in dem zu steuernden Pruefstand
pro Umdrehung erzeugt. Etwas was definitiv nicht negativ sein kann.

Folglich stand bei mir, bevor ich die Variable anderweitig angefasst habe
ein "PRECONDITION (IndexPulse <= 4)", weil es nur Scheiben mit dieser
maximalen Anzahl an Loechern gab, alles andere musste also Unfug sein.

Dummerweise hatte aber jemand die Variable als int deklariert und es ist
prompt eine negative Zahl (weil nicht initialisierte Variable) durch-
gerutscht, die an anderer Stelle einen Fehler verursacht hat, nach dem
ich ziemlich lange gesucht habe (deshalb habe ich das auch noch in guter
Erinnerung :-).

Das Problem liegt darin, dass die Variable von ihrem Ursprung her impliziert,
dass es eben keine negativen Werte geben kann (negative Loecher gibt es eben
nicht :-), und entsprechend habe ich sie behandelt.

Meine Regel ist deshalb "wenn etwas eigentlich nicht negativ werden kann,
dann soll es auch nicht als signed Wert repraesentiert werden". Wenn Du so
willst, dann ist die Abbildung einer Groesse, die in der Realitaet nicht
negativ werden kann auf einen signed eine unexakte Abbildung.

Das ist natuerlich nur meine Meinung. Es waere auch eine Regelung denkbar,
dass *alles* als signed deklariert wird, dann weiss jeder (oder sollte es
wissen), dass auf negative Werte geprueft werden muss. IMHO ist es
einfacher, direkt unsigned zu nehmen.

> darauf alle Pointer einzupacken...). Das interessiert mich aber: Hast
> Du dazu Messungen. Ist ein 'string const &' bzw. ggf. ein 'string &'
> WIRKLICH langsamer als ein 'char*'? Auf welchen Compilern/Platformen?

Da class string den String prinzipiell immer auf den Heap packt ist wohl
klar, woher der Performance Unterschied kommt. Stell Dir folgende Funktion
vor:

        int StrCmp1 (const string& lhs, const string& rhs);
        // Compare two strings

und     

        int StrCmp2 (const char* lhs, const char* rhs);
        // Compare two string

Wenn Du einen Aufuf hast, wie:

        if (StrCmpX ("foo", "bar") == 0) { /* ... */ }

dann werden das eine mal einfach zwei Zeiger uebergeben, das andere Mal
werden zwei Objekte konstruiert (dazu wird Speicher auf dem Heap belegt und
der String dort rein kopiert), nach dem Aufruf wird der belegte Speicher
wieder freigegeben.

> Stepanov hat einen Benchmark fuer die "Kosten von Abstraktion" gebaut,
> bei dem z.B. g++ auf SUNs recht gut abschneidet. Was mich interessiert,
> ist ob die Abstraktion 'string' wirklich "teuer" (*Klassen* langsamer)
> ist. Wenn Du einen Performance-Tests dafuer hast, lasse ich ihn gerne
> auf den mir zugaenglichen Platformen (diverse UNIX Derivate meist mit
> g++; teilweise aber auch kommerzielle Compiler) laufen.

Ich habe nicht gesagt, dass die niedrigere Performance tatsaechlich eine
Rolle spielt, das tut sie in den meisten Faellen nicht (auch wenn 99% aller
Programmierer fest davon ueberzeugt sind, dass genau ihr Programm mit -O9
uebersetzt werden muss, und dass Bounds Checking bei Arrays des Teufels ist,
weil es zwar Bugs abfaengt, aber die Performance drueckt).

Wenn Du einen Test haben willst, nimm obigen Code (vergiss aber nicht, den
Optimierer auszutricksen, indem Du beide Strings im StrCmpX Aufruf als
extern deklarierst und die Implementation der beiden StrCmp Routinen in ein
anderes Modul packst. Ein Test macht keinen Sinn, wenn der Optimierer Dir
Deine ganze Testumgebung wegoptimiert :-)

> Es hat niemand gesagt, dass der 'string' per value uebergeben werden
> soll: Dafuer gibt es Referenzen. Falls die Uebergabe per Referenz
> wirklich langsamer ist (ich habe keinen Test gemacht) koennte dieses
> Argument ziehen. Allerdings nur dann, wenn reichlich von den Objekten
> konstruiert werden sollen...

Das Problem ist nicht die Uebergabe, sondern dass strings so implementiert
sind, dass die Daten auf dem Heap liegen. Das kann in bestimmten
Konstellationen (wie die oben) zu einer recht lausigen Performance fuehren.

> Da sich der ISO C++ Standard nicht ueber Shared Memory auslaesst, ist
> ALLES unportable. ... und ich lege Dir trotzdem problemlos bestimmte
> Objekte in Shared Memory an (placement-new laesst gruessen).  Ausserdem

Tja, reingefallen (aber troeste Dich, so ging's mir auch :-).
Natuerlich laesst sich ein Objekt mittels placement new in das Shared Memory
legen. Aber rate mal, was passiert, wenn Du von einem anderen Programm (das
natuerlich auch Zugriff auf das SM haben muss) virtuelle Methoden aufrufst?
Stichwort VMT (oder vtable) Zeiger...

> Wenn ich mir das so angucke, dann finde ich, dass meine Argumente fuer
> mich ausreichen, Pointer aller Art nicht frei rumfliegen zu lassen:
> Mann kann sie immer einpacken. Allerdings sehe ich ein, dass davon

Natuerlich kann man Pointer immer einpacken. Die Frage ist, ob es Sinn
macht, d.h. ob dabei bessere (im sehr viel weiter oben definierten Sinne)
Programme rauskommen.

> Vielleicht sollten wir ueber etwas fundierteres diskutieren... Was
> haelst Du z.B. von meinen Vorschlag (in einem anderen Thread), DOCH
> einen Konstruktor aus einem anderen aufzurufen :-) Ziemlich nutzlos,
> aber ist es wenigstens portable? Aus clc++m habe ich dazu [noch] nichts

Dazu habe ich leider zu wenig Ahnung von so esoterischen Features. Ich habe
zwar den Draft zum neuen Sprachstandard hier rumliegen (700 Seiten, C++ ist
wirklich eine Monster-Sprache), und auch mehrfach (kopfschuettelnd) darin
rumgelesen, aber um Deine Loesung zu durchschauen, dazu reicht es eben
trotzdem nicht. Ich bin eben letzten Endes bloss ein Anwender...

Gruss


        Uz



P.S.: Was haeltst Du von einem beiderseitigen "Abruestungsabkommen" auf
      Artikel mit nicht mehr als 100 Zeilen?    :-)
-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

In article <4gkjtq$o89@news.BelWue.DE>, kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) says:

>: writes:
>
>: >Man braucht kein Hellseher zu sein, um zu wissen, dass 'char*' in einem
>: >sauberen C++-Programm nichts zu suchen hat.
>
>: Mist... das C++ Buch, das ich vor einer Woche kaufte (bin neu in C++), macht
>: regen Gebrauch von char* :-(
>
>Das ist nicht weiter verwunderlich: Die meisten Buecher ueber C++
>benutzen froh und munter Pointer und built-in Arrays, grade so, als
>wenn das der beste Programmierstil ist, den es gibt (das ist vermutlich
>auch einer der Gruende, warum ich hier mit meiner Anti-Pointer Meinung
>ziemlich alleine dastehe). Das hat, soweit ich es sehe, im wesentlichen
>zwei Gruende: 1. haben sich die Leute noch nicht abgewoehnt C zu
>programmieren 

Das hat nicht mit abgewöhnen zu tun - wenn Du mal ausserhalb Deines
universitären Arbeitsumfeldes C++ einsetzen würdest, könntest
Du festellen, daß man teilweise auch alte Bibliotheken ansprechen
muß, die Pointer verlangen. Versuch doch mal Motif mit deiner String-
Klasse anzusprechen... (Da nützr dir auch der operator const char* von
einer String-Klasse nichts...) !


> und 2. gibt es noch nicht lange gute (teilweise sogar
>ueberlegene) Alternativen. DIE Alternative zu built-in Arrays sind STL
>Vektoren. STL (Standard Template Library) ist der breiteren
>Oeffentlichkeit (aeh, dem C++ Standardisierungs-Kommittee) erst seit
>November '93 bekannt
Na gut, daß Du das Standardisierungskommitee nicht leitest. 1993 hatte
man andere Probleme, nämlich erstmal die Templates an laufen
 zu bringen (und entsprechende Spracherweiterungen diesbezgl.)

Tolle Idee ;-) Strings ueber Vektorklasse...

> Dem Normalverbraucher und Buchautor ist STL eher
>weniger lange oder immernoch nicht bekannt
>[...]

>Auf jeden Fall reicht ein Buch ueber C++ nicht aus, um mit C++ vertraut
>zu werden.  

Dann solltes Du nicht so viel lesen ...

> Dazu sind noch eine Reihe weiterer Buecher noetig. Wenn
>Bedarf besteht, kann ich eine kommentierte Liste von Buechern, die ich
>fuer empfehlenswert halte, posten.

Sag ich doch, NICHT SO VIEL LESEN !


Gruss

Michael

[Gemaess der Friedensvereinbarung unter 100 Zeilen :-)]

Michael Lechner wrote:
> Das hat nicht mit abgewöhnen zu tun - wenn Du mal ausserhalb Deines
> universitären Arbeitsumfeldes C++ einsetzen würdest, könntest
> Du festellen, daß man teilweise auch alte Bibliotheken ansprechen
> muß, die Pointer verlangen. Versuch doch mal Motif mit deiner String-
> Klasse anzusprechen... (Da nützr dir auch der operator const char* von
> einer String-Klasse nichts...) !

Es geht ja nicht darum, dass Dietmar keine char* verwendet (das
wird ihm schwer fallen und erinnert mich an das Kinderspiel, bei
dem man im Zimmer herumlaufen muss, ohne den Boden zu beruehren ;-),
sondern dass er sie enkapsuliert sehen moechte, eine nachvollzieh-
bare Meinung, die eben (s.Thread) eben nur nicht grundsaetzlich
fuer adaequat gehalten wird.

> Dann solltes Du nicht so viel lesen ...
Das ist definitiv *falsch*. Ich waere froh, wenn mehr Implementierer
vom gerne zitierten "Cowboy-Programming" abruecken wuerden. Man muss
sicher nicht den ANSI 3 Draft durchlesen, aber zur rechten Zeit (vor
dem Benutzen eines Features) duerfte ein Blick hinein nicht schaden.

+++

Grundsaetzlich werden ja Designfehler nicht beim Programmieren, 
sondern beim Entwerfen gemacht. Viele sind sich nicht einmal im
Klaren darueber, was die Vorbedingungen ihrer Operationen sind,
geschweige denn, dass deren Verletzung mit assert() oder via 
Exceptions abfangen. Zudem wird ja auch gerne auf Dokumentation
verzichtet, obwohl genau das Schwaechen offenlegen kann: was 
schlecht auf dem Papier aussieht, ist meist auch schlecht 
gestaltet. Da helfen dann auch Kommentare in den Quellen nicht.
Merke: "Wenn ein Kommentar nicht zum Programmcode passt, ist
beides falsch."
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz) writes:

> Wenn ich jemandem Hinweise geben will, wie er etwas besser machen kann, dann
> gibt es zwei Moeglichkeiten:

>   a. Entweder ich mache es anders, weil ich es eben anders mache. Dann kann
>      ich das schreiben, es bleibt aber jedem selber ueberlassen, was er
>      macht.

>   b. Oder es gibt tatsaechlich echte, nachweisbare Gruende dafuer, warum man
>      etwas so und nicht anders machen sollte.

> Dein Hinweis in einem anderen Thread, dass "void main()" eine sehr unkluge
> Deklaration ist faellt eindeutig unter letzteres. Was ist aber mit Deinen
> Stilhinweisen?

> IMHO fallen diese eindeutig unter a., sollten also etwas anders formuliert
> werden. Es sei denn, Du kannst tatsaechlich nachweisen (und nicht nur durch
> Behauptungen), dass durch Verwendung Deiner Hinweise "bessere" Programme
> entstehen (besser soll hier heissen: schneller fertiggestellt [Kosten],
> fehlerfreier [Kosten] und besser wartbar [Kosten]).

Das läßt sich leider nicht genau trennen, und es ist eine Sache der
persönlichen Einstellung.  Ich denke, auch Dietmar wird Dir gern
zugestehen, daß Du bei Wegwerfprogrammen ohne weiteres char* verwenden
kannst (auch wenn "string" mehr über die Verwendung aussagt).  Bei
Code, der irgendwann vielleicht mal in irgendeinem anderen Kontext
verwendet werden könnte, gibt es aber eben doch "echte, nachweisbare
Gruende": wenn in diesem anderen Kontext Exceptions auftreten (und die
Wahrscheinlichkeit dafür steigt), hat man schnell ein Speicherloch.

Ich denke, Eure Differenzen sind eine Sache des persönlichen
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.

> Ist das tatsaechlich so? Mir ist keine Untersuchung in dieser Richtung
> bekannt - aber heben wir das ganze mal auf einen etwas hoeheren Level: Wenn
> dem so waere, dann muessten ja C++ Programme generell "besser" (im oben
> definierten Sinne) sein, als C Programme, weil in C Programmen eben
> grundsaetzlich "char*" verwendet wird, in C++ Programmen dagegen in vielen
> Faellen nicht.

Nein.  C kennt keine Exceptions (zumindest nicht von der Sprache her -
longjmp's sind wohl eher selten).

> D.h. man koennte sich auch fragen: Sind C++ Programme bessere Programme? Und
> hier heisst - sowohl nach den Untersuchungen die ich kenne, als auch meiner
> persoenlichen Erfahrung nach - die Antwort eindeutig: NEIN.

Sehe ich auch so.  Aber C++ wurde u.a. explizit daraufhin entwickelt,
mit großen Programmsystemen besser klarzukommen als in C.  Wenn man
sich in C++ einen sauberen Stil angewöhnt, könnte man IMHO große
Programme auch sauberer und wartbarer schreiben als in C - eben weil
die Sprache mehr Möglichkeiten bietet.

> Es faellt mir in C++ etwas leichter, grosse Projekte zu managen,
> weil die Hilfsmittel der Sprache zur Modularisierung besser sind, der Re-Use
> Faktor ist bei C++ geringfuegig besser, aber das war's auch schon.

Na immerhin :-)

> Deine Argumentation in allen Ehren, aber ein bischen habe ich auch das
> Gefuehl, Du bist etwas in den Grenzen der Sprache befangen.

Na klar, als Standardisierungs-Fuzzi :-)

> Wenn Speicher
> Leaks tatsaechlich ein echtes Problem bei einer Applikation darstellen (und,
> entgegen landlaeufiger Meinung sind sie das in vielen Faellen nicht), warum
> nimmst Du nicht einfach einen Garbage Collector? Dann bist Du ohne viel
> Rumgemache alle Sorgen los, und vor allem: Du bist sie wirklich komplett
> los, auch dann, wenn Deine Klassen (die ja mit Pointern handeln) Fehler
> enthalten. Und ja, es gibt inzwischen Loesungen, die bis auf wenigen Code
> portabel und soweit ich weiss auch echtzeitfaehig sind.

Bei großen Programmsystemen hast Du eben oft keinen Einfluß auf den
wenigen Code, bei dem GC auf die Nase fällt.  (Der liberale Umgang mit
Pointern gehört übrigens zu diesem Code: Pointer in die Mitte von
Objekten z.B. wird von vielen Kollektoren gar nicht gern gesehen.)

Auch bei der Echtzeitfähigkeit würde ich Abstriche machen.  Man kann
die Totzeiten durch Generation Scavenging und andere Verfahren zwar
ziemlich weit runterdrücken, aber ich könnte mir durchaus
Echtzeitanforderungen vorstellen, bei denen nicht mal das akzeptabel
ist.  Im Grenzfall läuft es darauf hinaus, daß man erstens keinen
separaten Kollektor-Thread haben darf und sich zweitens bei _jedem_
new überlegen muß, ob es vertretbar ist, daß der Kollektor jetzt ein
bißchen Zeit bekommt.

GC ist durchaus nicht die Patentlösung, die Du hier andeutest, und
u.a. deswegen ist sie (im Gegensatz zu den meisten anderen
OO-Sprachen) nicht in C++.

> Da class string den String prinzipiell immer auf den Heap packt ist wohl
> klar, woher der Performance Unterschied kommt.

Die Frage ist aber, ob das die Nachteile von wildem Rumgepointere
aufwiegt.  Bekanntlich werden 90% der Laufzeit in 10% des Codes
verbraten, oft in engen Schleifen und so.  Wenn Dir Dein Programm
wirklich zu langsam läuft und wenn Dir Dein Profiler sagt, daß es
wirklich ein Aufruf einer String-Memberfunktion ist, der so teuer ist,
dann solltest Du tatsächlich an dieser Stelle const char* verwenden -
aber eben nur dann und nur mit einem entsprechenden Kommentar (ugly
kludge due to performance reasons).

> Tja, reingefallen (aber troeste Dich, so ging's mir auch :-).
> Natuerlich laesst sich ein Objekt mittels placement new in das Shared Memory
> legen. Aber rate mal, was passiert, wenn Du von einem anderen Programm (das
> natuerlich auch Zugriff auf das SM haben muss) virtuelle Methoden aufrufst?
> Stichwort VMT (oder vtable) Zeiger...

Das wird üblicherweise so gemacht, daß man eine plain old C struct in
SHM legt und einen C++-Wrapper schreibt, der einen Pointer darauf enthält.

> Ich bin eben letzten Endes bloss ein Anwender...

Ich auch, und ich bin dankbar dafür, daß sich ein "Superuser" die Zeit
nimmt, mehr oder minder dumme Anwenderfragen zu beantworten.  Über
gutgemeinte, aber mich eventuell nicht betreffende weitere Ratschläge
sehe ich da gern stillschweigend hinweg.

> P.S.: Was haeltst Du von einem beiderseitigen "Abruestungsabkommen" auf
>       Artikel mit nicht mehr als 100 Zeilen?    :-)

Schon verloren :-(

Harald Fuchs wrote:
> Ich denke, Eure Differenzen sind eine Sache des persönlichen
> 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.

Oje, oje,

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?

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. 

Wuerde mich freuen, wenn Du von der hypothetischen
Einschaetzung der Diskussionspartner Abstand nehmen wuerdest,
auch wenn Du offenbar auf den, offensichtlich recht kompe-
tenten, Dietmar grosse Stuecke haeltst.
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

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

Dietmar Kuehl wrote:
> 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).

Dieser vorsichtig und dennoch richtig formulierte Absatz
sollte wohl Beispiel werden, wie man ueber Techniken
sprechen kann. Ich kann da nur zustimmen, inklusive dass
man es sich mit der Verwendung von Pointern auch schwer
machen kann, Betonung aber auf: kann.

> 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)...

Kompetenz in bestimmten Sachgebieten hat erfahrungsgemaess
wenig mit dem Titel zu tun ;-)
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);

Ein anderes gutes Buch: "Programmieren in C++" von Schader/Rundshagen.
3. Auflage im Springer Verlag


L.FRANZEN@BIONIC.zerberus.de wrote:

>tombeck schrieb am Do, den 22.02.96:

>> Da haett ich jetzt gleich eine Frage dazu. Verzeiht, wenn sie nicht
>> zum Thema passt. Wie uebergebe ich denn einen String als Argument
>> einer Funktion? Mein Buchautor beschreibt das so:
>> 
>> #include<string.h>
>> 
>> void f(char* s) {
>> 	char a[50];
>> 	strcpy(a, s);
>> };
>> 
>> int main() {
>>   f("Das ist ein String");
>>   return 0;
>> }

>Also zum einen ist  das  kein  C++,  denn  sonst  waere  f ja als Klasse
>definiert worden, z.B. mit

>class f 
> {
> 	public:
>		f (char *s);
> }

>und dann den Konstruktor mit:

>void f::f (char *s)
> {
>	char a[50];
> 	strcpy(a, s);
> }

>und dann in main z.B.:

>int main
> {
> 	f 	myF ("mit diesem String wird nur Unsinn getrieben.");
>	return 0;
> }

>Aber zu Deiner Frage:  einen String im Sinne von Elementen des Datentyps
>char uebergibst Du als Zeiger, also als char*, in Elementfunktionen, die
>den String nicht aendern besser noch als const char*.

>> Ich hab das zwar auch nicht fuer eine elegante Loesung gehalten, hab
>> aber leider nix anderes gefunden. Kennt bei dieser Gelegenheit jemand
>> ein *gutes* C++ Buch, welches *sauberes* C++ Programmieren beibringt?

>Ja, es heisst 'Objektorientiertes Programmieren in C++' und ist von Nico
>Josuttis (der schreibt auch ab und an hier im Brett :-))

>> Meins ist "Das grosse Buch zu C++" von Data Becker. War das einzige
>> im Kaufhaus, und bereits das zweite Uebungsbeispiel hab ich eleganter
>> als der Autor geloest... 

>Wundert mich ueberhaupt nicht; die Buecker von Data Drecker haben in der
>Regel nicht mal Brennwert ...

>        LIO

>>> Kennt bei dieser Gelegenheit jemand
>>> ein *gutes* C++ Buch, welches *sauberes* C++ Programmieren beibringt?

Na klar. Bei Addison-Wesley gibt es einige hervorragende Bücher über
C/C++. Als gute Einfühung in C++ kann ich das Buch  "Die C++
Programmiersprache" (übersetzt aus dem Amerikanischen). 

Das gute am Buch finde Ich:

Übersichtlich (Man findet das Zeugs später auch wieder im Buch)
gute Beispiele
Komplett
Tips zur allgemeinen Programm- und Bibliothekentwicklung

Hi,
Pascal Eugster (eugster4@dial.centralnet.ch) wrote:

: >>> Kennt bei dieser Gelegenheit jemand
: >>> ein *gutes* C++ Buch, welches *sauberes* C++ Programmieren beibringt?

: Na klar. Bei Addison-Wesley gibt es einige hervorragende Bücher über
: C/C++. Als gute Einfühung in C++ kann ich das Buch  "Die C++
: Programmiersprache" (übersetzt aus dem Amerikanischen). 

C++PL2 (fuer "The C++ Programming Language, 2nd Edition", B.Stroustrup,
Addison-Wesley) bringt leider nur die Haelfte der Sprache bei...: Einige
wichtige Sprachkonstrukte, die in ISO C++ enthalten sind, werden
ueberhaupt nicht erwaehnt. Dazu gehoeren:

- der built-in Typ 'bool' (mit seinen Literalen 'true' und 'false')
- die Keywords 'explicit', 'mutable', 'static_cast', 'const_cast' und
  'reinterpret_cast'
- RTTI, mit den Keywords 'typeid' und 'dynamic_cast'
- Member-Templates

Desweiteren wird sich ISO C++ von der Sprache, die C++PL2 beschreibt,
in einigen Bereichen signifikant unterscheiden. Problematisch daran ist
insbesondere, dass derzeit verfuegbare Compiler sich bereits nach dem
zukuenftigen ISO C++ Standard richten (etwa bei dem Scope von Variablen
in der 'for' Schleife).

... und natuerlich mein Lieblingskritikpunkt an fast allen C++
Tutorials (auf jeden Fall an allen, die ich mir genauer angeguckt
habe):  Die Library wird nur rudimentaer benutzt. Insbesondere, werden
Klassen wie 'string' und 'vector' nicht verwendet und ueberhaupt findet
STL keine Erwaehnung.  Ein C++ Tutorial, das STL nicht einfuehrt, ist
eigentlich kein C++ Tutorial! Es fehlt ein wesentlicher Aspekt.

: Das gute am Buch finde Ich:

: Übersichtlich (Man findet das Zeugs später auch wieder im Buch)

In der englischen Auflage ist der Index leider falsch... Das macht es
erheblich schwerer, Sachen wiederzufinden :-(

: gute Beispiele
: Komplett

Siehe oben. Es ist SEHR weit von komplett entfernt. Fuer den Anfang
reicht es aber notfalls, wenn man sich noch Information ueber STL
beschafft. Eine exzellente Beschreibung von STL gibt es z.B. in "STL
Tutorial and Reference Guide", D.Musser & A.Saini, Addison-Wesley.
Sorry, aber dafuer was deutsches zu finden, wird schwer...


: Tips zur allgemeinen Programm- und Bibliothekentwicklung

Die sind in der Tat sehr gut. In die selbe Richtung, vielleicht etwas
spezifischer, gehen die beiden Buecher von Scott Meyers: "Effective
C++" (davon gibt es eine deutsche Fassung: "Effektiv C++
programmieren") und "More Effective C++". Beide von Addison-Wesley.
Fuer nochmehr Buecher sei auf die Liste verwiesen, die letztens hier
gepostet habe...
--
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

Dietmar Kuehl wrote:
> 
> Hi,
> Pascal Eugster (eugster4@dial.centralnet.ch) wrote:
> 
> : >>> Kennt bei dieser Gelegenheit jemand
> : >>> ein *gutes* C++ Buch, welches *sauberes* C++ Programmieren beibringt?
> 
> : Na klar. Bei Addison-Wesley gibt es einige hervorragende Bücher über
> : C/C++. Als gute Einfühung in C++ kann ich das Buch  "Die C++
> : Programmiersprache" (übersetzt aus dem Amerikanischen).
> 
> C++PL2 (fuer "The C++ Programming Language, 2nd Edition", B.Stroustrup,
> Addison-Wesley) bringt leider nur die Haelfte der Sprache bei...: Einige
> wichtige Sprachkonstrukte, die in ISO C++ enthalten sind, werden
> ueberhaupt nicht erwaehnt. Dazu gehoeren:
> 
> - der built-in Typ 'bool' (mit seinen Literalen 'true' und 'false')
> - die Keywords 'explicit', 'mutable', 'static_cast', 'const_cast' und
>   'reinterpret_cast'
> - RTTI, mit den Keywords 'typeid' und 'dynamic_cast'
> - Member-Templates
> 
> Desweiteren wird sich ISO C++ von der Sprache, die C++PL2 beschreibt,
> in einigen Bereichen signifikant unterscheiden. Problematisch daran ist
> insbesondere, dass derzeit verfuegbare Compiler sich bereits nach dem
> zukuenftigen ISO C++ Standard richten (etwa bei dem Scope von Variablen
> in der 'for' Schleife).
> 
> ... und natuerlich mein Lieblingskritikpunkt an fast allen C++
> Tutorials (auf jeden Fall an allen, die ich mir genauer angeguckt
> habe):  Die Library wird nur rudimentaer benutzt. Insbesondere, werden
> Klassen wie 'string' und 'vector' nicht verwendet und ueberhaupt findet
> STL keine Erwaehnung.  Ein C++ Tutorial, das STL nicht einfuehrt, ist
> eigentlich kein C++ Tutorial! Es fehlt ein wesentlicher Aspekt.
> 
> : Das gute am Buch finde Ich:
> 
> : Übersichtlich (Man findet das Zeugs später auch wieder im Buch)
> 
> In der englischen Auflage ist der Index leider falsch... Das macht es
> erheblich schwerer, Sachen wiederzufinden :-( 
 : gute Beispiele
 : Komplett
 
 Siehe oben. Es ist SEHR weit von komplett entfernt. Fuer den Anfang
 reicht es aber notfalls, wenn man sich noch Information ueber STL
 beschafft. Eine exzellente Beschreibung von STL gibt es z.B. in "STL
 Tutorial and Reference Guide", D.Musser & A.Saini, Addison-Wesley.
 Sorry, aber dafuer was deutsches zu finden, wird schwer...
 
 : Tips zur allgemeinen Programm- und Bibliothekentwicklung
 
 Die sind in der Tat sehr gut. In die selbe Richtung, vielleicht etwas
 spezifischer, gehen die beiden Buecher von Scott Meyers: "Effective
C++" (davon gibt es eine deutsche Fassung: "Effektiv C++ programmieren") 
und "More Effective C++". Beide von Addison-Wesley.
 Fuer nochmehr Buecher sei auf die Liste verwiesen, die letztens hier
 gepostet habe...
 --
 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

Dietmar Kuehl wrote:
> ...
> : Tips zur allgemeinen Programm- und Bibliothekentwicklung
> 
> Die sind in der Tat sehr gut. In die selbe Richtung, vielleicht etwas
> spezifischer, gehen die beiden Buecher von Scott Meyers: "Effective
> C++" (davon gibt es eine deutsche Fassung: "Effektiv C++
> programmieren") und "More Effective C++". Beide von Addison-Wesley.
> Fuer nochmehr Buecher sei auf die Liste verwiesen, die letztens hier
> gepostet habe...
> --
> 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

Von der deutschen Version "Effektiv C++ programmieren" wuerde ich abra-
ten, da es den Eindruck einer Hoppla-Hopp-Uebersetzung macht, die inner-
halb kuerzester Zeit fertig werden musste.
Neben einer Reihe kleiner Tippfehler, die sich im Laufe der Zeit zu
einem Aergerniss summieren, faellt besonders die gelungene Uebersetzung
von allocate/deallocate auf: dort heisst es dann allokalisieren bzw.
deallokalisieren. Beim ersten Mal haelt man es noch fuer einen Witz,
doch im weiteren Verlauf des Buches merkt man, das der Uebersetzer es
ernst meint.

Vom Inhalt her ist das Buch wirklich zu empfehlen!!!

Tschau,
        Michael

-- 
 ____________________________________________________
|    Michael Milde                                   |
|    Friedrich-Schiller-Universitaet Jena            |
|    Institut fuer Angewandte Mathematik             |
|    Leutragraben 1                                  |
|    07740 Jena                                      |
|    Germany                                         |
|                                                    |
|    PHONE   +49 3641 630821                         |
|    FAX     +49 3641 630810                         |
|    E-MAIL  milde@mathematik.uni-jena.de            |
|____________________________________________________|