3. [GELÖST] Klassenmember mit Objektpointer im Parameter und Return

[GELÖST] Klassenmember mit Objektpointer im Parameter und Return

  • V

    Hi,

    ich habe folgende Situation:

    class Request {
    ...
    Response* respond() { ... }
};

class Response {
    ...
    void send() { ... }
};

class Server {
    void doAccept() {
        this->onAccept(new Request(...))->send();
    }

    virtual Response* onAccept(Request* request) {
        // z.B.
        return request->respond();
    }
};

    Der Compiler (G++) beschwert sich heftigst:

    (Bezogen auf den Codeausschnitt oben Zeile 16:
    error: expected ';' at end of member declaration
    error: expected ')' before '*' token

    Das Serverobjekt erstellt also eine Request aus den empfangenen Daten und antwortet mit einem Response Objekt.

    Das ganze soll virtual sein, weil der Server nur ein Basisimplementierung sein soll und für den Eigentlichen Anwendungsfall abgeleitet werden soll.

    Ich bin auch auf die Idee gekommen, einfach einen funktionspointer zu setzen, anstatt abzuleiten.

    Aber einerseits passt das nicht ins Konzept und andererseits will ich wissen, wie ich genau diese Situation löse. Immerhin will ich auch was dazu lernen und nicht irgendein workaround suchen.

    Vielen Dank für Hilfe

    Der Verzweifelte

    0
  • T

    Auf den ersten Blick fehlen die ; am Ende der Klassen.

    0
  • V

    tommy_tom_tom schrieb:

    Auf den ersten Blick fehlen die ; am Ende der Klassen.

    ^^ Schlaupuper 😉 Danke. Habs mal hinzugefügt.
    Der Code ist nur ein Ausschnitt, halb Copy'n'Paste, halb ausm Kopf, dass nur der wesentliche Teil hier steht.

    Edit: Auch im Originalcode von mir sind die ;, keine Sorge, hab paranoider Weise nochmal geschaut ^^

    0
  • T

    Tja 😃 ... Aber wie soll man dazu was sagen, wenn der Code nichtmal dem Original entspricht?

    0
  • V

    tommy_tom_tom schrieb:

    Tja 😃 ... Aber wie soll man dazu was sagen, wenn der Code nichtmal dem Original entspricht?

    Prinzipiell ist es das Original. Nur das alles unwesentliche weggelassen ist (Namespaces, andere Member usw.) und der Teil ausm Kopf z.B. das class {} war, daher auch ohne ;, in eclipse hab ich nen Template damit ich's net vergess 🤡

    EDIT: mobilophon autovervollständigungs zeugs -.-

    0
  • T

    Schick doch mal den original Code und die ganze Fehlermeldung wenn dus zur Hand hast - ich seh da nix.

    An was schreibstn da überhaupt?
    Grübel selbst grad an Netzwerk rum...

    Gruss

    0
  • V

    Viel mehr gibts in dem Teil der Bibliothek noch nicht, WEIL gerade dieses Problem vorherrscht *g* Aber hier mal der Originalcode:

    #ifndef HTTP_H_
#define HTTP_H_

#include <Base.h>

#include <Network.h>

#include <Network/HTTP/Response.h>
#include <Network/HTTP/Request.h>
#include <Network/HTTP/Server.h>

#endif /* HTTP_H_ */

    #ifndef REQUEST_H_
#define REQUEST_H_

#include <Network/HTTP.h>

namespace Network {

namespace HTTP {

class Response;

class Request : public Object {
	DEFAULT_OBJECT_GETCLASSNAME("Network::HTTP", "Request")

public:
	enum Method {
		GET,
		POST,
		HEAD,
	};

private:
	Method method;

public:
	Request();

	Request(ByteBuffer* buffer);

	Request(Connection* client);

	Request(const Request& other);

	~Request();

private:
	void parseBuffer(ByteBuffer* buffer);

public:
	Response* respond() const {
		return new Response();
	}
};

}  // namespace HTTP

}  // namespace Network

#endif /* REQUEST_H_ */

    #ifndef RESPONSE_H_
#define RESPONSE_H_

#include <Network/HTTP.h>

namespace Network {

namespace HTTP {

class Response : public Object {
	DEFAULT_OBJECT_GETCLASSNAME("Network::HTTP", "Response")

private:

public:
	Response();

	Response(const Response& other);

	~Response();

public:
	void send();
};

}  // namespace HTTP

}  // namespace Network

#endif /* RESPONSE_H_ */

    #ifndef SERVER_H_
#define SERVER_H_

#include <Network/HTTP.h>

namespace Network {

namespace HTTP {

class Server : public Object {
	DEFAULT_OBJECT_GETCLASSNAME("Network::HTTP", "Server")

private:
	EndPoint *ep;
	Listener *listener;

public:
	Server();

	Server(EndPoint* ep);

	virtual ~Server();

public:
	void doListen() {
		this->listener = new Listener();
		this->listener->doListen(this->ep);

		this->onAccept(new Request(this->listener->doAccept()))->send();
	}

	virtual Response* onAccept(Request* request) const {
		return request->respond();
	}
};

}  // namespace HTTP

}  // namespace Network

#endif /* SERVER_H_ */

    Hilft nicht wirklich weiter, oder? ^^
    Die *.cpps sind bisher leer, also enthalten nur leere Methoden, der Code bisher ist in den Headern wie du oben siehst (dammit ich nicht ständig zwischen H und CPP umschalten muss.
    Aufrufe aus einer Main gibt es noch nicht, wird aber sowas wie

    Server *s = new MyServer(new EndPoint((char*)"0.0.0.0", 80, EndPoint::TCP))->doListen()

    wobei MyServer

    class MyServer : public Server {
	Response* onAccept(Request* request) const {
		// Hier der code der abgeleiteten klasse was mit der HTTP Anfrage passieren soll, die Response generieren und zurückgeben (das ->send() macht Server())
	}
}

    sein wird. Der Code fehlt aber auch noch weil ich erst dieses Problem loswerden will *g*

    Wie man sieht, es soll eine einfache synchrone HTTP Infrastruktur werden auf der ich aufbauen will.

    Hilft dir das?

    0
  • C
    Mod

    zirkuläre inkludes

    ... hatten wir das nicht eben schon mal?

    0
  • V

    camper schrieb:

    zirkuläre inkludes

    ... hatten wir das nicht eben schon mal?

    Nicht hier. Und zirkulär trotz der #ifdef? Erklärung bitte 😉

    0
  • C
    Mod

    Verzweifelter schrieb:

    camper schrieb:

    zirkuläre inkludes

    ... hatten wir das nicht eben schon mal?

    Nicht hier. Und zirkulär trotz der #ifdef? Erklärung bitte 😉

    Stimmt, war hier. Include Guards verhindern das mehrfache Einbinden eines Headers, falls dieser mehrfach im Include-Graph vorkommt. Sie lösen nicht auf magische Weise gegenseitige Abhängigkeiten auf, die dein Code enthält. Und im Falle gegenseitiger Abhängigkeiten hängt die endgültige Reihenfolge davon ab, welcher Header zuerst eingebunden wird. Die zirkuläre Abhängigkeit muss nicht weiter erläutert werden: alle Header inkludieren, http.h, http.h inkludierte jeden Einzelheader...

    0
  • T

    HaHa

    Sorry, ich mag Nelson sein Art 😉

    0
  • V

    camper schrieb:

    Stimmt, war hier. Include Guards verhindern das mehrfache Einbinden eines Headers, falls dieser mehrfach im Include-Graph vorkommt. Sie lösen nicht auf magische Weise gegenseitige Abhängigkeiten auf, die dein Code enthält. Und im Falle gegenseitiger Abhängigkeiten hängt die endgültige Reihenfolge davon ab, welcher Header zuerst eingebunden wird. Die zirkuläre Abhängigkeit muss nicht weiter erläutert werden: alle Header inkludieren, http.h, http.h inkludierte jeden Einzelheader...

    Dank dir. Ich glaube da war ein kleines Missverständnis zwischen mir und dem wie Includes funktionieren.

    Ich wollte alles möglichst übersichtlich halten und habe dadurch den Compiler bzw. Precompiler wohl verärgert.

    Ich habe meine Konstrukte wie die HTTP.h entfernt und include in jeder datei genau das was sie zum funktionieren braucht, anstatt einfach diese gobale header einzubinden und schon löst sich das problem in Luft auf.

    Server.h includes Request.h, Response.h
    Request.h includes Response.h
    und mein Programm includes einfach alle 3 weil ich dort gleichzeitig mit allen 3en arbeite und schon läuft es.

    Das eigentliche Problem war also nicht das Konstrukt

    Response* onAccept(Request* request) {
		return request->respond();
	}

    **

    Sondern mein Pfusch bei den includes.**

    Danke für die Erleuchtung 🙂

    0
Anmelden zum Antworten