vergesst C++ ...

[Power Off]

volkard schrieb:

Power Off schrieb:

Ich glaube nicht, daß das Schlüsselwort in der Zukunft zweckentfremdet wird!

lies mal schnell http://www.research.att.com/~bs/C++0x_keynote.pdf

Hmmm ... erstmal danke für den Link!

Also hier der Quote für die anderen:

Example: typeof/auto
• Solve half the problem
– (first implemented in 1982!)
template<class A, class B> typeof(a*b) operator*(A a, B b)
{
   auto x = a*b; // avoid replication of expression/type
   // …
   return x;
}
• What about non-local uses?:
auto glob = x*y; // would dcl or typeof be a better keyword for this?

Der Artikel stammt offensichtlich aus der Zeit vor 2003:

Bjarne Stroustrup schrieb:

The ISO C++ standard comes up for renewal in 2003. By then,

Da der 2003er Standard längst draußen ist, ist auch der Vorschlag bereits abgelehnt worden.

Ich hab Bjarne mal angeschrieben wegen des fehlenden valof-Operators in C++, und er meinte, die Sprache sei schon dermaßen festgelegt, daß man kaum noch was ändern könne. Er sagte auch, daß er auf das Kommittee keinen Einfluß habe.

Schick ihm doch mal 'ne Mail und sag ihm, er soll doch mehr Druck machen, wirst sehen, was er zurück schreibt.

Jedenfalls, sein Vorschlag ist anders als Deiner: Bei seiner Variante ist die Bekanntheit der Typen zur Compile-Zeit erhalten.

Es könnte ein ähnliches Problem verursachen wie bei den Templates: einige Compiler werden bei "extern auto " einen Fehler bringen, andere werden's ausführen.

volkard schrieb:

man müßte zu dem an sich einfachen code, der den op* implementiert auch noch in metaprogrammierung das returntypbestimmen programmieren. wir hassen alle diese programme, die 5 nutzzeilen haben aber 250 metaprogrammierungszeilen.

Eigentlich steht doch dem gar nichts im Wege: Deklarier den Rückgabewert einfach als Referenz-Parameter (mit Template-parametrisiertem Typ). Problem gelöst!

volkard schrieb:

das problem haben wir auch bei templates. löst man das problem der templates mit export, löst man auch auto, oder?

Nein. Die meisten C++ Compiler verwenden Name-Mangling, um Namen zu exportieren. Bei Template-Klassen geht das noch, da ja die Typen einer Template-Instanz (und nur einer Instanz, nicht der Deklaration!) zur Compile-Zeit bekannt sind. Einen anonymen Rückgabewert kann man nur dann erkennen, wenn die in Frage kommenden Typen zur Compile-Zeit bekannt waren.

volkard schrieb:

doch. das muss gemacht werden. ist ja auch nicht da höllen-problem, wenn man aufgibt, daß der objekt-code mit alten und uralten versionen gelinkt werden kann. oder einfach für so funktionen ne unique signature machen und der linker nimmt nur die erste, die er sieht.

Stell Dir vor: Du würdest den gesamten Compile-Link-Prozess über den Haufen werfen müssen. Wenn Du bisher Makefiles gehabt hast, kommt ein zusätzlicher Intermediate-Code-Linker-Aufruf dazu und neue Intermediate-Objektdateien.

Das wäre eine zu große Umstellung für die Software-Industrie.

Außer, man stellt sicher, daß alte Projekte sich nach dem alten Modell compilieren lassen und stellt dem Entwickler die Verwendung des Intermediate-Code-Linkers frei, für den Fall, daß er Template-Instanzen oder variante Rückgabetypen vorher auflösen möchte (im Extremfall kommt dann bei der Nicht-Verwendung des ICL ein Linker-Fehler).

[volkard]

Power Off schrieb:

Da der 2003er Standard längst draußen ist, ist auch der Vorschlag bereits abgelehnt worden.

der gedanke schwebt noch rum. hab keine links, über was aktuell beraten wird.

Er sagte auch, daß er auf das Kommittee keinen Einfluß habe.

