mehrere return-Anweisungen schlecht?

itedvo

wäre es eine möglichkeit, eine structur fest zu legen und das ganze per funktion
zu closen?

in etwa so:

struct FILE_struct{
   FILE* read;
   FILE* write;
   FILE* writeAndRead;
}fileStruct;

void CloseAll(void){

   fclose(fileStruct.read);
   fclose(fileStruct.write);
   fclose(fileStruct.writeAndRead);

}

ist das sinnvoll (in der art, ist nur so daumen mal pi) oder unaktzeptabel/unsauber?

volkard

SG1 schrieb:

volkard schrieb:

SeppJ schrieb:

Daumenregel

Faustregel.

Wo ist der Unterschied?

SeppJ hat sich als Englisch-Leser geoutet, nehme ich an. Kein Fehler, zum Beispiel "Programming Perls" (wo ich mir auch die Daumenregel angewöhnt hatte) ist auf englich so endgeil, ich würde abstreiten, daß man es einigermaßen erhaltend überhaupt übersetzen kann, wenn ich nicht "Gödel, Escher Bach" gelesen hätte. Aber Programmierbücher werden traditionell schlampig übersetzt.
http://en.wikipedia.org/wiki/Rule_of_thumb

Auf Hochdeutsch ist es die
http://de.wikipedia.org/wiki/Faustregel

Angeblich gibt es in den südlichen Grenzgebieten auch Dörfer wo auf "deutsch" Daumenregel üblich ist. Ich wäre an einer Klangprobe interessiert.

volkard

itedvo schrieb:

wäre es eine möglichkeit, eine structur fest zu legen und das ganze per funktion
zu closen?

in etwa so:
struct FILE_struct{
   FILE* read;
   FILE* write;
   FILE* writeAndRead;
}fileStruct;

void CloseAll(void){

   fclose(fileStruct.read);
   fclose(fileStruct.write);
   fclose(fileStruct.writeAndRead);

}
ist das sinnvoll (in der art, ist nur so daumen mal pi) oder unaktzeptabel/unsauber?

Erstmal schauen, WAS Du da machst.

Du faßt Objekte zu größeren Objekten zusammen und definierst dazu Funktionen. Du programmierst objektorientiert.

Das kann sinnvoll sein, muß aber nicht. Ich verweise dazu auf die unzähligen Threads C++ versus C. Wenn Du solche Zusammenfassungen magst, ist es vielleicht schlau, nach C++ zu wechseln. Dann würde man gleich Destruktoren benutzen, die von alleine aufräumen. Sehr lecker! Aber damit kaufst Du auch viel Ungemach ein. Weil schlechter C++-Code schlechter ist als normaler C-Code, und verdammt viele Folgerungen, auf die man nicht so von alleine kommt, aus dem Destruktor-Konzept erspringen, müßtest Du beim Umstieg eigentlich erstmal ein viertel Jahr anhalten und Kram lesen, bevor es mit gutem C++ weitergehen kann. Mit so einer Lesepause steigert man aber auch normalen C-Code zu gutem C-Code.

Daher wäre mir diese Zusammenfassung suspekt. Aber nicht undenkbar. Objektorientierte Programmierung geht ja auch ohne Destruktoren, wie C mit allen Objekten, die open()/close() haben beeindruckend zeigt. Warum nicht auch Zusammenfassen? Sobald es inhaltlich ok ist, nur zu!

Aber C braucht die Abstaktion nicht. Es fühlt sich an wie eine Abstraktion ohne großen Nutzen. C++ lebt davon, da wäre das (und noch viel mehr) eigentlich nötig. Unnütze Abstraktion fühlt sich schlecht an.

itedvo

ach, n'viertel jahr mehr lernen oder weniger... aber interessant, jetzt weiss ich
wieso mein professor teilweise meinen stil nicht mag... ich programmiere schon
immer so, hat mir keiner gesagt was objekt orientiert ist und auf die frage ob
man mir das erklären könnte, kam nur die antwort: das lernen wir eh in 2 jahren,
also konzentrier dich auf das jetzige...

