_bstr_t Alternative

dixxi_16c496 · 10. November 2019 um 18:20

Liebes Forum!

Ich benutze einen Code aus dem Internet um die CPU Auslastung zu ermitteln. Der Code wurde aber für Visual Studio geschrieben und ist unter Code::Blocks mit MinGW nicht ausführbar. Ich habe schon einiges umgeschrieben, aber die Zeilen mit dem _bstr_t machen mir noch Probleme:

#include 
...
LPCTSTR pInstanceName;
...
 pPerfInst = FirstInstance( pPerfObj );

 // Look for instance pInstanceName
 \_bstr\_t bstrInstance;
 \_bstr\_t bstrInputInstance = pInstanceName;
 for( int k=0; k NumInstances; k++ )
 {
 bstrInstance = (wchar\_t \*)((PBYTE)pPerfInst + pPerfInst-\>NameOffset);
 if (!stricmp((LPCTSTR)bstrInstance, (LPCTSTR)bstrInputInstance))
 {
 pCounterBlock = (PPERF\_COUNTER\_BLOCK) ((LPBYTE) pPerfInst + pPerfInst-\>ByteLength);
 break;
 }

 // Get the next instance.

 pPerfInst = NextInstance( pPerfInst );
 }

Weiß jemand wie ich ohne comdef.h und _bstr_t auskomme?

mfg dixxi

SebastianS · 10. November 2019 um 18:21

> bstrInstance = (wchar\_t \*)((PBYTE)pPerfInst +  
> pPerfInst-\>NameOffset);  
> if (!stricmp((LPCTSTR)bstrInstance,  
> (LPCTSTR)bstrInputInstance))

Weiß jemand wie ich ohne comdef.h und _bstr_t auskomme?

Ich weiß ja jetzt nicht genau, was ein LPCTSTR ist, vielleicht solltest du bei der Heilung des Codes von der Windows-API den Datentyp auch noch „normalisieren“.

Aber ich denke, dass das eigentliche Problem, das mit dem _bstr_t gelöst wird, die Konversion von wchar_t* zu char* ist (da der cast-Operator (const char*) für die Klasse _bstr_t überladen wird). Dann empfehlen sich als Ersatz die portableren Wandlungsfunktionen wcstombs/mbstowcs aus stdlib.h (ich denke, diese sind ANSI-C).

Grüße,
Sebastian

Peter_TOO · 10. November 2019 um 18:21

Hallo Sebastian,

Ich weiß ja jetzt nicht genau, was ein LPCTSTR ist, vielleicht
solltest du bei der Heilung des Codes von der Windows-API den
Datentyp auch noch „normalisieren“.

Das ist „ungarische Notation“.
http://de.wikipedia.org/wiki/Ungarische_Notation

MfG Peter(TOO)

SebastianS · 10. November 2019 um 18:22

Ich weiß ja jetzt nicht genau, was ein LPCTSTR ist, vielleicht
solltest du bei der Heilung des Codes von der Windows-API den
Datentyp auch noch „normalisieren“.

Das ist „ungarische Notation“.
http://de.wikipedia.org/wiki/Ungarische_Notation

Inwiefern? Ungarische Notation ist für mich (wie auch anscheinend für den Wikipediaartikel) etwas, das mit Präfixen an Variablennamen im Zusammenhang steht - und nicht mit Typnamen wie diesem großbuchstabigen typedef.

Und in deinem zitierten Wikipedia-Artikel steht konsequenterweise auch nicht, wofür LPCTSTR stehen soll. Long Pointer to Carriage return Terminated String? Glaube ich nicht, nachdem Standard-Stringvergleichsfunktionen darauf aufgerufen werden… weisst du’s?

Grüße,
Sebastian

Semjon_Michailowitsch_580bb3 · 10. November 2019 um 18:22

Hallo

Und in deinem zitierten Wikipedia-Artikel steht
konsequenterweise auch nicht, wofür LPCTSTR stehen soll. Long
Pointer to Carriage return Terminated String? Glaube ich
nicht, nachdem Standard-Stringvergleichsfunktionen darauf
aufgerufen werden… weisst du’s?

http://www.google.com/search?hl=en&q=%22long+pointer…

Grüße

CMБ

SebastianS · 10. November 2019 um 18:22

Hallo

Und in deinem zitierten Wikipedia-Artikel steht
konsequenterweise auch nicht, wofür LPCTSTR stehen soll. Long
Pointer to Carriage return Terminated String? Glaube ich
nicht, nachdem Standard-Stringvergleichsfunktionen darauf
aufgerufen werden… weisst du’s?

http://www.google.com/search?hl=en&q=%22long+pointer…

*stirnpatsch*. Da fragt man sich doch, wo der Gewinn gegenüber dem jedermann verständlichen Datentyp „char*“ liegt .

Andererseits: http://www.google.com/search?hl=en&q=%22long+pointer…

Dann wäre es ein „const char*“. Ebenfall kein Gewinn. *seufz*.

