4. COLORREF to char*- gibt's was schnelleres als stringstreams?

COLORREF to char*- gibt's was schnelleres als stringstreams?

  • A

    beim Rückkonvertieren macht das aber hofentlich nichts aus oder?

    ok aber wie kriege ich jetzt die empfangenen bytes wieder nach COLORREF?

    wenn ich nur immer einen colorref-wert sende wäre es klar:

    COLORREF recieved;
char* a=new char[sizeof(COLORREF)];
recv(socket, reinterpret_cast<COLORREF>(a), sizeof(recieved), 0);

    aber wie mache ich das jetzt wenn ich den bei send() nach char* gecasteten vektor wieder als COLORREF haben will?

    so?:

    vector<COLORREF> zeile;
char* a=new char[sizeof(COLORREF)];
recv(socket, reinterpret_cast<COLORREF>(a), sizeof(recieved), 0);
    0
  • ?

    Du benutzt die Variable "zeile" gar nicht 😕

    Wenn immer ein send und recv zusammengehören (kA, hab damit nix am Hut), dann einfach:

    // send
unsigned long color;
send(socket, reinterpret_cast<const char*>(&color), sizeof(unsigned long), 0);

// receive
unsigned long color;
recv(socket, reinterpret_cast<char*>(&color), sizeof(unsigned long), 0);
    0
  • Z

    Checker! schrieb:

    Du benutzt die Variable "zeile" gar nicht 😕

    Wenn immer ein send und recv zusammengehören (kA, hab damit nix am Hut), dann einfach:

    // send
unsigned long color;
send(socket, reinterpret_cast<const char*>(&color), sizeof(unsigned long), 0);

// receive
unsigned long color;
recv(socket, reinterpret_cast<char*>(&color), sizeof(unsigned long), 0);

    send(socket, reinterpret_cast<const char*>(&color), sizeof(unsigned long), 0);

    ... ein bisschen kurz die nachricht oder ?

    grüüße

    0
  • A

    ja klar, wenn ich nur einen COLORREF-Wert gleichzeitig senden würde könnte ich das so machen.

    das problem ist doch dass ich den vector<COLORREF> mit mehreren Werten einfach nach const char* gecastet und verschickt habe;

    d.h. ich kann das von recv() empfangene(nämlich mehrere COLORREF-Werte) doch nicht in eine COLORREF-Variable stecken 😕

    irgendwie muss das doch auch wieder in einen vector oder zumindest ein array...

    edit: davon mal ganz abgesehen kann ich nicht einfach einen vector nach char* casten, der Kompiler sagt nämlich selbst bei einem reinterpret_cast eine Lonvertierung sei unmöglich.

    obige Möglichkeit zum Senden ist demnach falsch. muss ich also jedes einzelne element des vektor extra casten und senden oder wie geht das dann?

    also meine Lösung würde momentan so aussehen:

    //send:
for(int y=0;y<1500;y++)
{
for(int x=0;x<1500;x++)
{
COLORREF farbe=GetPixel(GetDC(0), x, y);
send(socket, reinterpret_cast<const char*>(farbe), sizeof(COLORREF), 0);
}
}

//recv:
for(int y=0;y<1500;y++)
{
for(int x=0;x<1500;x++)
{
COLORREF farbe;
char* empfangen=new char[sizeof(COLORREF)];
recv(socket, empfangen, sizeof(COLORREF), 0);
farbe=reinterpret_cast<COLORREF>(farbe);
}
}

    stimmt das dann so?

    0
  • ?

    Lies noch mal die letzten beiden Beiträge von @hustbaer.

    zB.

    // send
unsigned long colors[3] = { 1, 2, 3 };
send(socket, reinterpret_cast<const char*>(colors), sizeof(colors), 0);

