vergesst C++ ...

[Power Off]

O'Rakl schrieb:

Wie geht denn dynamische Typisierung in C++ ?

Über virtuelle Basisklassen.

[Gast]

Power Off schrieb:

O'Rakl schrieb:

Wie geht denn dynamische Typisierung in C++ ?

Über virtuelle Basisklassen.

wie elegant..

[Sovok]

O'Rakl schrieb:

Aber mal etwas genereller:
Python-Programme haben eine Eleganz und Kürze, die einfach C++ nicht
erreichen kann, selbst bei raffiniertester Anwendung der STL.
Das liegt eben wesentlich an der dynamischen Typisierung und der
Orthogonalität.

eleganz und kürze is auch nich alles
ich mag prinzipiell keine zusätzlichen kontrollstrukturen zwischen mir und dem rechner... wer sauber programmiert und weiß was er tut hat eh keine probleme mit den lowlvl mechanismen
@GC imho führt sowas zu verschwenderischen und trägen programmen, sowohl in der software selber als auch im stil der programmierer

[Gast]

O'Rakl schrieb:

Das liegt eben wesentlich an der dynamischen Typisierung und der
Orthogonalität.

Was ist denn diese famose Orthogonalität? Oder ist das nur ein BWLer-Buzzword?

[rüdiger]

@Optimizer

IMHO kann man sowas nur auf Sprachebene einschränken und nicht mit einem selbstgebauten Typ.

So ein quatsch. Wenn eben jemand Zeiger manipuliert, dann ist er selbst schuld, wenn der GC ihm um die Ohren fliegt. Du könntest genauso behaupten, dass man mit C++ nicht programmieren kann, weil

int *i=0x0;
*i=10;

möglich ist.

C++ ist eben eine Sprache, die den Programmierer nicht vor sich selbst schützt. Das kann man meinetwegen an C++ kritisieren (oder auch lieben).

[Sovok]

kingruedi schrieb:

@Optimizer

IMHO kann man sowas nur auf Sprachebene einschränken und nicht mit einem selbstgebauten Typ.

So ein quatsch. Wenn eben jemand Zeiger manipuliert, dann ist er selbst schuld, wenn der GC ihm um die Ohren fliegt. Du könntest genauso behaupten, dass man mit C++ nicht programmieren kann, weil

int *i=0x0;
*i=10;

möglich ist.

C++ ist eben eine Sprache, die den Programmierer nicht vor sich selbst schützt. Das kann man meinetwegen an C++ kritisieren (oder auch lieben).

[volkard]

TactX schrieb:

Was ist denn diese famose Orthogonalität? Oder ist das nur ein BWLer-Buzzword?

siehe jedes beliebige algol-buch.

[Gast]

volkard schrieb:

TactX schrieb:

Was ist denn diese famose Orthogonalität? Oder ist das nur ein BWLer-Buzzword?

siehe jedes beliebige algol-buch.

Thx

[groovemaster]

O'Rakl schrieb:

Python-Programme haben eine Eleganz und Kürze

Obwohl ich für sowas immer zu haben bin, ist das wirtschaftlich gesehen praktisch bedeutungslos. Dort kommt es hauptsächlich darauf an, dass ein Produkt funktioniert (Kunde) und dass es wartbar ist (Entwickler). Kurze Entwicklungszeiten sind zwar immer gern gesehen, aber Eleganz und wenig Code stehen oftmals in keinem direkten Verhältnis dazu.

O'Rakl schrieb:

Das liegt eben wesentlich an der dynamischen Typisierung und der
Orthogonalität.

So hat halt jede Sprache ihre Vor- und Nachteile und damit ihre Einsatzgebiete. Hast du schon mal versucht, mit Python einen Emulator zu schreiben? Vermutlich nicht. Irgendwie hast du noch kein gutes Argument gebracht, warum man C++ wegen Python vergessen sollte. Und GC ist erst recht keines, da man in C++ schon lange bewährte Ressourcenmechanismen verwendet, die stetig verbessert werden, um mehr Sicherheit zu bekommen. Egal ob das jetzt über Sprachmittel realisert wird (zB Smart Pointer) oder über Compilerverbesserungen. Und GC ist dafür kein Allheilmittel, im Gegenteil, es hat nicht zu unterschätzende Nachteile. Nichtlineares Laufzeitverhalten ist zB einer, dh in Echtzeit Systemen ist GC praktisch nutzlos. Zudem ist das wichtigste immer noch, dass man Ressourcen sicher benutzen kann und nicht, dass diese automatisch freigegeben werden.
Ausserdem sei noch erwähnt, so wie ich Orthogonalität verstehe, magst du gegenüber C Recht haben, aber C++ bietet da wesentlich mehr. Sicher gibt es auch hier Einschränkungen (zB keine Referenzen auf Referenzen), aber die wesentlichen Unterschiede, die dann über Eleganz und Codelänge entscheiden, liegen bei den syntaktischen Gegebenheiten. Und da spielt idR auch der persönliche Geschmack eine Rolle. Bisher hab ich nur einige Beispile in Python gesehen, die mich nicht wirklich vom Hocker gehauen haben. Dennoch würde ich nicht behaupten, dass man Python vergessen kann, weil C++ viel besser ist.

