C++ Gurus

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.

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.

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?