// receive
unsigned long colors[3];
recv(socket, reinterpret_cast<char*>(colors), sizeof(colors), 0);
    0

  • in meinem code hat noch ein reinterpret_cast gefehlt, sowie ein vertipper war drin. hab ich nachgetragen sowie noch ein paar kommentare hinzugefügt.

    und flags ist üblicherweise 0 für alle die sich wundern was sie da mitgeben sollen.

    @Checker!:
    siehe nachgetragenes kommentar vor der recv()-schleife: die braucht man, sonst bekommt man (schwer zu debuggende) probleme. recv() wartet nämlich nicht bis "size" bytes empfangen wurden, sondern kommt u.u. schon zurück nachdem erst ein byte empfangen wurde.
    -> schleife

    0

  • andi01 schrieb:

    edit: davon mal ganz abgesehen kann ich nicht einfach einen vector nach char* casten, der Kompiler sagt nämlich selbst bei einem reinterpret_cast eine Lonvertierung sei unmöglich.

    kauf dir ein C++ buch und lern erstmal die grundlagen.

    oder schreib wenigstens richtig ab:

    std::vector<MEIN_POD_TYP> vec;

v.push_back(MEIN_POD_TYP(1));
v.push_back(MEIN_POD_TYP(2));
v.push_back(MEIN_POD_TYP(3));

char* char_ptr = reinterpret_cast<char*>(&vec[0]); // so geht's
//char* char_ptr = reinterpret_cast<char*>(vec); // so nicht
    0
  • ?

    @hustbaer
    Achso, aber nur mit dem TCP, oder?

    0
  • A

    so, ich habe jetzt mal versucht hustbaers codebeispiel auf S.2 zu kompilieren, foo() funktioniert, bei bar() kommt aber noch ein Fehler vom Compiler in Z.44:

    MS Visual C++ 2008 EE schrieb:

    (44) : error C2440: '=': 'COLORREF' kann nicht in 'COLORREF [100]' konvertiert werden

    sollte wahrscheinlich cols[i] heißen 😉

    ich teste es mal schnell ob das senden jetzt geht

    0
  • Z

    @hustbÄR:

    Hi,
    ich habe schon öfters gesehen dass auf den datenbereich von STL Komponenten referenziert wird, man sollte aber nicht davon ausgehen dass der allocierte Speicherbereich von STL' komponenten in Reihe liegt. Sollte es nämlich zu einer höheren fragmentation des Heaps kommen, wäre die folge das bei der iteration deines gecasteten ptr'S ein bekanntes 0x00000005 kommt.

    Ansonsten braucht man auch kein reinterpret_cast, sondern kopiert ainfach die addresse von einem pointer zum anderen....(Wenn der inhalt nicht konvertiert werden soll...)

    Es gäbe aber noch eine Alternative:

    typedef	union _ta{
COLORREF _farbe;
char a[4];
} BLUB,*LPBLUB;

LPBLUB _sendMeBabY=(LPBLUB)malloc(12*sizeof(COLORREF));
_sendMeBabY[0]._farbe=0x0044444;
char* _Snd=(_sendMeBabY[0].a);
//Speicher bereich:
//a[0]= 0x44
//a[1]= 0x44
//a[2]= 0x04
//a[3] = 0x00

    Seid gegrüßt und einen schönen tag der Arbeit 😃

    0
  • ?

    @zeusosc
    So richtig hässlich!
    Es ist garantiert, dass die Elemente von std::vector im Speicher hintereinander liegen.

    0

  • zeusosc schrieb:

    @hustbÄR:

    Hi,
    ich habe schon öfters gesehen dass auf den datenbereich von STL Komponenten referenziert wird, man sollte aber nicht davon ausgehen dass der allocierte Speicherbereich von STL' komponenten in Reihe liegt. Sollte es nämlich zu einer höheren fragmentation des Heaps kommen, wäre die folge das bei der iteration deines gecasteten ptr'S ein bekanntes 0x00000005 kommt.

    Falsch. Der Standard garantiert dieses Verhalten, und alle STL Implementierungen die ich kenne setzen das auch korrekt um.

    Ansonsten braucht man auch kein reinterpret_cast, sondern kopiert ainfach die addresse von einem pointer zum anderen....(Wenn der inhalt nicht konvertiert werden soll...)

    Es gäbe aber noch eine Alternative:

    typedef	union _ta{
COLORREF _farbe;
char a[4];
} BLUB,*LPBLUB;

