|
Thanks for that. Interesting article.
STL's vector and sort are looking more elegant, but I've used a lot of CArray's over the years...
Decisions... decisions!
Iain.
|
|
|
|
|
The 'cheat' I generally use for this is a bit of a zen solution. I don't sort the array at all 
Instead I keep a parallel array of simple unsigned integers and I sort that and use it as an index into my array of complex objects. I use the standard sort algorithums but my comparator functions, instead of just comparing integers uses them to look up the real array and returns a comparison result dependent on what it finds there.
If you dig around in the source of my constructional patterns article [^] you'll find an indexed list class, possibly even templated so you use it with your data structures.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
"The best way to sort is to not sort at all".
Very wax-on, wax-off...
My structures are not highly horrible to swap about, luckily, but I can see your method being very useful if copying is an expensive or impossible process (ie, open DB handles are a classic baddie).
As you normally give good answers, I assume your articles are worth a peek too...
Iain.
|
|
|
|
|
Thanks for the vote of confidence, it's nice to be able to actually point someone at some relevant code for a change. I'm always finding myself wanting to refer to code, in answers to questions, which I either can't post or no longer have or worse still know that I must have but can't find.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Iain Clarke wrote: How to [...] with minimum effort
Uhmmmmmmmmmmmmm, what a lazy guy. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: what a lazy guy.
Isn't that the best bit about programming? The lazy way is often the best one. Less typing -> less bugs.
That only works if you're lazy over the long term though... Short term laziness leads to more work overall.
(And yes, I know you were getting at me. Sigh... I'm such a martyr...)
Iain.
ps, "Infamy, infamy, they've all got it in for me!".
|
|
|
|
|
Unless it's a trivial structure, if I need to sort an array, I usually use a pointer array. Swapping items then becomes just swapping the pointer.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
HI,
Could anyone see memory leak in following code? When I used some debugging tool, it is telling me 'Memory Leak due to reassignment:Address 0x10084 allocated by global_operator_new'.
static const char DEFAULT_DATE_FORMAT[] = "US";
DSLoginConfigurationImplementation::DSLoginConfigurationImplementation(const char *CategoryPath):m_ImportDateFormat(NULL)
{
Restore(CategoryPath);/*This function will call below function*/
}
void DSLoginConfigurationImplementation::SetInputDateFormat(const char* ImportDateFormat)
{
if(!DSAccessConfigurationImplementation::GetInUse())
{
if(m_ImportDateFormat!=NULL)
{
delete [] m_ImportDateFormat;
m_ImportDateFormat=NULL;
}
if(ImportDateFormat!=NULL && strlen(ImportDateFormat))
{
m_ImportDateFormat=new char[strlen(ImportDateFormat)+1];/* debugger is pointing here showing memory leak*/
strcpy(m_ImportDateFormat,ImportDateFormat);
}
}
}
Please help.
Thanks in advance.
|
|
|
|
|
That seems pretty straight forward, m_ImportDateFormat is being allocated with new at the line indicated and then never deleted. The only delete I can see in your sample occurs before the new!
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
m_ImportDateFormat is a class member variable and it has taken care in the destructor. Meory allocated here is de-allocated in the destructor.
|
|
|
|
|
SRKSHOME wrote: in this code?
Well, if you're going to cheat and start tidying up outside, then all bets are off!
Please modify your post to use the pre tags (code block). It's hard enough reading your own code, let alone others. And other people's code without formatting is even harder.
Iain.
|
|
|
|
|
I am sorry for that. There was no intention like you think.
|
|
|
|
|
SRKSHOME wrote: I am sorry for that. There was no intention like you think.
It's alright - I missed off the joke icon on my reply. Noone deliberately sabotages themselves. I hope you've found your memory leak!
Iain.
|
|
|
|
|
|
In that case plase post the destuctor code and any check the code that allocates and deallocates the objects of which the problem item is a member, your problem migth be further up the chain but the symptoms only showing up here.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks Matthew. I will dig it up further.
|
|
|
|
|
Hi all,
in my application i want to get the devicename of the external HID devices connected to the sytem from the device manager .I am using GetRawInputDeviceInfo()and i have included the header files winuser.h and windows.h and imported the user32.dll and included the library USER32.LIB in the debug folder.
Even then i am getting the error as GetRawInputDeviceInfo undeclared identifier....
Can anyone suggest me the reason for this??
Thanks in advance....
modified on Tuesday, September 16, 2008 5:58 AM
|
|
|
|
|
What are you trying to do?
GetRawInputDeviceInfo() does not even provide you with a device name and/or symbolic link.
To get the friendly names and symbolic links to devices attached to the system you should use the setup API, such as ::SetupDiEnumDeviceInfo().
Have a look here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
modified on Tuesday, September 16, 2008 6:10 AM
Pulled the function name out of my memory, which turned out to be wrong...
|
|
|
|
|
Roger Stoltz wrote: GetRawInputDeviceInfo() does not even provide you with a device name and/or symbolic link.
GetRawInputDeviceInfoW(hDevice, RIDI_DEVICENAME, pData, pcbSize);
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Sorry about that, you're right; you can get the device name with ::GetRawInputDevice().
I didn't read the docs carefully enough... 
I suppose the answer you got from Sarath helped you.
Otherwise post again...
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
The function runs only under windows XP or above. Please check the WINVER definition in your stdafx.h. before including the windows header, define it as 0x501
Check MSDN: using the Windows Headers[^]
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Hello, I have a view that has a property sheet and property pages. when I want start a new document an assertion error happens. I followed the call stack and found out that problem occurs at this function
CWnd* PASCAL CWnd::FromHandlePermanent(HWND hWnd)
{
CHandleMap* pMap = afxMapHWND();
CWnd* pWnd = NULL;
if (pMap != NULL)
{
pWnd = (CWnd*)pMap->LookupPermanent(hWnd);
ASSERT(pWnd == NULL || pWnd->m_hWnd == hWnd);
}
return pWnd;
}
I took the hWnd and searched it in spy++ windows list and I found out that this window is the property sheet. In spy++ I couldn't find any problem in properties of this window even its childs(property pages) seemed OK. but the problem is when windows look in its permanent handle map it returns an erroneous pointer. the pointer is not null neither the hWnd of the returned pointer but hWnd of returned pointer is 0x30203020 which is different from the FromHandlePermanent(HWND hWnd) supplied sane handle. of course the returned pointer is completely erroneous and this supposed to be a window has no sane owner, child, next window or prev window. How can I find the problem?
thanks
|
|
|
|
|
Electronic75 wrote: I followed the call stack and found out that problem occurs at this function
Is this on a different thread than the thread the
window was created on?
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hello Mark, No it is in the same thread. I followed the stack more closely and with the help of a lot of breaking points and many hours I found out problem occurs in an XML class that tries to read an XML file. I have a MFC application and I used a MSXML wrapper class from this address http://www.codeguru.com/cpp/data/data-misc/xml/article.php/c8287/[^] (I don't know credit of this work goes to whom I later found out some people developed very similar codes earlier).
Now I already had defined a pointer to my CPropertySheet in my CDocument class
m_pDefineSheet = new CDefineSheet;
and when I open a new document a new view is created and the property sheet will be created as its child
CFormView::Create(lpszClassName, lpszWindowName, dwStyle, rect, pParentWnd, nID, pContext);
pDoc = (CMyoc*) GetDocument();
if(!pDoc)
return 0;
pDoc->m_pDefineSheet->AddPage(pDoc->m_pDev1);
pDoc->m_pDefineSheet->AddPage(pDoc->m_pDev2);
pDoc->m_pDefineSheet->AddPage(pDoc->m_pDev3);
if (!pDoc->m_pDefineSheet->Create(this,
DS_CONTEXTHELP | DS_SETFONT | WS_CHILD | WS_VISIBLE))
{
DestroyWindow();
return FALSE;
}
No problem thus far then CMyDoc::OnNewDocument()will be executed and there it loads an XML document using CXMLManager m_xmlManager
m_xmlManager.Initlize();
m_xmlManager.Load(sData);
m_xmlManager.GetRoot()->get_childNodes(&pList1);
n1 = m_xmlManager.GetNoOfChilds(pList1) ;
for(i1=0;i1<n1;i1++)>
{
pNode1 = m_xmlManager.GetItemNode(i1,pList1);
pList2 = m_xmlManager.GetChildList(pNode1);
n2 = m_xmlManager.GetNoOfChilds(pList2) ;
sName1 = m_xmlManager.GetNodeName(pNode1);
sData = m_xmlManager.GetText(pNode1);
}
Upon execution of this code it seems that something overwrites the m_pDefineSheet location and when I execute
AfxGetMainWnd()->FromHandle((HWND)x)
in immediate window
x is the handle of m_pDefinesheet which was ok prior to execution of this code
it returns error
note that I receive no error of memory access violation that someone illegally has tried to write in memory
This is first time I have encountered such problem!
Thank you anyway.
|
|
|
|
|
Hi Mark, It took almost a day of my time but problem solved problem was in MSXML get_text when it tries to read a big chunk of data it was overwriting on m_pDefineSheet place so FromHandle() returned an erroneous address that already had been overwritten by evil get_text. One thing I still didn't understand is why windows wouldn't give a memory access violation error.
cheers
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
