vergesst C++ ...

[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.)))

[Gast]

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.

[O'Rakl]

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?

[->Sovok<-]

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*)

[Gast]

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.

[Gast]

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.

[volkard]

maximAL schrieb:

trotzdem muss du in der definition angeben, dass es ein triple zurückgibt -

ultra-lästig. mit typeof vom gcc kann ich die variablen ja schon machen, aber rückgabetypen in der funktionsdefintion gehen o nicht. ich hoffe auf den nächsten standard.

[groovemaster]

@O'Rakl
Weisst du, du bist ein echter Troll. Immer wieder die selben und sinnlosen Argumente. Wie wäre es, wenn du meine Beiträge mal ganz durchliest, anstatt einzelne Passagen zu zitieren und mir dann die Worte im Mund umzudrehen. Nur mal so als Bsp.

O'Rakl schrieb:

Hauptsache, C/C++, hm ?

Wo hab ich denn sowas gesagt? Du solltest echt Lesen lernen, vielleicht hast du deshalb auch nie C++ begriffen. Lesen heisst nicht nur, aneinander gereihte Buchstaben zu wiederholen, sondern diese auch zu verstehen.

groovemaster schrieb:

Selbst C++ Programmierer in diesem Forum betonen immer wieder, dass man die Sprache nehmen sollte, die für den Zweck angemessen ist. [...] Und wenn Python für ein Projekt die bessere Wahl ist, dann wäre ich dumm, dies nicht zu nehmen.

O'Rakl schrieb:

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.

Gähn... (Anm.: seltsamerweise musste ich tatsächlich gähnen, als ich das gelesen habe - kein Witz)

O'Rakl schrieb:

Meinst Du wirklich ?

Dir fehlt echt das Verständnis Zusammenhänge zu verstehen. Mein Statement bezog sich auf maximAL's tuple Beispiel.

O'Rakl schrieb:

Zum Einen erfordert höhere programmtechnische Eleganz
und Kürze eine gewisse Abstraktion in Form eines dynamischen Typkonzepts
und Garbage Collection

Erstmal nö. Ich wüsste nicht, warum GC zu mehr Eleganz und Abstraktion führen sollte. Beschäftige dich mal mit scope-basiertem Ressourcenmanagement, dann verstehst du vielleicht, warum C++ keinen GC braucht. Was das dynamische Typkonzept betrifft, da hab ich erstmal grundsätzlich nichts dagegen, aber nur, wenn es nicht auf Kosten des statischen Typsystems implementiert ist. Und da hab ich so meine Zweifel, dass beide Typsysteme unter einem Dach zu mehr Eleganz führen.

O'Rakl schrieb:

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

Das kommt natürlich immer auf den Standpunkt an. Für Leute wie dich, die davon überhaupt keine Ahnung haben, mag das so erscheinen. Erfahrene C++ Programmierer werden an der Sprache nicht mehr viel finden, was wirklich kompliziert ist. Da bietet die Verwendung der richtigen Algorithmen und Design Patterns schon deutlich mehr Herausforderung.

@maximAL
Wenn ich dich richtig verstanden habe, willst du sowas hier:

auto add_multiply_divide(int a, int b)
{
    return make_tuple(a+b, a*b, double(a)/double(b));
}
// bzw.
tuple add_multiply_divide(int a, int b)
{
    return make_tuple(a+b, a*b, double(a)/double(b));
}

Sowas geht aber nicht, denn was soll der Compiler denn hier machen?

auto add_multiply_divide(int a, int b);
// bzw.
tuple add_multiply_divide(int a, int b);

Im ersten Fall kann er den Typ überhaupt nicht herleiten, ausser auto beschreibt etwas wie VB's Variant. Und im zweiten Fall weiss er zwar, dass es ein tuple ist. Er weiss aber nicht, wie es aussieht. Ausser es wird dynamisch gehandelt. Beides hat aber mit einem statischen Typsystem nichts zu tun. Und wer jetzt behauptet, dass Funktionsdeklarationen überflüssig sind, bekommt eins auf die Nuss. Gerade für Schnittstellen, zB über dynamische Bibliotheken, ist das äusserst effektiv und universell einsetzbar. Selbst in anderen Sprachen.