SeppJ

volkard schrieb:

SG1 schrieb:

volkard schrieb:

SeppJ schrieb:

Daumenregel

Faustregel.

Wo ist der Unterschied?

SeppJ hat sich als Englisch-Leser geoutet, nehme ich an.

Das hast du übrigens vollkommen Recht. Da wo ich herkomme, sagt man tatsächlich Faustregel. Aber ich lese und spreche so viel Englisch, dass ich immer häufiger mit solchen Redewendungen durcheinander komme. Wobei es mir hinterher peinlich ist, wenn es mir auffällt (die Daumenregel klingt jedoch lustig ). Auch die ganzen anderen typischen Verdreher wie "nicht wirklich" oder "das macht Sinn" mache ich dauernd. Die Daumenregel ist mal wieder etwas neues.

EOP

Nix substantiell Neues zu dem Thema, nur ein LOL:

It is often claimed that the term originally referred to a law that limited the maximum thickness of a stick with which it was permissible for a man to beat his wife.

Ich persönlich denke ja, daß der Ausdruck Daumenregel daher kommt, Enfernungen mit der ausgestreckten, zur Faust geballten Hand (mit erhobenenm Daumen) abzuschätzen.

Mehrere return Anweisungen sind wichtig, weil so etwas sonst nicht funktionieren würde:

./configure && make

oder, da das nur Scripte sind bei richtigen Programmen:

tar c bla blub.tar && gzip blub.tar
(oder so ähnlich)

Wenn das tar funzt, dann liefert es return 0.
Wenn nicht, dann irgendeinen Error Code abweichend von 0 und gzip wird dann nicht mehr aufgerufen.
Deswegen sind mehrere returns in einem Programm notwendig.

volkard

EOP schrieb:

Ich persönlich denke ja, daß der Ausdruck Daumenregel daher kommt, Enfernungen mit der ausgestreckten, zur Faust geballten Hand (mit erhobenenm Daumen) abzuschätzen.

Aber das ist nur eine das Schätzen begleitende Geste.
Zum Einen wird sie z.B. bei Kraftfahrzeugschlossern zur Rechnungsbetragsermittlung verwendet, dabei mit den Worten "Pi mal Daumen" unterstützt. Na, das wars auch. Wobei der Daumen am ausgetreckten Arm gerne eine Sekunde lang zusammen dreimal zwischen senkrecht und 45-60 Grad nach links (beim Rechtshänder) dreht und wieder in die Ausgangslage geht.
Kein Mensch verwendet den Daumensprung noch als Maß.
Aber dabei ist es immer eine, im übertragenen Sinne, Daumenpeilung.

supertux

Ist notwendig schrieb:

Mehrere return Anweisungen sind wichtig, weil so etwas sonst nicht funktionieren würde:

./configure && make

oder, da das nur Scripte sind bei richtigen Programmen:

tar c bla blub.tar && gzip blub.tar
(oder so ähnlich)

Wenn das tar funzt, dann liefert es return 0.
Wenn nicht, dann irgendeinen Error Code abweichend von 0 und gzip wird dann nicht mehr aufgerufen.
Deswegen sind mehrere returns in einem Programm notwendig.

das hat aber mit dem Thema nichts zu tun.

R3FRESH

Hm, warum mein Miniprogramm immer die selben Zufallszahlen an der selben Posi ausgibt, hat bis jetzt noch keiner erklärt.
& auf die Frage wie man Zufallszahlen initialisiert bzw was das für n Sinn hat, gibts auch noch keine Antwort...

SeppJ hat auch noch immer nich geantwortet, was so 'Spagetti' an meinem Code sein soll??
Nur zur Info, der Code is die Buchvorlage, von daher kann ich mir fast nich vorstellen, dass die Buchschreiber-Jungs Spagetticode
drucken lassen.

