🚀 go-pugleaf

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