O'Rakl schrieb:

Ansonsten: Zeigerarithmetik, Pointer-Casting ("(void*)"...)

Scheinbar denkst du zu viel C.

O'Rakl schrieb:

und Garbage Collection gleichzeitig geht nicht

GC ist ein Konzept und beschreibt keine konkrete Implementierung. Mit konsequenter Benutzung von Smart Pointern hast du auch in C++ GC.

[Gast]

kingruedi schrieb:

@Optimizer

IMHO kann man sowas nur auf Sprachebene einschränken und nicht mit einem selbstgebauten Typ.

So ein quatsch. Wenn eben jemand Zeiger manipuliert, dann ist er selbst schuld, wenn der GC ihm um die Ohren fliegt. Du könntest genauso behaupten, dass man mit C++ nicht programmieren kann, weil

int *i=0x0;
*i=10;

möglich ist.

C++ ist eben eine Sprache, die den Programmierer nicht vor sich selbst schützt. Das kann man meinetwegen an C++ kritisieren (oder auch lieben).

Ach komm, warum habe ich extra zweimal erwähnt, dass man dazu nicht mutwillig die Arbeit des GC sabotieren muss?
Es reicht eine simple Übergabe eines Objekts per Referenz (und damit meine ich eine C++-Referenz), die kann intern auf einen Zeiger abgebildet werden und bumm. Oder ich hab ein char[], was natürlich vom GC verwaltet werden soll und geb nen char* mal schnell an ne DLL rüber, während der GC das bereinigen anfängt. Bumm.
Warum meinst du, habe ich geschrieben

Optimizer schrieb:

Du könntest mir jetzt natürlich Böswilligkeit unterstellen und C++ soll vor Böswilligkeit ja gar nicht schützen - aber schon das Übergeben eines Objekts als Referenz (&) kann intern das Übergeben eines Zeigers sein. Rohe Zeiger machen alle Sicherheit beim GC-Heap kaputt und solange man von allem die Adresse holen kann, ob beabsichtigt oder nicht, ob explizit oder nicht ...

damit du es nicht liest?

groovemaster schrieb:

Zudem zeigt es, dass GC unter C++ möglich ist, auch wenn man diesbezüglich Erweiterungen benötigt.

Hach ja. Dann sind wir uns doch einig.

Ich finde es nur etwas seltsam einer Sprache vorzuwerfen, dass sie kein GC erlaubt, obwohl sie dafür nie konzipiert war.

Es war nie als Vorwurf formuliert. Bitte sag mir wie ich mich noch vorsichtiger ausdrücken kann als mit "dass _kann_ man als Nachteil auffassen, _wenn_ man einen GC mag..."

[Ben04]

Vor einiger Zeit hab ich mich an einem GC für C++ versucht. Eigentlich war alles lösbarer Natur bis auf das Verschieben der Objekte. Der Knackpunkt heißt this. Das Problem ist, dass man in keiner Methode einen Heap komprimiren kann. Dies könnte ja den this Pointer verändern wodurch sämtliche Zugriffe auf das Objekt danach fehlschlagen. Mit Smartpointer ist hier nur mit einem sehr hässlichen Syntax etwas zu machen und sobald mehrer Threads ins Spiel kommen ist es nicht meher lösbar. Höchstens noch ein Hack der den this Pointer verändern würde.

C++ braucht um GC fähig zu werden eine Spracherweiterung. GC-Spracherweiterung sind dazu allerdings nicht nötig. Legentlich muß man den this Pointer konsequent duch einen Smartpointer ersetzen können.

[Power Off]

Ben04 schrieb:

C++ braucht um GC fähig zu werden eine Spracherweiterung.

So ein Käse. Es gibt GC System für C++, die auch funktionieren.

Wichtig ist auf jeden Fall die Verwendung einer eigenen Referenz-Klasse, damit Objekte, die noch benutzt werden, nicht vom GC hopps genommen werden können. Das ist doch logisch, oder!

[groovemaster]

Optimizer schrieb:

Es war nie als Vorwurf formuliert. Bitte sag mir wie ich mich noch vorsichtiger ausdrücken kann als mit "dass _kann_ man als Nachteil auffassen, _wenn_ man einen GC mag..."

