Eine Sprache = Nur ein mittel zum Zweck



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

    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.

    Das wäre mal was 👍

    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?



  • volkard schrieb:

    Vector<int> v(5); lege ein Array an mit 5 Elementen.

    ich würde sagen, das ist kein array, sondern nur ein vector<int>, der schon mal platz für 5 elemente hat.

    volkard schrieb:

    Vector<int> v{5}; lege ein Array an mit nur einem Element, nämlich 5.

    diese schreibweise kenne ich überhaupt nicht (ist das neu, c++0x?). ein array mit nur einem element '5' würde ich (mit meinem verständnis C-ähnlicher syntaxen) so schreiben: vector<int> v[1] = {5};
    ich nehme an, c++ erlaubt auch noch den : vector<int> v[5]; also ein array, bestehend aus 5 mal vector<int>, oder nicht?

    quadratulending schrieb:

    volkard schrieb:

    #include <iostream>
    #include <ctime>
    
    using namespace std;
    
    class SquareGenerator{
    	private:
    	int value_;
    	int step_;
    	public:
    	SquareGenerator(){
    		value_=1;
    		step_=1;
    	}
    	inline void step(){
    		step_+=2;
    		value_+=step_;
    	}
    	int value(){
    		return value_;
    	}
    };
    
    int main()
    {
    	int sum=0;
    	clock_t start=clock();
    	for(int o=0;o<1000000;++o){
    #if 1
    		for(int i=1;i<10000;++i)
    			sum+=i*i;
    #else
    		for(SquareGenerator s;s.value()<100000000;s.step())
    			sum+=s.value();
    #endif
    	}
    	cout<<clock()-start<<'\n';
    	cout<<sum<<'\n';
        return 0;
    }
    

    Der SquareGenerator ist langsamer, unleserlicher und nicht mal const correct.

    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. dass der asm-output annähernd gleich klein und schnell ist, wie die (völlig ausreichende) primitivlösung, ist nur volkards programmiererischem können und viel glück zu verdanken.

    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.

    sowas wie die variablen in PHP oder 'variant' in VB z.b.? naja, c++0x hat ja das 'auto'-keyword wiederbelebt (type inference), da bestimmt die initialisierung den typ. das geht vielleicht ein wenig in die richtung, nur dass der typ danach unglücklicherweise feststeht:

    auto someStrangeCallableType = boost::bind(&SomeFunction, _2, _1, someObject);
    

    ^^welchen typ hat 'someStrangeCallableType'? c++ programmierer werden auch künftig höchstleistungen beim gehirnjogging vollbringen müssen.
    🙂



  • +fricky schrieb:

    langsamer isser doch nicht

    lass es mal laufen



  • quadratulending schrieb:

    +fricky schrieb:

    langsamer isser doch nicht

    lass es mal laufen

    ah stimmt, die innere schleife des einen asm-codes läuft 10000 mal häufiger durch als die andere.
    🙂



  • +fricky schrieb:

    quadratulending schrieb:

    +fricky schrieb:

    langsamer isser doch nicht

    lass es mal laufen

    ah stimmt, die innere schleife des einen asm-codes läuft 10000 mal häufiger durch als die andere.
    🙂

    Ach? Mache ich wirklich solche Fehler? Ich glaube nicht.



  • Noch viel schlimmere Fehler.

    Und du hast es nicht mal geschafft um 11:22:33 Uhr zu posten.



  • 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.

    Das wäre mal was 👍

    void* zeiger?



  • +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. und außerdem passen sie ja soo wunderar zu den ranges und range based loops, wie sollte ich da den leckerschmecker umgehen können?

    dass der asm-output annähernd gleich klein und schnell ist, wie die (völlig ausreichende) primitivlösung,

    inwiefern die gleichschnelligkeit zutrifft, sollte das programm mir zeigen. das zielprogramm wird nämlich praktisch nichts machen, außer quadratzahlen zu generieren und in einer liste abzuhaken.

    verglichen habe ich nur die methode mit IMUL gegen die Lösung C:

    //Lösung C
    for(int x=1,s=1;x<100000000;s+=2,x+=s)
       sum+=i;
    

    aber, daß die lösung C zu null mehrkosten mit einem generator aufgeschrieben werden kann, war mir so klar, daß ich sie gar nicht erst hingeschrieben habe. das ist typisch für c++, daß solche abstraktion komplett wegoptimiert wird.



  • heißt der neue standard eigentlich noch c++0x oder schon c++1x 😃



  • void* zeiger?

    Oder boost.any, dann hat man das ganze in schön.

    any dont_care_var(3);
    dont_care_var = string("hi"); 
    dont_care_var = vector<int>(3, 2);
    

    oder wie meintest du das?
    Bei der Anwendung muss man dann wieder in den richtigen Typ `casten`, aber es wäre zum Beispiel möglich eine solche Lib zu entwickeln.



  • volkard schrieb:

    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.

    Konstrukte aus fremden Sprachen verwenden - ein sicheres Zeichen, dass C++ bald ausstirbt, weil es allein nicht lebensfähig ist.



  • penis12 schrieb:

    heißt der neue standard eigentlich noch c++0x oder schon c++1x 😃

    c++0a, c++0b, c++0c...



  • könnte mal einer mit einem modernen prozessor das programm mit allen compileroptimierungen messen und mir die beiden zeiten sagen?



  • Intel® Core™2 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.



  • 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.



  • 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.


  • Administrator

    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.


Anmelden zum Antworten