vergesst C++ ...

Ja, da hast Du wohl recht, wahrscheinlich wird es in Zukunft keine CPUs geben, die C ausführen können. War ja nur so 'ne Idee, um nicht allzu pessimistisch zu
erscheinen, was die Zukunft von C angeht.

Danke für den Cintpos-Link übrigens

groovemaster

maximAL schrieb:

the right tool for the job - aber da C++ ja von low bis highlevel alles perfekt abdeckt, ist es auch immer das richtige werkzeug, gell?

Nein, du versuchst hier irgendwelche Statements zu zitieren, die es nie gegeben hat, zumindest nicht in diesem Thread. Also lass es einfach bleiben. Selbst C++ Programmierer in diesem Forum betonen immer wieder, dass man die Sprache nehmen sollte, die für den Zweck angemessen ist. Und da ist C++ sicherlich nicht immer die beste Wahl. Das ist aber nicht der Punkt. Der Punkt ist, dass C++ einem fast alles ermöglicht, egal wie einfach oder kompliziert das am Ende ausfällt. Und wenn Python für ein Projekt die bessere Wahl ist, dann wäre ich dumm, dies nicht zu nehmen. Auf der anderen Seite hat C++ genauso seine Einsatzgebiete.

O'Rakl schrieb:

C++ ist keine ausdrucksstarke Sprache.

Jede Programmiersprache ist auf seine Art und Weise ausdrucksstark, sonst hätte sie wohl keiner entwickelt und einfach eine bereits vorhandene genommen. Letztendlich könnten wir uns mit Beispielen bewerfen, bis der Arzt kommt. Nur weiss ich, dass das nichts bringt, du auch?

O'Rakl schrieb:

Zur Erinnerung: "ausdrucksstark" bedeutet, daß man eine Vielzahl von Konzepten
mit *wenig* Code beschreiben kann, nicht, daß die Quelltexte besonders viele
Ausdrücke enthalten

Irgendwie scheinst du selbst nicht zu verstehen, was du da von dir gibst. Die Beschreibung von Konzepten und deren Implementierung mit Code sind immer noch zwei verschiedene Dinge. Alles was du uns sagen willst, ist, dass Python eleganter ist. Schön, das tust du aber schon seit Seite 1. Noch irgendwas neues?

btw:
Könntest du endlich mal richtig quoten. Das ist ja noch schlimmer als deine Argumente.

O'Rakl schrieb:

Man kann
nicht die Nicht-Existenz von Features mit Codebeispielen beweisen

Schön, dass das mal jemand sagt. Das war mir bisher nicht bewusst.

O'Rakl schrieb:

Leg' Deine C++-Referenz mal auf den Schreibtisch und dann sieh von vorne
auf das Buch. Was siehst Du ?
5 bis 10 cm Papier.

Nö, ich sehe ein PDF mit 757 Seiten, auch bekannt als ISO/IEC 14882:2003(E). Aber wenn wir mal davon ausgehen, dass eine Seite 0,1 mm dick ist, ja, dann kommt das ungefähr hin.

O'Rakl schrieb:

-- und nun überlege mal scharf, ob wir hier über eine ausdrucksstarke
Sprache reden, wenn soviel Papier notwendig ist, um überhaupt erst mal
an den Datentyp "string" oder "liste" (der zweiteinfachste zusammengesetzte Datentyp) zu gelangen.

Ja...ich überlege...hmm, list scheinen 5 Seiten zu sein. string ist etwas mehr, 24 Seiten. Schnell mal nachgeschaut...ist fast so wie erwartet. Viel Code, sehr viel Code. Eigentlich nur für STL Implementierungen hilfreich. Können wir also überspringen. Aahhhhh, jetzt wird's interessant, jede Funktion wird beschrieben mit Effects und Returns. Sehr schön, genau was wir brauchen. Wie war nochmal das Thema?

maximAL schrieb:

