|
Fix the type of secondPart so it matches the type that ParsePath() is expecting:
const char* secondPart;
|
|
|
|
|
Michael Dunn wrote: Ford, what's this fish doing in my ear?
Ford as in Prefect? 
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
That's the one
|
|
|
|
|
Is this function being called exist in a LIB or a DLL?
On older versions of VC++, a reference was really a pointer behind the scenes (it might still be), which is why you could pass pointer to something to a function that expected reference to something, like calling an extern "C" C++ function that took a reference from straight C code (there is no reference type in C). This kind of thing works in VC++ 6.0 (IIRC).
You just might be seeing more strict type checking that let you get away with other stuff (see below).
Actually, the type expected for the secondPart parameter is const char *, so you should declare that variable as:
const char *secondPart = NULL; Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
You are right - the function is in a DLL from older version of VC++
I've already tried casting, that worked:
General->ParsePath(parent, path, pathType, pathIsDir, (const char *&)secondPart);
but I'm not happy about it.
Your sugestion looks much nicer, but I have to test it yet.
Do you think, there will be some problems when using different versions of VC++?
Asdef Jaker
What part of "Thou shall not kill" don't you understand? GOD
|
|
|
|
|
The implementation of a reference in C++ is implementation-dependent. This means that the way it works in any C++ compiler suite can change at any time (e.g. download a VC service pack, and it might change), and may not be compatible between two different C++ platforms.
If you need to support reference-like behavior in a DLL that may be used by other 3rd-party applications (which may NOT have been written using VC++), I would suggest using a pointer instead of a reference (change to const char ** instead of const char *&).
I would advise that you change the type of the variable you are using as opposed to casting. Casting should be your last resort to getting things working, and is usually a sign that something is not quite right.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Thank you for your insight!
I changed all occurences of the secondPart definition to const, but I ran into another problem: The code I work on changes the secondPart string after calling the ParsePath(..) method. This is prohibited, because the string is now defined as const... 
If i understand the const char *secondPart = NULL; declaration corectly - it means changeable pointer to constant string - is that right? Do I need to make a copy if I need to change the secondPart string?
Asdef Jaker
What part of "Thou shall not kill" don't you understand? GOD
|
|
|
|
|
No, it sounds like it is working correctly. const char * is a pointer to a constant char (a "string"), whereas a char const * is a constant pointer to a (non-const) "string".
const char *pPtrToConstChar = "First Const Const";
char* const pConstPtrToChar = "Second String";
pPtrToConstChar = "Second Const String";
strcpy( <code>pPtrToConstChar</code>, "Test" );
<code>
<code>pConstPtrToChar</code> = "Third String";
<code>
strcpy( pConstPtrToChar, "Test" );
Note that I am using static strings here, so copying into their memory is technically incorrect but I am trying to demonstrate pointer const-ness as opposed to data const-ness.
The function is allowed to take a pointer to constant data as a reference, and change the pointer so that it points to other constant data.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
I am reading from a file after opening using this command
ReadFile(hFile,&strData, 300, &dwbytes, NULL); in a C++ dll
strData is defined as a std::string
say std::string test = strData;
After executing the above command, i get an error .. something about misaligned string. I am not sure what could be going on here. When i debug and watch the values i see strData as {???} but then when i drill down, i actually see the correct data read from the file, but it seems like something is wrong such that strData cannot be accessed
|
|
|
|
|
std::string is a class. you cannot pass it as a parameter when the function expects a C-style string (array of character).
please show the definition of ReadFile()
|
|
|
|
|
How would i get around this??
Myabe use a TCHAR or LPVOID in the ReadFile and then once i get the value, convert that to an std::string??
How would that work?
The definition of ReadFile is
BOOL ReadFile(
HANDLE hFile,
LPVOID lpBuffer,
DWORD nNumberOfBytesToRead,
LPDWORD lpNumberOfBytesRead,
LPOVERLAPPED lpOverlapped
);
Parameters
hFile
[in] Handle to the file to be read. The file handle must have been created with the GENERIC_READ access right. For more information, see File Security and Access Rights.
For asynchronous read operations, hFile can be any handle opened with the FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle returned by the socket or accept function.
Windows Me/98/95: For asynchronous read operations, hFile can be a communications resource opened with the FILE_FLAG_OVERLAPPED flag by CreateFile, or a socket handle returned by socket or accept. You cannot perform asynchronous read operations on mailslots, named pipes, or disk files.
lpBuffer
[out] Pointer to the buffer that receives the data read from the file.
nNumberOfBytesToRead
[in] Number of bytes to be read from the file.
lpNumberOfBytesRead
[out] Pointer to the variable that receives the number of bytes read. ReadFile sets this value to zero before doing any work or error checking. If this parameter is zero when ReadFile returns TRUE on a named pipe, the other end of the message-mode pipe called the WriteFile function with nNumberOfBytesToWrite set to zero.
If lpOverlapped is NULL, lpNumberOfBytesRead cannot be NULL. If lpOverlapped is not NULL, lpNumberOfBytesRead can be NULL. If this is an overlapped read operation, you can get the number of bytes read by calling GetOverlappedResult. If hFile is associated with an I/O completion port, you can get the number of bytes read by calling GetQueuedCompletionStatus.
If I/O completion ports are used and you are using a callback routine to free the memory allocated to the OVERLAPPED structure pointed to by the lpOverlapped parameter, specify NULL as the value of this parameter to avoid a memory corruption problem during the deallocation. This memory corruption problem will cause an invalid number of bytes to be returned in this parameter.
Windows Me/98/95: This parameter cannot be NULL.
lpOverlapped
[in] Pointer to an OVERLAPPED structure. This structure is required if hFile was created with FILE_FLAG_OVERLAPPED.
If hFile was opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must not be NULL. It must point to a valid OVERLAPPED structure. If hFile was created with FILE_FLAG_OVERLAPPED and lpOverlapped is NULL, the function can incorrectly report that the read operation is complete.
If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the read operation starts at the offset specified in the OVERLAPPED structure and ReadFile may return before the read operation has been completed. In this case, ReadFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue while the read operation finishes. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the read operation.
If hFile was not opened with FILE_FLAG_OVERLAPPED and lpOverlapped is NULL, the read operation starts at the current file position and ReadFile does not return until the operation has been completed.
If hFile is not opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the read operation starts at the offset specified in the OVERLAPPED structure. ReadFile does not return until the read operation has been completed.
Windows 95/98/Me: For operations on files, disks, pipes, or mailslots, this parameter must be NULL; a pointer to an OVERLAPPED structure causes the call to fail. However, you can perform overlapped I/O on serial and parallel ports.
|
|
|
|
|
i didn't ask for the whole documentation, only the definition, that is
BOOL ReadFile(
HANDLE hFile,
LPVOID lpBuffer,
DWORD nNumberOfBytesToRead,
LPDWORD lpNumberOfBytesRead,
LPOVERLAPPED lpOverlapped
);
don't pass a std::string, pass a char*
|
|
|
|
|
LCI wrote: Myabe use a TCHAR or LPVOID in the ReadFile and then once i get the value, convert that to an std::string??
Yes, that would be just fine. Or you could opt for an ifstream instead, and read directly into a string object.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
If i were using a TCHAR, how would i convert that to std::string.
Or for that matter and ifstream , don't believe that i ever used one of these.
|
|
|
|
|
LCI wrote: If i were using a TCHAR, how would i convert that to std::string.
#ifdef _UNICODE
#define tstring wstring
#else
#define tstring string
#endif
TCHAR szBuffer[1234];
tstring str = szBuffer;
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: TCHAR szBuffer[1234] = _T("David");
in pounds or in Kgs ? 
|
|
|
|
|
I think that std::string is really std::basic_string< TCHAR >, so it automatically becomes the "right kind of" string.
Peace!
-- modified at 14:50 Thursday 1st March, 2007
Well, I guess not...
Musta been thinking of my own string classes... :P
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: I think that std::string is really std::basic_string< TCHAR >...
It's std::basic_string<char>, while wstring is std::basic_string<wchar_t>.
James R. Twine wrote: ...so it automatically becomes the "right kind of" string.
Only if _UNICODE is not defined. If it is, wstring must be used.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
James R. Twine wrote: I think that std::string is really std::basic_string< TCHAR >,
Nope[^]
|
|
|
|
|
I totally understand what you are saying in terms of it being a class, but just do not know how to legally get around this.
|
|
|
|
|
toxcct wrote: ...when the function expects a C-style string (array of character).
It actually expects a void* as the second argument. Passing the address of a string object satisfies that requirement. That does not imply that ReadFile() knows what to do with it, however. 
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Any suggestions on how to get around this?
|
|
|
|
|
LCI wrote: Any suggestions on how to get around this?
i already answered this
|
|
|
|
|
DavidCrow wrote: It actually expects a void* as the second argument. Passing the address of a string object satisfies that requirement
yes, it term of syntax, what he does is correct, that's why his program crashed at runtime, not at compile time.
but the function is a C function (win32 API, no ?), so i doubt it would deal with C++ classes
|
|
|
|
|
You are not mixing an exe built in debug and a DLL built in release mode, are you?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
