vergesst C++ ...

[ChockoCookie]

Ben04 schrieb:

Genau das ist ja das Problem! Erstens wird von Compiler Schwachsinn übersetzt und zweitens knallt es noch nicht einmal at runtime. Erst wenn der Kunde da sitzt und den Fall value = 1 durchspielt, den man vorher ja natürlich in den Betatests vergessen hat, kommen ganz merkwürdige Resultate raus.

Es knallt auch in Python zur runtime, wenn du eine Methode aufrufst, die der Typ nicht unterstützt.
Ausserdem hast du auch in C++ genügend Möglichkeiten Fehler einzubauen, die du ohne ausreichende Tests übersiehst.

Ben04 schrieb:

In braucht man in C++ dafür weder STL noch RTTI. Templates schaffen das ohne Runtimeoverheat. Aber das ist ja nicht das Thema, da es sich in dem Beispiel nicht um einen generischen Algorithmus handelt ist alles was du diesbezüglich gesagt hast hinfällig.

Ja, aber auch für Templates muss der Typ zur Laufzeit feststehen.
Die einzige Chance, die du hast in C++ dynamische Typisierung zu betreiben, sind Virtuelle Funktionen. Und das ist im Vergleich zu Python doch sehr begrenzt.

Ben04 schrieb:

Dann sind wir uns ja einig, dass O'Rakls Argument, dass Phyton iditonsicher ist nicht weiter hält.

Natürlich sind wir das. Ich finde es in der Tat schwer, neben ihm Python zu verteidigen, da einiges was er sagt irrelevant / nicht haltbar ist. Womit er aber nicht alleine ist.

Ben04 schrieb:

ChockoCookie schrieb:

Ich kann mir dafür keine Situation vorstellen, in der man einen solchen Fehler unabsichtlich machen würde. Und wenn, würde man ihn sofort herausfinden.

Ich schon : Primzahlenzerlegung. 1 wird sonder behandelt also hat man dann

def foo(value):
if (value==1):
return [1];
else:
  /* code */

Ich brauch nur die [] zu vergessen und fertig ist der Lack. Gut vielleicht kann man auch sagen 1 habe keine Primzahlenzerlegung aber das eigentliche Problem dürft klar sein.

Schon, aber sowas würde man sofort bemerken (wie gesagt), da die Python runtime excellente Fehlerinformationen liefert.

Ben04 schrieb:

Bisher hast du mir noch keinen einzigen klar gemacht. Also nochmal wieso sollte ich C++ vergessen und auf Python wechseln?

Die Gründe wieso ich Python mag sind:

• Die unglaublich mächtigen Sachen, die du mit der Sprache anstellen kannst und der daraus folgende hohe Abstraktionsgrad. Stell dir vor, C++ hätte eine RTTI, in der wirklich alles über das betreffende Objekt steht und du könntest sogar einiges davon ändern.
• Die umfangreiche Standard Bib
• List Comprehensions: [i+5 for i in myList]

[kartoffelsack]

Ja, aber auch für Templates muss der Typ zur Laufzeit feststehen.
Die einzige Chance, die du hast in C++ dynamische Typisierung zu betreiben, sind Virtuelle Funktionen. Und das ist im Vergleich zu Python doch sehr begrenzt.

Aber mit std::list<int> kann ich halt sagen, dass da einfach nur ints drin sein dürfen. Und mit std::listboost::any kann ich sagen, dass da alles rein darf. Und mit std::list<boost::variant<int, string> >, dass da ints und strings reindürfen. Genau das ist der Vorteil der statischen Typisierung. Die dynamische Typisierung nimmt mir die Möglichkeit dieser Festlegung.
Ein bisschen mehr dynamik (rtti a la reflexions) würden natürlich trotzdem nicht schaden.

[super!!]

Die unglaublich mächtigen Sachen, die du mit der Sprache anstellen kannst und der daraus folgende hohe Abstraktionsgrad. Stell dir vor, C++ hätte eine RTTI, in der wirklich alles über das betreffende Objekt steht und du könntest sogar einiges davon ändern.

Toll. Sowas braucht man aber nicht.

[kartoffelsack]

Toll. Sowas braucht man aber nicht.

Du vielleicht nicht. Aber wenn Du was mit interprozesskommunikation machen willst, Deployment zur Laufzeit etc.. Dann brauchst Du es. Und eine 'general-purpose-Language' wie C++ es ist, sollte sowas durch die Sprache unterstützen.

