Typecasting

[Stormhawk]

I am reading this book that has all its examples in c. So far I've been able to write it all using c++ but I was wondering if anyone could tell me what does this mean.

static char achOutBuf[]= "This is a jest of the emergency comedy system";

/* this was a parameter to a function in case anyone wanted to know spefically */
(LPSTR)&achOutBuf;

When I had looked into it I found that LPSTR was a long string. Then I check up in the c++ for how it was written and saw it was just typecasting. I never realy typecast this way before so I had to check. but the & is the only part that is throwing me off. I believe its just typecasting this as a long string pointer of achOutBuf by reference. If I am wrong feel free to correct me.

Also on a side note while I am at it. Would anyone know what _fstrlen is?

[MiiNiPaa]

Stormhawk wrote:

(LPSTR)&achOutBuf;

It probably should be (LPSTR)&achOutBuf[1] or similar. In other case it will be address of a pointer casted to another pointer and probably will be dangerous.
& here is an address of operator. It returns address of its argument.

The _fstrlen() function is a data-model-independent form of the strlen() function that accepts far pointer arguments. It's most useful in mixed memory model applications.

You will probably will never need it.

[Stormhawk]

I was just wonder if you can make an example of the LPSTR.

And from what your saying its pretty much;

a char array was cast to long string pointer.. but only the address of the char array as passed to the long string pointer. If what I said was true then why use a Long string pointer if your not casting the chars into becoming strings. Also would char* work just the same as LPSTR or no?

[kbw]

C and hence C++ are consistent with the treatment of points and array. When an array is passed as a parameter to a function, the address of the first element is passed. So the function just sees a pointer.

Don't get confused by LPSTR, it's just char*.

[MiiNiPaa]

Also would char* work just the same as LPSTR or no?

const char* would. But what if in next Windows version it will be changed? Some of windows typedefs would change depending on compiler and size of types (until C++11 and fixed-width integers). There is a little sense in pointer cast unless compiler prevents you from using char* here.

[Stormhawk]

I never really understood the point of const pointers since a pointer only passing a value by reference wouldn't making a const pointer be kind of useless?

or for at one of the parameters for an declare function. I guess I should reword that as a question. What is the meaning for const char* when used in a declare function parameter?

[kbw]

With pointers, the thing pointed to can be read-only, or the pointer itself can be read-only, or both. For example:

int n[] = { 5, 6 };

int* p = &n;
++(*p);  // increment n[0]
++p;  // p points to n[1]

const int* q = &n;
++(*q);  // attempt to increment n[0], compiler error
++q;  // q points to n[1]

int* const r = &n;
++(*r);  // increment n[0];
++r;  // attempt to point to n[1], compiler error

const int* const s = &n;
++(*s);  // attempt to increment n[0], compiler error
++s;  // attempt to point to n[1], compiler error 

[helios]

const char* would. But what if in next Windows version it will be changed?

Then the code would be incorrect anyway, because it would be casting a char * to (for example) a wchar_t *.
If anything, it'd be best not to make the cast at all. If the prototype does indeed change, a compiler error is preferable to generating incorrect code.