Feedback: Socket-Klasse

EnginEx

Wenn ich das jetzt auf Linux portieren wollen würde, dann müsste ich doch bei fast jeder Methode sowas machen, oder?

#ifdef OS_WINDOWS
   // Windows Code
#else
  // Linux, Mac, whatever
#endif

Gibt es da auch eine elegantere Methode?

cooky451

EnginEx schrieb:

Wieso? Für eine optimale Kapselung? Ist das später nicht eher hinderlich, wenn ich meine Socket-Klasse mal in Threads nutzen möchte?

Nein, wie kommst du denn da drauf?

EnginEx schrieb:

Habe da jetzt einen std::string genommen, reicht meiner Meinung nach vollkommen aus.

Ein Socket der nur Strings empfangen kann, ja, sehr sinnvoll.

Dass du in deiner swap Funktion einen neuen Socket erstellst, macht auch keinen Sinn. Der Gag an einer swap Methode ist eigentlich, dass du einfach die handels tauschst. Also:

socket::swap(socket& rhs)
{
  std::swap(handle_, rhs.handle_);
}

Vorausgesetzt deine Klasse hat nur ein handle als Member - was recht sinnvoll ist.

EnginEx

cooky451 schrieb:

Nein, wie kommst du denn da drauf?

Naja, angenommen in einem Thread wird die connect()-Methode mit entsprechenden Parametern aufgerufen. Daraufhin wird u.a. in sockAddr der Port und Host gespeichert. Wenn nach dem setzen und vor dem connect()-Aufruf in einem anderen Thread genau das gleiche mit anderem Port/Host geschieht und in sockAddr gespeichert wird verbindet sich Socket 1 nun woanders hin als ursprünglich gewollt, oder nicht?

cooky451

EnginEx schrieb:

cooky451 schrieb:

Nein, wie kommst du denn da drauf?

Naja, angenommen in einem Thread wird die connect()-Methode mit entsprechenden Parametern aufgerufen. Daraufhin wird u.a. in sockAddr der Port und Host gespeichert. Wenn nach dem setzen und vor dem connect()-Aufruf in einem anderen Thread genau das gleiche mit anderem Port/Host geschieht und in sockAddr gespeichert wird verbindet sich Socket 1 nun woanders hin als ursprünglich gewollt, oder nicht?

Nö, jeder "Aufruf" einer Funktion bekommt seine eigenen lokalen Variablen. Wie sollte sonst rekursion funktionieren? "Thread sicherer" als lokale Variablen geht nicht. Aufpassen musst du da gerade bei nicht lokalen Variablen.

EnginEx

Dann verstehe ich aber nicht, was es bringen soll die sockaddr_in etc. zu lokalen Variablen zu machen. Ich sehe da keinerlei Vorteil, eher einen Nachteil, da direkt darauf zugegriffen werden kann.

Kellerautomat

Wozu braucht der Socket ueberhaupt die anderen Member als das Handle? Die sind fuer die Identifikation irrelephant.

cooky451

EnginEx schrieb:

Ich sehe da keinerlei Vorteil,

Sie sind lokaler und liegen nicht die ganze Zeit sinnlos im Speicher rum?

EnginEx schrieb:

eher einen Nachteil, da direkt darauf zugegriffen werden kann.

Hä? Erklär mal.

EnginEx

Vergesst alles was ich gesagt habe. Missverständnis meinerseits, irgendwie dachte ich bei lokalen Variablen an sowas:

namespace network {

   struct sockaddr_in sockAddr;
   struct hostent     *host;

   bool startWSA();
   void stopWSA();

   class Socket { /* ... */ };
}

... was natürlich Blödsinn ist. Sorry.

TyRoXx

cooky451 schrieb:

EnginEx schrieb:

Habe da jetzt einen std::string genommen, reicht meiner Meinung nach vollkommen aus.

Ein Socket der nur Strings empfangen kann, ja, sehr sinnvoll.

Ein string ist wie ein vector<char> eine Folge von Bytes. Was kann man denn außer Bytes noch empfangen?

TyRoXx schrieb:

cooky451 schrieb:

EnginEx schrieb:

Habe da jetzt einen std::string genommen, reicht meiner Meinung nach vollkommen aus.

Ein Socket der nur Strings empfangen kann, ja, sehr sinnvoll.

Ein string ist wie ein vector<char> eine Folge von Bytes. Was kann man denn außer Bytes noch empfangen?

Man kann es evtl. nur anders interpretieren (z.B. als int, double,...), aber das geht mit einem std::string(buf, len) auch.

cooky451

TyRoXx schrieb:

Ein string ist wie ein vector<char> eine Folge von Bytes. Was kann man denn außer Bytes noch empfangen?

Ein std::string modelliert einen String. Ein vector<char> modelliert eine Folge von char. Wenn ich eine Folge von char/byte empfangen will, nehme ich einen vector<char>.
Und nein, ein String ist semantisch nicht das gleiche wie eine Folge von char.