Die Bemerkung von mir bezog sich vielmehr aufs Orakel und nicht auf dich. Wer GC unbedingt möchte, kann das durchaus als Nachteil bei C++ empfinden. Nur finde ich es seltsam, der Sprache dies vorzuwerfen. Immerhin beschwere ich mich bei Assembler auch nicht, dass dort kein OO Konzept vorhanden ist. Verstehst du, was ich meine?

[Gast]

Power Off schrieb:

Ben04 schrieb:

C++ braucht um GC fähig zu werden eine Spracherweiterung.

So ein Käse. Es gibt GC System für C++, die auch funktionieren.

Wichtig ist auf jeden Fall die Verwendung einer eigenen Referenz-Klasse, damit Objekte, die noch benutzt werden, nicht vom GC hopps genommen werden können. Das ist doch logisch, oder!

Versteh halt, dass der C++-Compiler implizit bei einer ganzen Reihe von Gelegenheiten Zeiger verwendet, rohe Zeiger, nicht deinen Referenztyp. Und die vorhandenen GCs funktionieren nicht toll, Stichwort Sicherheit und Performance. Sicherheit kann man irgendwie noch erreichen, wenn man sich selber an enge Regeln hält, für deren Einhaltung kein Compiler und keine Sprachbeschränkung sorgt, die daher leicht verletzt werden können, ohne dass böse Absicht dahinter steht. Die Performance ist ohne die Möglichkeit, Objekte zu verschieben, für die meisten Allokationsprofile im Eimer.

groovemaster schrieb:

Optimizer schrieb:

Es war nie als Vorwurf formuliert. Bitte sag mir wie ich mich noch vorsichtiger ausdrücken kann als mit "dass _kann_ man als Nachteil auffassen, _wenn_ man einen GC mag..."

Die Bemerkung von mir bezog sich vielmehr aufs Orakel und nicht auf dich. Wer GC unbedingt möchte, kann das durchaus als Nachteil bei C++ empfinden. Nur finde ich es seltsam, der Sprache dies vorzuwerfen. Immerhin beschwere ich mich bei Assembler auch nicht, dass dort kein OO Konzept vorhanden ist. Verstehst du, was ich meine?

Klar, zu 100%.

