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

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

  • 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