->Sovok<- schrieb:

und wie gesagt in der praxis sind zahlen und strings im selben container selten nötig

Das würde ich zwar nicht behaupten, für die Praxis ist das Beispiel trotzdem irrelevant, da man die Elemente des Containers eher dynamisch einliest (zB aus einem Textfile oder einer Datenbank), anstatt diese fest vorzugeben.

[volkard]

groovemaster schrieb:

Sowas geht aber nicht, denn was soll der Compiler denn hier machen?

auto add_multiply_divide(int a, int b);
// bzw.
tuple add_multiply_divide(int a, int b);

error 4711: auto kann nicht in deklarition ohne definition benutzt werden
error 4712: basta.

ich will das aber haben tun.
ich schreib ja jetzt schon lieber

#define AUTO(name,init) typeof(init) name(init)
AUTO(in,openFileForRead("in.txt"));
AUTO(out,openFileForWrite("out.txt"));

als

FileReader in(...);
FileReader out(...);

und weil ich schon lange vergessen haben will, wie die typen wirklich heißen, wenn ich nur die erzeugende funktion kenne, muß es dann auch weitergehen mit

auto openFileForReadByNumber(int nr){
   strstream name;
   name<<nr<<".txt";
   return openFileForRead(name.c_str());
}

daß der compiler dann auch noch dafür sorgen sollte, daß das ding nicht zwingend static linkage haben muß, gehört halt auch noch dazu. mit export?

[maximAL]

groovemaster schrieb:

Im ersten Fall kann er den Typ überhaupt nicht herleiten, ausser auto beschreibt etwas wie VB's Variant. Und im zweiten Fall weiss er zwar, dass es ein tuple ist. Er weiss aber nicht, wie es aussieht.

also ehrlichgesagt versteh ich das problem jetzt nicht so ganz.
nochmal ganz kurz, wie das typsystem in meinem beispiel funzt: die funktion ist generisch und erst mit dem aufruf der parameter wird der rückgabetyp bestimmt. desweiteren muss man den rückgabetyp nirgends explizit hinschreiben (auch keinen "platzhalter"), sondern es wird überprüft, welchen typ die funktion tatsächlich zurückgibt. dürfte in C++ schwierig sein, denn da muss man im prinzip gar nichts zurückgeben - selbst wenn ein rückgabewert definiert ist
quasi: würde in meiner C++ funktion return MeinInteger; stehen, dann wüsste der compiler, was ich will.

ps: das soll übrigens kein aufruf sein, diese funktionalität irgendwie nachzubauen oder den standard dementsprechend zu erweitern. ich sage nur, dass es leider so nicht geht, aber imho in eine wirklich moderne hochsprache gehört.

[volkard]

maximAL schrieb:

dürfte in C++ schwierig sein, denn da muss man im prinzip gar nichts zurückgeben - selbst wenn ein rückgabewert definiert ist

da wirft schon wieder einer halbwissend der armen sprache c++ was vor, was in c so ist. also mein compiler erlaubt ir nicht int f(){};.

[maximAL]

volkard schrieb:

maximAL schrieb:

dürfte in C++ schwierig sein, denn da muss man im prinzip gar nichts zurückgeben - selbst wenn ein rückgabewert definiert ist

da wirft schon wieder einer halbwissend der armen sprache c++ was vor, was in c so ist. also mein compiler erlaubt ir nicht int f(){};.

also mein minGW frisst das ohne weiteres. ok, mit -Wall gibts zumindest ne warnung...

[GPC]

maximAL schrieb:

also mein minGW frisst das ohne weiteres. ok, mit -Wall gibts zumindest ne warnung...

Mein gcc gibt nen Error raus.

[Gast]

Werfen wir einfach einen genaueren Blick darauf.

// nicht erlaubt
int foo() {
}

// erlaubt
int foo(bool something) {
	if( something )
		return 5;
}

affig