Wenn O'rakl mit solchen Sachen kommen würde, dann könnte man ihm ja recht geben ...

[O'Rakl]

groovemaster schrieb:

Was ist für dich denn der Unterschied zwischen "abstürzen" und "Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception"?

Ganz einfach: Im letzteren Fall stürzt nur eine *virtuelle* Maschine ab.
Dabei entstehen weder Schäden am Speicher noch am Dateisystem.

Groovemaster schrieb:

Also ein gewisses komödiantisches Talent muss man ihm ja durchaus zugestehen.

Die aber auch nicht, das muß der Neid Dir lassen

Groovemaster schrieb:

Übrigens, C++ enthält Objektorientierung auch als Grundlage.

So ein Käse.
C++ ist ein um OOP-Elemente erweitertes C und C ist bekanntlich keine objektorientierte Sprache. ursprünglich hieß C++ ja "C with
classes", was meinen Standpunkt beweist. C++ ist keine native OO-Sprache,
im Ggs. etwa zu Smalltalk oder Ruby.

[volkard]

O'Rakl schrieb:

Ganz einfach: Im letzteren Fall stürzt nur eine *virtuelle* Maschine ab. Dabei entstehen weder Schäden am Speicher noch am Dateisystem.

wie willste denn mit deiner anwendung in c++ durch nen absturz schäden am speicher oder dem dateisystem machen?
tip: es geht nicht.
langsam nervt diese ausgeburt der unwissenheit.

[volkardus]

kartoffelsack schrieb:

Toll. Sowas [RTTI nur mehr] braucht man aber nicht.

Du vielleicht nicht. Aber wenn Du was mit interprozesskommunikation machen willst, Deployment zur Laufzeit etc.. Dann brauchst Du es.

wir schicken texte. schlimmstenfalls eine silple folge von zeilen mit name=wert. erklär doch mal schnell, warum das nicht geht.

[Sovok]

kartoffelsack schrieb:

Vorkompilierte Header etc. bringen zwar was, lösen aber das Problem nicht.

warum lösen die das problem nich? die header werden dann schliesslich nur einmal übersetzt

kartoffelsack schrieb:

In C++ freu ich mich wie ein kleines Kind, wenn die Codevervollständigung die richtigen hints gibt.

probier mal visual assist x... macht n deutlich besseren job als die standardvervollständigung

[O'Rakl]

volkard schrieb:

wie willste denn mit deiner anwendung in c++ durch nen absturz schäden am speicher oder dem dateisystem machen?
tip: es geht nicht.

Oho Ein Amok laufendes C++-Programm kann den Speicher so zumüllen, daß das OS
den Prozeß abbrechen muß. Eine "access violation"-Meldung weist auch auf eine versuchte Beschädigung (natürlich nicht im Hardware-Sinne, sondern im
Sinne der Speicher-Integrität) des Speichers hin. Ein Pointer, der durch Programmfehler auf falsche Adressen zeigt, und dabei einen Befehlsstring wie "del $" in "del *"
verändert, kann das Dateisystem ebenso beschädigen wie ein durch ein überlaufendes Array veränderter Return-Stack, auf dem sich solche Daten befinden.

Dein Vertrauen in die Sicherheit der PC-Technik ehrt Dich, aber etliche
Sicherheitslücken, die auf überlaufenden C-Arrays und überschriebenen Returnstacks basieren, sprechen da eine etwas andere Sprache.

langsam nervt diese ausgeburt der unwissenheit.

Papperlapapp

[Helium]

Offtpic:
Ich hab mir auf Optimizers Rat hin C# 3 mal angesehen und wurde überzeugt. Die erste Version war ja irgendwie mehr eine Testsprache oder so, jedenfalls nichts tolles. Die zweite hat versucht die groben Fehler auszubügeln. Mit der dritten haben sie es jetzt endlich geschaft ne ordentliche Sprache draus zu machen.

Ich denke ich werde umsteigen.

[Artchi]

O'Rakl schrieb:

Oho Ein Amok laufendes C++-Programm kann den Speicher so zumüllen, daß das OS
den Prozeß abbrechen muß. Eine "access violation"-Meldung weist auch auf eine versuchte Beschädigung (natürlich nicht im Hardware-Sinne, sondern im
Sinne der Speicher-Integrität) des Speichers hin.

Und das OS (windows, Unix, wie auch immer) ist nicht schon eine Art "VM"??? Was meinste warum eine access violation Meldung kommt? Nicht wegen dem Speicher***schutz***, den letztendlich meistens sogar die CPUs in Hardware gegossen mitbringen? Eine VM in Software ist ja ganz nett, aber es ist eigentlich nur doppelt gemoppelt, was schon eine CPU und ein vernünftiges OS mitbringen. Wenn dem nicht so wäre, frage ich mich, warum ihr keine Angst vor der VM selbst habt (egal ob PythonVM oder JavaVM)? Diese VM kann doch dann auch Mist anstellen (ohne das das User-Programm schuld ist). Wer garantiert mir, das SUN nicht einen fiesen Bug in ihrer VM hat? Aber ich sage dir eines: die VM kann höchstens abstürzen, weil mich das OS und die CPU schützt!

Ein Pointer, der durch Programmfehler auf falsche Adressen zeigt, und dabei einen Befehlsstring wie "del $" in "del *"
verändert, kann das Dateisystem ebenso beschädigen

Komisch, aber gibts dafür nicht Berechtigungen im OS das mich vor solchen Dingen schützen soll? Warum will das die VM nochmalig leisten, wenn es schon der OS-Entwickler implementiert hat? Doppelt gemoppelt!

wie ein durch ein überlaufendes Array veränderter Return-Stack, auf dem sich solche Daten befinden.

Alte Geschichten, die seit MS VC++ 7.1 der Vergangenheit angehören! Der Compiler hat mittlerweile eine Array-Überlaufprüfung drin, die zur Laufzeit anspringt (gibts einen Compiler-Switch für). Dann wird dem User eine Meldung präsentiert, das ihn davor schützt. Das ganze wird mit einer Zufallsprüfsumme gecheckt. Wohlgemerkt kein Managed C++, sondern natives C und C++!

Dein Vertrauen in die Sicherheit der PC-Technik ehrt Dich, aber etliche
Sicherheitslücken, die auf überlaufenden C-Arrays und überschriebenen Returnstacks basieren, sprechen da eine etwas andere Sprache.

Wie gesagt, jeder moderne C und C++ Compiler hat heute Checks drin, die zur Laufzeit sowas prüfen.

[volkard]

O'Rakl schrieb:

Oho Ein Amok laufendes C++-Programm kann den Speicher so zumüllen, daß das OS den Prozeß abbrechen muß.

ein amok laufendes python-programm kann den speicher auch vollmüllen und wird auch abgebrochen. wo siehst du den elenden unterschied?

Ein Pointer, der durch Programmfehler auf falsche Adressen zeigt, und dabei einen Befehlsstring wie "del $" in "del *" verändert, kann das Dateisystem ebenso beschädigen wie ein durch ein überlaufendes Array veränderter Return-Stack, auf dem sich solche Daten befinden.

beides kommt nicht vor, wenn man arrays nimmt, die gegen indexüberläufe schützen. und das soll jeder tun. nur weil es möglich ist, muß man doch nicht jeden tag jeden fehler machen?

Dein Vertrauen in die Sicherheit der PC-Technik ehrt Dich, aber etliche
Sicherheitslücken, die auf überlaufenden C-Arrays und überschriebenen Returnstacks basieren, sprechen da eine etwas andere Sprache.

wirfst jetzt schon wieder fehler von C der sprache C++ vor.
langsam nervt diese ausgeburt der unwissenheit. du würdest einfach alle deine argumente gegen c++ fallen lassen, wenn du dich damit auseinandersetzen würdest. bisher ist mir nämlich kein überzeugendes untergekommen. viel eher waren 95% einfach falsch.

[:o)]

Power Off schrieb:

Perl ist übrigens auch sehr mächtig [...]

yo, mächtig scheisse

[Gast]

O'Rakl: Die zusätzliche Sicherheit durch die Nutzung von virtuellen Maschinen besteht zumeist darin, dass man mehr Möglichkeiten hat, die Freiheit einer Anwendung einzuschränken, insbesondere betrifft das Freiheiten die spezifisch für eine Programmierplattform (z.B. ReflectionPermission). Eine VM ist aber nicht prinzipbedingt ein toller Schutz gegen Bufferoverflows oder der Manipulation von prozessfremden Speicher. Wenn eine Sprache diese Freiheiten bietet, wie beispielsweise C++/CLI oder C# unsafe code, verhindert auch eine virtuelle Maschine solche Gefährdungen nicht. Dass ein amoklaufendes C++ Programm prozessfremden Speicher zu überschreiben versuchen kann und dann vom OS gekillt wird, würde auf Python genauso zutreffen, wenn die Sprache diese Möglichkeiten böte. Und wenn sie die Möglichkeite böte, Pointerarithmetik ohne range-check zu erlauben, könnten dort genauso Bufferoverflows auftreten, ohne dass die VM es verhindert. Denn die VM ist dann der eigentliche böse Prozess und würde vom OS gekickt. Besser noch, falls die VM mehrere Anwendungen in einem Prozess ausführt wie die Java MVM oder das .Net Framework mit seinen AppDomains, werden die unschuldigen Programme ebenfalls abgebrochen.

Umgekehrt kann ein anständiges Betriebssystem auch völlig ohne VM einer Anwendung alles untersagen, was irgendwie bedenktlich wäre, wie zum Beispiel den Zugriff auf das Dateisystem, Sockets, prozessfremden Speicher. Du tust so, als bräuchte man zwingend eine VM, weil sonst ein kaputtes Programm beliebige Freiheiten darin hätte, den Computer zu beschädigen.

[kartoffelsack]

Du vielleicht nicht. Aber wenn Du was mit interprozesskommunikation machen willst, Deployment zur Laufzeit etc.. Dann brauchst Du es.

wir schicken texte. schlimmstenfalls eine silple folge von zeilen mit name=wert. erklär doch mal schnell, warum das nicht geht.

Natürlich kannst Du eine Objekt in ne simple Zeichenfolge zerdröseln, das über tcp verschicken und auf der anderen Seite wieder zusammenbasteln. Nur: Mit Reflexions würde das Serialisieren automatisch funzen. In J2EE muss ich mir keine Gedanken darüber machen, wie das Ding serialisiert wird. (natürlich kann ich mir gedanken machen, und ich muss es auch, wenn ich etwas komplexere Objekte verschicken will. Aber das ist nicht der Standardfall und für den sollte eine Sprache was mitbringen. Genauso wie std::vector den Standardfall für Conatainer abdeckt). Automatische Serialisierung kann nicht von externen Bibs abgebildet werden, außer mann lässt nochmal spezielle Generatoren laufen (wie mans z.B. bei gSoap macht) -> für interprozesskommunikation wichtig.

Fürs Deployment bräuchte man natürlich zusätzlich byte-Code-Kompatibilität.

[Talla@work]

Helium schrieb:

Offtpic:
Ich hab mir auf Optimizers Rat hin C# 3 mal angesehen und wurde überzeugt. Die erste Version war ja irgendwie mehr eine Testsprache oder so, jedenfalls nichts tolles. Die zweite hat versucht die groben Fehler auszubügeln. Mit der dritten haben sie es jetzt endlich geschaft ne ordentliche Sprache draus zu machen.

Ich denke ich werde umsteigen.

Ein Erleuchteter
Aber so schlecht wie du C# 1.0 darstellst ist es nicht. Die meisten Unzulänglichkeiten gibts eher im .Net Framework 1.0/1.1 - die Sprache an sich hat keine groben Patzer - aber man kann sie halt noch um ein paar gute Konzepte erweitern. Und das wird ja mit C# 2.0 geschehen. C# 3.0 ist grad mal in der Planungsphase, wird aber nochmal um einige sehr interessante Aspekte erweitert die man heute schon in der Experimentalsprache Comega ausprobiert und sich so in den wenigsten momentanen Sprachen befinden. Durch all das wird sich C# immer mehr von Java abheben weil es mehr bietet und das Framework wird auch immer besser. Mit 2.0 ist den echt nen riesen Wurf gelungen.

[kartoffelsack]

kartoffelsack schrieb:
Vorkompilierte Header etc. bringen zwar was, lösen aber das Problem nicht.

warum lösen die das problem nich? die header werden dann schliesslich nur einmal übersetzt

Ist mir egal, wenn ein ein mittelgroßes Projekt dann trotzdem noch ein zwei drei oder 5 Minuten compiliert. Hab noch nie ein Java oder Delphi-Projekt gesehen, das auch nur ne Minute brauchen würde. Ja, ich weiß, C++-Code ist komplexer etc. aber es sind wirklich Größenordnungen. Und das, wenn ich alle vorkompilierten-Header- und Abhängigkeiten-vermeide-Tricks nutze. Wenn ich einfach versuche mein Problem mit Code zu lösen bin ich schnell bei compile-Zeiten von nem Viertelstündchen.

Außerdem muss ich für die vorkompilierten Header n Haufen herstellerspezifischer Regeln einhalten. Bei VC++ überall stdafx.h einbinde, da alle häufig genutzen wenig veränderten Header reintu (und damit in jedem Modul mehr abhängigkeiten schaffe, als ich eigentlich bruach. bei C++Builder dürfen die Header keinen Code (keine inline-Funktionen) beinhalten ...

Warum es nicht geht, jeden Header einzeln vorkompiliert vorzuhalten ...???

[Gast]

Ich finde schon, dass C# 1.0 grobe Patzer hat, auch solche, die man nicht mehr korrigieren kann. Der größte Patzer war, dass sie die Generics noch nicht hatte und man daraufhin die Standardbibliothek an einigen Stellen schlecht designed hat. Das Problem ist, dass generische Typen nicht abwärtskompatibel sind. Jetzt gibt es in der Standardbibliothek nicht-generische Collections und generische. Das einfache VB wird aufgemotzt weil sonst die neuen Klassen nicht genutzt werden könnten und implizit scheinbar nicht Object als Typparemeter angenommen werden kann.
Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>. Im System.Drawing-Namespace gibt es ein Rectangle, Size, Point sowie ein RectangleF, SizeF, PointF.
Am schlimmsten IMHO das kovariante Array mit Performance-Strafe für Referenztypen. Wenn von Anfang an Generics drin gewesen wäre, hätte man vielleicht so etwas gemacht wie Array<T>, wobei T[] dann nur eine abkürzende Schreibweise ist. Und Kovarianz hätte man dann immer noch explizit haben können mit Array<T> where T: Foo. Ich brauche so selten ein kovariantes Array, dass es mir weh tut, dafür zahlen zu müssen.

[Artchi]

kartoffelsack schrieb:

Natürlich kannst Du eine Objekt in ne simple Zeichenfolge zerdröseln, das über tcp verschicken und auf der anderen Seite wieder zusammenbasteln. Nur: Mit Reflexions würde das Serialisieren automatisch funzen. In J2EE muss ich mir keine Gedanken darüber machen, wie das Ding serialisiert wird. ...

Aha? Aber schon mal die Praxis durchgemacht? Wie haben hier einen J2EE 1.3 Server von IBM (WebSphere), natürlich sind die serialisierten Objekte die wir über RMI verschicken, mit einem J2SE 1.4 Client inkompatibel. Schöne tolle Welt, wo man sich keine Sorgen machen muß.

SUN hat das Problem erkannt, und seit Java 1.4 (oder 1.4.2?) werden alle Serialisierungen defaultmäßig per XML getätigt -> Text-Format! Eben damit es keine Binary-Inkompatibilitäten mehr zwischen Java Versionen geben kann (da bringt mir auch eine VM nichts mehr).

Ja ja, Theorie und Praxis!

Ich arbeite täglich 8 Std. mit Java, und glaubt mir: es hat schon seine Vorteile gegenüber C++. Aber es gibt Sachen, da frage ich mich "Was machen wir hier eigentlich mit dem Java-Kram?"

[Power Off]

schrieb:

Power Off schrieb:

Perl ist übrigens auch sehr mächtig [...]

yo, mächtig scheisse

Ich hab schon Compiler-Generatoren und Anwendungen mit grafischer Oberflaeche in Perl entwickelt.

Einziger Wermutstropfen ist, dass Perl so langsam ist. Z.B. OO-Programmierung in Perl ist sehr lahm.

Aber Perl ist halt sehr komfortabel.

Hatte mal ein Problem mit den Windows-Implementationen von Perl (z.B. ActiveState Perl), das lief irgendwie nicht zuverlaessig, da hab ich mit Perl unter Windows aufgehoert.

Aber unter Linux z.B. kann man's ja noch benutzen (oder unter Windows eine andere Perl-Distro nehmen).

Es gibt halt SWIW keine kostenlosen Perl Compiler, die die Programme schneller machen wuerden.