|
Gary R. Wheeler wrote: Do you know of any benchmark results?
Nothing scientific, just empirical testing.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Gary R. Wheeler wrote: Is string actually faster? Do you know of any benchmark results? I've got a couple classes in an application that use CString heavily, and wonder if string would improve their performance.
The memory allocation schemes are different between the two. I believe (but I could be wrong) that the std::string object allocates like std::vector does - that is, it doubles each time. 8 characters, then 16 characters, then 32 characters, etc.
CString on the other hand, basically only allocates what it needs. In MFC 6.0 release mode, CString will use the CPlex* allocators which allocate memory in fixed sized chunks, so that if you keep appending smaller strings or single characters to a CString it may not have to reallocate each time.
std::string can have its reference counting turned off (or it may be by default in some implementations), which may increase its performance a bit.
I guess it would depend on the usage of the string object. If you are simply using them as replacements for a manually managed char buffer, and are not doing anything really specific to a string object with it, you may not notice much difference. If you build strings through constant append operations, you may notice a difference.
If using a multithreaded VC++ 6.0 app, you can customize the allocator used for std::string much easier than CString, which will allow you to help mitigate heap contention between threads. (Which can be a big hit if CString abuse is high.)
:P IMHO, the best way you can increase CString performance is to avoid it entirely! :P
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
|
|
|
|
|
James R. Twine wrote: std::string can have its reference counting turned off (or it may be by default in some implementations), which may increase its performance a bit.
See the comparison in http://www.codeproject.com/string/fix_str.asp[^]
|
|
|
|
|
Unless I am missing something, I am not seeing a good comparison there. I see a few mentions of the words "fast" and "slow" but nothing that shows exactly how fast or slow something is. Something has to be faster or slower than another.
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'm having some issues converting to wide char string, and I think my brain is too far shot to figure it out anymore 
Not using UNICODE, so I'm trying to convert a filepath returned from GetOpenFileName into a wide string to pass to a DirectShow function. Looks like this:
TCHAR achPath[MAX_PATH];<br />
WCHAR wcPath[MAX_PATH];<br />
<br />
...after GetOpenFileName<br />
<br />
sprintf(achPath, ofn.lpstrFile);<br />
int nLen = MultiByteToWideChar(CP_ACP, 0, (LPCSTR)achPath, -1, NULL, NULL);<br />
MultiByteToWideChar(CP_ACP, 0, achPath, -1, wcPath, nLen);<br />
nLen is returning the correct number.
If I use nLen as the last parm in the second call, I get only the first char in wcPath. If I use NULL, I get a whole bunch of weird chars, then the full path at the end.
I'm sure I'm doing something stupid, but my brain is not working well on this one. Help 
|
|
|
|
|
These APIs r complicated. Better u use CRT functions.
From Wide to MultiByte, use wcstombs ().
From MultiByte to Wide, use mbstowcs ().
These two CRT function r very simple to use and reliable, ofcourse.
Come online at:-
jubinc@skype
|
|
|
|
|
Don Box wrote: These APIs r complicated. Better u use CRT functions.
Is that a joke?
|
|
|
|
|
This code works perfectly for me. Can you give more inputs,
Here is its snippet,
TCHAR achPath[MAX_PATH];
WCHAR wcPath[MAX_PATH];
OPENFILENAME ofn;
TCHAR szFile[260]={0};
ZeroMemory(&ofn, sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hwndOwner = this->m_hWnd;
ofn.lpstrFile = szFile;
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFilter = "*.TXT\0";
ofn.nFilterIndex = 1;
ofn.lpstrFileTitle = NULL;
ofn.nMaxFileTitle = 0;
ofn.lpstrInitialDir = NULL;
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
if (GetOpenFileName(&ofn)!=TRUE)
{
return;
}
sprintf(achPath, ofn.lpstrFile);
int nLen = MultiByteToWideChar(CP_ACP, 0, (LPCSTR)achPath, -1, NULL, NULL);
MultiByteToWideChar(CP_ACP, 0, achPath, -1, wcPath, nLen);
|
|
|
|
|
I finally got too frustrated with MultiByteToWideChar. So I ended up doing it like this, which works fine:
WCHAR wFile[MAX_PATH];
wcsncpy(wFile, T2W(ofn.lpstrFile), NUMELMS(wFile)-1);
Thanx for getting me back on track 
|
|
|
|
|
Actually, you can just do:
WCHAR *wFile = T2W(ofn.lpstrFile); - Because T2W(...) returns a pointer to memory allocated from your own stack. Which, BTW, is why you need to be very careful with how you use things like _alloca(...) and the conversion macros. Do not use them in loops or with large amounts of memory.
There is no reason to copy that string twice.
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
|
|
|
|
|
Where can I find the basics to start learning the usage of graphics library functions(OpenGL)?Plz help.........
Thanks
|
|
|
|
|
|
I need to include a little assembly language in my code. I have no problem with 32 bit builds, but I have no way of testing a 64bit build. After reading this[^] page, it tells me there is no more __stdcall and __thiscall calling conventions in the 64bit architecture. So I'm wondering what is happening to the this pointer on member functions.
If anybody has access to a 64bit environment, could you please do me a favour? Place a breakpoint on any member function, and tell me in which register is the this pointer being stored.
Thankyou.
|
|
|
|
|
The answer is compiler-specific. Check your compiler documentation.
Software Zen: delete this;
|
|
|
|
|
http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx[^]
About 1/2 way down:
The primary thing to know about the x64 calling convention is its similarity to the x86 fastcall convention. Using the x64 convention, the first four integer arguments (from left to right) are passed in 64-bit registers designated for that purpose:
RCX: 1st integer argument
RDX: 2nd integer argument
R8: 3rd integer argument
R9: 4th integer argument
Integer arguments beyond the first four are passed on the stack. The this pointer is considered an integer argument, so can always be found in the RCX register. As for floating point parameters, the first four are passed in the XMM0 through XMM3 registers, with subsequent floating point parameters placed on the thread stack.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
I use CreatePropertySheetPage to create three pages and they work fine
in normal case. When destroy the node, I send WM_CLOSE message to the
property sheet window using the handle that saved in fist page's
procedure function. Then page's WM_DESTROY will be called when get
WM_CLOSE message.
But If I call PropSheet_CancelToClose and PropSheet_Changed in page's
procedure function, WM_DESTROY will not be called when node sends
WM_CLOSE.
I don't know the reason.
Anybody knows?
|
|
|
|
|
Are you always calling DefWindowProc() when you get a WM_CLOSE message?
|
|
|
|
|
No, I don't call DefWindowProc
|
|
|
|
|
Then do you call DestroyWindow()? That's the only way you'll eventually get the WM_DESTROY
message through WM_CLOSE.
Mark
|
|
|
|
|
It doesn't work. The property sheet doesn't recieve the WM_DESTORY message at all.
|
|
|
|
|
Modal or modeless? If modeless, are you using the handle returned by PropertySheet()?
|
|
|
|
|
The property sheet is modeless window
|
|
|
|
|
Hi everyone,
In a project I have to implement area selection by polygons and as I don't want to invent the wheel for the fourth or fifth time, I'd like to ask, wether someone knows of a good library or so, helping me to manage polygons. I hope for some code that also includes constructing by mouse, editing (inserting and moving vertices), checking for intersection and overlapping, filling by hatching (or some other transparent filling) etc. but even the most basic functionality will help.
Thanks in Advance
Martin Dietz
|
|
|
|
|
Hai,
I was running "BAT" file in Dos Prompt for Vc++ files .
in that while running iam getting the following error:
Command line error D2022 : cannot open '..\cfront\cl_preprocess_options.txt'
Can anyone please tell how to rectify it
Thanks
Harshadha..
|
|
|
|
|
harshadha wrote: Command line error D2022 : cannot open '..\cfront\cl_preprocess_options.txt'
Create a text file at one directory up, then down into cfront-directory, and name it cl_preprocess_options.txt
Thats the answer to yout question. It is probably only mildly helpful.
With a few wild guesses and completly unjustified assumptions, I would say that you did some mistake unzipping the source code you want to work at.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
