zeiger als Rückgabewert einer Funktion

paloncino

Hallo,
ich möchte einen Zeiger von einer Funktion zurückgeben lassen. Ich dachte mir das so:

int* testFunction();

int main()
{
int* pPointer;
pPointer=testFunction();
return 0;
}

int* testFunction()
{
int zahl = 5:
int* pPointer;
pPointer= &zahl;
return pPointer;
}

Mal beiseite gelassen, wie sinnvoll das Programm ist es geht mir nur um die Technik, wie man einen Pointer zurückgibt aus einer Funktion. So wie beschrieben geht's ja nit ,gell.
Kann den Code jemand berichtigen bitte. Das wäre super.
Danke
paloncino

TGGC

Geht schon, der Zugriff auf den Speicher hinter dem Pointer ist allerdings nur während der Lebensdauer von zahl erlaubt.

Bye, TGGC (Denken, und gut ist.)

paloncino

Hallo TGGC,

danke für die Antwort
Du hast recht, man soll ja auch keine lokalen Variablen aus Funktionen als Zeiger zurückgeben. Mach ich auch nit, es sollte nur als simples Beispiel dienen. Das komische ist, ich hab den Code hier im Forum getippt und gar nicht ausprobiert, weil ich sicher ar, er funktioniert nicht. Dabei funktioniert er doch. Klasse
Ich habe noch eine andere Frage, vielleicht kannst du mir da auch helfen?
Ich hab das in einem anderen Zusammenhang schon einmal hier gefragt, aber keine befriedigende Antwort erhalten. Es geht um die Aufteilung der klassen in einem C++ Programm. Laut Lehrbuch soll man die klassen aufteilen in drei Dateien. In den Header die Deklaration, also z.B die Prototypen der Methoden, in eine cpp Datei die Implementierung, also den eigentlichen code und natürlich die klasse, die dann schließlich die besagte Klasse nutzt.
Warum teilt man so arg auf? Damit anderen Programme oder Teile die Klassen auch nutzen können, das ist mir schon klar, aber warum nicht nur eine Datei, in der Deklaration und Implementierung drin stehen? Dann wäre doch auch alles nutzbar für andere klassen? Warum wird in den Header Dateien "nur" deklariert und nicht definiert? Weisst du das?

Grüße

paloncino

CarstenJ

paloncino schrieb:

Dabei funktioniert er doch. Klasse

Das ist es ja eben nicht. Du kannst dich nicht drauf verlassen, dass der Code funktioniert, denn es wird auf einen Speicherbereich zugegriffen, der nicht mehr gültig ist.

Warum teilt man so arg auf? Damit anderen Programme oder Teile die Klassen auch nutzen können, das ist mir schon klar, aber warum nicht nur eine Datei, in der Deklaration und Implementierung drin stehen? Dann wäre doch auch alles nutzbar für andere klassen? Warum wird in den Header Dateien "nur" deklariert und nicht definiert? Weisst du das?

Das hat vor allem was damit zu tun, dass du Abhängigkeiten weitesgehend vermeidest. Wenn du alles schön aufteilst, dann musst nicht alles neukompilieren, sondern u. U. nur den Teil, den du geändert hast. Übersichtlicher wird es dadurch zudem auch noch.

paloncino

Hallo Carsten,

ja, ich weiss. Deswegen schrieb ich ja, man soll nicht lokale Variablen in Funktionen mit Zeigern zurückgeben. Es diente nur als einfaches Beispiel. Mit "es funktioniert" meinte ich nicht die Programmlogik, sondenr die Syntax, um Zeiger zurückzugeben.
Zum Thema Klassen aufteilen. Das versteh ich schon. Aber trotzdem fände ich es irgendiwe logischer, Deklaration und Definition zusammen in einer Datei zu haben. Gibt es noch einen technischen Grund, warum man derart aufteilt? Anders gefragt...ist es schlechter Stil, Deklaratin und definition in den header zusammenzuschreiben?

paloncino

CarstenJ

Gibt es noch einen technischen Grund, warum man derart aufteilt? Anders gefragt...ist es schlechter Stil, Deklaratin und definition in den header zusammenzuschreiben?

Ja, denn manchmal braucht man nur die Deklaration einer Klasse, so dass man eben nur die Headerdatei einbinden braucht. Eben genau das minimiert die Abhängigkeiten. Für Streams gibt es extra eine Headerdatei <iosfwd>, die genau dann sinnvoll ist, wenn du die Implementation nicht benötigst.

paloncino

Hallo Carsten,

das Argument überzeugt mich zu 100%. Es ist nur...wann gibt es denn diesen Fall, dass man nur die Deklaration braucht und nicht die Implementierung? Das hiesse ja, man holt sich nur die Schnittstelle ins "Boot". Was hat man davon dann ,wenn man nicht den Code nutzen kann? Wenn du dafür eine Erklärug hast, hast du mich wirklic hein ganzes Stück weitergebracht

paloncino

int* testFunction() 
{ 
static int zahl = 5;
static int* pPointer; 
pPointer = &zahl; 
return pPointer;
}

sowas wäre dann sinnvoll;-)

weitere infos: http://tutorial.schornboeck.net/referenz_return.htm

cu

CarstenJ

Hallo,

es gibt Funktionen, die müssen nur wissen, um was für ein Objekt es sich handelt und nicht, ob und wie es implementiert ist:

#ifndef STUDENT_H
#define STUDENT_H

class student{
public:
    student(){};
    void ausgabe();
};
#endif

#include <iostream>
#include <vector>

#include "student.h"

using namespace std;

int main()
{
    student Student;
    student Student2;
    student Student3;

    vector<student> vecStudent;

    vecStudent.push_back(Student);
    vecStudent.push_back(Student2);
    vecStudent.push_back(Student3);

    cout << vecStudent.size() << endl;

    //vecStudent[0].ausgabe(); // Das geht nicht ohne Implementation...
}

Ob sinnvoll ist oder nicht, aber u. U. brauchst die Implemntation nicht, so wie oben. Es existiert nichtmal eine, dennoch kannst du die Studenten in den Vector packen. Sobald du natürlich auf eine Memberfunktion zugreifen willst, musst du wissen (oder der Kompiler bzw. Linker) wie die Funktion aussieht und wo sie zu finden ist. Bei Einzeilern (wie z. B. dem Konstruktor) macht man ne Ausnahme, weil die nicht so gravierend groß sind.

net 0

man kann aber auch definition und implementierung in ein einziges .h-file packen. vielleicht ist für dich java oder c# das richtige. da wird 'ne 'class' immer in eine datei geschrieben.

paloncino

Hallo Carsten,
so langsam entsteht ein Gefühl für ein derartiges vorgehen. Ich weiss schon ,was du meinst. wie immer, wird man sicherer, indem man einfach programmiert, das ersetzt alle Theorie nicht. Trotzdem möchte ich die dinge auch verstehen, die ich mache. Da hast du mir auf jeden fall weiter geholfen. Danke
Natürlich auch die Schreiber der anderen kommentare. Danke euch

paloncino