Ich habe es eben noch mal in ein Visual Studio eingegeben und die Intellisense-Typauflösung verfolgt: es ist tatsächlich abhängig von der seltsamen TCHAR-Geschichte ein „const char*“ oder „const wchar_t*“. Das heisst, im vom Urposter zitierten Code ist der Datentyp nicht sinnvoll verwendet worden, da von der Identität LPCTSTR zu (const) char* ausgegangen wurde. Tatsächlich gewollt ist, wie man an der verwendeten Vergleichsfunktion sieht, char*, aber je nach Definition von _TCHAR würde es fehlschlagen.

Viele Grüße,
Sebastian

SebastianS · 10. November 2019 um 18:22

LPCTSTR

Die Bedeutung ist also wohl im Endeffekt „long pointer to constant _TCHAR string“…

Grüße,
Sebastian

Semjon_Michailowitsch_580bb3 · 10. November 2019 um 18:22

Hallo

LPCTSTR

Die Bedeutung ist also wohl im Endeffekt „long pointer to
constant _TCHAR string“…

Unwahrscheinlich. LPCTSTR stammt aus dem „ganz alten“
Windows-3 API, da gab es weder ‚constant‘ noch ‚_TCHAR‘.

„LONG PTR“ bezieht sich imho klar auf 16-bit API. Remember,
„Turbo-C-Speichermodelle“ – „tiny“, „small“, „large“, huge"
unterschieden sich in den Zeigerlängen (2byte/64K vs. 4 byte/
segmented).

Wer weiss.

Grüße

CMБ

SebastianS · 10. November 2019 um 18:22

Hallo

LPCTSTR

Die Bedeutung ist also wohl im Endeffekt „long pointer to
constant _TCHAR string“…

Unwahrscheinlich. LPCTSTR stammt aus dem „ganz alten“
Windows-3 API, da gab es weder ‚constant‘ noch ‚_TCHAR‘.

Jedenfalls ist es in den Headern, die mein Visual Studio inkludiert, ähnlich _TCHAR in Abhängigkeit vom #define UNICODE auf LPCWSTR oder LPCSTR definiert, welche wiederum letztendlich auf const wchar_t* oder const char* landen.

„LONG PTR“ bezieht sich imho klar auf 16-bit API.

Aber leider wurden diese Überbleibsel ja nicht mit dem Wechsel auf die 32-bit-Architektur beerdigt. Ich würde nicht ausschließen, dass auch „neuere“ Entwicklungen dem antiquierten Namensschema folgen.

Remember,
„Turbo-C-Speichermodelle“ – „tiny“, „small“, „large“, huge"
unterschieden sich in den Zeigerlängen (2byte/64K vs. 4 byte/
segmented).

Das war zum Glück alles lange vor meiner Zeit… und bei weniger gruseligen APIs als Win32 begegnen einem solche Relikte auch schon lange nicht mehr.

Viele Grüße,
Sebastian

lupus_consiliarius_9a153c · 10. November 2019 um 18:22

Hallo Sebastian,

willkommen im Windows-C-Typenzoo.
Im Windows-(C/C++ -)API beginnen Zeigertypen mit P oder LP (früher wurden dadurch tatsächlich NEAR und FAR Zeiger unterschieden, also Pointer und LongPointer - inzwischen ist P = LP). Aus Gründen der Rückwärtskompatibilität sind beide Typen noch definiert.

An Text- und Zeichenpointern hat Windows zu bieten:

CHAR 8-bit Windows (ANSI) character. 
WCHAR 16-bit Unicode character. 
TCHAR A WCHAR if UNICODE is defined, a CHAR otherwise. 

PCHAR Pointer to a CHAR. 
PWCHAR Pointer to a WCHAR. 
PTCHAR Pointer to a TCHAR. 

PSTR Pointer to a null-terminated string of 8-bit Windows (ANSI) characters.
LPSTR Pointer to a null-terminated string of 8-bit Windows (ANSI) characters. 
PWSTR Pointer to a null-terminated string of 16-bit Unicode characters. 
LPWSTR Pointer to a null-terminated string of 16-bit Unicode characters. 
PTSTR A PWSTR if UNICODE is defined, a PSTR otherwise. 
LPTSTR An LPWSTR if UNICODE is defined, an LPSTR otherwise. 

PCSTR Pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters. 
LPCSTR Pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters. 
PCWSTR Pointer to a constant null-terminated string of 16-bit Unicode characters. 
LPCWSTR Pointer to a constant null-terminated string of 16-bit Unicode characters.
PCTSTR A PCWSTR if UNICODE is defined, a PCSTR otherwise. 
LPCTSTR An LPCWSTR if UNICODE is defined, an LPCTSTR otherwise.

Gruß,
Ralf

dixxi_16c496 · 10. November 2019 um 18:23

Gelöst
So hab das Problem jetzt selbst gelöst:

 char Instance[128];
 for ( int k=0; k NumInstances; k++ )
 {
 wcstombs(Instance, (wchar\_t \*) ((PBYTE)pPerfInst + pPerfInst-\>NameOffset), 128);
 if (!stricmp(Instance, pInstanceName))
 {
 pCounterBlock = (PPERF\_COUNTER\_BLOCK) ((LPBYTE) pPerfInst + pPerfInst-\>ByteLength);
 break;
 }

 // Get the next instance.

 pPerfInst = NextInstance( pPerfInst );
 }

mfg dixxi