Problem mit überladener Methode

camper

mr-bigman schrieb:

igendwo in einer anderen Fkt./Klasse steht folgender Aufruf:
[cpp]
CMessage Message;
...
...
bRetVal = SendMessage("192.168.178.10", 5036, Message);
...
...
[/cpp]

Wenn das keine Funktion der Klasse CMessage ist, stellt das allerdings auch mit Sicherheit keinen Aufruf einer Memberfunktion von CMessage dar.

Simon2

Hi,

Kurze Vorabbemerkung1: Bezeichner sollten nicht mit "_" anfangen. Da kommt man sich schnell mit Compilerinternen Bezeichnern in die Quere.

Kurze Vorabbemerkung2: Mit cpp-Tags braucht man keine code-Tags mehr

@Style:

mr-bigman schrieb:

...ich habe in meiner Klasse 6 Methoden überladen ...

Das würde ich einfach auch nicht machen.
Da wird man ja weich, weil man jedesmal die Schnittstelle seiner Klasse ändern muss, sobald ein neuer Typ dazukommt.

Wenn Du schon nicht jedesmal eine Konvertierungsfunktion aufrufen möchtest, würde ich eine entspechende "Zwischenklasse" schreiben (wie heißt eigentlich Deine "Klasse mit SendMessage()" ?):

public:
    bool SendMessage(string strDestinationIPAddress, int iDestinationPort, SendableObject message);
};

struct SendableObject {
   string message; // Passt alles rein
   SendableObject(string const& s) : message(s) {} // char* brauchst Du dann auch nicht mehr
   SendableObject(CMessage const& MessageToSend); // Pointerversion brauchst DSu auch nicht mehr
   SendableObject(int numberToSend);
   SendableObject(double numberToSend);
   SendableObject(long numberToSend);
};

Oder mittels templates noch einfacher als:

struct SendableObject {
   string message; // Passt alles rein
   template <typename T>
   SendableObject(T const& m) {
      ostringstream ost;
      ost << m;
      message = ost.str();
   }
};

Damit ist alles konvertierbar, was einen operator<<() definiert hat.

Oder sogar noch direkter kannst Du Deine Klasse von ostream ableiten und entsprechende Funktionen überschreiben. Dann könntest Du "kanonisch auf den Stream" schreiben... (aber das vielleicht erst im nächsten Schritt).

@Topic: Ich kenne leider den Typ "CMessage" nicht, vermute aber, dass im Call nicht wirklich dieser Typ vorliegt (oder nicht wirklich die "long-Version" aufgerufen wird). Eigentlich funktioniert das Overloading in C++ ziemlich zuverlässig.
Lästig wird's eigentlich erst bei impliziten Konvertierungen (via CTor oder Konvertierungsoperatoren) ... da ich mir aber nicht vorstellen kann, dass long einen CMessage-Konvertierungsoperator hat, gehe ich nicht davon aus...

Gruß,

Simon2.

Die Methoden SendMessage(...) gehören zur Klasse "CUdpIO" und der Aufruf erfolgt natürlich über ein instantiiertes Objekt von "CUdpIO" a al:

[cpp]
...
CUdpIO* pUdpIO = new CUdpIO(...);

bRetVal = pUdpIO->SendMessage(...);

[/cpp]

Die Klasse "CMessage" ist ein sog. Transporter-Objekt hier kommen die eigentlichen Nutzdaten und noch zusätzliche Headerinformationen hinein die ich beim Empfang der Nachricht benötige...

CStoll

Und wie stellst du fest, daß die "falsche" Methode aufgerufen wurde?

(btw, ich würde auch Simon's Ansatz vorziehen - gib der Klasse CMessage die nötigen Konstruktoren, um aus einem String oder einer Zahl zusammengebaut zu werden, dann brauchst du nur noch die CMessage-Version der Methode)

1. ich sehe im Debugger, in welche Methode er gerade hineinspringt und
2. sagen mir das mein Debug-Meldungen

Simon2

mr-bigman schrieb:

...
Die Klasse "CMessage" ist ein sog. Transporter-Objekt hier kommen die eigentlichen Nutzdaten und noch zusätzliche Headerinformationen hinein die ich beim Empfang der Nachricht benötige...

Also gerade DAS spricht dafür, CUdpIO nur eine Sendmessage()-Funktion zu verpassen und die Konvertierungen CMessage (hat dann die Funktion, die ich mit "SendableObject" umgesetzt habe) zu überlassen.

Was macht Dein Programm denn, wenn Du CUdpIO die "long-Variante" (oder vielleicht sogar alle außer CMessage) wegnimmst ?
Ach ja: Ich würde auch folgende Signatur verwenden:

SendMessage(string const& destinationIPAddress, int destinationPort, CMessage const & messageToSend);

Spart Kopierarbeit (und damit evtl. verbundene Fehler).

Gruß,

Simon2.

camper

Wie sehen denn die vollständigen Definitionen von CUdpIO und CMessage sowie der Aufruf von SendMessage exakt aus?

also wenn ich die long-Variante entferne, läuft's wie gewünscht. Das ist ja das Ding, ich würde gerne wissen warum sich das Prog so verhält??!
ok, vielen Dank für den Vorschlag mit "SendableObject" etc. ich werde es im Team vorschlagen bzw. hatte soetwas in der Art auch schon implementiert gehabt...aber trotzdem möchte ich gerne herausfinden warum das ganze jetzt SO WIE ES IST nicht läuft? bzw. falsch läuft..

Simon2

mr-bigman schrieb:

...
ok, vielen Dank für den Vorschlag mit "SendableObject" etc. ...

Naja, eigentlich hast Du das schon und heißt CMessage.

mr-bigman schrieb:

...aber trotzdem möchte ich gerne herausfinden warum das ganze jetzt SO WIE ES IST nicht läuft? bzw. falsch läuft..

Zeig doch dazu mal Deinen CMessage-Code (nur die Klassendeklaration).

Gruß,

Simon2.

hallo Simon,
hier ist der Quelltextausschnitt:

class CMessage
{
public:

    CMessage(enumMESSAGETYPE _MESSAGETYPE = msgEMPTY);
    CMessage(CMessage& _Message);
    ~CMessage(void);
    void Copy(CMessage& _Message);
    CMessage& operator=(CMessage& _MessageToCopy);

private:
...
//Setter/Getter
};