mir wärs nun wirklich zu blöd, noch weiter zu machen, denn mir ist eh klar, dass es im grunde keiner hören will.

Naja, zumindest mit boost muss ich dir teilweise Recht geben. boost ist KEIN Standard, kann man somit auch nicht zum Umfang von Standard C++ zählen. Und wer es benutzt, sollte schon gute C++ Kenntnisse besitzen. Ansonsten gibt es natürlich Sachen, die man, wenn schon nicht built-in, sich zumindest in der STL wünschen würde. Das kann man aber nicht C++ zum Vorwurf machen, sondern muss feststellen, dass andere Sprachen aus den Unzulänglichkeiten gelernt haben. Und das soll nicht heissen, dass es sowas in Zukunft nicht auch in C++ geben wird.
Deine Kritik an den Typen kann ich allerdings nicht nachvollziehen. Man sollte sich immer im Klaren sein, dass C++ ein statisches Typsystem verfolgt. Einige Leute scheinen sich darüber zwar aufzuregen. Denen kann man allerdings nur sagen, das ist kein Bug sondern ein Feature.

groovemaster schrieb:

Deine Kritik an den Typen kann ich allerdings nicht nachvollziehen. Man sollte sich immer im Klaren sein, dass C++ ein statisches Typsystem verfolgt. Einige Leute scheinen sich darüber zwar aufzuregen. Denen kann man allerdings nur sagen, das ist kein Bug sondern ein Feature.

Typen sind nichts schlimmes. Nur sollten lediglich Werte typisiert sein, nicht aber Variablen. Das ist aber bei C++ leider nicht der Fall.

Ähm, wie meinst du das genau, dass man ein statisches Typsystem hat, wo aber nicht die Variablen typisiert sind? Kannst du mal ein Beispiel geben?

Helium

Ich denke er will es so wie in Python, nicht aber wie in VB.

maximAL

groovemaster schrieb:

Deine Kritik an den Typen kann ich allerdings nicht nachvollziehen. Man sollte sich immer im Klaren sein, dass C++ ein statisches Typsystem verfolgt. Einige Leute scheinen sich darüber zwar aufzuregen. Denen kann man allerdings nur sagen, das ist kein Bug sondern ein Feature.

oh, es gibt auch statische typsysteme, die ohne explizites deklarieren der typen auskommen
mag sein, dass die dann wieder andere fallstricke haben, aber ich fands schon ganz angenehm

Optimizer schrieb:

Ähm, wie meinst du das genau, dass man ein statisches Typsystem hat, wo aber nicht die Variablen typisiert sind? Kannst du mal ein Beispiel geben?

Visual Basic 6 z.B. hat von seinen Vorgängern geerbt, daß es eigentlich gar
keine Datentypen gibt (nur den Typ "variant" mit einem dutzend Untertypen),
man kann aber auch explizit Typen zuweisen.
Das ist dann eine schwache Typisierung, denn dieselbe Variable kann ohne
Konversion mal als Typ A, mal als Typ B verwendet werden, andererseits
kann man durch explizite Typzuweisung Variablen statisch typisieren.

Chew-Z

Klar hat VB6 seine eigenen Typen. Variant ist nichts weiter als eine Art
struct/union die in eine Typkennung hat, und alle "Basisdatentypen" an
entsprechender Stelle der stuct/union aufnehmen kann. Dazu existeren
bequemerweise noch eine paar Funktionen die Typ-Konvertierungen durchführen
und fertig ist der Variant.
Wer halbwegs vernünftig mit VB6 arbeiten will/muss sollte "option explicit"
vrogeben und anschliessend auch explizit die Datentypen wählen die der
Problemstellung angemessen sind.

maximAL

Optimizer schrieb:

Ähm, wie meinst du das genau, dass man ein statisches Typsystem hat, wo aber nicht die Variablen typisiert sind? Kannst du mal ein Beispiel geben?

ahja, wenn du schon fragst:

let make_triple a b c = (a,b,c);;

