another vector question

ok, now I need to get an actual pointer to the data in a vector, I have to pass this to a function that only accepts raw pointers.

Quote:

---

Originally Posted by abachler

ok, now I need to get an actual pointer to the data in a vector, I have to pass this to a function that only accepts raw pointers.

---

Code:

---

&vec[0]

---

so if I have -

Code:

---

string Foo;

---

I can just pass

Code:

---

MyFunction((LPVOID)&Foo);

---

and that will point to the characters int eh string themselves?

Not even remotely...

Example:

Code:

---

MyFunction((LPCVOID)Foo.c_str());

---

It seems that string (currently) doesn't really allow non-constant access to the internal buffer (it is not required to be contiguous). You can use a vector<char> instead of string.

Pointers needn't be cast to void* in either C or C++ either.
Also there's no such thing as LPCVOID ;)

The only reason I put the cast was to assure that the OP was aware of the fact that std::string::c_str() is constant. Hence the LPCVOID.

There is no such thing as LPCVOID. I think it's just better to write const void*.
All those LP* defines/typedefs are evil anyway. They obfuscate code, makes it harder to read and more prone to errors.

Whether you like them or not, to say that they don't exist is absurd, and totally irrelevant to the thread, too.

I said "LPCVOID" didn't exist. Unless you typedef that one yourself, it doesn't exist in any common windows header.

OK, you're right. Sorry.

Quote:

---

Originally Posted by Elysia

I said "LPCVOID" didn't exist. Unless you typedef that one yourself, it doesn't exist in any common windows header.

---

http://msdn2.microsoft.com/en-us/library/aa383751(VS.85).aspx

WinDef.h

News to me. Never seen it before that I can remember.
But... I stand corrected.
Although, const void* is much easier to read and interpret rather than LPCVOID. I still stand fast to that.

And I grepped the wrong directory in my search.

Quote:

---

Originally Posted by Elysia

News to me. Never seen it before that I can remember.
But... I stand corrected.
Although, const void* is much easier to read and interpret rather than LPCVOID. I still stand fast to that.

---

i am hearing such comments from someone who uses cryptic (to me, at least :() #defines to make it even more difficult to understand template ridden code :(

but anyways such typedefs have advantages:
like:

Code:

---

char* p, q r; // not all are pointers :(
LPSTR p, q, r; // all are pointers :)

---

LPCVOID is a typedef, not a #define. And it doesn't have anything to do with templates. Win32 is a C interface, and templates are C++, not C.

i am not saying anything like you have assumed from my post :D

Oh. Then could you clarify?

consider this:
why we should use LPCVOID instead of const void *?

For type-matching with an API that specifies the use of such type.

Quote:

---

Originally Posted by manav

i am hearing such comments from someone who uses cryptic (to me, at least :() #defines to make it even more difficult to understand template ridden code :(

---

Not really. You need some more practice, that's all. It removes long, template-ish lines which has to be duplicated all the time.

Quote:

---

but anyways such typedefs have advantages:
like:

Code:

---

char* p, q r; // not all are pointers :(
LPSTR p, q, r; // all are pointers :)

---

---

Code:

---

typedef LPVOID void*;
typedef LPPVOID void**;
typedef LPINT int*;

void myfunc(LPVOID p);

int main()
{
    LPVOID myvar;
    LPPVOID myvarr;
    myvarr = &myvar; /* Wtf? How can you assign the address of one variable to another which is not a pointer? */
    int myint = 0;
    LPINT myint2;
    myint2 = &myint; /* Wtf? How can you assign the address of one variable to another which is not a pointer? */
    *myint2 = 5; /* Wtf? Myint2 is a variable, not a pointer */

    LPVOID myvar2 = 100; /* Valid in C! */
    myfunc(myvar2, 4);
}

void myfunc(LPVOID p)
{
    int val = 4;
    memcpy(p, &val, sizeof(val));
}

---

It could go on. This will make your head hurt in complex code whereas, if you simply typed int, int*, void* or void**, it would be so much simpler.
Worse is if someone renames them such as:

Code:

---

typedef struct
{
    /* ... */
} *mystruct;
/* Wtf? mystruct is a pointer, not a variable! */

---

Quote:

---

Originally Posted by robwhit

For type-matching with an API that specifies the use of such type.

---

Use documentation instead. It's much less error prone than using stupid typedefs for taking arguments.
Say: this function expects the address of a variable of type X instead of typing LPVOID.

Quote:

---

For type-matching with an API that specifies the use of such type.

---

Well in this case ...
It would have been much better if the API used this:

Code:

---

void MSAPIFunction(char * s);

---

instead of this ugliness:

Code:

---

typedef char * LPSTR;
void MSAPIFunction(LPSTR s);

---

Quote:

---

myvarr = &myvar; /* Wtf? How can you assign the address of one variable to another which is not a pointer? */

---

Smart pointers aren't pointers either. Spotting that a type name starts with P or LP isn't really harder than spotting a * in the declaration. It's a very simple convention.

Not saying that I'd use it, but I don't see it decreasing readability.

It introduces confusion if abused. There have been examples of that with linked lists in the C forum multiple times.
At least it boggles my mind.

Win32 is an API, not an implementation. There might be another implementation on another platform which has different representations for variable types. Then what would you do if you wanted binary compatibility?

I think a better solution would be to have an API compatibility layer between the Win32 API and the code that you need to be in regular C types. Also consider whether you actually need Win32 types or C data types. I don't think Win32 data types would be a good choice for a linked list. Where's the connection?

Quote:

---

Originally Posted by Elysia

Use documentation instead.

---

I thought I was...?

Quote:

---

Originally Posted by Elysia

It introduces confusion if abused.

---

Not a good mantra for computer programming. ;)

Of course it's fine to typedef types.
But it's bad to typedef pointers to types.
:|

Ah I see. But pointers are types. How do you know that the pointer types are the same?

typedef something mytype;
void foo(mytype* p);

This guarantees that it takes a pointer to something of type mytype.
So why the need for pointer typedefs?

Just as a quick clarification to Elysia, The only reason I even used LPCVOID was because he used LPVOID. Had he not used a win32 type I would have also not used a win32 type. Furthermore, I try to always match JAVA source with JAVA source, C++ source with C++ source, and even pseudo-code with pseudo-code. It represents one of two things happening, people getting an understandable answer to their question, or people wondering "why on earth did he post pseudo-code as an answer?" Thus inspiring them not to post it in the question :)

I see. Well, don't worry - I'm not blaming anyone (phew).
Friends again? :D

Quote:

---

Originally Posted by Elysia

This guarantees that it takes a pointer to something of type mytype.

---

Yes, but if you agree that non-pointer data types can be different, then pointer types could be different just as easily... ...right?

I've decided this is a rather weak argument. I think I'll agree with you, Elysia. :D

Naw its cool Elysia. And in fact I do agree with her on this one mostly because typedefs are something that have become evil in the industry. Sometimes the quest towards making things portable is commendable, but sometimes that just doesn't seem to be the rationale behind the typedefs.

To be honest, I think its a territorial issue more often than anything else. "Psh.. an int... what the hell is an int? If you want to use my library then you will use a my_int. And don't you dare think of trying to sneak in a SOCKET in there!"

And true, sometimes (such as in the example of descriptors) typedefs merely distinguish between integral types and a descriptor, but people are very liberal about their type defining these days. There need only be enough types to be portable, and debuggable and nothing more.