Arbeiten mit Unterprogrammen (quadrieren)

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.

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.