Eine Sprache = Nur ein mittel zum Zweck

volkard

Rock'n'RollSexgott schrieb:

i*i: 7656
SquareGenerator: 8500

Vielen Dank.

(Damit gibt es überhaupt keinen Grund mehr, sich vor int32-Multiplikationen zu drücken. Das wollte ich wissen.)

audacia schrieb:

Duck-Typing ist ja in gewissem Maße mit Templates möglich. In deinem Beispiel reicht das schon: [...]

schöner wäre es, wenn man so etwas in C++ ohne Templates und ohne void* formulieren könnte. Man könnte dann einen Prototyp mit "late binding" herstellen, ohne auf eine dynamisch typisierte Sprache ausweichen zu müssen, und um aus dem Prototpyen das Endprodukt zu entwickeln, bräuchte man lediglich an einigen (oder allen) Stellen die Typisierung hinzufügen.

Dravere

u_ser-l schrieb:

schöner wäre es, wenn man so etwas in C++ ohne Templates und ohne void* formulieren könnte. Man könnte dann einen Prototyp mit "late binding" herstellen, ohne auf eine dynamisch typisierte Sprache ausweichen zu müssen, und um aus dem Prototpyen das Endprodukt zu entwickeln, bräuchte man lediglich an einigen (oder allen) Stellen die Typisierung hinzufügen.

Mich würde interessieren, wie du dir das ohne VM/JIT oder sonstiges vorstellst. Wie soll sowas in Maschinencode übersetzt werden?
Interessant wäre es ganz sicher, nur wie man das umsetzen sollte, da sehe ich ziemlich grosse Probleme.

Grüssli

es müßte für diejenigen Variablen (+ Funktionsargumente, Rückgabewerte usw.), deren Typ zur compilezeit nicht festgelegt ist, eine Prüfung zur Laufzeit stattfinden. So, wie das in den dynamisch typisierten Sprachen in der einen oder anderen Form auch gemacht wird. Variablen ohne feste Typzuweisung wären dann lediglich Zeiger, an die man zur Laufzeit Werte jeden beliebigen Typs (oder Objekte beliebiger Klassen) hängen kann. Ein paralleles "dynamisch typisiertes Subsystem" in einer ansonsten statisch typisierten Sprache, sozusagen.

audacia

Dravere schrieb:

Mich würde interessieren, wie du dir das ohne VM/JIT oder sonstiges vorstellst. Wie soll sowas in Maschinencode übersetzt werden?

Man benötigt dafür Reflection, nicht aber VM oder JIT. Delphi kann das z.B., allerdings nur für Objekte, die IDispatch implementieren.

Allerdings sehe ich außerhalb der üblichen Einsatzgebiete, wie der Interaktion mit Skriptsprachen oder COM, wenig Nutzen in einem sprachintegrierten Late-Binding-Mechanismus. Mir leuchtet immer noch nicht ein, wieso Templates für die Vorhaben von u_ser-l nicht ausreichen. (Anders gesagt: ich glaube kaum, daß die Überführung eines Prototyps aus "dynamischem C++" in "statisches C++" nur das "lediglich an einigen (oder allen) Stellen die Typisierung hinzufügen" erforderte.)

weil templates für meinen Geschmack zu kompliziert sind. Mir schwebt eher so etwas vor wie

'a = 3.1516;
'b = "wasauchimmer";
'foo('x, 'y){ cout << 'x << endl << 'y; return 28; }...
...
'r = 'foo('a, 'b);
's = 'r + 'a;

volkard schrieb:

+fricky schrieb:
langsamer isser doch nicht (hast wohl den asm-code nicht gesehen), aber er ist ein typisches beispiel für 'over engineering'. mit einem mal spielt sowas wie 'const-correctness' eine rolle (sinnlose komplexität) und aus dem leicht verständlichen zweizeiler:
for(int i=1;...) 
  sum = sum + i*i;
ca. 20 zeilen zu machen, finde ich ziemlich übertrieben.
Nö, aus
for(int i=1;...) 
  sum = sum + i*i;
wurde
for(SquareGenerator s;s.value()<100000000;s.step())
  sum+=i;
solche generatoren benutze ich in C++ seit 15 jahren und sie machen den hauptcode code lesbarer und gelegentlich sogar erst realistisch lösbar. wenn die in haskell das dürfen, will ich das auch.

klar, ein oo basierter ansatz hat vorteile, leichte austauschbarkeit, gemeinsames interface für verschiedene generatoren und so. aber in einem miniprogramm, in dem diese vorteile nicht zum tragen kommen, ist ein einfaches i*i doch günstiger. OOP ist doch nicht dazu da, simple dinge zu verstecken.

volkard

+fricky schrieb:

klar, ein oo basierter ansatz hat vorteile, leichte austauschbarkeit, gemeinsames interface für verschiedene generatoren und so. aber in einem miniprogramm, in dem diese vorteile nicht zum tragen kommen, ist ein einfaches i*i doch günstiger. OOP ist doch nicht dazu da, simple dinge zu verstecken.

klar, aber das da oben mit sum+= war nur ein testmessprogramm. würde ich wirklich nur die summe von quadratzahlen suchen, würde ich sum+=i*i nehmen, (wenn nicht wie jetzt der bronstein links neben mir stände).

volkard schrieb:

klar, aber das da oben mit sum+= war nur ein testmessprogramm. würde ich wirklich nur die summe von quadratzahlen suchen, würde ich sum+=i*i nehmen, (wenn nicht wie jetzt der bronstein links neben mir stände).

aber dann würdeste diese quadratsummenformel, die ja nicht sonderlich kompliziert ist, als eine codezeile hinschreiben und hättest keinen extra 'SquareSumGenerator' dafür, ne?

volkard

+fricky schrieb:

volkard schrieb:

klar, aber das da oben mit sum+= war nur ein testmessprogramm. würde ich wirklich nur die summe von quadratzahlen suchen, würde ich sum+=i*i nehmen, (wenn nicht wie jetzt der bronstein links neben mir stände).

aber dann würdeste diese quadratsummenformel, die ja nicht sonderlich kompliziert ist, als eine codezeile hinschreiben und hättest keinen extra 'SquareSumGenerator' dafür, ne?

int calcSum(int n){ //http://pirate.shu.edu/~wachsmut/ira/infinity/answers/sm_sq_cb.html
 return n*(n+1)*(2*n+1)/6;
}

Der Generator ist doch ne Range und produziert tausende von Dingen, nicht nur eine Zahl. Ganz andere Aufgaben.

+fricky schrieb:

OOP ist doch nicht dazu da, simple dinge zu verstecken.

Doch, natürlich.
Aus genau dem Argument, wie ich im Hauptprogramm calcSum(*i) statt *i*(*i+1)*(2**i+1)/6 schreiben will. Sie dient dazu, daß die Hauptfunktionen einfacher werden. Und genauso, wie es triviale einzeilige Funktionen gibt, gibt es triviale Klassen mit einem Attribut und sowas.