Hi could you please help us in copying one wchar_t* to another wchar_t*.
I'm using the following code:
wchar_t* str1=L"sreeni";
wchar_t* str2;
wcscpy(str2,str1);
In the last line I'm getting a run time error as without allocating memory to *str2, i'm trying to copy the value of str1;
is there any method like wcscpy to copy wchar_t pointer to another wchar_t pointer?
I dont want to use wide character arrays, i.e there shouldn't be any restriction on the size of string. And I want to copy the content of complete string str1 into string str2.
I assume you mean you want to duplicate the string, rather than just the pointer.
wcsdup() is the wide equivalent of strdup(), which will allocate the memory for the duplicated string.
Related
I have a Vec<Vec<char>> as a console frame buffer.
I'd like to render the buffer, but it would make me to print!() every char. I would like to represent the inner &Vec<char> as &str (not converting, not making a new String, but just casting) to print it as a whole with print!().
Is it possible, or is print!() already as fast for many characters as print!() for a single string slice?
A &str represents a reference to a memory location where a string is stored encoded using UTF-8.
Since your Vec<char> is not a string encoded using UTF-8, there is no way around creating a new String in memory somewhere that you can then reference.
Luckily it's easy and fast to convert, if v is your Vec<char>, it's simply v.iter().cloned().collect::<String>(). If you no longer wish to keep the old v around, you can replace .iter().cloned() with .into_iter().
I have a dump file that I am trying to extract a very long string from. I find the thread, then find the variable and dump part of it using the following steps:
~1s
dv /v, which returns:
00000000`07a4f6e8 basicString = class _bstr_t
dt -n basicString
Command 3 truncates the string in the debugging console to just a fraction of its actual contents.
What I would like to do is find the actual length of the _bstr_t variable so that I can dump its contents out to a file with a command like the following:
.writemem c:\debugging\output\string.txt 07a4f6e8 L<StringByteLength>
So my question is how can I determine what I should put in for StringByteLength?
Your .writemem line is pretty close to what you need already.
First, you'll need the correct address of the string in memory. 07a4f6e8 is the address of the _bstr_t, so writing memory at that address won't do any good.
_bstr_t is a pretty complicated type, but ultimately it holds a BSTR member called m_wstr.
We can store its address in a register like so:
r? #$t0 = ##c++(basicString.m_Data->m_wstr)
As Igor Tandetnik's comment says, the length of a BSTR can be found in the 4 bytes preceding it.
Let's put that into a register as well:
r? #$t1 = *(DWORD*)(((BYTE*)#$t0)-4)
And now, you can writemem using those registers.
.writemem c:\debugging\output\string.txt #$t0 L?#$t1
I have added the CString value in CPtrList. And using Find function. When I try to Find the CString value using Find method of CPtrList, I always got NULL position.
Below is my code to add the CString value in CPtrList ptrFolderPath:
CString sTemp;//
ptrFolderPath.AddTail(new CString (sTemp));
While searching I using below code:
POSITION pos = ptrFolderPath.Find(sPath.GetBuffer(sPath.GetLength()));
here sPath is a CString.
But the pos value is always NULL.
Any idea, where I am missing?
The key point is a line in the MSDN Help for CPtrList::Find(): "Note that the pointer values are compared, not the contents of the objects."
When your code calls "new CString (sTemp)" a new CString object is created, and what is returned (and added to the CPtrList) is the pointer value - the location in memory of your new CString. Let's say, for example, this is at memory location 0x001234500.
Your code that calls Find() is passing in the address of character buffer, but, even if this contains the same string characters as your above CString, its location in memory will be completely different. Since you're not passing in 0x0012234500 (in this example), you don't find the entry you expect.
Given what you appear to be trying to do, CPtrList is probably not the appropriate container type - something like CStringList would be more suitable, since there comparisons are done by value (i.e. the contents of the string) not by pointer.
If all this doesn't make sense, I'm afraid that you need to spend some time reading up on pointers, and concepts such as the difference between equality (two different objects that have the same value) and identity (different references to the same object)
I have the following code:
var wqry:TAdoQuery;
...
FillChar(wSpaces,cSpacesAfter,' ');
try
wqry := TADOQuery.Create(nil);//here the error
wqry.Connection:=...
cSpacesAfter is a constant and has the value 1035. wSpaces is a local string variable. The problem is that I receive the following error when TAdoQuery is created
even it is in french, I believe you got the idea.....
If I comment the FillChar code, everything works ok. I have the usual compiler directives, nothing special. I'm using Delphi 7.
Can someone tell me what is wrong with that code?
The troublesome code is most likely this one
FillChar(wSpaces,cSpacesAfter,' ');
I'm assuming that wSpaces is of string type. A string variable is in fact nothing more than a pointer to the data structure that holds the string. You don't need to use pointer syntax because the compiler takes care of that for you.
So what this code does is overwrite the variable holding that pointer with 4 space characters and then write 1031 more spaces over the top of whatever follows the variable. In short you will completely corrupt your memory. That would explain why the FillChar works but the very next line of code dies a painful and dramatic death.
If your string indeed had space for 1035 characters your could instead write:
FillChar(wSpaces[1], cSpacesAfter, ' ');
However, if may be more idiomatic to write:
wSpaces := StringOfChar(' ', cSpacesAfter);
FillChar procedure fills out a section of storage Buffer with the same byte or character FillValue FillCount times.
It is principally used to initialise arrays of numbers. It can be used to initialise records and strings, but care should be used to avoid overwriting length fields. StringOfChar is best for filling out strings to the same character.
Are you sure wSpaces has the size enough to fit all of cSpacesAfter you write to it?
I'm using the folowing code to read files from a folder in windows. However since this a MFC application I have to convert the char array to UNICODE. For example if I hard code the path as "C:\images3\test\" as shown below the code works.
WIN32_FIND_DATA FindFileData;
HANDLE hFind = INVALID_HANDLE_VALUE;
hFind = FindFirstFile(_T("C:\\images3\\test\\"), &FindFileData);
What I want is to get this working as follows:
char* pathOfFileType;
hFind = FindFirstFile(_T(pathOfFileType), &FindFileData);
Can anyone tell me how to fix this problem ?
Thanks
Thanks a lot for all your responses. I learnt a lot from those answers because I also didn't have much idea about what is happening underneath. Meanwhile I managed to get rid of the issue by simply converting to UNICODE using the following code with minimum changes to my existing code.
#include <atlconv.h>
USES_CONVERSION;
//An ANSI string
LPSTR lpsz_ANSI_String = pathOfFileType;
//ANSI string being converted to a UNICODE string
LPWSTR lpUnicodeStr = A2W( lpsz_ANSI_String );
hFind = FindFirstFile(lpUnicodeStr, &FindFileData);
You can use the MultiByteToWideChar function to convert a string from chars to UTF-16, but you'd better to get pathOfFileType directly in Unicode from the user or from wherever you take it, otherwise you may still experience problems with paths that contain characters not included in the current CP.
Your question demonstrates a confusion of several issues. First, using MFC doesn't mean you have to convert the character array to Unicode, one has nothing to do with the other. Furthermore, FindFirstFile is a Win32 API, not an MFC function. Finaly, _T("abc") is not necessarily unicode, rather _T(X) is a macro that in multi-byte builds expands to X, and in unicode builds expands to L X, creating a wide character literal. This is designed so that your code can compile in a unciode or multi-byte configuration. To achieve the same flexibility when declaring a variable, you use the TCHAR type instead of char or wchar_t. So your second snippet should look like
TCHAR* pathOfFileType;
hFind = FindFirstFile(pathOfFileType, &FindFileData);
Note no _T macro, that is only applied to string literals, not identifiers.
"since this a MFC application I have to convert the char array to UNICODE"
Not so. If you wish, you can use change to use the Multi-Byte Character Set.
In project properties, general change character set to 'Use Multi-Byte Character Set'
Now this will work
char* pathOfFileType;
hFind = FindFirstFile(pathOfFileType, &FindFileData);
Supposing you want to use UNICODE ( visual studio's name for the 2 byte encoding of UNICODE characters native to Windows ) then you have to explicitly call the MBCS version of the API
char* pathOfFileType;
hFind = FindFirstFileA(pathOfFileType, &FindFileData);