Liste mit beliebig langen Stellen
-
;fricky schrieb:
na klar, und schon hat er's mit code zu tun, der vor der 'main' aufgerufen wird. auch ein ganz tolles feature von c++ *gg*
Ist nur die Folge, weil Du so viel mit globalen Variablen rummachst, was auch in C eine Sünde ist, normalerweise tut man sowas nicht machen.
-
Ja was nun? Ist es nun eine Sünde, oder macht man es einfach nur "normal" nicht? Was ist "unnormal"? Ohne etwas Erklärung ist diese Regel einfach etwas zu "religiös", findest du nicht?
-
volkard schrieb:
Ist nur die Folge, weil Du so viel mit globalen Variablen rummachst, was auch in C eine Sünde ist, normalerweise tut man sowas nicht machen.
im prinzip haste recht, aber hier haben wir's nur mit 'nem überschaubaren 30-zeiler zu tun, da ist es nicht so schlimm. und falls man globalvariablen-verseuchten code in ein grösseres programm integrieren wollte, könnte man immer noch 'static' vor die variablen setzen, dann sind sie nur noch datei-global. direkte zugriffe auf globale daten machen code auch meistens kleiner und schneller, weil 'ne indirektionsstufe fehlt (oder man greift über restrict-pointers darauf zu).
-
Tim schrieb:
Ja was nun? Ist es nun eine Sünde, oder macht man es einfach nur "normal" nicht? Was ist "unnormal"? Ohne etwas Erklärung ist diese Regel einfach etwas zu "religiös", findest du nicht?
Globale Variablen sind ungünstig weil man den Überblick verliert. Bei jeder globalen Variablen muss man genau wissen was sie tut und in welcher Situation in welcher Funktion man was mit ihnen machen muss. Und wenn eine globale Variable Blödsinn enthält sucht man sich dumm und dämlich herauszufinden welche Funktion in welcher Situation Blödsinn macht. Bei 30 Zeilen ist es egal, aber bei >1000 Zeilen ist jede globale Variable eine Zumutung.
Edit: Es ist vergleichbar mit goto, mächtig und unkontrollierbar. Nicht ganz so schlimm wie goto, aber es geht in die Richtung.
-
nwp2 schrieb:
Ich habe das mal in python zusammengehackt:
... def permutationen(liste): ... for l in permutationen(liste[1:]): ...
Das geht so nicht, weil Python die Rekursion auf C abbildet:
http://mail.python.org/pipermail/python-dev/2006-January/059652.htmlZwar gibt es Stackless Python (ein Minoritätsprojekt), aber solche Kindereien sind für eine "Very High Level Language" echt lachhaft. Wenn schon cheaten, warum nicht so:
(define (char) (amb 'a 'b 'c 'd)) (let ((sol (list (char) (char) (char) (char)))) (require (distinct? sol)) sol)
-
nwp2 schrieb:
Globale Variablen sind ungünstig weil man den Überblick verliert. Bei jeder globalen Variablen muss man genau wissen was sie tut und in welcher Situation in welcher Funktion man was mit ihnen machen muss. Und wenn eine globale Variable Blödsinn enthält sucht man sich dumm und dämlich herauszufinden welche Funktion in welcher Situation Blödsinn macht. Bei 30 Zeilen ist es egal, aber bei >1000 Zeilen ist jede globale Variable eine Zumutung.
Trivial beherrschbar durch Konventionen wie "Globale Größe darf nur von definierendem Modul beschrieben werden" und Namenskonventionen. Null Problem. Ich rede hier von Projekten >100k Codezeilen.
Was du vielmehr beschreibst sind hirnlose Dahincoder. Und bei denen bricht das Kartenhaus eh irgendwann zusammen. Sinnfreier Einsatz von globalen Variablen und goto fördert hier sogar das gute "crash early" Prinzip
-
nwp2 schrieb:
Es ist vergleichbar mit goto, mächtig und unkontrollierbar. Nicht ganz so schlimm wie goto, aber es geht in die Richtung.
was hältste denn von: http://en.wikipedia.org/wiki/Setjmp.h das dürfte, deinem verständnis nach, doch einem weltuntergang gleichkommen, ne? *fg*
btw, ich glaube ich bastel mal 'nen sortieralgorithmus nur mit throw/try/catch, den poste ich ins C++-forum mit der frage: 'hi, ich lerne gerade in C++. hier mein erstes programm, bitte um verbesserungsvorschläge.' *gg*
-
Ach, macht doch was ihr wollt. Von mir aus benutzt goto mit globalen Variablen und buffer[wirdschonreichen], von 17 Klassen geerbt und über den überladenen Operator ! aufgerufen.
Genies wie ihr seid ist das überhaupt kein Problem damit perfekten Code zu schreiben. Vielleicht solltet ihr aber bedenken, dass Leute die hier Fragen stellen keine Genies sind und auf verständlichen Code angewiesen sind.Btw von Namenskonventionen alla INT_var und CHARP_string halte ich garnichts.
-
nwp2 schrieb:
Vielleicht solltet ihr aber bedenken, dass Leute die hier Fragen stellen keine Genies sind und auf verständlichen Code angewiesen sind.
Eben deswegen schreite ich auch ein wenn du deine "Buffer" die ja Listen sind an Anfänger verkaufst. Und nochmal: Man kann auch verständlichen Code mit globalen Variablen schreiben. Du vielleicht nicht, aber man schon.
-
nwp2 schrieb:
Vielleicht solltet ihr aber bedenken, dass Leute die hier Fragen stellen keine Genies sind und auf verständlichen Code angewiesen sind.
und deshalb muss man auch nicht ständig erzählen, dass statische buffer und goto generell schlecht sind. das sind sie nämlich garnicht. kommt immer drauf an, was man vorhat. manchmal ist ein goto äusserst hilfreich und feste arrays sowieso. sogar 'malloc' ist manchmal angebracht, obwohl ich der meinung bin, dass manche hier damit ganz schön übertreiben (nicht nur du).
-
@;fricky
richtig so zeigs ihnen
jedem studenten in der uni wir heutzutage erklärt das ein goto böse ist,
und dabei sagen die godfathers of c27. Horrors! goto's and labels
C has a goto statement and labels, so you can branch about the way you used to. But most of the time goto's aren't needed. (How many have we used up to this point?) The code can almost always be more clearly expressed by for/while, if/else, and compound statements.One use of goto's with some legitimacy is in a program which contains a long loop, where a while(1) would be too extended. Then you might write
mainloop:
...
goto mainloop;Another use is to implement a break out of more than one level of for or while. goto's can only branch to labels within the same function.
wobei für mich der vorletzte satz eigentlich der entscheidende ist.
nachzulesen unter http://www.lysator.liu.se/c/bwk-tutor.html#gotoda eine function eh keine 1000 zeilen lang sein soll ist das mit der übersichtlichkeit auch kein problem, da das label ja nur innerhalb der function gültig ist.
wollte nur auch mal wieder was loswerden
lg lolo