LPBLUB _sendMeBabY=(LPBLUB)malloc(12*sizeof(COLORREF));
_sendMeBabY[0]._farbe=0x0044444;
char* _Snd=(_sendMeBabY[0].a);
//Speicher bereich:
//a[0]= 0x44
//a[1]= 0x44
//a[2]= 0x04
//a[3] = 0x00

    Sinnloser Scheissendreck. Und AFAIK ist nichtmal garantiert dass es funktioniert.

    0
  • T

    Bezüglich "Union Hack":

    Sinnloser Scheissendreck. Und AFAIK ist nichtmal garantiert dass es funktioniert.

    Korrekt, das ist nicht garantiert. Garantiert ist nur dass lesen/schreiben von derselben Variable funktioniert.
    Simon

    0
  • Z

    Punkt a)
    Stimmt, ich habe den random access mit der alloc fkt verwechselt,.. sry

    template<class _Ty> inline
	_Ty _FARQ *_Allocate(_SIZT _Count, _Ty _FARQ *)
	{	// check for integer overflow
	if (_Count <= 0)
		_Count = 0;
	else if (((_SIZT)(-1) / _Count) < sizeof (_Ty))
		_THROW_NCEE(std::bad_alloc, NULL);

		// allocate storage for _Count elements of type _Ty
	return ((_Ty _FARQ *)::operator new(_Count * sizeof (_Ty)));
	}

    Punkt b)
    Mir wÄr unklar das das nicht funktionieren sollte,..
    Union == Überlappender Speicherbereich ?

    Und wenn ihr angst vor char a[4] habt weil sonst ja der ptr auf die addresse des wertes zeigt nemmt ihr halt vier char, davon abgesehen ist der Kompiler schlau genug den ptr des char array's auf den gleichen speicherbereich von der colorref variablen zu legen.

    Also nochmal die Frage: Warum sollte das nicht gehen?

    grüüße

    0
  • ?

    Weil der Standard sagt, dass es undefiniert ist.

    0

  • @zeusosc:
    Es funktioniert ja auch mit den meisten Compilern. Es wird nur vom Standard nicht vorgeschrieben dass es funktioniert. Und der Standard macht auch keine Vorschrift, dass die Implementierung (der Compiler) eine Aussage darüber treffen müsste was in dem Fall passiert.
    Das nennt man "undefined behaviour".

    Und ich verstehe nicht, warum man etwas einfaches wie einen reinterpret_cast durch etwas weniger einfaches ersetzen sollte, wenn beim weniger einfachen nichtmal garantiert ist dass es funktioniert.

    0
  • Z

    Ok,.. danke für die Antworten.

    Ich werde mich nochmal ein bisschen belesen zu diesem Thema,
    hätte aber gerade weil ich es reletiv häufig verwende wohl fälschlicher weise gedacht das eine union typ standard ist..

    Wiedermal was dazu gelernt 😃

    Thx und greetz

    0
  • T

    union ansich schon, bloss die oben erwähnte Art der Benutzung nicht.
    Simon

    0
  • ?

    Hi
    @andi1

    Lerne mal die Grundlagen verdammtnochmal. Dan wäre der scheiss den du hier fragst überflüssig. das sind alles Grundlagen. Wenigstens das sollte man können, ansonnsten hat man nicht verloren hier !
    wen du nicht endlich lernst was zeiger structuren unions etc. Sin bzw. wie man es richtig anwendet, dan wirsrt du nie was verstehen. bzw. Wirst dich im Pointer-salat verliern.

    "rtfm"

    lowbyte

    0
Anmelden zum Antworten