vergesst C++ ...

Meine Lieblingssprache/Framework ist immer noch C# mit dem .Net Framework

0'Rakl schrieb:

...spart euch die Zeit und den Stress und nehmt Python.
X-mal kürzere Entwicklungszeit, 5-mal
kürzere Quellcodes, kaum Debugging,
erlernbar in wenigen Stunden.

Ist C# auch, produktiver ist kaum ne Sprache zur Anwendungsentwicklung unter Windows.

0'Rakl schrieb:

Absturzfreie Compilate, selbst bei
groben Programmierfehlern.

Wer beim programmieren schlampt soll auch dafür bestraft werden!

0'Rakl schrieb:

Umfangreiche Standardbibliotheken mit
GUI-Toolkits und Networking, wird alles
mitgeliefert.

Die .Net BCL ist auch extrem umfangreich, in Version 2.0 bietet sie noch mehr ohne dabei unsauber und überladen zu werden.

0'Rakl schrieb:

Kein Ärger mit Pointern, Speicherverwaltung
und Arraygrenzen, dafür eingebaute Garbage Collection.

Dito in .Net, Arrays sollten Grenzen haben! Für den Rest gibts Collections.

0'Rakl schrieb:

Dynamische Typisierung, mit der man Dinge
schreibt, von denen man bei der Arbeit mit
STL nicht mal zu träumen wagt.

STL *hust* und naja, dynamische Typisierung kann ganz schön ins Auge gehen wenn man nicht aufpasst.

0'Rakl schrieb:

Festeingebaute Datentypen String,Liste,Tupel
und Dicitionary mit Verarbeitungsmöglichkeiten
der funktionalen Programmierung.

Okay, String sollte es in jeder Sprache geben als Datentyp, gibt im .Net Framework auch, aber Listen, Tupel, usw. sollten extra Klassen sein und keine integralen Datentypen. Dadurch wird die Sprache auch net schlanker

0'Rakl schrieb:

Adieu, C++ und Java

Aber auch nicht welcome Python

Kennt einer von euch die Spezifikationen für C# Version 3 ?
ist echt der Hammer was die aus der Sprache machen Comega lässt grüßen

hallo

wie "caste" ich in python? ich dachte das macht Python automatisch

z.b.

string = "a" + "b" + "c" 
print string
zahl = 123
string2  = "abc" + zahl + "def"

=========console============
abc
abc123
def

==========================

warum steht das def nicht direkt hinter "123" sondern erst eine zeile weiter unten?

C ist eine hervorragende Sprache, um hardwarenahe und resourcen-kritische
Probleme zu lösen, im Sinne eines portablen Assemblers.
Aber wieso deshalb gleich alle anderen Probleme auch ?
Nur weil ein Kaffeelöffel gut zum Umrühren von Kaffee geeginet ist, muß man ihn doch nicht gleich auch im Bergwerk, auf dem Bau und zum Ausbaggern von Flüssen
nehmen.

Aber ich gestehe zu, daß man nicht leicht merkt, wie viel Arbeit man bei C++
investiert in Dinge, die eigentlich der Compiler machen soll
(Zeiger, Referenzen, Speicherverwaltung, Garbage Collection,...), wenn
man sich richtig in C++ vertieft hat. Da muß man erstmal einen
Schritt zurück treten und sich umsehen, um zu merken, daß man da eigentlich
objektorientierten portablen Assembler schiebt.

O'Rakl schrieb:

C ist eine hervorragende Sprache, um hardwarenahe und resourcen-kritische
Probleme zu lösen, im Sinne eines portablen Assemblers.
Aber wieso deshalb gleich alle anderen Probleme auch ?

Ähmmm, du warst doch derjenige der "vergesst C++, nehmt Python" gesagt hat

Talla@work schrieb:

Kennt einer von euch die Spezifikationen für C# Version 3 ?

Chill mal, C# 2.0 ist gerade vor kurzem erst fest.

ist echt der Hammer was die aus der Sprache machen

Nein, eigentlich nicht. "Hammer" find ich Delegates, der Rest ist nur konsequente Weiterenticklung von Java, wobei man noch nicht mal aus dessen Fehlern gelernt hat. Zum Zeitpunkt der Entwicklung von C# gab es bereits eine Beta von Java 5, man hätte ohne Probleme von Anfang an Generics in die Sprache einbauen können und jetzt ist schon alles doppelt drin.

