|
Use std::sort (not qsort, it's crap) with the following definitions:
struct aaa
{
int a1;
int a2;
float a3;
};
inline bool operator<(const aaa &lhs, const aaa &rhs)
{
return lhs.a3 < rhs.a3;
}
Steve
|
|
|
|
|
Yes, thank you.. I am coding this..
I really appreciate your help 
I will post results here
Thanks again
Mohammad
And ever has it been that love knows not its own depth until the hour of separation
|
|
|
|
|
I did it and yes, it worked!
this fastened sorting from about 185msec (using our qsort implementation) to 172msec using std::sort, so it wasn't a major enhancement, but I hope I can enhance things further
Thanks for all who helped me and especially <b>Stephen Hewitt </b>
Thank you all,
Mohammad
And ever has it been that love knows not its own depth until the hour of separation
|
|
|
|
|
What does the following yield:
void qsort( int a[], int lo, int hi )
{
int low = lo;
int high = hi;
int mid = a[(low + high) / 2];
do
{
while (a[low] < mid) low++;
while (a[high] > mid) high--;
if (low <= high)
{
swap(a[low], a[high]);
low++
high--
}
} while (low <= high);
if (high > lo) qsort(a, lo, high);
if (low < hi) qsort(a, low, hi);
}
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Yes, this appears to be even a little bit faster , just a 2msec enhancement, about 2.5% enahncement..
Thanks
And ever has it been that love knows not its own depth until the hour of separation
|
|
|
|
|
Could someone explain to me how to solve this ?
I am editing CListView using modal dialog – pretty much “standard” operation. In this “main” dialog I open another dialog. In this “sub dialog” I want to change text and bacground colors of CEdit controls.
These COOLOREFs variables are initialized in the CListView.
Obviously I need the CList View data in my dialog – so I use parameterized constructor and pass my CListView “this” pointer to it.
Here is the code snippet:
m_clrText = RGB( 0, 0, 0 );
m_clrBkgnd = RGB( 255, 255, 0 );
C_Dialog_Edit_Color_Weight dlg(this);
int nRet = -1;
nRet = dlg.DoModal();
....
So far so good.
The “problem” is that I do not fully undestand the syntax of the C_Dialog_Edit_Color_Weight parametrized constructor.
Therefore I do not know how include C_Edit_ parameters to pass the correct pareameters to the C_Edit_.
C_Dialog_Edit_Color_Weight::C_Dialog_Edit_Color_Weight(C_Dialog_Block *pDialog , CWnd* pParent /*=NULL*/)
: CDialog(C_Dialog_Edit_Color_Weight::IDD, pParent)
{…
With this constructor I can only get to the C_Edit_ default constructor.
So, how do I include parametrized C_Edit_ in this C_Dialog_Edit_Color_Weight constructor ?
Thanks for reading.
Cheers
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: C_Dialog_Edit_Color_Weight
Is this a class that you defined or is it a third party library class?
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.
[my articles]
|
|
|
|
|
It is MFC CDialog derived class
|
|
|
|
|
I know (there's a call to base class contructor in your code) but, I ask again, is it your own defined class or is it a third party library class? I mean, can you change its code or not?
Moreover, could you please detail more what you need?
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.
[my articles]
|
|
|
|
|
Now I am confused. I don't undestand what are you askig.
Here is my real code (with some exras)
// C_Dialog_Edit_Color_Weight dialog
class C_Dialog_Edit_Color_Weight : public CDialog
{
// Construction
public:
C_Edit_ *m_C_Edit_;
C_Dialog_Block *m_C_Dialog_Block;
C_Dialog_Edit_Color_Weight(CWnd* pParent = NULL); // standard constructor
C_Dialog_Edit_Color_Weight(C_Dialog_Block *pDialog, CWnd* pParent = NULL); // my dialog constructor
This constructor has no code to use C_Edit_ class ( derived from MFC CEdit) constructor with paramaters - I do not know how to code it!
But my code does work with C_Edit_ default constructor where I redefine the needed COLORREF variables - until I figure how to get the parametrized constructor in my code.
What I need:
1. Define COLORREF variable in class derived from CListView
2. Open modal dialog with list control containing CLIstView data
3. Modify list control subitems value (int) "Weight" - open another modal dialog
4. Change subitems "Text" to selected color.
What I have - the color assigment is currently retrived from the
default C_Edit_ constructor where it is "hardcoded".
Thanks for helping me.
Cheers
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: This constructor has no code to use C_Edit_ class ( derived from MFC CEdit) constructor with paramaters - I do not know how to code it!
something like
class C_Edit_ public CEdit
{
public:
C_Edit_(COLORREF cr):CEdit()
{
}
};
does help?
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.
[my articles]
|
|
|
|
|
"
C_Dialog_Edit_Color_Weight(C_Dialog_Block *pDialog, CWnd* pParent = NULL); // my dialog constructor
This constructor has no code to use C_Edit_ class ( derived from MFC CEdit) constructor with paramaters - I do not know how to code it!
"
I was not clear with this.
I do have a C_Edit_ parametrized constructor but I cannot "get to it" from C_Dialog_Edit_Color_Weight constructor because I am missing something.
This C_Dialog_Edit_Color_Weight constructor executes the dialog fine than it "calls"
C_Edit_ default constructor.
That is the step I am missing - I do not know how to get to the C_Edit_ parametrized constructor instead of the default.
Cheers
Vaclav
|
|
|
|
|
After several failures to force main CDialog constructor to use parameterized CEdit "child" constructor I came up with this shameless hack!
I use global COLORREF variables and assign them to local variables in the default constructor.
I could just use them but it keeps the rest of the code intact and somewhat sane.
So, is usage of globals in “OOP” on same level as GoTo?
Vaclav
|
|
|
|
|
Couldn't you just change the colors to your desired COLOREF values in the dialog's OnInitDialog() function? Maybe it's not as nice as setting it through the constructor, but it's better than using global variables.
Mike
|
|
|
|
|
Hey i'm new to visual C++ and i'm using windows forms but that forum doesn't seem to get answered.
I'm wondering how to call a method from a class in the form1.h?
so for example:
<br />
<br />
form1.h<br />
<br />
private: System::Void testToolStripMenuItem_Click(System::Object^ sender, System::EventArgs^ e) <br />
<br />
<br />
{<br />
Class test<br />
void test()<br />
{<br />
}<br />
|
|
|
|
|
You should ask the managed C++/CLI one.
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.
[my articles]
|
|
|
|
|
Hi,
I am using right shift operator in my project. The following code snippet shows the sample of the project.
This project is compiled in VS 2005
#include "stdafx.h"
#include <iostream>
#include<conio.h>
using namespace std;
#define JULIAN_ADJUSTMENT 1721425L
int _tmain(int argc, _TCHAR* argv[])
{
long theDate=2453843;
long theAdjustedDays = (theDate >> 32 ) - JULIAN_ADJUSTMENT;
std::cout<<theAdjustedDays;
getch();
return 0;
}
While in debug build, I am getting correct answer: 732418
and in release build, it gives wrong value: -1721425
Please let me know how to resolve this issue in release build.
Thanks in advance
Sumanta
|
|
|
|
|
Sumanta Rout wrote: While in debug build, I am getting correct answer: 732418
and in release build, it gives wrong value: -1721425
Maybe I'm looking at it wrong, but if you divide 2453843 by 232, the result is less than one. Subtracting 1721425 from that will yield a difference of -1721424.99.
I think the difference between Debug and Release boils down to a signed vs. unsigned issue, but that's just a guess.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
the debug build seems to have an error lol....
in fact -1721425 is correct since 2453843 >> 32 is 0.
Don't try it, just do it! 
|
|
|
|
|
Actually (at least IMHO) only the release build is working properly.
To keep things easy, let's ignore sign: if you shift a long (i.e. a 4-bytes, 32-bits integer) 32 times then you must obtain zero.
I've seen the disassembly, both of the debug build and of the release build and I suppose that in the latter one code optimization hides a compiler bug (if you turn OFF optimization then the release build behave exactly like the debug one).
In the debug build the compiler translates the right shift operation into SAR assembly instruction. SAR instruction executes the right shift ignoring all but the four least significative ones of the second operand, i.e. does nothing in your particular case. I don't think that standard C or C++ language allows this behaviour.
I think you hit a subtle compiler bug, though I'm not sure about (I'll post the question on the general discussion forum).
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.
[my articles]
modified on Monday, January 21, 2008 10:29:21 AM
|
|
|
|
|
Actually you shouldn't use a 32 bit shift on a 32 bit wide number because the compiler is allowed to return you a wrong result:
(from C language specification [^], 6.5.7 Bitwise shift operators, Semantics)
The integer promotions are performed on each of the operands. The type of the result is
that of the promoted left operand. If the value of the right operand is negative or is
greater than or equal to the width of the promoted left operand, the behavior is undefined.
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.
[my articles]
|
|
|
|
|
Hello!
Is there any API that I can use in my application in order to detect at some moment that another application is trying to install a Windows hook (SetWindowsHookEx) ?
Thanks in advance!
|
|
|
|
|
no this is no api to do so. you could create a global api hook for SetWindowsHookEx.
Don't try it, just do it!
|
|
|
|
|
I guess you are refering to WH_DEBUG. I read the documentation for SetWindowsHookEx again and this seems to be the type of hook I was looking for...
modified on Monday, January 21, 2008 10:18:12 AM
|
|
|
|
|
Urgent help required.
Tons of experience yet unable to see where I go wrong with this one.
Got a CPropertySheet in wizard mode.
One of its pages is scanning the serial ports for a device and for this I elected to use a callback method so that this process is kept asynchronously.
Obviously when this page receives the callback it's (possibly/likely) on another thread so I cast one of the callbacks parameter to the instance and post a user defined message to it, like so:
void CCommsPage::NotifyAPC(unsigned nId, bool bResult, void* pParam)<br />
{<br />
CWnd* pThis = reinterpret_cast<cwnd*>(pParam);<br />
<br />
if (pThis > NULL)<br />
{<br />
pThis->PostMessage(WM_NOTIFY_CB, nId, bResult);
}<br />
}</cwnd*>
When this message is processed by the page I am indeed back on the thread that the port scan was initiated from.
Yet when I then get this page to instruct the wizard to progress to the next page, like so:
<br />
CCommsPage::OnCallBackConnect(bool bSuccess)<br />
{<br />
if (bSuccess)<br />
{<br />
...<br />
<br />
#ifdef _DEBUG<br />
CPropertySheet* pSheet = dynamic_cast<cpropertysheet*>(GetParent());<br />
ASSERT(pSheet > NULL);<br />
#else<br />
CPropertySheet* pSheet = static_cast<cpropertysheet*>(GetParent());<br />
#endif<br />
<br />
pSheet->PressButton(PSWIZB_NEXT);<br />
...<br />
}<br />
}</cpropertysheet*></cpropertysheet*>
The wizard boms out completely when CPropertySheet::PressButton() is invoked.
If I replace the call to PressButton() with...
pSheet->SetWizardButtons(PSWIZB_BACK | PSWIZB_NEXT);
Then the "Next" button is enabled and when I manually click on that button then the wizard does go on to the next page.
That - however - is not an ideal solution and I really want the wizard to progress programmatically.
I've googled and googled and cannot find any article that has the answers that I look for.
I am sure that someone must have had a similar experience. Either that or I am making such a basic mistake that I should reconsider this career.
Someone please help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