jo.

Schick ihm doch mal 'ne Mail und sag ihm, er soll doch mehr Druck machen, wirst sehen, was er zurück schreibt.

ich traue mich nicht, ich bin so ein kleines licht.

Jedenfalls, sein Vorschlag ist anders als Deiner: Bei seiner Variante ist die Bekanntheit der Typen zur Compile-Zeit erhalten.

BEI MIR AUCH! aber klaro. alles ander würde das wesen von c++ killen. laufzeit-typ-bestimmung mach interpretersprache. mit undendlich vielen vorteilen, aber mit abstraction overhead.

Es könnte ein ähnliches Problem verursachen wie bei den Templates: einige Compiler werden bei "extern auto " einen Fehler bringen, andere werden's ausführen.

man darf nicht warten, bis auch der hinterindische sogenannte c++-compiler für die kernels der miele-spülmaschinen es auch haben, sondern man muß was sinnvolles und in kurzer zeit erreichbares definieren (am besten was, was schon welche gebaut haben, wie typeof!) und verlangen.

volkard schrieb:

man müßte zu dem an sich einfachen code, der den op* implementiert auch noch in metaprogrammierung das returntypbestimmen programmieren. wir hassen alle diese programme, die 5 nutzzeilen haben aber 250 metaprogrammierungszeilen.

Eigentlich steht doch dem gar nichts im Wege: Deklarier den Rückgabewert einfach als Referenz-Parameter (mit Template-parametrisiertem Typ). Problem gelöst!

nee. muß ja speicher anlegen, was referenz verbietet. aber auch sonst kenne ich den rückgabetyp nicht. es ist nicht A oder B.

Nein. Die meisten C++ Compiler verwenden Name-Mangling, um Namen zu exportieren. Bei Template-Klassen geht das noch, da ja die Typen einer Template-Instanz (und nur einer Instanz, nicht der Deklaration!) zur Compile-Zeit bekannt sind. Einen anonymen Rückgabewert kann man nur dann erkennen, wenn die in Frage kommenden Typen zur Compile-Zeit bekannt waren.

was hindert einen daran, ins name-mangeling bei auto-return-funktionen den md5 des whtespacebereinigten codes in den namen reinzumachen? nur so als dummer gedanke, mit ein paar tagen überlegen kriegt man bestimmt auch nen guten plan hin, den man in wenigen monaten zufriedenstellend (echt zufriedenstellend meine ich damit) implementierren kann.

Stell Dir vor: Du würdest den gesamten Compile-Link-Prozess über den Haufen werfen müssen. Wenn Du bisher Makefiles gehabt hast, kommt ein zusätzlicher Intermediate-Code-Linker-Aufruf dazu und neue Intermediate-Objektdateien.

siehe gcc repro http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Template-Instantiation.html#Template-Instantiation
es ist nicht notwendig, jeden zu zwingen, für doppel-definitionen nur eine echte instanz zu kreieren. der gcc sorgt wenn befohlen mit zusätzlichen repo-dateien für uniqueness. muss er aber nicht. doppel macht nur den code größer aber das prog läuft auch so. und so können wir auch fein auto machen. alle compilerbauer, die es nicht sofort perfekt hinkriegen, machen mehrfachen code. und wir geben ihnen 10 jahre, es fertigzubringen, daß sie den code auch zusammenfassen. und wir kündigen das jetzt an. wir sagen "static-variablen in funktionen, die auto zurückgeben können aber müssen nicht mehrfach sein" und "funnktionszeiger von fun... sein" und "in 10 jahren dürfen sie nicht mehr merhfach sein". wo ist das problem?

[Power Off]

volkard schrieb:

ich traue mich nicht, ich bin so ein kleines licht.

Na, da unterschätz Dich mal nicht so!

volkard schrieb:

Power Off schrieb:

Eigentlich steht doch dem gar nichts im Wege: Deklarier den Rückgabewert einfach als Referenz-Parameter (mit Template-parametrisiertem Typ). Problem gelöst!

