C++ Gurus

interpreter

Reyx schrieb:

Was ich nur nicht verstehe ist, warum so viele Leute behaupten, die Syntax von C++ währe schwierig, kryptisch, unübersichtlich... usw.

Ich persönliche finde die Syntax genau richtig: logisch, eigentlich überhaupt nicht kryptisch, intuitiv und vor allen Dingen: übersichtlich. Wenn ich mir dagegen mal einen vierhundert Zeilen langen DelphiLanguage- oder ObjectPascal-Quellcode ansehe, dann wird mir einfach nur schlecht!

Muss eine Sprache wirklich vollgesprickt mit "PROCEDURE"s, "BEGIN"s und "END"s sein, damit die Leute ihre Syntax als gut preisen?

Absolut. C++ Code ist in der Tat sehr übersichtlich, wie auch in diesem Beispiel:

template< class R, class T >
class mem_fun_t : public unary_function<T*, R>{    
R( T::*pmf)();  
public:    explicit mem_fun_t( R( T::*f )() ) : pmf(f) {}    
R operator()( T* t ){ return t->*pmf(); }}

template< class R, class T >mem_fun_t< R, T > mem_fun( R( T::*pmf )() ){    return mem_fun_t< R, T >( pmf );}

So muss Sourcecode im Jahr 2005 aussehen

Helium

Muss eine Sprache wirklich vollgesprickt mit "PROCEDURE"s, "BEGIN"s und "END"s sein, damit die Leute ihre Syntax als gut preisen?

Naja, also die meisten Denken da weniger an Pascal, sondern eher an Python oder sowas.

interpreter schrieb:

C++ Code ist in der Tat sehr übersichtlich, wie auch in diesem Beispiel:

template< class R, class T >
class mem_fun_t : public unary_function<T*, R>{    
R( T::*pmf)();  
public:    explicit mem_fun_t( R( T::*f )() ) : pmf(f) {}    
R operator()( T* t ){ return t->*pmf(); }}

template< class R, class T >mem_fun_t< R, T > mem_fun( R( T::*pmf )() ){    return mem_fun_t< R, T >( pmf );}

Er könnte auch so aussehen

template< class R, class T >
class mem_fun_t : public unary_function<T*, R>
{    
      R( T::*pmf)();  

 public:    

      explicit mem_fun_t( R( T::*f )() ) : pmf(f) {}    
      R operator()( T* t )
      { 
           return t->*pmf(); 
      }
};

template< class R, class T > mem_fun_t< R, T > mem_fun( R( T::*pmf )() )
{    
      return mem_fun_t< R, T >( pmf );
}

net 0

Freak_Coder schrieb:

Er könnte auch so aussehen

...aber nicht viel besser

interpreter

Da kannste so viel formatieren wie du willst - es wird immer ein unleserlicher Salat bleiben.

interpreter schrieb:

Da kannste so viel formatieren wie du willst - es wird immer ein unleserlicher Salat bleiben.

ausser wenn man ahnung hat

Reyx

In der Hinsicht sei allerdings bemerkt, dass es auch am Programmierstiel liegt: Dein Code ist in der Tat ein auf den ersten Blick unleserlicher Salat, aber mit richtigen Konventionen (Kommentaren, Strukturen, Einrückungen etc.) kann man da einiges retten.

Es kommt halt darauf an, wie man die Sprache einsetzt, aber gerade da finde ich, kann man mit C++ übersichtlicher proggen als in vielen anderen Sprachen!

Ist und bleibt aber wohl Geschmackssache...

volkard

wir sehen also, daß die syntax von c++ eine katastrophe ist.

aber naja, es ist nur die syntax. im vergleich zum rest des programmierens ganz einfach. vom gesamtkonzept her ist c++ klar und geradlinig und genau richtig und es ist in c++ am allerleichtesten, komplexere gedanken in code zu gießen.
(wenn man mal davon absieht, daß es kein yield gibt, keine gescheite compilezeitprogrammierung, man in destruktoren (da, wo die datenbank geschrieben wird) keine exceptions werfen darf, exception-spezifikationen nix bringen, man im standard keine sockets, farben, threads kennt...)

interpreter

c++ guru 2 schrieb:

interpreter schrieb:

Da kannste so viel formatieren wie du willst - es wird immer ein unleserlicher Salat bleiben.

ausser wenn man ahnung hat

Naja, das so ein Einwand kommt war klar. Es ist völlig unerheblich wie viel Ahnung man hat. Der Code ist und bleibt kryptisch und unübersichtlich. In Python schreibe ich den selben Code in ein paar Zeilen, den nahezu jeder Standardprogrammierer sofort versteht.
Ich will C++ nicht generell schlecht reden. Dennoch bin ich der Meinung, dass es in einigen Bereichen ein veralteter Dinosaurier ist und es mittlerweile für viele Einsatzbereiche von C++ gute Alternativen gibt.
Aber kann natürlich sein, dass du unleserliches Pointer-Template-Gehaxx0re brauchst, um dich elitär zu fühlen

Zarniwoop

Mit etwas aussagekräftigeren Namen könnet man auch diesen Codeschnipsel einigermaßen lesbar machen. Natürlich ist es möglich, hässlichen und unverständlichen Code zu schreiben, aber da ist dann der Programmierer schuld.

Zarniwoop

Gunnar

