|
If its just about the predicates, I also like boost.orgs lambda-lib[^]
With it, you can write the predicate exactly where you need it, not somewhere else.
Comes in handy when your classes do not have the one, inherent order, but instead need to be sorted by varying criteria.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all. Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Just added a comparison, and it works a treat, thanks!
Iain.
struct NamedPos
{
CString Name;
... other member data here
bool operator < (NamedPos const &p) const;
}
bool NamedPos::operator < (NamedPos const &p) const
{
return (Name.Compare (p.Name) < 0);
}
...
NamedPos p;
p.Name = "1";
m_NamedPositions.push_back (p);
p.Name = "3";
m_NamedPositions.push_back (p);
p.Name = "2";
m_NamedPositions.push_back (p);
p.Name = "5";
m_NamedPositions.push_back (p);
p.Name = "4";
m_NamedPositions.push_back (p);
std::sort (m_NamedPositions.begin(), m_NamedPositions.end ());
|
|
|
|
|
Iain Clarke wrote: it works a treat
Great!
Actually, operator overloading is a good thing!
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all. Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Iain Clarke wrote: Feel free to give me pointers to some vector::sort library or such...
I don't know what you are looking for exactly but the STL does have sorting algorithms. You can have a look here[^] (don't look at how he is inheriting from std::vector, because, in my opinion, it is not really the way to do).
The function swap two items, meaning that it uses the assignement operator and the copy constructor (not sure about this one). You could override this operator for your structure if you want to make it more efficient (if possible). I don't really see how you could sort, without swapping items anyway...
Does that more or less answer your question ?
|
|
|
|
|
Cedric Moonen wrote: Does that more or less answer your question ?
Yes thanks - the prevailing winds are blowing in STL's direction. I'll try jwurmbach's idea of providing comparison operator's in my own struct first - seems like less heavy lifting.
Iain.
|
|
|
|
|
|
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
|
|
|
|