vergesst C++ ...

volkard

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

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

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.

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

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

volkard, ich hoffe, dass du durch solche Diskussionen keine wertvolle Zeit verschwendest, die eigentlich deiner VLib zu gut kommen sollte.
mfg

*gute

Volkard schrieb:

python ist müll für dumme masochisten.

Wenn man da an der richtigen Stelle nen Komma setzt, bekommt der Satz ne ganz andere Bedeutung, wer sagt uns, dass Volkard da nicht nur nen Komma vergessen hat

wer sagt uns, dass Volkard da nicht nur nen Komma vergessen hat

Ganz einfach, es steht nicht da und trotzdem kann ich den Satz parsen. Also muss ich den Sinn annehmen, den der Satz so vermittelt. Stell' dir vor, dein Compiler würde so rumraten wie du...

volkard

User--- schrieb:

Volkard schrieb:

python ist müll für dumme masochisten.

Wenn man da an der richtigen Stelle nen Komma setzt, bekommt der Satz ne ganz andere Bedeutung, wer sagt uns, dass Volkard da nicht nur nen Komma vergessen hat

na, das probiere ich gleich mal aus.

python, ist müll für dumme masochisten.
also der herr python wird angesprochen un befragt, ob müll für dumme masochisten sei. müßte aber ein fragezeichen ans ende.
falsch.

python ist, müll für dumme masochisten.
also python existiert und ich fprdere müll für dumme masochisten. müßte aber ein rufzeichen nach der forderung stehen.
falsch.

python ist müll, für dumme masochisten.
falsch.

python ist müll für, dumme masochisten.
falsch.

python ist müll für dumme, masochisten.
also das hier meinste?

Komischerweise gibt es kein Wort das per Definition das genaue Gegenteil von Müll ist.

volkard

.aw schrieb:

Komischerweise gibt es kein Wort das per Definition das genaue Gegenteil von Müll ist.

komisch?
haben nicht fast alle wörter kein gegenteil?
ich teste mal.
auto
baum
apfelkuchen
computer
taschentuch
alkohol
tintenstrahldrucker
feuerzeug

hmm. keins der wörter hat ein gegenteil, oder?

python ist müll, für dumme masochisten.
falsch.

Ich denke das hier wird er gemeint haben, wobei das "für" zu interpretieren ist als "nach der Meinung von". Daran sieht man natürlich wieder sehr gut, dass natürliche Sprachen in der Praxis einfach unbrauchbar sind.

Sovok

lol

lol

Talla

volkard schrieb:

.aw schrieb:

Komischerweise gibt es kein Wort das per Definition das genaue Gegenteil von Müll ist.

komisch?
haben nicht fast alle wörter kein gegenteil?
ich teste mal.
auto
baum
apfelkuchen
computer
taschentuch
alkohol
tintenstrahldrucker
feuerzeug

hmm. keins der wörter hat ein gegenteil, oder?

Substantive haben in den seltensten Fällen Gegenteile - bei Adjektiven siehts schon ganz anders aus.