[O'Rakl]

<Über virtuelle Basisklassen.>

Eben. Objektorientierter Assembler. Ich bin sicher, es gibt auch einen
Weg, mit C++ Listenkomprehension nachzubilden oder Funktionen als Parameter an
generische Algorithmen zu übergeben, wahrscheinlich wird das ein halbes
Dutzend Bildschirmseiten voll von STL-Code erfordern und beim Lesen nur noch an
der Endung .cpp vom Compilat zu unterscheiden sein.

Mit Python macht man sowas mit eins, zwei Zeilen. Und zwar so, daß man es
in Kapitel 1 auf Seite 3 einer Python-Einführung -- für Leute, die noch nie zuvor eine Zeile programmiert haben -- erklären kann und nicht
erst in Kapitel 45 auf Seite 1200 eines Buches für Programmierer mit
Hochschulausbildung.

Das ist das, was ich mit "vergesst C++" meinte.

[Power Off]

Optimizer schrieb:

Versteh halt, dass der C++-Compiler implizit bei einer ganzen Reihe von Gelegenheiten Zeiger verwendet, rohe Zeiger, nicht deinen Referenztyp.

Das ist doch völlig wurscht, was der Compiler macht.

Eine richtige Garbage Collection greift nur für die Objekte, die dort sauber an- und abgemeldet werden. Ein Refernzzähler verhindert bei Zuweisungen etc., daß Objekte gekillt werden, die noch verwendet werden. Natürlich muß der Programmierer mit dem Ding auch entsprechend umgehen.

Lies doch mal ein Buch über Algorithmen oder Software-Techniken in C++, es gibt auch in solchen Büchern gelegentlich Referenz-Implementationen von verschiedenen Garbage Collector Typen. Wenn man die Sache versteht und richtig einsetzt, dann funktioniert das auch.

Es gibt in der Industrie massig Systeme, die für C++ GC einsetzen, aus was für Gründen auch immer. Das ist gar nicht so ungewöhnlich.

[Ben04]

Power Off schrieb:

So ein Käse. Es gibt GC System für C++, die auch funktionieren.

Ich meinte ein GC nach Java/.NET/... Vorbild.

Power Off schrieb:

Wichtig ist auf jeden Fall die Verwendung einer eigenen Referenz-Klasse, damit Objekte, die noch benutzt werden, nicht vom GC hopps genommen werden können. Das ist doch logisch, oder!

Ach und wie sieht deine Reference-Klasse aus? Also boost::shared_ptr ist jedenfals nicht sicher. A referenziert B und B A aber niemand sonst A oder B. boost::shared_ptr wird das nicht fangen. Der Java GC aber. Desweiteren ist ein heapkomprimierender Java GC in der Speicherfreigabe und Reservierung in der Geschwindigkeit und Speicherausnutzung nicht zu schlagen. Den Heap kann man komprimieren wann man will. C++s new und delete machen die Arbeit genau dann wenn man sie aufruft und nicht dann wenn man nichts besseres zu tun hat.

C++s new und delete haben sicher Vorteile aber ein GC nach Java Stil auch.

[Gast]

Power Off schrieb:

Optimizer schrieb:

Versteh halt, dass der C++-Compiler implizit bei einer ganzen Reihe von Gelegenheiten Zeiger verwendet, rohe Zeiger, nicht deinen Referenztyp.

Das ist doch völlig wurscht, was der Compiler macht.

Eine richtige Garbage Collection greift nur für die Objekte, die dort sauber an- und abgemeldet werden. Ein Refernzzähler verhindert bei Zuweisungen etc., daß Objekte gekillt werden, die noch verwendet werden. Natürlich muß der Programmierer mit dem Ding auch entsprechend umgehen.

Nein, das ist kein richtiger Garbage Collector. So ein GC erkennt zum Beispiel keine zirkulären Abhängigkeiten. Und es erklärt auch nicht, warum es wurscht sein soll, wenn irgendwo noch ein temporärer roher Zeiger auf ein Objekt vorhanden ist.

Lies doch mal ein Buch über Algorithmen oder Software-Techniken in C++, es gibt auch in solchen Büchern gelegentlich Referenz-Implementationen von verschiedenen Garbage Collector Typen. Wenn man die Sache versteht und richtig einsetzt, dann funktioniert das auch.

Das würde ich dir mal empfehlen, du hast es dringender nötig. Eat this:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx
http://de.wikipedia.org/wiki/Garbage_Collector#Mark_.26_Compact-Algorithmus
und lerne, wie eine anständige garbage collection funktioniert.

Es gibt in der Industrie massig Systeme, die für C++ GC einsetzen, aus was für Gründen auch immer. Das ist gar nicht so ungewöhnlich.

Den Eindruck konnte ich nicht gewinnen.

[Power Off]

Ben04 schrieb:

Ach und wie sieht deine Reference-Klasse aus? Also boost::shared_ptr ist jedenfals nicht sicher. A referenziert B und B A aber niemand sonst A oder B. boost::shared_ptr wird das nicht fangen. Der Java GC aber. Desweiteren ist ein heapkomprimierender Java GC in der Speicherfreigabe und Reservierung in der Geschwindigkeit und Speicherausnutzung nicht zu schlagen. Den Heap kann man komprimieren wann man will. C++s new und delete machen die Arbeit genau dann wenn man sie aufruft und nicht dann wenn man nichts besseres zu tun hat.

Ach was! Der Java GC ist saulahm. Mit einer schnelleren GC wäre Java viel besser. Außerdem blockiert der Java GC die Ausführung sämtlichen VM-Codes. Das ist doch totaler Blödsinn. Wenn die Architektur richtig ist, dann kann man den Heap im Hintergrund kompakten ohne die Objekte zu betreffen, die gerade in der Verwendung sind. Die sollten auch mal ein Buch lesen.

[Gast]

LOL, du weißt es natürlich besser als die Luschen von Sun. Naja, die haben halt einfach nichts drauf. Und wenn sie dich nicht um Hilfe bitten, warum solltest du dich aufdrängen, da hast du natürlich schon Recht.

Scherz beiseite. Dass der GC die Ausführung ewig blockiert ist natürlich Unsinn. Die Threads werden nur in der Remark- und in der Kompaktierungsphase angehalten, was der kleinste Teil der Arbeit ist. Und dass der GC saulahm ist, ist natürlich auch nicht richtig. Ich habe Gen0-Zeiten von ein paar hundertstel Millisekunden, bei denen einige Megabyte frei werden. Wenn die Anwendung nicht mit aller Gewalt so allokiert, dass die Objekte alle genau den Eden- und Surviver-Space gerade noch überleben, dann kann der GC gar nicht langsam sein. Ein bisschen tunen kann oft einiges bewirken und ein klassischer Heap mit Freispeicherliste ist auch lahm. Mit angepassten Allokatoren kann man natürlich eine allgemeine GC-Implementierung übertreffen, wie es Volkard vor einiger Zeit mal geschafft hat. Irgendwie ein paar Jahre oder so hat er gebraucht bis er das nötige Wissen zusammenhatte, meinte er dazu. Vielleicht findest du den Thread wieder, er hieß "@Gregor" oder so.