Arbeiten mit Unterprogrammen (quadrieren)

[Fricky667]

wob schrieb:

4. Vermeide globale Variablen, schiebe das "int zahl" ins main.

...

Edit: Zeile 9 solltest du auch nochmal angucken[u]...

Aber nur wenn er deinen Punkt 4 umsetzt. Ansonsten ist die Zeile okay.

[SeppJ]

Fricky667 schrieb:

wob schrieb:

4. Vermeide globale Variablen, schiebe das "int zahl" ins main.

...

Edit: Zeile 9 solltest du auch nochmal angucken[u]...

Aber nur wenn er deinen Punkt 4 umsetzt. Ansonsten ist die Zeile okay.

Nein, ist sie nicht. Guck genauer hin!

[Fricky667]

SeppJ schrieb:

Nein, ist sie nicht. Guck genauer hin!

Meinste weil scanf veraltet ist?

Das Progrämmchen des OP mit minimalen Änderungen lauffähig gemacht. Zeile 9 (hier ist unverändert:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int zahl;
void einlesen()
{
    scanf("%d",&zahl);

}
int quadrat(int zahl)
{
    return (zahl*zahl);

}

void ausgeben(void)
{
    printf(" zAhl %d zum quadrat %d ",zahl,quadrat(zahl));
}
int main()

{
    einlesen();
    ausgeben();
}

[SeppJ]

Fricky667 schrieb:

Meinste weil scanf veraltet ist?

scanf soll veraltet sein?

Nein. Wie ich sagte: Guck genauer hin! Vielleicht könnte die Korrektheit eines Codeabschnitts ja eventuell auch davon abhängen, was drumherum steht?

Und dass du nun das Programm verschlimmbesserst, indem du voll in globalen Variablen aufgehst, hilft dem Threadersteller gewiss nicht weiter. @Threadersteller: Bloß nichts von Fricky667 nachmachen!

[Fricky667]

SeppJ schrieb:

Fricky667 schrieb:

Meinste weil scanf veraltet ist?

scanf soll veraltet sein?

Jedenfalls sieht Mickrigweich scanf als Sicherheitslücke an.
--> https://stackoverflow.com/questions/21434735/difference-between-scanf-and-scanf-s

SeppJ schrieb:

Nein. Wie ich sagte: Guck genauer hin! Vielleicht könnte die Korrektheit eines Codeabschnitts ja eventuell auch davon abhängen, was drumherum steht?

Ich bezog mich nur auf Fehler, die eine Programmausführung verhindern. Nicht auf korrekten Code. Und Variablen außerhalb von Funktionen pauschal zu verteufeln, finde ich auch nicht sinnvoll.

[SeppJ]

Fricky667 schrieb:

SeppJ schrieb:

Nein. Wie ich sagte: Guck genauer hin! Vielleicht könnte die Korrektheit eines Codeabschnitts ja eventuell auch davon abhängen, was drumherum steht?

Ich bezog mich nur auf Fehler, die eine Programmausführung verhindern. Nicht auf korrekten Code. Und Variablen außerhalb von Funktionen pauschal zu verteufeln, finde ich auch nicht sinnvoll.

Es ist ein Fehler, der die Programmausführung verhindert! Meine Güte, das ist ja nicht zum Aushalten! Guck doch endlich mal, wie zahl definiert ist! Das kommt davon, wenn man lieber zufällig ausprobiert, anstatt seine Programme zu verstehen

[Fricky667]

SeppJ schrieb:

Es ist ein Fehler, der die Programmausführung verhindert!

Bei mir nicht (MinGW unter Windoze).

SeppJ schrieb:

Meine Güte, das ist ja nicht zum Aushalten!

Nimms nicht persönlich.

SeppJ schrieb:

Guck doch endlich mal, wie zahl definiert ist!

Guck du doch mal, dass meine "void einlesen()" kein Argument mehr braucht.

[EOP]

Fricky667 schrieb:

Guck du doch mal, dass meine "void einlesen()" kein Argument mehr braucht.

Tolle Leistung. Das Argument wurde sowieso zu keinem Zeitpunkt benutzt.

[Dumpfbacke]

Fricky667 schrieb:

Guck du doch mal, dass meine "void einlesen()" kein Argument mehr braucht.

Das ist aber nicht was Akai laut seinem ersten Beitrag hier üben wollte: Unterprogramme

Hab keine Ahnung von C, deshalb der Nick.
Quelltext auf eigene Gefahr ansehen.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int einlesen()
{
    int lieszahl;
    ...
    return lieszahl;
}

int quadrat(int zahlq)
{
    return (zahlq * zahlq);
}

void ausgeben(int zeigezahl)
{
    ...
}

int main(void)
{
    int zahl;
    zahl = einlesen();
    ausgeben(zahl);
}

Fricky eine globale Variable verdeckt bei Übungen mit Unterprogrammen oft Fehler oder führt mindestens zu Missverständnissen!

[Fricky667]

EOP schrieb:

Fricky667 schrieb:

Guck du doch mal, dass meine "void einlesen()" kein Argument mehr braucht.

Tolle Leistung. Das Argument wurde sowieso zu keinem Zeitpunkt benutzt.

Klar doch, vom scanf. Eine lokale Variable innerhalb einer Funktion überdeckt gleichnamige globale Variablen d.h. auch die im Funktionskopf sind lokale Variablen.

[Fricky667]

Dumpfbacke schrieb:

Fricky eine globale Variable verdeckt bei Übungen mit Unterprogrammen oft Fehler oder führt mindestens zu Missverständnissen!

Damit hast du sicher recht.

[Schlangenmensch]

[quote="Fricky667"][quote="EOP"]

Fricky667 schrieb:

Klar doch, vom scanf. Eine lokale Variable innerhalb einer Funktion überdeckt gleichnamige globale Variablen d.h. auch die im Funktionskopf sind lokale Variablen.

Und wenn dir jetzt noch auffällt, dass das Argument ein Pointer war, hast du den Fehler, der in besagter Zeile 9 gemacht wurde, auch schon gefunden.

[Fricky667]

Schlangenmensch schrieb:

Und wenn dir jetzt noch auffällt, dass das Argument ein Pointer war, hast du den Fehler, der in besagter Zeile 9 gemacht wurde, auch schon gefunden.

Das fällt kaum noch ins Gewicht. Scanf ist es egal, ob es einen int* oder einen int** bekommt. Eine von den Variablen Namens 'zahl' muss verschwinden, sonst funzt es nicht.

Naja, ein schlauer Compiler würde schon merken, dass das Argument nicht zur Formatspezifikation passt (müsste bei int** IMHO %p sein).

[SeppJ]

Fricky667 schrieb:

Schlangenmensch schrieb:

Und wenn dir jetzt noch auffällt, dass das Argument ein Pointer war, hast du den Fehler, der in besagter Zeile 9 gemacht wurde, auch schon gefunden.

Das fällt kaum noch ins Gewicht. Scanf ist es egal, ob es einen int* oder einen int** bekommt. Eine von den Variablen Namens 'zahl' muss verschwinden, sonst funzt es nicht.

Quatsch, mal wieder.

[DirkB]

Fricky667 schrieb:

Naja, ein schlauer Compiler würde schon merken, dass das Argument nicht zur Formatspezifikation passt (müsste bei int** IMHO %p sein).

Der Compiler meldet das auch, wenn man ihn läßt.

Und man muss dann auch die Warnungen beachten, sie wie Fehler behandeln und deren Ursache beseitigen - was man immer tun sollte.