C++ Gurus

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

[User--]

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.

[gute frage]

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.

[Unix-Tom]

Wie schon gesagt:
Es geht nicht um falsch.

Außer bei z.B. for (int i = 0 habe ich noch nie Variablennamen,etc. genommen wie Z,X, oder was auch immer. Mir ging es um die Namen. Warum muss man hier einzelne Buchstaben verwenden.
Da könnte ich ja auch gleich jede Methode von A - Z benennen.
Dadurch ist es auf den ersten Blick sehr kryptisch und ein einziger Buchstabensalat.

[Jester]

Dann mußte aber auch konsequent weiter schauen und sehen, daß es vielleicht ne Konvention ist. Und gerade bei ner STL-Implementierung scheint das so auch recht sinnvoll zu sein.

Also ist es ein Beispiel wie man es richtig macht und nicht das Gegenteil wie Du behauptet hattest, oder?

[Shade Of Mine]

Jester schrieb:

Dann mußte aber auch konsequent weiter schauen und sehen, daß es vielleicht ne Konvention ist. Und gerade bei ner STL-Implementierung scheint das so auch recht sinnvoll zu sein.

Begründung?

T für Type ist das höchste aller Gefühle, ein Type tut da aber auch nicht weh.

Bei einem
K<V, T<X> >
wird es dann aber wirklich doof...

Den Code mit dem op+ habe ich jetzt nicht gefunden, aber ein andere Code hier im Thread:

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 );}

autsch. Sieht aus wie aus einer STL Implementierung geklaut. Und die sind idR einfach nur mist.

Meine Idee:

template<typename Result, class Class>
class mem_fun_adapter : public unary_function<Class*, Result>
{
public:
  typedef Result (Class::*Method)();

private:
  Method method;

public:
  explicit mem_fun_adapter(Method method)
  : method(method)
  {}    

  Result operator()(Class* object)
  {
    return object->*method();
  }
}

template<typename Result, class Class>
mem_fun_adapter<Result, Class> mem_fun(Result (Class::*method)())
{
  return mem_fun_adapter<Result, Class>(method);
}

Jetzt haben wir 2 häßliche stellen:
object->*method()
und
Result (Class::*method)()
aber da ist die Syntax einfach so, das geht kaum schöner.

[besser]

template<typename ResultType, class ClassType>

[Daniel E.]

Jester schrieb:

Ich finde den Code jetzt auch nicht sonderlich kryptisch. Man muß sich in die Sache halt mal ne Zeit reinlesen.

Ich kenne eigentlich keine Sprache, die so viele Schüsselwörter und syntaktischen Overhead braucht, um so wenig Abstraktionsmechanismen bereitzustellen wie C++. Du?

[Shade Of Mine]

besser schrieb:

template<typename ResultType, class ClassType>

Bei mir ist immer alles was einen Großbuchstaben am Anfang hat ein Typ. Aber ein ResultType würde natürlich kein bisschen schaden. Lieber mehr schreiben als zu wenig.

[finix]

Shade Of Mine schrieb:

besser schrieb:

template<typename ResultType, class ClassType>

Bei mir ist immer alles was einen Großbuchstaben am Anfang hat ein Typ. Aber ein ResultType würde natürlich kein bisschen schaden. Lieber mehr schreiben als zu wenig.

Wie wär's mit ResultT & ClassT? Zu viel schreiben (-> Detailgrad vs Übersichtlichkeit) ist ähnlich grässlich wie zu wenig...

[frage?]

oder sollte Class besser ObjectType bzw. ObjectT heissen?

[volkard]

Shade Of Mine schrieb:

Aber ein ResultType würde natürlich kein bisschen schaden.

doch.
rutsch bitte nicht ins suboptimale ab.

[reiner2]

volkard das ist reine geschmackssache.