nee. muß ja speicher anlegen, was referenz verbietet. aber auch sonst kenne ich den rückgabetyp nicht. es ist nicht A oder B.

Na ja, aber was spricht dagegen:

template <class A, class B, class C>
void func( A a, B b, C& c ) { c = a * b; }

und dann:

char a = 2;
short b = 7;
int c;
func( a, b, c );

bzw.

func<char,short,int>( a, b, c );

Ist mir klar, daß je abstrakter die Template-Klassen werden, um so unwahrscheinlicher ist es, daß man den Typ einiger Ausdrücke noch vorausahnen kann.

Leider hab ich so eine Konstruktion wie Du noch nie gebraucht.

Kannst Du mal ein Beispiel nennen, wo man sowas wirklich braucht? Also, in welchen Fällen ist es wirklich unmöglich, den Typ zu wissen? Ich meine, wenn ein Compiler den Rückgabetyp erraten kann, kann das ein Programmierer doch auch, oder?

(Aber ich kapier auch die BOOST Library nicht, ist mir zu unlesbar, aber ist wohl Geschmackssache; ich gehör nicht zu denen, die ständig neue Sprachfeatures lernen, wenn ich sie nicht brauche -- leider; hab lang gebraucht, bis ich mir mal die STL so richtig reingezogen habe)

volkard schrieb:

was hindert einen daran, ins name-mangeling bei auto-return-funktionen den md5 des whtespacebereinigten codes in den namen reinzumachen? nur so als dummer gedanke, mit ein paar tagen überlegen kriegt man bestimmt auch nen guten plan hin, den man in wenigen monaten zufriedenstellend (echt zufriedenstellend meine ich damit) implementierren kann.

So dumm ist der Gedanke eigentlich gar nicht. Man könnte eine Art Code-Signatur verwenden, die dann irgendwo im Objektmodul ausspezifiziert wird (z.B. als platter Syntaxbaum oder sowas).

Jedenfalls MD5 allein reicht nicht, weil sonst bei Duplikaten Mißverständnisse seitens des Compilers oder Linkers auftreten könnten. Man muß auf jeden Fall noch den Code irgendwo mit hinspeichern. Das sollte aber das geringste Problem sein.

Wenn man externe Referenzen nur zulässt, wenn auch die Implementation bekannt ist, dann dürfte das Ganze funktionieren, sogar ziemlich einfach.

volkard schrieb:

siehe gcc repro http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Template-Instantiation.html#Template-Instantiation

Yikes! IBM Visual Age, ick hör dir trapsen ...

volkard schrieb:

es ist nicht notwendig, jeden zu zwingen, für doppel-definitionen nur eine echte instanz zu kreieren. der gcc sorgt wenn befohlen mit zusätzlichen repo-dateien für uniqueness. muss er aber nicht. doppel macht nur den code größer aber das prog läuft auch so. und so können wir auch fein auto machen. alle compilerbauer, die es nicht sofort perfekt hinkriegen, machen mehrfachen code. und wir geben ihnen 10 jahre, es fertigzubringen, daß sie den code auch zusammenfassen. und wir kündigen das jetzt an. wir sagen "static-variablen in funktionen, die auto zurückgeben können aber müssen nicht mehrfach sein" und "funnktionszeiger von fun... sein" und "in 10 jahren dürfen sie nicht mehr merhfach sein". wo ist das problem?

Hast ja recht, im Prinzip gibt's keins, wenn man es wie besprochen handhabt.

[Jester]

Power Off schrieb:

Da der 2003er Standard längst draußen ist, ist auch der Vorschlag bereits abgelehnt worden.

2003 war keine Neuauflage des Standards, sondern hauptsächlich eine Korrektur. Die nächste Version des C++ Standards (C++0x) soll wohl irgendwann gegen Ende dieses Jahrzehnts kommen. Soweit ich weiß ist das veränderte auto-keyword dort schon beschlossene Sache. Ebenso wie typeof.

[Power Off]

Jester schrieb:

2003 war keine Neuauflage des Standards, sondern hauptsächlich eine Korrektur. Die nächste Version des C++ Standards (C++0x) soll wohl irgendwann gegen Ende dieses Jahrzehnts kommen. Soweit ich weiß ist das veränderte auto-keyword dort schon beschlossene Sache. Ebenso wie typeof.

Wo hast Du die Infos her? Wuerde mich mal interessieren, an was die grad so rumschrauben ...

[otze]

Kannst Du mal ein Beispiel nennen, wo man sowas wirklich braucht? Also, in welchen Fällen ist es wirklich unmöglich, den Typ zu wissen? Ich meine, wenn ein Compiler den Rückgabetyp erraten kann, kann das ein Programmierer doch auch, oder?

wenn du ein expression template hast, wirds unheimlich kompliziert.
ich benutze die im moment, und wenn ich da mal nen fehler mache, krieg ich einen typ an den Hals geworfen, der 800(!) und mehr zeichen lang ist. sowas kann man nicht mehr erraten.

dann kommt folgendes problem noch dazu:

var=expression_template;

mit dem auto keyword wär das kein problem. ohne auto keyword musst du aus dem expression template einen polymorphen typ basteln den du dann var zuweisen kannst.

wenn nun das expression-template folgende funktion hat:

template<class T,class U>
void foo(T,U);

wie willst du das mit einem polymorphen typ durchbringen? template+virtual=müll.

im endeffekt muss ich dann also auf die flexibilität dieses templates verzichten und var folgenden typ geben: Rule<T,U>. Rule selber hat 500 zeilen quellcode, nur(!) um ein expression template speichern zu können, eine sache die mit auto nur eine einzige zeile brauchen würde, und die einem auch noch den virtual overhead erspart.

[volkard]

Power Off schrieb:

Na ja, aber was spricht dagegen:

template <class A, class B, class C>
void func( A a, B b, C& c ) { c = a * b; }

und dann:

char a = 2;
short b = 7;
int c;
func( a, b, c );

bzw.

func<char,short,int>( a, b, c );

es ist

int c;//autsch, aua, ui, oh, aua, ohweh!

ich wollte doch nicht gezwungen sein, den typ zu wissen.

char a = 2;
short b = 7;
auto c=func( a, b );

Kannst Du mal ein Beispiel nennen, wo man sowas wirklich braucht? Also, in welchen Fällen ist es wirklich unmöglich, den Typ zu wissen? Ich meine, wenn ein Compiler den Rückgabetyp erraten kann, kann das ein Programmierer doch auch, oder?

haste schon das paper über expression templates von todd Veldhuizen gelesen? muß man eigentlich, ist ja 10 jahre alt und mindestens so wichtig wie modern c++ design.
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
dann kannste dich an

template<class A, class B>
DExpr<DBinExprOp<DExpr<A>, DExpr<B>, DApDivide> >
operator/(const DExpr<A>& a, const DExpr<B>& b)
{
      typedef DBinExprOp<DExpr<A>, DExpr<B>,DApDivide> ExprT;
      return DExpr<ExprT>(ExprT(a,b));
}

erinnern.
ok, es ist immer möglich, den ergebnistyp hinzuschreiben. logischwerweise gibts komplexere sachen, ich nenne die einheitenmitführung, wie von meyers im vorwort zu modern c++ design skizziert, wo man auch noch metaprogrammierung zur bestimmung des rückgabetyps braucht.

(Aber ich kapier auch die BOOST Library nicht, ist mir zu unlesbar, aber ist wohl Geschmackssache; ich gehör nicht zu denen, die ständig neue Sprachfeatures lernen, wenn ich sie nicht brauche -- leider; hab lang gebraucht, bis ich mir mal die STL so richtig reingezogen habe)

geht mir ähnlich. stl und boost sind mir so unangenehm, daß ich nicht mehr drauf aufsetze und leiber alles selber mache.

[Gast]

volkard schrieb:

aber was ist eigentlich mit

template<typename T,int size>
auto findElemAndIKnowItsExistent(T (&arr)[size],T const& toFind){
   for(int i=0;i<size;++i)
      if(arr[i]==toFind)
          return &arr[i];
   //hier ist was komisch. 
}

