|
Don't take this as gospel unless someone at Microsoft confirms it but SysAllocString is potentially faster than using a simple wide character string becuase it uses some kind of reserved string memory. Could be part of non-paged pool or another special memory area. Someone may be able to point you at MS documentation as to how this works but I have never seen any.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
So you never use Matthew? What do you use instead? 
regards,
George
|
|
|
|
|
Yes I use BSTRs (known as bee stings because they can be painful ) every day, generally on WinCE though where the memory model is a bit different. They are indeed allocated by the COM runtime and almost certainly in some sort of 'global' memory belonging to the COM runtime itself. Check out CoTaskMemAlloc, I suspect that's what's being used under SysAllocString. Can't prove it though.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
I am interested to learn what do you mean *memory belonging to the COM runtime itself*? For example, in the following scenario, an EXE will utilize an in-process server COM DLL.
1. The EXE will load the in-process server COM DLL into its process space;
2. When we use SysAllocString to allocate memory for strings in the in-process server COM DLL, the memory will brlongs to the EXE heap space? or the *memory belonging to the COM runtime itself*? What is COM runtime? A separate process or some other DLLs loaded by the EXE which utilizes the in-process server COM DLL?
regards,
George
|
|
|
|
|
The COM runtime is a bunch of DLLs e.g. oleaut32.dll which implement COM itself. These get loaded into your EXE process but they contain code capable of crossing process boundaries and the Kernel/User mode boundary so it is theoretically possible for COM runtime data to exist across processes( The Running Object List is a mysterious beast of this kind). BSTRs are certainly allocated per-process and have to be auto-marshalled to transfer them but because of the peculiar nature of the COM allocator it may or may not be using the processes normal heap. If it is then it isn't using it through the normal (slow) heap manager. I don't know whether COM simply uses it's own manager on a preallocated chunk of the default heap, uses a second help, or uses Kernel memory outside the process but assigned to it. It is capable of all 3 but only MS would know for sure where BSTRs really live and why they turn out slightly faster than ordinary strings.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
Why do you think BSTR is faster than ordinary strings? Do you have any performance data?
regards,
George
|
|
|
|
|
I don't have any data but the excolleague of mine who wrote the high performance String classes for my company did do a lot of testing and he reckoned BSTRs were faster in real usage than the alternatives. I suspect this is to do with their use of the COM memory allocator.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I don't know if you have noticed[^] but SysAllocString is part of the COM library (you need to link to oleaut32.lib if you use it).
The returned type is a BSTR – a string type used by COM – rather than a WCHAR *. The differences are:
- BSTRs are allocated using the COM allocator, so they can passed to another process (and deallocated by another process). This is why you should use SysFreeString rather than delete or free.
- BSTRs have a length prefix (besides having null terminator).
The length is kept (as a UINT) in the memory location just before the first character.
The BSTR type is actually defined as a WCHAR *, pointing to the first character (just like a regular LPWSTR), so you can use BSTRs wherever you can use LPWSTRs. Just remember that you should use SysFreeString to deallocate it.
So, a regular string looks in memory like this:
S o m e [space] t e x t [null]
53 00 6f 00 6d 00 65 00 20 00 74 00 65 00 78 00 74 00 00
whereas a BSTR looks like this
string length S o m e [space] t e x t [null]
09 00 00 00 53 00 6f 00 6d 00 65 00 20 00 74 00 65 00 78 00 74 00 00
Hope this clears things up a little bit.
See also this page[^].
Florin Crişan
|
|
|
|
|
Cool Florin!
I have a further question, you mentioned below,
Florin Crisan wrote: so they can passed to another process (and deallocated by another process).
I do not quite understand what do you mean passing to another process? In my limited knowledge, I only developed in-process server COM (.DLL) before and I have never met with situation that I need to pass something to another process (in-process server COM DLL will be loaded by another process).
It is appreciated if you could provide more information about what do you mean passing the BSTR value to another process.
have a good weekend,
George
|
|
|
|
|
I'll reply to that...
If you used an out of process COM (either just in an exe, or on another machine), windows does the heavy lifting of transferring the parameters to your COM interface functions for you.
BSTR is a) Easy for it to marshall (moving about) and (b) is the string type originally used by VB, so your COM object can be used by VB programs, VBScript, etc. Lots more than clean nice pure C++ programs.
Iain.
|
|
|
|
|
Thanks Iain,
As you mentioned marshall, it is one of the things I want to learn in the past, but missed some good tutorials. I have C++ native unmanaged COM (in-process server) development experience, could you recommend some learning materials about marshall please?
regards,
George
|
|
|
|
|
Sorry, I've just been picking this stuff up as I go.
I would recommend Michael Dunn's series on shell extensions for a good (free) start.
Iain.
|
|
|
|
|
Hi Iain,
What do you mean *Michael Dunn's series on shell extensions*? Could you provide an URL please?
regards,
George
|
|
|
|
|
Try using the author search - they'll be pretty obvious!
Iain.
|
|
|
|
|
SysAllocString() creates a BSTR (BASIC STRing), which is the primary means for passing strings between COM objects. Memory for the string is managed by COM. Depending upon the usage, you may need to call SysFreeString() to release the memory allocated to the string when you're finished with it.
If you are using COM, then you will probably need to use BSTR's.
There is no performance or other advantage to using them otherwise. If you just need simple wide character strings, use wchar_t strings.
Software Zen: delete this;
|
|
|
|
|
Thanks Gary,
I have also done some self-study, here in MSDN
http://msdn2.microsoft.com/en-us/library/ms221069.aspx
It is mentioned,
BSTRs are allocated using COM memory allocation functions. This allows them
to be returned from methods without concern for memory allocation.
I do not quite understand what does it mean? No need to take care of memory
allocation? We still need to call SysFreeString manually.
regards,
George
|
|
|
|
|
Hello,
Can we use DoModal like this:
<br />
CMyAlert *alert = new CMYAlert;<br />
alert->Create(CMYAlert::IDD,this);<br />
<br />
<br />
if (alert->DoModal()==IDOK)<br />
{<br />
message("IDOK is clicked")<br />
}<br />
I want to know when IDOK is clicked On CMyAlert,
Is there another way to know it?
thanks
|
|
|
|
|
Gofur Halmurat wrote: I want to know when IDOK is clicked On CMyAlert,
The CMyAlert dialog will have to notify the parent window that the OK button was clicked. either by passing a pointer to the parent to the dialog? or from the dialog, send a private message to the parent window saying the OK was clicked.
What is your intention ?
Do you want to have the dialog dismissed when the user clicks on Ok ?
|
|
|
|
|
Hello,
My parent window has a button, if i click the button the CMyAlert appears, and there is a button on CMyAlert, when i click the button on CMyAlert, Some changes will have to be done on parent window. How can i implement this?
either by passing a pointer to the parent to the dialog? or from the dialog, send a private message to the parent window saying the OK was clicked.
How can i implement this option? can u show me with examples?
thanks
|
|
|
|
|
are you wanting a modeless dialog by any chances ?
if not, then why don't you do the job when the modal dialog is closed ?
|
|
|
|
|
Hello,
yes, i want a modeless dialog by any changes
|
|
|
|
|
so you mustn't use DoModal() (which, as its name states, creates a Modal Dialog).
use Create() method to create it.
to have the possibility to modify the window which spamn it, you must give it a pointer to its parent (commonly, this) as a constructor parameter
also read This[^] good article about modeless dialogs.
|
|
|
|
|
Thanks, that was what i was looking for. it helped me alot
|
|
|
|
|
And no, you can't use Create() and DoModal() - you use one or the other,
depending on whether you want a modal or a modeless dialog.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
No. By calling the Create function for your alert dialog, you've made it a modeless dialog. Calling DoModal() in this case will not work correctly.
There are two solutions here. One, use the alert dialog modally:
CMyAlert *alert = new CMyAlert;
if (alert->DoModal() == IDOK) {
message("IDOK is clicked");
}
delete alert;The second is to use your alert dialog as a modeless dialog, and have it send a user-defined message to the parent when the OK button is clicked, which is more complicated:
#define WM_MyAlertMessage (WM_USER + 1)
void CMyAlert::OnOK()
{
CWnd *parent = GetParent();
if (parent != NULL) {
parent->SendMessage(WM_MyAlertMessage,0,0);
}
}
BEGIN_MESSAGE_MAP(CMyParentWindow,CDialog)
ON_MESSAGE(WM_MyAlertMessage,OnMyAlertMessage)
END_MESSAGE_MAP()
LRESULT CMyParentWindow::OnMyAlertMessage(WPARAM ,LPARAM )
{
message("IDOK is clicked");
return (LRESULT)0;
}
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
