Eine Sprache = Nur ein mittel zum Zweck

Intel Core2 Duo 2.66 GHz
VS 2008 Express
Compiler optionen: /O2 /Ob2 /Oi /Ot /GT /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc /MD /Gy /Fo"Release\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt

i*i: 7656
SquareGenerator: 8500

zeig0r schrieb:

void* zeiger?

ja, aber das hat den Nachteil, daß man bei jeder Deklaration störenderweise diesen Typ angeben müßte, außerdem müßte man alle library-Funktionen wrappen. Ich will ein Syntaxelement in C++, das dem Compiler anzeigt, daß die Typangabe weggelassen werden kann, z.B. indem man den dafür in Frage kommenden Bezeichnern (Rückgabetypen von Funktionen, formale Parameter, Variablen), die als "late binding" behandelt werden sollen, bei der Deklaration ein unauffälliges Zeichen wie ' oder . voranstellt:

's = "hallo";
foo('t){ cout << 't << endl; }

Das wäre der Knüller.

audacia

u_ser-l schrieb:

... und weitere Mehrfachbelegungen syntaktischer Elemente: extern, auto, [], und wieviele unterschiedliche Bedeutungen ":" haben wird, wer will es zählen?

+1. Finde ich auch ganz furchtbar. auto ist vertretbar, das gebraucht ja wirklich niemand in der Originalbedeutung - aber müssen class (-> enum class), default und delete (-> für Standardkonstruktoren und ihresgleichen) und sizeof (Anzahl der Argumente bei Variadic Templates ) wirklich noch weiter mißbraucht werden?

u_ser-l schrieb:

Was ich nach wie vor sehr in C++ vermisse, ist eine einfache Möglichkeit, das Typsystem zu umgehen, etwa, indem fehlende Typangaben in Variablen- und Funktionsdeklarationen implizit als ein besonderer Typ "dontcare" angenommen werden, der die Typprüfung des Compilers für diese Variable, Funktion o.ä. aufhebt, sodaß bei Bedarf für rapid prototyping ein "late bindung" Stil programmiert werden kann.

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

template <typename T>
    void foo (T v)
{ cout << v << endl; }
int main (void)
{
    auto s = "hallo";
    foo (s);
}

Oder wäre das, was du willst, eher wie der Variant-Typ in Delphi oder VB oder das dynamic-Keyword in C# 4?

u_ser-l schrieb:

Was gibt es denn in C++0x Neues, das nicht in der einen oder anderen Form in der einen oder anderen Programmiersprache schon lange realisiert wäre?

Da fallen mir auf Anhieb nur Concepts ein. Ähnliche Konzepte (NPI) gibt es zwar z.B. in Haskell (Typklassen), aber in keiner mir bekannten Mainstream-Sprache.
Allerdings teile ich in bezug auf dieses Feature die skeptischen Ansichten, die Daveed Vandevoorde hier mal auf den Punkt brachte. Besonders fragwürdig finde ich es, ein derart umfangreiches Feature aufzunehmen, dessen effiziente Implementierbarkeit noch nicht belegt wurde.

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.