eine funktion, die aus 3 parametern ein triplet erzeugt. keine typangaben nötig, die funktion ist generisch.
im unterschied zu template-funktionen in C++ muss ich aber nicht den typ des rückgabewerts angeben.
benutzen kann man das ganz einfach so:

make_triple 1 1. 'a';;
- : int * float * char = (1, 1., 'a')

make_triple ("xyz", 10) 'x' (1,(2.,3.));;
- : (string * int) * char * (int * (float * float)) =
(("xyz", 10), 'x', (1, (2., 3.)))

Triple<A, B, C> createTriple<A, B, C>(A a, B b, C c)

Naja super. Möglicherweise übersehe ich was, aber ich finde hier gerade nichts tolles daran. Lässt sich auch ohne Angabe der Typparameter benutzen:

createTriple(2, 5.0f, "hoi!");

O'Rakl schrieb:

Visual Basic 6 z.B. hat von seinen Vorgängern geerbt, daß es eigentlich gar
keine Datentypen gibt (nur den Typ "variant" mit einem dutzend Untertypen),
man kann aber auch explizit Typen zuweisen.
Das ist dann eine schwache Typisierung, denn dieselbe Variable kann ohne
Konversion mal als Typ A, mal als Typ B verwendet werden, andererseits
kann man durch explizite Typzuweisung Variablen statisch typisieren.

Das ist kein besonderes Feature, welches mehr Flexibilität ermöglicht, sondern mehr die Möglichkeit, automatisch Typ-Konvertierungen durchführen zu lassen. Ich denke sogar, dass Variant einfach nur existiert, damit die Sprache noch leichter zu benutzen ist, ohne dass man überhaupt versteht, was Typen sind.

groovemaster schrieb:

Der Punkt ist, dass C++ einem fast alles ermöglicht,...

Das tut Assembler auch.

Nun ist es aber so, daß C++ mangels eingebauter Datenstrukturen und aufgrund des auf C aufgepropften Objekt-Modells viele sehr einfache Dinge (wie L=["a",1.0]) sehr kompliziert macht, auch wenn sie mit hohem Aufwand und unter Verwendung
äußerst raffinierter externer Bibliotheken (STL,boost,...) möglich sind.

egal wie einfach oder kompliziert das am Ende ausfällt.

Hauptsache, C/C++, hm ? So dachte ich auch einige Jahre lang, bis ich
merkte, daß die Evolution der Programmiersprachen in den vergangenen
10 bis 15 Jahren Fortschritte gemacht hat, die das C-Konzept von 1970
ein wenig angestaubt erscheinen lassen, womit ich nicht in Abrede stelle,
daß C für resourcen-kritische und hardware-nahe Aufgaben erste Wahl ist,
das muß ich ja in jedem zweiten Satz erwähnen, um die Gemüter zu besänftigen

Und das soll nicht heissen, dass es sowas in Zukunft nicht auch in C++ geben wird.

Meinst Du wirklich ? Zum Einen erfordert höhere programmtechnische Eleganz
und Kürze eine gewisse Abstraktion in Form eines dynamischen Typkonzepts
und Garbage Collection, zum Andern ist C++ doch schon groß und kompliziert
genug (die komplizierteste Sprache überhaupt, selbst Common LISP mit seinen
900 Funktionen ist leichter).

Vielleicht wäre es im Sinne der Laufzeitoptimierung besser, eine der moderneren Sprachen wie Ruby oder Python
mit einem wahlweise statischen Typkonzept zu erweitern, ähnlich wie es Dylan
wohl schon macht; das würde sicherlich weniger Aufwand erfordern, als C++ nach STL und Templates noch weiter zu verkomplizieren.

maximAL

Optimizer schrieb:

Triple<A, B, C> createTriple<A, B, C>(A a, B b, C c)
Naja super. Möglicherweise übersehe ich was, aber ich finde hier gerade nichts tolles daran. Lässt sich auch ohne Angabe der Typparameter benutzen:
createTriple(2, 5.0f, "hoi!");

