Bytebuffer anlegen?

Konrad Rudolph

CStoll schrieb:

In der Rangfolge der "Güte":
* nimm std::vector
* new char[100];
* bleib bei malloc();

Hm. In C++ gibt's dafür doch Allokatoren bzw. 'temporary_buffer'.

Danke.
Ich schaue mir mal vektor an.

@Konrad: Allokatoren sind mir erstmal etwas zu kompiliert. Bei get_temporary_buffer<T>(num) bin ich wieder beim Datentyp. Eigentlich ist doch mein Problem das es kein Datentyp Byte gibt?

http://www.c-plusplus.net/forum/viewtopic-var-t-is-159231.html

Konrad Rudolph

Rolli rollt schrieb:

@Konrad: Allokatoren sind mir erstmal etwas zu kompiliert. Bei get_temporary_buffer<T>(num) bin ich wieder beim Datentyp.

Ja, das Problem mit dem Datentyp hast Du immer, wenn Du nicht 'malloc' verwendest. Ich würde mir einfach folgendes Typedef anlegen:

typedef unsigned char byte_t;

Das klappt auf fast allen Systemen und dort, wo es nicht zutrifft, passt man eben das Typedef an.

Artchi

Du mußt nichts über allokatoren wissen. Die Std-Library hat einen Default-Allokator, wenn du keinen angibst. Mach mal folgendes:

std::vector<char> my_buffer(100);

LMwoot

Seit C++ benutzt man new um Speicher zu reservieren bzw. zu allokieren.

Es gibt einen gewaltigen Unterschied zwischen Vektor und allokiertem Speicher, denn ein Vektor ist ein STL-Container. Container haben einen relativ hohen Verwaltungsaufwand im Gegensatz zu allokiertem Speicher.

Ein Vektor ist quasi durch die Klasse gemanaged und allokierten Speicher muss man selbst managen (dazu gehoert das das deallokieren).

Legt man also Wert auf Einfachheit und Benutzerfreundlichkeit sind Vektoren sicher besser, wenns aber um hohe Geschwindigkeit geht, sollte man allokierten Speicher benutzen.

PS: Man sollte genau soviel Speicher allokieren, wie man auch benoetigt!
Hier ein Bytebuffer:

char *var = new char[size];

delete[] var;

//alternativ wie schon erwaehnt

std::vector<char> v1;

Wenn du einen Allzweckbuffer haben moechtest, dann solltest du dir Templates anschauen.

template<typename T>
T *malloc(int size)
{
  T *res = new T[size];
  return res;

}

oder so aehnlich... hab es nicht getestet

Ich werde doch bei char* bleiben, da ich den Datentyp sowieso schon bei anderen Buffer Funktionen verwende. Außerdem wird mir das Casten auch nicht erspart bleiben. Also bleibe ich bei char*.

Trotzdem vielen Dank für die Mühe

LMwoot

hoffe du bekommst emails... les nochmal den beitrag... habe ihn editiert!
Auch doofe Logik, aber gut

Artchi

LMWoot! Dein Posting enthält leider sehr viele Fehlinformationen.

Ein Vector ist intern ein Array, der Zugriff ist genauso schnell wie auf ein Array. Ich kann hier (zum Glück) keinen Performancenachteili ggü. einem Array sehen.

Hm.. also die Funktion um die es konkret geht ist:

BOOL VerQueryValue(
    const LPVOID pBlock,	// address of buffer for version resource
    LPTSTR lpSubBlock,	// address of value to retrieve
    LPVOID *lplpBuffer,	// address of buffer for version pointer
    PUINT puLen 	// address of version-value length buffer
   );

Beim ersten bekomme ich die Buffergröße für lplpBuffer und im zweiten Aufruf wird der Buffer befüllt.
Da mache ich lieber ein kurzes char* und caste ein bißchen rum, als irgendwas Größeres, was ich nicht 100%tig verstehe.

Konrad Rudolph

Also, wenn Du eh die Windows-Platform-API verwendest, kannst Du auch gleich deren Typedefs mitverwenden, also in diesem Fall 'BYTE'.

Wenn die Funktion einen void* will muß ich wieder von BYTE* nach void* casten... aber zumindest hätte ich dann die richtige Buffergröße genommen.

@LMwoot: Ich habe keine eMail angegeben. Ich hoffe es standen keine Beleidigungen in der eMail
Dein Weg wird in meinem Fall nicht effizient sein, weil ich den Speicher nach dem Befüllen in einen struct mit dem Namen VS_FIXEDFILEINFO konvertieren muß.

Bei VerQueryValue() hatte ich mich vertan. Die Buffergröße ich schon durch sizeof(VS_FIXEDFILEINFO) fix vorgegeben.

LMwoot

also von der geschwindigkeit her ist allokierter speicher einfach schneller... ich weiss nich mehr genau unter welchem thema, aber irgendwo hier im forum wurde ein benchmark mit 10.000.000 Chars durchgefuehrt, wo der vector ueber eine minute gebraucht hat um diesen ueber seine methoden zu fuellen.... der allokierte speicher wurde in ca. 10 Sekunden gefuellt.

Einfach mal ausprobieren.... sicher bin ich mir da auch nicht.

und ich hasse microsoft spezifische abkuerzungen die beruehmte extrawurst!

Simon2

LMwoot schrieb:

also von der geschwindigkeit her ist allokierter speicher einfach schneller... ich weiss nich mehr genau unter welchem thema, aber irgendwo hier im forum wurde ein benchmark mit 10.000.000 Chars durchgefuehrt, ...

Und genau in diesem Thread kam auch raus, dass bei dieser Messung Äpfel mit Birnen verglichen wurden !!!
Schau Dir den Thread nochmal genau und komplett an !!!
Das Allokieren eines Vektors ist nichts Anderes (und dauert nicht länger) als das eines dynamischen Arrays !

Gruß,

Simon2.

hustbaer

wenns aber um hohe Geschwindigkeit geht, sollte man allokierten Speicher benutzen.

Wenns um hohe Geschwindigkeit geht sollte man IMHO trotzdem mal messen wieviel es überhaupt um ist, da ein std::vector<char> normalerweise nicht wirklich spürbar langsamer ist als ein einfaches "new" - zumindest solange man nicht wirklich grosse Blöcke anfordert. "new" alleine ist nämlich auf vielen Systemen ein ziemlicher Killer, auch bei kleinen Blockgrössen.

Der einzige ernstzunehmende Overhead sollte sein dass "std::vector<vhar>(size)" alle Bytes (chars) initialisiert, was oft zu einem memset optimiert wird. Wenn man mit kleinen Blöcken arbeitet bzw. sowieso initialisierten Speicher braucht... sollte es egal sein.

Nachtrag: Es ging mir nicht um Geschwindigkeit. Ich hatte bisher nur C gemacht und nun muß ich ein paar Module für ein paar C++'ler schreiben und wollte mich nicht lächerlich machen bzw. von Anfang an einen guten Stil anzugewöhnen. Bei unseren SW Projekten geht es nicht um Geschwindigkeit sondern viel viel viel mehr um Korrektheit.