System.Drawing - namespace:
Point, PointF, Size, SizeF, Rectangle, RectangleF, ein PointL hätt ich mal gebraucht gibt's aber nicht - wie affig.

Ja, jetzt sind die Generics drin und was hab ich für nen XmlSerializer?
public XmlSerializer(System.Type) und nicht XmlSerializer<System.Type>. Erinnert mich verdächtig an die technischen Unzulänglichkeiten der Generics in Java mit T[] toArray(T object).
Und sprachlich sind die Generics sogar noch weniger flexibel. Nix mit Bivarianzen, Invarianzen und Contravarianzen wie in Java. Stattdessen ist der Fehler von Java übernommen worden, das Array Covariant zu machen und ich zahle jedesmal mit ein Stückchen Performance dafür, wenn ich einen Referenztyp in einem Array ablege. Ein ordentliches Array<T>, für dass T[] nur eine andere Syntax wäre, wäre performant gewesen und mit besseren Generics könnte ich für die Fälle, wo ich es brauche, ein Covariantes Array ala Array<? : T> benutzen.

Schon erstaunlich eigentlich, wie viele Nachteile von Java man nicht ausgemerzt hat und wo man überall Chancen verpasst hat. C# ist für mich zur Zeit die beste C-ähnliche Sprache, aber ich glaube trotzdem, dass einiges besser gemacht hätte werden können, was man jetzt nicht mehr korrigieren kann.

<<Schon erstaunlich eigentlich, wie viele Nachteile von Java man nicht ausgemerzt hat und wo man überall Chancen verpasst hat>>

C# und Java sind doch hoffentlich die Höhepunkte und gleichzeitig der Abschluß einer Epoche von umständlichen und syntaktisch häßlichen Programmiersprachen, bei denen der Compiler die ganze Arbeit dem Programmierer aufgehalst hat, mit naheliegenden Folgen für Fehlerdichte und Komplexität. Zeit, die man bei C++
mit technischen Details wie Speicherverwaltung und Zeigerarithmetik vergeudet,
könnte man auch zur Entwicklung statt zur Implementierung verwenden.

Seit Programmierzeit x-mal teurer ist als Rechenzeit, gibt es keinen
Grund, mangelnden Programmierkomfort, fehlende Datenstrukturen und
nichtvorhandene Orthogonalität einer Programmiersprache durch Effizienz zur Laufzeit zu entschuldigen (außer bei hardwarenaher und resourcenkritischer
Programmierung, das sind vielleicht 5% aller Anwendungen).

volkard

O'Rakl schrieb:

Zeit, die man bei C++
mit technischen Details wie Speicherverwaltung und Zeigerarithmetik vergeudet,

du machst den fehler, den alle java-befürworter machen. du zählt nachteile von C auf und wirfst sie C++ vor. würdest du C++ kennen, wärst du kein java-befürworter.

ps: windows xp ist riesenmist, weil windows 95 öfters abgestürzt ist.

GPC

O'Rakl schrieb:

, fehlende Datenstrukturen

Was bitte hat Python für Strukturen die C++ nicht auch in der Standardbibliothek (oder in irgendeiner anderen) hat?

O'Rakl schrieb:

und nichtvorhandene Orthogonalität einer Programmiersprache

Was ist Orthogonalität bei einer Programmiersprache, ich kenne das eigentlich eher aus Mathe und Vektorenrechnung

volkard schrieb:

ps: windows xp ist riesenmist, weil windows 95 öfters abgestürzt ist.

(Win95 war doch eigentlich recht stabil, 98 und ME sind doch häufiger ins Trudeln gekommen, oder täusch ich mich da? )

Power Off

freakz schrieb:

Perl ist schwer erweiterbar.

nimm ein Perl Programm was ca. 3000-5000 zeilen hat ( was ein anderer geschrieben hat ) und versuch das zu erweitern

Da ist Python wesentlich besser, aber auch das ist bei grösseren Projekten ( ab 5 Entwickler ) zu vergessen.

Das ist wie bei allen anderen Programmiersprachen auch: Wenn der Code sauber geschrieben und gut dokumentiert ist, ist das alles kein Problem.

... mit dem Unterschied, daß ich Java gar nicht befürworte, sondern
überflüssig finde. Java hätte der C-Nachfolger werden können, wenn Java 10 Jahre
früher gekommen wäre.

volkard

GPC schrieb:

(Win95 war doch eigentlich recht stabil, 98 und ME sind doch häufiger ins Trudeln gekommen, oder täusch ich mich da? )