die normale lösung wäre

template<typename T,int size>
auto findElemAndIKnowItsExistent(T (&arr)[size],T const& toFind){
   for(int i=0;i<size;++i)
      if(arr[i]==toFind)
          return &arr[i];
   return *(T*)0;//only to make the compiler happy
}

Heyhey, diese "normale" Lösung kann doch unmöglich der tolle C++ Stil sein. Und du willst doch nicht zu einer MS-Erweiterung raten, oder? Da würde ich doch lieber eine Exception werfen, das macht den Compiler genauso glücklich, auch in Sprachen, die keine affigen Funktionen erlauben.

[volkard]

Optimizer schrieb:

Heyhey, diese "normale" Lösung kann doch unmöglich der tolle C++ Stil sein.

doch. der kommentar "only to make the compiler happy" muß aber zwingend dabei stehen.

Und du willst doch nicht zu einer MS-Erweiterung raten, oder?

doch. wir müssen gute compilerbauer auch belohnen, die hilfreiche erweiterungen anbieten. und nicht immer nur standard-c++ benutzen. sonst haben die compilerbauer überhaupt keinen zug, hilfreiche features einzubauen.

Da würde ich doch lieber eine Exception werfen, das macht den Compiler genauso glücklich,

aber bläht den code auf wie ungeheuer. exceptions sind hier sicherlich die zweitschlechteste lösung (nich schlechter wäre nur exit(1);.

auch in Sprachen, die keine affigen Funktionen erlauben.

dort sind exceptions angesagt, daran zweifle ich gar nicht. aber ich weiß, daß sie in c++ hier müll wären.

was stört dich eigentlich an der default-lösung?

[Gast]

Naja, unter der Annahme, dass der Programmierer (oder ein anderer) ein Mensch ist und einen Fehler einbauen könnte, der dazu führt, dass die Funktion doch nichts findet, kann die default-Lösung den Fehler enorm verschleiern. Wenn du den zurückgegebenen Pointer nicht sofort benutzt sondern in einem Tree ablegst, den du noch mit 80 weiteren Pointern füllst (und du weißt natürlich ganz genau, dass da niiiiieeeee ein 0-Pointer drin ist) und irgendwann mal eine access violation kriegst, dann hast du Spaß beim Suchen. Fail-fast ist diese Lösung jedenfalls nicht.

[volkard]

Optimizer schrieb:

Naja, unter der Annahme, dass der Programmierer (oder ein anderer) ein Mensch ist und einen Fehler einbauen könnte, der dazu führt, dass die Funktion doch nichts findet, kann die default-Lösung den Fehler enorm verschleiern.

gement war natürlich (T*)0 und nicht (T)0, sonst paßt der untere typ ja nicht zum oberen.
wenn die funktion nix findet, wird was zurückgegeben, was eh kein sinnvolles objekt sein kann, also bei vergleichen muß keiner lögen und wenn sich jemand das objekt abguckt, fliegt ne schutzverletzung, der debugger (wenn dahinter) wirft mich in die fehlerzeile und ich geh den call-stack rauf zum fehler. 0 derefenzieren ist (wenigstens mit dem MSVC60) genausogut wie assert.
aber ich würde da assert(false); hinschreiben, auch um nochmal bescheid zu sagen, daß der rechner gar nicht an diese stelle laufen darf. hatte ich schon erwähnt, daß mein ASSERT-makro auch __assume benutzt? bei mir reicht ASSERT(false) schon und __assume muß ich gar nicht mehr machen.

Wenn du den zurückgegebenen Pointer nicht sofort benutzt sondern in einem Tree ablegst, den du noch mit 80 weiteren Pointern füllst (und du weißt natürlich ganz genau, dass da niiiiieeeee ein 0-Pointer drin ist) und irgendwann mal eine access violation kriegst, dann hast du Spaß beim Suchen.

würde auch nicht so lange dauern, ich würde ja gleich sehen, daß im tree ne 0 steht und dann halt zugucken, was in den tree gesteckt wird.

Fail-fast ist diese Lösung jedenfalls nicht.

ich überlasse es dem leser zur übung, kleine details fein auszuschmücken.

[volkard]

wir kommen vom thema ab.
also nur, damit das nochmal klar ist: python ist müll für dumme masochisten.

[Gast]

würde auch nicht so lange dauern, ich würde ja gleich sehen, daß im tree ne 0 steht und dann halt zugucken, was in den tree gesteckt wird.

Warum baust du dann nen ranged-checked Iterator? Wird doch auch nicht so lange dauern, wenn es irgendwann kracht, dann wirst du dir den Iterator anschaun, sehen, dass der ungültig ist, dann suchst du dir die Stellen, wo du ihn überall erhöhst und denkst nach, was es ist. Ich finde es immer angenehmer, wenn ein Programm früher abstürzt als später. Am liebsten ist es mir, wenn ich es schon gar nicht starten kann, so lange ein Fehler drin ist.

hatte ich schon erwähnt, daß mein ASSERT-makro auch __assume benutzt? bei mir reicht ASSERT(false) schon und __assume muß ich gar nicht mehr machen.

Wie implementierst du dann ASSERT auf nicht MS-Compilern? Der Unterschied ist nicht unwesentlich, wenn __assume dem Compiler bescheid sagt, dass der Kontrollfluss hier endet und was anderes das nicht tut.

volkard schrieb:

wir kommen vom thema ab.
also nur, damit das nochmal klar ist: python ist müll für dumme masochisten.

Davon ging ich sowieso schon die ganze Zeit aus.

[volkard]

Optimizer schrieb:

Warum baust du dann nen ranged-checked Iterator? Wird doch auch nicht so lange dauern, wenn es irgendwann kracht, dann wirst du dir den Iterator anschaun, sehen, dass der ungültig ist, dann suchst du dir die Stellen, wo du ihn überall erhöhst und denkst nach, was es ist.

0 ist was ganz anderes, als eins hinter dem array-ende!
zugriff auf 0 wirkt bei ner guten ide wie assert.
array-ende kann nicht gefunden werden.
feines beispiel: http://www.volkard.de/vcppkold/shell_sort.html
hab erst ein dreiviertel jahr später bemerkt, daß das abtürzt.

Ich finde es immer angenehmer, wenn ein Programm früher abstürzt als später. Am liebsten ist es mir, wenn ich es schon gar nicht starten kann, so lange ein Fehler drin ist.

auch deswegen mag ich c++.

Wie implementierst du dann ASSERT auf nicht MS-Compilern? Der Unterschied ist nicht unwesentlich, wenn __assume dem Compiler bescheid sagt, dass der Kontrollfluss hier endet und was anderes das nicht tut.

der unterschied ist gewaltig. wenn der rechner fälschlicherweise über ein __assume(false) läuft, dann passieren spannende, lustige und überraschende dinge. zum beispiel hat die funktion hinten gar kein ret mehr stehen, weil da eh keiner hinlaufen kann. also muß man assume sinnvollerweise auch gleich mit assert schützen.

//für ms
__declspec(noreturn) void raiseAssertError(char const* cond,char const* file,int line);

#ifndef NDEBUG
#define ASSERT(cond) if(cond);else ::raiseAssertError(#cond,__FILE__,__LINE__)
#else
#define ASSERT(cond) _assume(cond)
#endif

//für gcc
void raiseAssertError(char const* cond,char const* file,int line) __attribute((noreturn));

#ifndef NDEBUG
#define ASSERT(cond) if(cond);else ::raiseAssertError(#cond,__FILE__,__LINE__)
#else
#define ASSERT(cond) typedef int VHassert
#endif

[Gast]

volkard schrieb:

Optimizer schrieb:

Warum baust du dann nen ranged-checked Iterator? Wird doch auch nicht so lange dauern, wenn es irgendwann kracht, dann wirst du dir den Iterator anschaun, sehen, dass der ungültig ist, dann suchst du dir die Stellen, wo du ihn überall erhöhst und denkst nach, was es ist.

0 ist was ganz anderes, als eins hinter dem array-ende!
zugriff auf 0 wirkt bei ner guten ide wie assert.
array-ende kann nicht gefunden werden.

Das ist klar, aber nicht exakt das, was ich meinte. Du magst C++, weil du es für fail-fast hältst, da habe ich zwar eine andere Meinung von, aber auch das müssen wir ja nicht genauer ausführen. Den meisten Einfluss darauf, ob dein Programm schnell abstürzt, hat dein Programmcode selber und nicht die Sprache. Bei 0 ist es weg, das weiß ich, aber da kann es schon lange zu spät sein. Wie bereits aufgeführt, kann der Pointer erstmal reihum gehen und in einer Datenstruktur 10 Jahre gammeln, bis er benutzt wird und dann ist nichts mehr mit dem call stack runtergehen und schauen, ab wann es zum ersten mal nicht mehr passt.
Du würdest dann schaun, wo du die 0 in den Tree tust, das würde ich auch. Wenn du aber Pech hast, passiert das erst beim nächsten Vollmond wieder, dass das Element nicht gefunden wurde und 0 in den Tree kommt, dann hast du deine Chance verpasst und Schuld daran ist das zurückgeben eines Fluchtwerts in einer Situation, wo es IMHO krachen sollte.

[O'Rakl]

volkard schrieb:

wir kommen vom thema ab.
also nur, damit das nochmal klar ist: python ist müll für dumme masochisten.

Python ist in der Summer aller ihrer Eigenschaften für nicht-resourcenkritische Anwendungen die beste verfügbare Programmiersprache. Mit Abstand.

Wer von zwei Programmierern, einem C++-Programmierer und einem Python-Programmierer
der größere Masochist ist, da habe ich allerdings eine *ganz* andere Meinung als Du, was daran liegen mag, daß ich beides kenne. Das werde ich aber in diesem
C++-Forum nicht weiter verexplizieren

Python, mein lieber volkard, ist kein "Müll", sondern eine überaus
elegente und mächtige Programmiersprache.

Du bist ohnehin nur neidisch, weil ich jetzt ein freies Wochenende habe, wo
ich mit C++ noch manche Nächte bis in die Morgendämmerung durcharbeiten mußte
und auch keine müdigkeitsbedingten "C++-Ringe" mehr unter den Augen habe, seit
die Arbeit einer Woche nun mit Python an einem Vormittag zu schaffen ist.

Wie dem auch sei -- von mir aus kannst Du Deine Programme in Oktalcode
einhacken.

Grüße und ein schönes Wochenende allerseits

[Gast]

Ich gratuliere dir, anscheinend hast du deine Sprache gefunden.

[GPC]

Was bei mir persönlich Kopfweh auslöst sind solche Sachen:

def foo(value):
  if (value==1):
    return 123;
  else:
    return list = ["1", "2", "3"]

x = foo(1)  #Und was jetzt???

Das gefällt mir irgendwie gar nicht. Logisch, wer so programmiert gehört geschlagen, und das Beispiel ist nicht direkt praxisnah, aber ich hab ähnliches bei einem Bekannten schon gesehen.

[groovemaster]

O'Rakl schrieb:

Wer von zwei Programmierern, einem C++-Programmierer und einem Python-Programmierer
der größere Masochist ist, da habe ich allerdings eine *ganz* andere Meinung als Du, was daran liegen mag, daß ich beides kenne.

Beweise?

Optimizer schrieb:

Ich gratuliere dir, anscheinend hast du deine Sprache gefunden.

Zu dumm, dass er nicht lesen kann.

[volkard]

O'Rakl schrieb:

Python, mein lieber volkard, ist kein "Müll", sondern eine überaus elegente und mächtige Programmiersprache.

da habe ich allerdings eine *ganz* andere Meinung als Du, was daran liegen mag, daß ich beides kenne. Das werde ich aber in diesem C++-Forum nicht weiter verexplizieren