|
When I look at a class like MyClass (in your original post), I would assume that the lifetime of the vector would be the same as the lifetime of the object that contains it. I would control when the vector gets destroyed by controlling the lifetime of the MyClass object, rather than getting a pointer to the vector out of the object.
Similarly, I would assume that the lifetime of the vector inside an OtherClass object should be the same as the object containing it.
For both of these objects, this seemed to be the case, as you were allocating the vector in the constructor of the object. You didn't show a destructor, so I couldn't tell whether you intended to keep the vector after destroying the object.
You might want to rethink this, as it seems that the ownership of the vectors really belong to the objects that contain the pointers.
I don't know what your intentions are, so I am not sure which way I would change this. ( Of course, you can just leave it the way it is... I am just giving my opinion  )
If you intend MyClass to be a class that initializes a vector of OtherClass objects, but does not have anything to do with the vector afterwards, I would probably pass a reference to the vector to the constructor of the MyClass object. The ownership of the vector would then be outside of the MyClass object. The vector would persist because it would be declared at a higher level, and passed in to the MyClass object for initialization. The vector object could be declared as high level as you need it to persist, and could be passed by reference to the various routines that need it.
If you intend MyClass to be a class that is a vector of OtherClass objects, I would keep the actual vector inside the object (not a pointer), and make sure that the MyClass object persists (by either declaring it at a high enough level that it remains in scope, or by allocating a MyClass object with new). I personally would lean this way, as I could then add routines to manipulate the vector to the MyClass object.
Best regards,
John
|
|
|
|
|
I am using ofstream to write very large files, of size greater than MAX_LONG. It works fine except for one problem; when the file gets to big I cannot use tellp() to get the file position. It seems a little weird; tellp() returns an fpos<int> object which has a __int64 member in it (returned from get_fpos_t()) -- so I should be able to get the file size out of that member. But once the file size is over 2GB, that member is set to 0. What can I do? I am using Visual C++ 6.
READIN writin rhythmetic
|
|
|
|
|
What OS ? 2 gb is the file size limit for W98, which may be the issue.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Windows 2000 -- the file is getting written just fine, 7G output last time I ran the project; but while I'm writing I want to store file positions in an index file and cannot do that if I can't get a good file position. The workaround I found is to flush the file, then use _stati64 to get the file size -- I would prefer an STL solution if one exists.
READIN writin rhythmetic
|
|
|
|
|
Get it here! Enjoy the reading.
|
|
|
|
|
hi,all:
I have a ATL server ,and it support an interface with Connection Point.
I use MultiClient connect the Connection point.
I hope that,when data is received the connect point can fire all the
Connected Client. But I found that only the last client can receive the
fire. I mean that the number of connections in server is always 1.
Though the fact is MultiClient has Connected. It looks that ,all clients
were throw into a stack ,server process it one by one.
Why??
___________________________________________
HRESULT Fire_Draw(INT type, INT x, INT y)
{
CComVariant varResult;
T* pT = static_cast<t*>(this);
int nConnectionIndex;
CComVariant* pvars = new CComVariant[3];
int nConnections = m_vec.GetSize();
for (nConnectionIndex = 0; nConnectionIndex < nConnections;
nConnectionIndex++)
{
pT->Lock();
CComPtr<iunknown> sp = m_vec.GetAt(nConnectionIndex);
pT->Unlock();
IDispatch* pDispatch = reinterpret_cast<idispatch*>(sp.p);
if (pDispatch != NULL)
{
VariantClear(&varResult);
pvars[2] = type;
pvars[1] = x;
pvars[0] = y;
DISPPARAMS disp = { pvars, NULL, 3, 0 };
pDispatch->Invoke(0x1, IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_METHOD,
&disp, &varResult, NULL, NULL);
}
}
delete[] pvars;
return varResult.scode;
}
_____________________________________
m_vec.GetSize() is always 1.
I love fish,like i love C++.
|
|
|
|
|
Hi, all, i want to learn ATL, i could find books just like
<inside atl=""> <atl internal="">, but i heared that these books
are not suit to a beginner 
Someone said <developers workshop="" to="" com="" and="" atl="" 3.0=""> is a
nice book for ATL beginner, but i cann't find it in China
I want download a ebook, but i cann't find it on Web.Can
anybody tell me where i can download a ebook?
Thanks~~
.
|
|
|
|
|
Hi All,
After reading Michael Dunns WTL articles I want to convert my ATL/MFC COM Dlls to ATL/WTL ones.
Building the DLL from base setting I have built a standard ATL project and then added the required WTL #includes as per the examples in Michaels articles. I have changes the CComModule to CAppModule and compiled. Everything works a treat!
I am little bit confused though an where to exactly define/create my CMessageLoop object.
Should I do this in the DLLMain function?
<br />
extern "C"<br />
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID )<br />
{<br />
if (dwReason == DLL_PROCESS_ATTACH)<br />
{<br />
_Module.Init(ObjectMap, hInstance, &LIBID_WTLHISTORYLib);<br />
DisableThreadLibraryCalls(hInstance);<br />
<br />
CMessageLoop* pLoop = _Module.GetMessageLoop();<br />
<br />
ATLASSERT(pLoop != NULL);<br />
pLoop->AddMessageFilter(this);<br />
pLoop->AddIdleHandler(this);<br />
}<br />
else if (dwReason == DLL_PROCESS_DETACH)<br />
_Module.Term();<br />
return TRUE;
}<br />
What the DLL is to do is:
Have however many classes required, each implementing whatever COM interfaces that they need too
Do there thing and return back to Calling Application.
Am I in the right ballpark or because it is a DLL each COM implemented class has its own map... like below
<br />
class ATL_NO_VTABLE CMyReport: <br />
public CComObjectRootEx<CComSingleThreadModel>,<br />
public CComCoClass<CMyReport, &CLSID_MyReport>,<br />
public ISupportErrorInfo,<br />
public IHistoryReport,<br />
public ICommand<br />
{<br />
public:<br />
CMyReport();<br />
~CMyReport();<br />
<br />
DECLARE_REGISTRY_RESOURCEID(IDR_MYREPORT)<br />
<br />
DECLARE_PROTECT_FINAL_CONSTRUCT()<br />
<br />
BEGIN_COM_MAP(CMyReport)<br />
COM_INTERFACE_ENTRY(IMyReport)<br />
COM_INTERFACE_ENTRY(ISupportErrorInfo)<br />
COM_INTERFACE_ENTRY(ICommand)<br />
END_COM_MAP()<br />
<br />
BEGIN_CATEGORY_MAP(CMyReport)<br />
IMPLEMENTED_CATEGORY( __uuidof(CATID_MxCommands))<br />
END_CATEGORY_MAP()<br />
<br />
public:<br />
STDMETHOD(get_Enabled)(VARIANT_BOOL * Enabled);<br />
STDMETHOD(get_Checked)(VARIANT_BOOL * Checked);<br />
STDMETHOD(get_Name)(BSTR * Name);<br />
STDMETHOD(get_Caption)(BSTR * Caption);<br />
STDMETHOD(get_Tooltip)(BSTR * Tooltip);<br />
STDMETHOD(get_Message)(BSTR * Message);<br />
STDMETHOD(get_HelpFile)(BSTR * HelpFile);<br />
STDMETHOD(get_HelpContextID)(LONG * helpID);<br />
STDMETHOD(get_Bitmap)(OLE_HANDLE * Bitmap);<br />
STDMETHOD(get_Category)(BSTR * categoryName);<br />
STDMETHOD(OnCreate)(IDispatch * hook);<br />
STDMETHOD(OnClick)();<br />
<br />
private:<br />
};<br />
Thanks for your help in advance
cheers
Bryce
|
|
|
|
|
CMessageLoop is a WTL class, and _Module has to have message loops added to it explicitly. IOW there is no API or method that says "give me some object representing the EXE's message loop"
Also, _Module is per-module (thus the name), unlike MFC DLLs where several DLLs can share the same CWinApp object. So unless you control the EXE as well, the DLL has no access to the EXE's message loop. If you do control the EXE too, I guess you could pass a pointer to the DLL, although it wouldn't be possible to get to it in DllMain(); you'd need some other exported initialize function that the EXE would call.
Now, if you create your own UI threads in the DLL, then you control the message loop and you can set up the CMessageLoop object like you want.
--Mike--
Ericahist [updated Oct 26] | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
If my rhyme was a drug, I'd sell it by the gram.
|
|
|
|
|
Hi,
If I use a stl deque as a buffer between two threads. If thread A would only push at the back and thread B would only get and pop from the front. (Both without locking) And I would make absolutely sure tha at least one element stays in the deque as a delimiter. Would I run in to any issues that could cause data corruption or racing conditions?
If I would run into problems is there another way to make sure that thread A can always push its data without having to wait? (it has a time critical task)
Thanks a lot in advance,
Erik
|
|
|
|
|
I think it is implementation specific - but I would normally put here some locking mechanism - it's shared resource between two threads - it means, say on two processor machine you can have half pushed object in a dequeue and in the very same moment second thread running in another processor receives that half baked object and consider that it's complete - where it can lead noone knows...
How to do it without waiting in A thread - that depends on your requirements - e.g. I can imagine a mechanism where thread A makes some batches (queue of commands say) and when there's some free time or the queue reaches some maximum size it's marked as complete (event signalled e.g.) and pushed to the thread B for processing, while A thread creates new (or uses previously created) queue for pushing...
just an idea, maybe there can be dozens of other solutions, it really depend on the requirements you have for the processing.
hope this helps
|
|
|
|
|
One solution is a critical section for single process and a mutex for multiple processes. Check the size of the container.
Kuphryn
|
|
|
|
|
I don't think that you can do this without using a critical section. You have to synchronize access in some way. I'd be interested to hear more on your plan for this delimiter object-- how do you think that it will solve the problem of A and B both accessing the same memory at the same time? I'm really curious.
One tactic that you can take is to buffer things a little before even putting them in the queue. A can stack up a few things destined for the queue, and just copy them into the queue on a scheduled basis or when the buffer gets full. In my experience, it will still have to lock, but this can greatly decrease the per-element synchronization overhead. Of course, this can mean some tradeoffs like extra memory overhead, and another drawback is that the elements aren't immediately made available to thread B.
Thank you.
Jeff Varszegi
|
|
|
|
|
Well my thought was because a deque is basically made up out memory ellements with two pointers one to the next element and one to the pervious. So if you make sure one or two elements always stay in the deqeu the two threads wil never access the same memory space (because each thread only operates at one end of the queue). At least that is my theory please correct me if I'm wrong.
But apperantly it's safest to find some locking meganism, the problem is just that thread A is reading from a serial port, so I never really know whether I have time to wait for a lock on the deque, or I'll mis incomming bytes. Secondly it's rather important to get all bytes in de deque as soon as possible (I need to register when they got in), so buffering them is not really an option.
Thanks for all reactions,
Erik
|
|
|
|
|
There are many approaches. Depending on what you are doing, have a searh on google for Producer/Consumer, Bounded Buffer and Multiple Reader/Writer as thread syncronisation methods. If you have just two threaads, then all you should need is a Mutex or a Critical Section (which is a faster method for all in process - Mutex can do cross process).
If you want to limit the size of the buffer i.e. the writer can outrun the reader, then have a look at the bounded buffer.
Personally for lots of different patterns with good descriptions and full working implementations is a book called "Multithreaded Programming with Win32" written by T.Q. Pham and P.K. Garg.
Its even demonstrates a multithreaded quicksort.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table.
Shameless Plug - Distributed Database Transactions in .NET using COM+
|
|
|
|
|
Hello,
I am using eVC 3.0 and trying to build a database application. I am using an #import of arm\adoce31.dll. It is giving me a linker error [CODE]unresolved external symbol "class _variant_t vtMissing"[/CODE].
I have read in one section of MSDN that vtMissing is suppiled by #import. Do I have to include some more libraries ?
Many thanks in advance.
Regards,
Amit
|
|
|
|
|
If this is the only value you are missing
just define your own:
vtMissing.vt = VT_ERROR;
vtMissing.scode = DISP_E_PARAMNOTFOUND;
|
|
|
|
|
I am brand new to STL so please bear with me. I am creating an item Label based on an abstract class button. In code in the first segment works for me as expected. But In the second part I was not expected to have to cast (delete (Label*)pB; ) as noted below. When I don't cast the destuctor does not get called.
So, finally my question. As I am going thru the vector should I have to know each type of thing being deleted so I can cast it accordingly or am I approaching this all wrong?
In my application I was only using ( delete pB; ) and this is causing a memory leak. The only solution I see during clean up I query each object being destroyed for its type then call the appropriate code.
for example
if( objecttype == Label )
delete (Label*)pButton;
else if ( objecttype == Image )
delete (Image*)pButton;
This seems wrong to me. Please enlighten me.
// First part of code example
std::vector<Button*> vButtons;
pButton = new Label( ... );
vButtons.push_back( pButton );
// Second part of code example
int count = vButtons.size();
if( count > 0 )
{
std::vector<Button*>::iterator it;
Button *pB;
for (it = vButtons.begin(); it != vButtons.end(); ++it)
{
pB = *it;
if(pB != NULL)
{
delete (Label*)pB;
pB = NULL;
}
}
vButtons.clear();
}
|
|
|
|
|
Did you declare your destructor (in the button class) as virtual?
John
|
|
|
|
|
Thanks, that worked great. I guess you noticed that I am new to more than just STL.
|
|
|
|
|
smesser wrote:
I guess you noticed that I am new to more than just STL.
No problem, thats what the forums are for. I remember having the same problem a few years back...
John
|
|
|
|
|
John M. Drescher wrote:
No problem, thats what the forums are for. I remember having the same problem a few years back...
Well, thanks again for your wisdom.
Steve
|
|
|
|
|
hi,
How can i convert the window handle in to object pointer
Regards
Abhay
eeeshwar
|
|
|
|
|
Hi there,
suppose u have HANDLE , HWND of a Window class CWnd
Create a Object of that class
HWND m_hwnd
CWnd wndObj;
or CWnd *wndObj=new CWnd()
wndObj.Attach(m_hwnd)
or wndObj->Attach(m_hwnd)
in this way object is created.
is that u wnat to know
Abhishek Srivastava
Software Engg (VC++)
India ,Noida
Mobile no 9891492921
|
|
|
|
|
hi,
i tried the same i wrote win32 dll with following code:
long __declspec(dllexport)__stdcall GetControlReference(long handle)
{
long reference;
CWnd* controlwindow=new CWnd();
controlwindow->Attach((HWND)handle);
reference=(long)controlwindow;
return reference;
}
//here is my vb client
function GetObject (hwnd1) as object
dim obj as object
dim ret as long
ret = GetControlReference(hwnd1) //calling win32 dll
If Not IsBadCodePtr(ret) Then
CopyMemory obj, ret&, 4
If Not obj Is Nothing Then
Set GetObject = obj //crashing here
CopyMemory obj, 0&, 4
End If
End If
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