Muss eine Sprache wirklich vollgesprickt mit "PROCEDURE"s, "BEGIN"s und "END"s sein, damit die Leute ihre Syntax als gut preisen?

Die Lisp-Leute behaupten dasselbe ueber C++. Die halten viele andere Sprachen fuer ungeschickt, wegen vollkommen willkuerlicher Syntax (Schluesselwort hier, Semikolon da aber nicht dort, ...). Zum einen haben sie irgendwie recht, aber zum anderen arbeitet ein Mensch nun mal anders als ein Computer. Ich halte so was wie C++, Java, ML fuer genau richtig.

Daniel E.

Gunnar schrieb:

Muss eine Sprache wirklich vollgesprickt mit "PROCEDURE"s, "BEGIN"s und "END"s sein, damit die Leute ihre Syntax als gut preisen?

Die Lisp-Leute behaupten dasselbe ueber C++. Die halten viele andere Sprachen fuer ungeschickt, wegen vollkommen willkuerlicher Syntax (Schluesselwort hier, Semikolon da aber nicht dort, ...). Zum einen haben sie irgendwie recht, aber zum anderen arbeitet ein Mensch nun mal anders als ein Computer.

Äh, Du erklärst ja selbst, daß die Lisp-Leute das anders sehen und ich behaupte, daß die Lisp-Leute keine Computer sind. Der Mensch liest Quelltext so, wie er gelernt hat, ihn zu lesen. Das braucht man für Lisp genau so, wie für C++.

Gunnar

Daniel E. schrieb:

Äh, Du erklärst ja selbst, daß die Lisp-Leute das anders sehen und ich behaupte, daß die Lisp-Leute keine Computer sind. Der Mensch liest Quelltext so, wie er gelernt hat, ihn zu lesen. Das braucht man für Lisp genau so, wie für C++.

Ja, hast recht. Unterbewusst habe ich halt... naja. Danke fuer den Selbsterkenntnisgewinn.

Unix-Tom

Der Code ist schön. Er zeigt genau wie man es nicht machen sollte. So ein Code sagt nicht aus das der Programmierer ein "Guru" ist. Im Gegenteil.

Die Syntax des c++ snippets wirkt auf den ersten Blick sicherlich furchtbar, aber die meisten von euch haben keine Probleme beim Verständnis dieser Funktion.
Sowas findet sich (einheitlich formatiert) doch in jeder größeren Bibliothek und als c++ Programmierer muss man damit wohl leben und ich persönlich kann es inzwischen ganz gut, vor allem weil ich keine Sprache kenne die ich lieber mag als c++.

Jester

Unix-Tom schrieb:

Der Code ist schön. Er zeigt genau wie man es nicht machen sollte. So ein Code sagt nicht aus das der Programmierer ein "Guru" ist. Im Gegenteil.

Was genau ist an dem Code so schlecht? (Ich beziehe mich auf die 2. Formatierungsart).

Bedenken wir mal, das ist ein Stück Code aus ner STL-Implementierung. Nehmen wir mal an die Konvention besagt: R ist der Typ für den Rückgabewert, pmf steht für pointer to member-function.
Das dürfte bei ner STL-Implementierung nicht unüblich sein.

Dann steht das doch relativ ordentlich da. Okay, ein typedef für R (T::*)() wäre nett gewesen.

Die Funktion hintendran ist doch der übliche Standardtrick um template argument deduction auch bei Klassen nutzen zu können.

Bin gespannt wo genau in Deiner/Eurer Sicht die ganzen Fehler liegen.

Daniel E.

Jester schrieb:

Bin gespannt wo genau in Deiner/Eurer Sicht die ganzen Fehler liegen.

Es geht nicht um falsch, es geht um Augenkrebs, genau wie bei

template<typename T> const static inline K<T>::operator+(const K<T> &r) { }

oder der Unterscheidung von 'T operator++(int)' und 'T operator++()'. Wem's gefällt, für den ist es bestimmt das Höchste und Masochismus ist ja nicht verboten.

die frage ist nur: hätte man es (viel) besser machen können?

mantiz

Es ist ja ganz einfach so:
Du kannst entweder Templates benutzen und Dir so das Leben um vieles einfacher machen, musst Dich halt nur einmal reinarbeiten, oder weiterhin für jeden Typ eine eigene Funktion/Methode schreiben.

Stichwort:

template<typename T> T square(T value) {
    return value * value;
}

// oder:
int square(int value) {
    return value * value;
}
double square(double value) {
    return value * value;
}
int square(double value) {
    return (int)(value * value);
}

OK, hier kann man mit Typumwandlung auch nur mit doubles arbeiten, und die ints implizit umwandeln lassen, aber warum sollte man zig Funktionen haben, um die man sich kümmern muss, wenn mal Änderungen anfallen? Das war ja jetzt nur ein Beispiel.

Jester

Daniel E. schrieb:

Es geht nicht um falsch, es geht um Augenkrebs, genau wie bei

Unix-Tom sagte aber das sei ein sehr schönes Beispiel wie man es *nicht* machen soll. Ich wollte jetzt wissen wie man es denn dann bitte machen soll.

Ich finde den Code jetzt auch nicht sonderlich kryptisch. Man muß sich in die Sache halt mal ne Zeit reinlesen. Das muß man aber bei z.B. LISP oder auch anderen Sprachen genauso.