äh, wo kommt der triplet-typ jetzt her?

O'Rakl schrieb:

viele sehr einfache Dinge (wie L=["a",1.0]) sehr kompliziert macht

hast du noch andere beispiele oder warum bringst du immer dasselbe?
und wie gesagt in der praxis sind zahlen und strings im selben container selten nötig
entweder du arbeitest mit text zur ausgabe oder sonstwas oder du rechnest aber ned beides vermischt

O'Rakl schrieb:

zum Andern ist C++ doch schon groß und kompliziert
genug (die komplizierteste Sprache überhaupt, selbst Common LISP mit seinen
900 Funktionen ist leichter).

ok nochmal laaangsam
du-musst-nicht-jedes-feature-verwenden-nur-weil-es-vorhanden-ist
du-verwendest-ein-feature-weil-du-es-für-deine-umsetzung-brauchst

und weil du dich schon letztesmal rausgeredet hast beispiele zu geben kannst ja diesmal 5 codebeispiele nennen die c++ so schrecklich kompliziert machen

volkard

O'Rakl schrieb:

Hauptsache, C/C++, hm ? So dachte ich auch einige Jahre lang,

aber du glaubest das aus ganz anderen gründen! zum beispiel, weil C/C++ (lol, du unterscheidest die sprachen ja nichtmal) schnell sind.
klar, wächst man aus solchen edanken heraus. und man beschäftigt sich mit anderen sprachen. und wenn man dann so 20 bis 25 sprechen durch hat und langsam an übersicht gewinnt, kommt man wieder nach c++ zurück.

bis ich merkte, daß die Evolution der Programmiersprachen in den vergangenen 10 bis 15 Jahren Fortschritte gemacht hat, die das C-Konzept von 1970 ein wenig angestaubt erscheinen lassen,

darf ich noch zu fuß zum bäcker gehen, obwohl seit über 100 jahren autos erfunden sind? es kommt doch nicht darauf an, was es gibt, sondern was das beste ist.

womit ich nicht in Abrede stelle, daß C für resourcen-kritische und hardware-nahe Aufgaben erste Wahl ist,

erstens falsch und zweitens irrelevat.

das muß ich ja in jedem zweiten Satz erwähnen, um die Gemüter zu besänftigen

meins nicht. micht nervt das gelaber über c. keiner hier verteidigt doch c außer dir.

Meinst Du wirklich ? Zum Einen erfordert höhere programmtechnische Eleganz und Kürze eine gewisse Abstraktion in Form eines dynamischen Typkonzepts

beiweise?

und Garbage Collection,

ganz falsch. c++ braucht keinen gc. wir haben funktionierende destruktoren. java braucht einen gc. lisp braucht einen gc.

zum Andern ist C++ doch schon groß und kompliziert genug

70 schlüsselwörter

(die komplizierteste Sprache überhaupt, selbst Common LISP mit seinen 900 Funktionen ist leichter).

also wenn du die kompliziertheit an der anzahl der funktionen festmachst, wundert mich nicht, daß du nen klammernwald lieber hast als ein wenig text.

Vielleicht wäre es im Sinne der Laufzeitoptimierung besser, eine der moderneren Sprachen wie Ruby oder Python mit einem wahlweise statischen Typkonzept zu erweitern, ähnlich wie es Dylan wohl schon macht; das würde sicherlich weniger Aufwand erfordern, als C++ nach STL und Templates noch weiter zu verkomplizieren.

aufwand? wer redet davon?

volkard

maximAL schrieb:

äh, wo kommt der triplet-typ jetzt her?

ist allgemeinbildung

template<class A,class B,class C>
struct Triple{
  A a;
  B b;
  C c;
  Triple(A const& _a,B const& _b,C const& _c):
  a(_a),b(_b),c(_c){
  }
};

maximAL

volkard schrieb:

maximAL schrieb:

äh, wo kommt der triplet-typ jetzt her?

ist allgemeinbildung...

ja, schon klar
ändert aber nichts dran, dass C++ die rückgabetypen nicht vollständig selbst ermitteln kann (davon, dass man nichtmal was zurückgeben muss ganz zu schweigen *brrr*)

volkard schrieb:

O'Rakl schrieb:

womit ich nicht in Abrede stelle, daß C für resourcen-kritische und hardware-nahe Aufgaben erste Wahl ist,

erstens falsch und zweitens irrelevat.

Bezüglich "hardwarenah": Irrelevant? Ja. Falsch? Nein, eher unvollständig. C _und_ C++ (O.K. gibt noch andere) sind bestens dafür geeignet. Die Frage ist, ob der/die Schreiber nun die Vorteile von OOP nutzen wollen oder nicht. Viele (die meisten) wollen das halt nicht. Oft scheitert es halt auch daran, dass für die Zielarchitektur keine (guten) C++ Compiler verfügbar sind.

volkard

maximAL schrieb:

ändert aber nichts dran, dass C++ die rückgabetypen nicht vollständig selbst ermitteln kann

kann es nicht? welchen typ wird createTriple(2, 5.0f, "hoi!") wohl haben?
nur unpraktisch ist, daß man typen vor variablen schreiben muß. aber das wird geändert, hoffe ich.

auto t=createTriple(2, 5.0f, "hoi!");

und wenn nicht, geh ich von c++ weg. dann hat's einfach keinen sinn mehr mit diesem standardisierungskomitee.

maximAL

volkard schrieb:

maximAL schrieb:

ändert aber nichts dran, dass C++ die rückgabetypen nicht vollständig selbst ermitteln kann

kann es nicht? welchen typ wird createTriple(2, 5.0f, "hoi!") wohl haben?

trotzdem muss du in der definition angeben, dass es ein triple zurückgibt - und du brauchst erstmal den entsprechenden rückgabetyp. gut, das mag in diesem beispiel nicht so schlimm erscheinen, aber auf ein komplettes programm bezogen macht das imho schon was aus.

volkard schrieb:

und wenn nicht, geh ich von c++ weg. dann hat's einfach keinen sinn mehr mit diesem standardisierungskomitee.

Dann würde ich weggehen, das werden die nie im Leben ändern. Geh zu C#, für C# 3.0 sind implizite Typen geplant.
btw. finde ich nicht, dass Destruktoren GC ersetzen. Destruktoren sind toll für deterministische Destruktion von Objekten, was man in jeder Sprache braucht und in jeder Sprache, die hier angesprochen wurde, auch hat. Deterministische Destruktion mit einer automatischen Speicherverwaltung zu vergleichen ist wie Äpfel mit Birnen zu vergleichen.

Bei komplizierten Zusammenhängen kann man nicht immer leicht den idealen Zeitpunkt bestimmen, wann ein Objekt freizugeben ist. Nimm doch mal nen Graphen mit vielen Knoten der ständig dabei ist, sich irgendwie zu verändern. Wie wir beide wissen, ist Referenzzählung hier nicht zuverlässig.
Was ist jetzt der ideale Zeitpunkt für die Freigabe eines Knotens? Klar geht es. Niemand behauptet, dass automatische Speicherverwaltung notwendig ist. Aber angenehm ist sie, effizient ist sie (meistens) und sie lässt sich nicht durch Destruktoren oder Referenzzählung ersetzen. Die Antwort ist, wenn man einen GC hat: "Ist mir egal, was der ideale Zeitpunkt wäre". Die Antwort ist, wenn man keinen GC hat, kompliziert, weil man den idealen Zeitpunkt schlicht nicht verpassen oder ihm zuvor kommen darf. Ich verstehe nicht, was du immer gegen garbage collection hast. Das ist wirklich ein Feature, was man meistens ohne Bedenken anwenden und einem die Arbeit wirklich erleichtern kann.