folgende Aufgabenstellung habe ich erhalten:

Schreiben Sie ein Programm mit einer Funktion produkt(). Die Funktion produkt soll 2 int
Argumente haben und einen Rückgabewert vom Typ int. Sie soll das Produkt der
übergebenen Parameter berechnen und als Rückgabewert zurückgeben. Demonstrieren
Sie die Funktionalität, indem Sie die Parameter von der Tastatur einlesen und das
Ergebnis auf der Konsole ausgeben.

, die ich dann folgendermaßen interpretiert habe:

#include <iostream>

using namespace std;

void produkt(int a1, int a2);
int rueckgabe;

void produkt(int a1, int a2)
{
    cout << "Zahl 1 eingeben: " << endl;
    cin >> a1;
    cout << "Zahl 2 eingeben: " << endl;
    cin >> a2;
    rueckgabe = a1*a2;
    cout << "Ergebnis: " << rueckgabe << endl;
}

int main()
{
    produkt();
    return 0;
}

Leider klappt das nicht, so wie ich es will. Kann natürlich sein, dass ich die Aufgabe nicht verstanden habe.

Am besten nochmal das Kapitel über die Funktionen lernen Der Rückgabewert ist der Wert, der von der Funktion selbst zurückgegeben wird (lol?!). Wär dieser "void" also "leer", dann würde die Funktion nichts zurückgeben (meistens bei Ausgaben von Texten). Bei dieser Funktion (produkt) gibst du den Wert zurück, der duch die Multiplikation der beiden Parameter berechnet wird. Bei einer Division bekommt man meistens eine Kommazahl heraus, weshalb man dort rein logisch einen Rückgabetyp von "float" bzw. "double" festlegen muss/kann.
Außerdem macht man das normalerweise so, dass man die Definition einer Funktion hinter die "main" Funktion macht. Die Deklaration vor der "main" Funktion. Ist allgemeiner Programmierstil

Außerdem macht man das normalerweise so, dass man die Definition einer Funktion hinter die "main" Funktion macht. Die Deklaration vor der "main" Funktion. Ist allgemeiner Programmierstil

Eigentlich eher nicht. Das ist Jürgen Wolfs Stil.

WeißIkNet schrieb:

Außerdem macht man das normalerweise so, dass man die Definition einer Funktion hinter die "main" Funktion macht. Die Deklaration vor der "main" Funktion. Ist allgemeiner Programmierstil

Eigentlich eher nicht. Das ist Jürgen Wolfs Stil.

Hm ok, ich habs aber auch so gelernt

Hm ok, ich habs aber auch so gelernt

Naja, im Prinzip ist es müßig, da man das sowieso nur bei Programmen < 100 Zeilen überhaupt so macht, daher kann man nicht wirklich von allgemeinem Stil reden. Mir ist nur aufgefallen, dass die JW-Schüler es so machen und sonst nur sehr wenige Leute. Und es ist halt total sinnlos und macht nur mehr zu schreiben.

Lies nächstes Mal die Compilerfehler durch. Dann können solche Fehler in der Regel nicht passieren.

Wenn du die Ausgabe außerhalb der Funktion haben willst, kannst dann halt

return a1*a2

in die Funktion schreiben.

-Gruß P_T

WeißIkNet schrieb:

Hm ok, ich habs aber auch so gelernt

Naja, im Prinzip ist es müßig, da man das sowieso nur bei Programmen < 100 Zeilen überhaupt so macht, daher kann man nicht wirklich von allgemeinem Stil reden. Mir ist nur aufgefallen, dass die JW-Schüler es so machen und sonst nur sehr wenige Leute. Und es ist halt total sinnlos und macht nur mehr zu schreiben.

Naja, das kommt wohl von früheren Tagen her, da machte das durchaus Sinn.

Denn der Compiler konnte so schneller die Funktionsdeklarationen zusammenfassen und wußte bei der Main schon was los war, d.h. er mußte bis zur main weniger Parsen.
Das beschleunigte wohl die Compilezeit.
Und bei begrenztem Arbeitsspeicher half die schnelle knappe Zusammenfassung auch sicher.