täuscht.
win95 kackte fast täglich ab und win98 nur noch alle 2 wochen. bei normaler installation, 10 stunden benutzung am tag. aber wer hatte schon ein sauberes system? netzwerkkarten und grafikkarten verlangten treiberdisketten, die treiber waren so unsauber und win9x so empfindlich gegen unsaubere treiber, daß es eigentlich nur daran lag. die meisten, die auch win98 hatten, hatten viel viel mehr abstürze als ich mit meiner on-board-graka und nur ms-treibern.

Power Off

volkard schrieb:

win95 kackte fast täglich ab und win98 nur noch alle 2 wochen. bei normaler installation, 10 stunden benutzung am tag. aber wer hatte schon ein sauberes system? netzwerkkarten und grafikkarten verlangten treiberdisketten, die treiber waren so unsauber und win9x so empfindlich gegen unsaubere treiber, daß es eigentlich nur daran lag. die meisten, die auch win98 hatten, hatten viel viel mehr abstürze als ich mit meiner on-board-graka und nur ms-treibern.

Wenn Windows 95 sauber installiert war, mit guten Treibern, war es durchaus sehr stabil und stürzte selten ab. Ich hatte mal einen Rechner mit Windows 95, der rund um die Uhr lief, ohne oft abzustürzen. Meist kam das nur, wenn fehlerhafte Programme sich aufgehängt hatten. Dasselbe galt auch für Windows 98. Da die Windows 95, 98 und ME Linie aus 16-/32-Bit-Hybridsystemen besteht, ist das auch nicht weiter verweunderlich.

Die Windows NT Linie, also Windows NT, 2000 und XP (und jetzt Vista) sind deutlich stabiler, weil sie "reine" 32-Bit-Systeme sind (von den 16-Bit-Kompatibilitätslayern für MS-DOS, Windows 3.x und OS/2 1.x mal abgesehen, die jedoch der Speicherüberwachung durch die MMU unterliegen). Ich nehme an, daß bei diesen Systemen der Prozessor primär im Protect Mode läuft, während bei den Hybridsystemen der Prozessor oft im ungeschützten V86-Mode lief (hoffe, meine Terminologie hier stimmt).

groovemaster

O'Rakl schrieb:

Aber ich gestehe zu, daß man nicht leicht merkt, wie viel Arbeit man bei C++
investiert in Dinge, die eigentlich der Compiler machen soll
(Zeiger, Referenzen, Speicherverwaltung, Garbage Collection,...)

Du hast noch nie wirklich C++ programmiert, oder?
Leider geht es wie dir vielen Leuten, die nie richtig gelernt haben, mit C++ umzugehen. Mit Speicherverwaltung kommt man praktisch nie in Berührung, sondern benutzt bequeme Container. Da fällt höchstens mal ein foo.reserve(bla) an, aber auch nur wenn's um Laufzeiteffizienz geht. Das Problem ist einfach, dass zu viele Programmierer sich dessen nicht bewusst sind und einfach new verwenden. Sie haben das ja mal so gelernt. Und am Ende vergessen sie natürlich mit delete wieder alles freizugeben.
Zeiger wirst du nur sehr spärlich verwenden. Wobei das natürlich auch davon abhängt, wie hardwarenah du programmieren möchtest. Referenzen möchte ich persönlich nicht missen und wüsste jetzt nicht, wieso die mich zu viel Zeit kosten. Für Garbage Collection gibt es unter C++ keinen Grund, weil praktisch alle Implementierungen scope-basiertes Freigeben von Ressourcen verfolgen (was imo vorteilhafter ist).

GPC schrieb:

Was ist Orthogonalität bei einer Programmiersprache, ich kenne das eigentlich eher aus Mathe und Vektorenrechnung

Das frage ich mich auch schon die ganze Zeit.

volkard schrieb:

win95 kackte fast täglich ab und win98 nur noch alle 2 wochen.

Da hab ich ähnliche Erfahrungen gemacht. Wobei es mir so vorkommt, dass spätere Win95 Versionen (B, C) etwas stabiler waren. Aber gerade frühe A Versionen waren teilweise richtig grausam.

rüdiger

O'Rakl schrieb:

Aber ich gestehe zu, daß man nicht leicht merkt, wie viel Arbeit man bei C++
investiert in Dinge, die eigentlich der Compiler machen soll
(Zeiger, Referenzen, Speicherverwaltung, Garbage Collection,...)

