Win32 API function ReadFile()'s second argument takes an LPVOID.
Is there a way to use a C++ string directly for the second argument?
Code:string strBuf;
ReadFile(h, reinterpret_cast<LPVOID>strBuf.c_str(), size, &dwRead, NULL);
Printable View
Win32 API function ReadFile()'s second argument takes an LPVOID.
Is there a way to use a C++ string directly for the second argument?
Code:string strBuf;
ReadFile(h, reinterpret_cast<LPVOID>strBuf.c_str(), size, &dwRead, NULL);
No. Second parameter is a buffer that receives data, but `c_str()` returns `const char*`.
So I should pass the string to a char* first, that defeats the purpose of using a string.
The inventor of C++ should have thought about Win32 API functions too when he was writing the language.
You can pass &strBuf[0] as the argument, but of course, you must have set the std::string object to have a large enough size, possibly including a null terminator if applicable.Quote:
Originally Posted by Ducky
The inventor of the Win32 API functions should have thought about C++ when he was designing the API (although it is in C :p).Quote:
Originally Posted by Ducky
Since when we have to set the size of a C++ string? I thought that, that was the point of C++ strings (no need to set a size).
Haha, wasn't it the Win32 API that came first? :-)
We don't, but we can with `std::string::reserve()`.
You can't pass a string to a dll, because the dll's implementation of string may be different than what your program uses.
Also, it's the library writer's responsibility to make their library easy to use. The C++ committee does tailor the language to specific libraries, libraries must tailor themselves to the language.
You decided to use an API that has no notion of a C++ string, so it is up to you to do what is necessary.Quote:
Originally Posted by Ducky
In that case, you should use std::getline, or some other API that provides such a convenience.Quote:
Originally Posted by Ducky
They had enough time to change their API, so it is obviously the Win32 API designers' fault. Okay, seriously: you're using an OS specific API and asking why a general purpose programming language's standard library does not directly support it as part of the standard :oQuote:
Originally Posted by Ducky
That would be wrong: reserve would reserve capacity, but here the elements should actually exist.Quote:
Originally Posted by msh
Ok, that clears it up. It's just better to forget about C++ with Win32 API.
Just because one little API is giving you trouble, you decide to throw in the towel? Yes, that is going to get you far...
I mean, it can't be helped. The library is C, and C requires you to have a sufficient buffer. It expects this. No possible language in the world could possibly change this. You must have a buffer of sufficient size.
So just reserve space, then pass the buffer and its size to the function. Hard? Not very.
Oh, you don't like doing that? Then why are you using a C API? There are alternatives, you know...
Or you could write a wrapper around these functions with a similar interface to "tame" them. How do you think the C++ standard library is implemented?
The real world sucks, and we have to live with it. Throwing in the towel because a little mishap is just not going to work. You need to tame the world to your needs.
Well its not just one little API function, all the API functions take C style strings.
And if I have to reserve space with C++ strings that kinda defeats the purpose of using it.
Why complicate things when you can have it simple?
It is the price you pay for using low level functions. And besides, strings require no manual memory management.