Heutzutage ist das aber total sinnlos. Denn man merkt auf heutigen Rechnern da keinen Geschwindigkeitsunterschied mehr.

SeppJ schrieb:

WeißIkNet schrieb:

Hm ok, ich habs aber auch so gelernt

Naja, im Prinzip ist es müßig, da man das sowieso nur bei Programmen < 100 Zeilen überhaupt so macht, daher kann man nicht wirklich von allgemeinem Stil reden. Mir ist nur aufgefallen, dass die JW-Schüler es so machen und sonst nur sehr wenige Leute. Und es ist halt total sinnlos und macht nur mehr zu schreiben.

Naja, das kommt wohl von früheren Tagen her, da machte das durchaus Sinn.

Denn der Compiler konnte so schneller die Funktionsdeklarationen zusammenfassen und wußte bei der Main schon was los war, d.h. er mußte bis zur main weniger Parsen.
Das beschleunigte wohl die Compilezeit.
Und bei begrenztem Arbeitsspeicher half die schnelle knappe Zusammenfassung auch sicher.

Heutzutage ist das aber total sinnlos. Denn man merkt auf heutigen Rechnern da keinen Geschwindigkeitsunterschied mehr.

PS:
Aus ähnlichem Grund gab es auch die Headerdateien.

Das macht keinen Sinn. Wenn alles in einer Datei steht, dann wird auch alles Verarbeitet. Dann greift das Prinzip der Header eben gerade nicht mehr.

Man kann auch nur bis zur main Funktion suchen, genau deswegen sollten damals die Funktionsdeklarationen ja auch über der main stehen.

Allerdings schreibe ich selten ein Programm ausschließlich in der main(), das kommt eher bei Testanwendungen vor, wo es dann ohnehin quick and dirty um eine Idee geht, die ich außerhalb des Projektes testen will.

Wenn Du jedoch die Fehlermeldng des Compilers nicht versteht, probiere es mal mit einem Grundlagenbuch.

mfg Martin

Ich verstehe Dich nicht. Der Compiler sagt Dir doch schon selber, was ihm nicht passt. Meinst Du, Du kannst durch Einholen einer zweiten Meinung hier im Forum den Compiler davon überzeugen, daß Du recht hast?

Wenn Du jedoch die Fehlermeldng des Compilers nicht versteht, probiere es mal mit einem Grundlagenbuch.

mfg Martin

Auf welchen Posting bezieht sich dein Kommentar?? Nächstes Mal bitte Zitate verwenden oder zumindest den Autornamen hinschreiben.

Auf welchen Posting bezieht sich dein Kommentar?? Nächstes Mal bitte Zitate verwenden oder zumindest den Autornamen hinschreiben.

Stimmt. Sorry, ich vergaß, die hier verwendete Forensoftware zeigt das nicht an. Ich bezog mich auf die erste Nachricht.

mfg Martin

Dieser Programmierstil wird auch von manchen praktiziert, die nicht unbedingt die JW-Schule besucht haben. Er wird auch in guten Grundlagebüchern vorgestellt und nahegelegt. Ich stimme SeppJ zu, dass das nicht unbedingt das Gelbe vom Ei ist, aber das soll zum Einen dem Compiler helfen, die Funktionsaufrufe und -definitionen schneller zu überprüfen, zum Anderen ist es nicht schlecht, wenn main() als Erstes steht, weil es die Struktur des Programms vorgibt. So die Theorie.

Bei mir ist main immer das Letzte. Dadurch spare ich mir die Prototypen der aufgerufenen Funktionen, wernn sie im gleichen Modul sind. Schneller ist der Compiler übrigens auch nicht, wenn main als erstes steht. Denn dann muß er sowohl die Prototypen als auch die Funktionsdefinitionen parsen.

mfg Martin

Grüße,
Rew.