Tjou & der gut gemeinte lange Absatz von volkard auf page1 is für mich nur Bahnhof, weil ich leider noch nichts mit
- open-/close-Anweisungen,
- foo, fooSub & Co &
- schon gar nich mit irgendwelchen 'mystischen Wrapper-Tricks'
zu tun hatte.

...also bin ich jetzt noch genauso schlau wie vor der Erstellung dieses Threads...

Wenn ihr mir feedbackt, dann brauche ich bitte Anfänger-gerechte Feedbacks (hört sich zwar blöd an, is aber so)
& Antworten auf die Fragen, die ich im Threadverlauf stelle.

volkard

R3FRESH schrieb:

Hm, warum mein Miniprogramm immer die selben Zufallszahlen an der selben Posi ausgibt, hat bis jetzt noch keiner erklärt.
& auf die Frage wie man Zufallszahlen initialisiert bzw was das für n Sinn hat, gibts auch noch keine Antwort...

SeppJ hat auch noch immer nich geantwortet, was so 'Spagetti' an meinem Code sein soll??
Nur zur Info, der Code is die Buchvorlage, von daher kann ich mir fast nich vorstellen, dass die Buchschreiber-Jungs Spagetticode
drucken lassen.

Tjou & der gut gemeinte lange Absatz von volkard auf page1 is für mich nur Bahnhof, weil ich leider noch nichts mit
- open-/close-Anweisungen,
- foo, fooSub & Co &
- schon gar nich mit irgendwelchen 'mystischen Wrapper-Tricks'
zu tun hatte.

...also bin ich jetzt noch genauso schlau wie vor der Erstellung dieses Threads...

Wenn ihr mir feedbackt, dann brauche ich bitte Anfänger-gerechte Feedbacks (hört sich zwar blöd an, is aber so)
& Antworten auf die Fragen, die ich im Threadverlauf stelle.

Nö, so nicht. Direkt im zweiten Posting hat f.-th. das mit dem Zufall gelöst. Manchmal kann man ein Wort nicht zuordnen, aber dann fragt man schnell mal google.
http://lmgtfy.com/?q=c+zufallszahlen+initialisieren
Das war ganz einfach und wird von Dir erwartet.

R3FRESH

Ah ok.
Was mich aber wundert, dass das Buch nich drauf hinweist, dass immer die selben Zahlen kommen & wie bzw das überhaupt initialisiert werden muss.

& was findest du an meinem Code so Spagetti?

volkard

R3FRESH schrieb:

& was findest du an meinem Code so Spagetti?

Ich nenne Code nie Spaghetti-Code. Für mich ist das ein Schlagwort und Totschlagargument der meist unbegabten Strukturiertes-Programmieren-Dogmatisten der 70-er und 80-er Jahre.

Das Programm zu bewerten, klappt nicht, denn es tut nichts tun, sondern tut einfach nur sein. Das dreidimensionale Array löst keine Probleme, sondern wird nur gezeigt.

Diese "Programmieren" in 21 Tagen Bücher sind ja schon ein wenig länger auf dem Markt. Von wann ist deine Auflage? Bis auf ein oder zwei von denen hatten die vor 15 Jahren oder so, keine guten Buchbesprechungen. Oder sind die späteren Auflagen deutlich überarbeitet worden?

MfG f.-th.

R3FRESH

Die Originalvorlage in Englisch is anscheinend 1999 erschienen, die Übersetzung is 2007 durch Markt+Technik veröffentlicht worden.
Da ich keine früheren Ausgaben von dem Buch kenne, kann ich nich sagen, ob es überarbeitet worden is, kP...
Das Buch is mir aber von mehreren Seiten wärmsten empfohlen worden.
Gibt ja genug Schrottbücher, die dir ebenfalls C vermitteln sollen/wollen, zB 'C von A bis Z', ...