Nein, ein Garbage Collector hat nichts mit dem Compiler zu tun und läuft nebenbei, wenn du das Programm ausführst. Für C++ gibt es übrigens auch GCs (Bsp. http://www.hpl.hp.com/personal/Hans_Boehm/gc/)

@Groovemaster:
<Für Garbage Collection gibt es unter C++ keinen Grund,>

GC ist aus einer modernen, abstrakteren Sprache nicht wegzudenken, denn alles, was der Compiler oder die Runtime erledigen kann, sollte nicht dem Programmierer
aufgelastet werden.
Die Wahrheit ist eher: C++ erlaubt gar keine GC, denn das ist mit einem
Zeigerkonzept und dem Casting (void*) unverträglich. Wenn die GC einen Speicherbereich freigegeben würde,
wüßte sie nicht, ob nicht im nächsten Augenblick ein Zeiger umgebogen
wird, der zunächst noch auf etwas ganz Anderes zeigte, um nun auf den
soeben freigegebenen Speicherbereicht zu zeigen:
Bingo.
<segmentation fault - address violation at 0x0012:3456>

Nach dem Studium von weit über tausend Seiten C++-Referenz bin ich
nicht mit Containern in Berührung gekommen, aber ständig mit
new, delete, malloc etc.
Wenn die simple Aufgabe, einen Speicherbereicht sicher zu belegen und
vor allem sicher wieder freizugeben, mehr als 1500 Seiten Lektüre erfordert,
dann -- da werden wir uns doch einig sein -- stimmt mit einer solchen
Programmiersprache didaktisch und womöglich konzeptuell etwas ganz entschieden nicht.

Ergänzung: Mit Containern bin ich schon
in Kontakt gekommen, allerdings habe ich nicht gesehen, wieso dadurch
eine Speicherverwaltung generell überflüssig würde.
Spätestens beim Implementieren eigener Klassen, die im Konstruktor Speicher belegen und im Destruktor wieder freigibt, hat man es mit klassischen Garbage-Collection-Aufgaben
zu tun.

groovemaster

O'Rakl schrieb:

denn alles, was der Compiler oder die Runtime erledigen kann, sollte nicht dem Programmierer
aufgelastet werden.

Sehe ich genauso. Nur wozu soll das ein Widerspruch sein?

O'Rakl schrieb:

Die Wahrheit ist eher: C++ erlaubt gar keine GC, denn das ist mit einem
Zeigerkonzept und dem Casting (void*) unverträglich.

Unsinn. MS nutzt für C++/CLI ebenfalls GC.

O'Rakl schrieb:

Wenn die GC einen Speicherbereich freigegeben würde,
wüßte sie nicht, ob nicht im nächsten Augenblick ein Zeiger umgebogen
wird, der zunächst noch auf etwas ganz Anderes zeigte, um nun auf den
soeben freigegebenen Speicherbereicht zu zeigen:
Bingo.
<segmentation fault - address violation at 0x0012:3456>

Das ist doch kein Problem einer Speicherverwaltung. Zeiger kann man nunmal auf jede beliebige Adresse verweisen lassen. Und wenn dieser Bereich dir nicht gehört, dann hast du auch kein Recht darauf zuzugreifen. Und wenn Non-Client Code auf ungültige Bereiche zugreift, dann ist das ein Problem der Speicherverwaltung bzw. der verwendeten Container, egal ob GC oder nicht.

O'Rakl schrieb:

Nach dem Studium von weit über tausend Seiten C++-Referenz bin ich
nicht mit Containern in Berührung gekommen, aber ständig mit
new, delete, malloc etc.

Genau darüber hab ich ja gesprochen. Zu viele Leute machen sich das Leben zu schwer, weil sie es einfach nie richtig gelernt haben. Ich bin zwar ein Befürworter, dass man sich gerade in C++, bevor man sich auf Bibliotheken wie STL oder Boost stürzt, die Grundlagen aneignen sollte, aber danach sollte man auf jedenfall die Funktionalität dieser oder anderer Bibliotheken nutzen.

O'Rakl schrieb:

Wenn die simple Aufgabe, einen Speicherbereicht sicher zu belegen und
vor allem sicher wieder freizugeben, mehr als 1500 Seiten Lektüre erfordert,
dann -- da werden wir uns doch einig sein -- stimmt mit einer solchen
Programmiersprache didaktisch und womöglich konzeptuell etwas ganz entschieden nicht.

Geb ich dir absolut Recht. Aber was hat das mit C++ zu tun?

O'Rakl schrieb:

Spätestens beim Implementieren eigener Klassen, die im Konstruktor Speicher belegen und im Destruktor wieder freigibt, hat man es mit klassischen Garbage-Collection-Aufgaben
zu tun.

Nö. Du kannst in Klassen natürlich auch Container verwenden und musst dich nicht um Speicherverwaltung kümmern. Und das alles ohne GC.

GPC

Die Wahrheit ist eher: C++ erlaubt gar keine GC, denn das ist mit einem Zeigerkonzept und dem Casting (void*) unverträglich

Die Wahrheit scheint mir eher dass du keine Ahnung hast, erstens hat kingruedi grad nen Link zur GarbageCollection gepostet und zweitens sind auch SmartPointer irgendwie "Garbage-Collectoren". Bloß nebenbei: Durch SP kann man oft normale Zeiger vermeiden (siehe Glib::RefPtr)

Spätestens beim Implementieren eigener Klassen, die im Konstruktor Speicher belegen und im Destruktor wieder freigibt, hat man es mit klassischen Garbage-Collection-Aufgaben
zu tun

Stimmt zwar mehr oder weniger, allerdings sind diese in einer Klasse gekapselt und können so besser überwacht und gesteuert werden, somit ist es unwahrscheinlicher dass man mal ein delete vergisst. Wozu hat man schließlich Ctors und Dtors? Wer schlampig programmiert, klar, der pisst sich selber an.

groovemaster

Ich glaube Smart Pointer ist für Orakel generell ein guter Tipp. Genug Lektüre dazu sollte ja im Netz zu finden sein.

Ich stimme mit O'Rakl fast nirgendwo überein, aber im Punkt mit der GC hat er Recht.
@groovemaster: C++/CLI ist kein Standard-C++. Nur mit Hilfe der Erweiterungen lassen sich Objekte erstellen, die auch wieder vom GC gefressen werden. Der Grund ist auch vollkommen klar, gewöhliche rohe Zeiger, die alles erlauben, sind vollkommen unbrauchbar, um damit auf einem verwalteten Heap zu arbeiten. Ein ordentlicher Garbage Collector verschiebt Objekte, weswegen spezielle Zeiger erforderlich sind, die entweder dem GC bekannt sind, damit er sie ändern kann, oder die über eine zusätzliche Indirektion verfügen. Vor allem aber, darf es nicht möglich sein, an die Adresse eines Objekts auf dem GC-Heap ranzukommen oder gar damit zu rechnen. In C++ kannst du von allem die Adresse holen, damit ist eine große Unsicherheit schon gegeben.

@kingruedi: Der von dir genannte GC ist unter keinen Bedingungen konkurrenzfähig zu einem "anständigen" GC, weder in Punkto Sicherheit, noch Performance. Der GC kann Zeiger auf ein Objekt nur erkennen, wenn du wirklich einen Zeiger darauf hast. Wenn du dir über Pointerarithmetik die Adresse des Objekts ausrechnest, erkennt er das nicht und entfernt es. Außerdem ist der Collector konservativ und erkennt damit generell schon nicht alle unbrauchbaren Objekte.
Bei der Performance wird es richtig schlimm. Normale GCs müssen aufwändig nach Verweisen auf Objekte suchen, was sie aber sehr optimieren können, indem sie Generationen benutzen. Ein Mark & Sweep Collector kann aber keine Generationen haben, da er den Heap nicht kompaktiert. Weiterhin ist das ändern der Freispeicherliste bei einer Bereinigung wesentlich aufwändiger, als das Verschieben der lebenden Objekte. Dieser GC hat also mehr Arbeit beim Auffinden der Objekte und beim Bereinigen dieser. Das Auffinden ist nochmal zusätzlich aufwändig, weil der GC alle 4 Byte-Blöcke auf dem Stack und auf dem Heap als Pointer annehmen muss und dementsprechend mehr mögliche Pointer prüft als ein GC, der entsprechende Metadaten zur Verfügung hat.

Fazit: Mit Standard C++ ist weder ein sicherer (im Sinne von "macht nix weg, was ich noch brauch, macht alles weg, was ich nicht mehr brauch) noch ein performanter GC möglich, so wie in C++/CLI mit Erweiterungen direkt an der Sprache ist es die einzige Möglichkeit. Das kann man, wenn man GCs mag, als Nachteil von C++ auffassen, so einsichtig könntet ihr schon sein.