C / C++ / MFC

14-Jul-07 14:53

[Message Deleted]

Paul Conrad14-Jul-07 16:42

14-Jul-07 16:42

kevinxli wrote:
I want to use SSE

What parts of your code do you want to do this to? Have you looked at compiler flags to use SSE instructions?

"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus

KevinXLi14-Jul-07 18:22

14-Jul-07 18:22

Paul Conrad wrote:
What parts of your code do you want to do this to?

ConvertRGB2HSV(...) is too slow.I want to rewrite this function using SSE (C++ code with inline Assembly ,like as: _asm{ movaps xmm1,xmm2 ... })

Paul Conrad14-Jul-07 18:35

14-Jul-07 18:35

Have you tried with the /arch:SSE flag set with full optimization? Sometimes it is easier to try and let the compiler do this kind of dirty work. If it doesn't increase the performance, then look into some inline assembly. I would only do the inline assembly where the code bottlenecks the worst.

---modified

You could try to unroll the two for loops for better cache utilization, as another thought Big Grin | :-D

"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus

KevinXLi14-Jul-07 18:47

14-Jul-07 18:47

Paul Conrad wrote:
Have you tried with the /arch:SSE flag set with full optimization?

My compiler is VC6(SP5),not support this flag D'Oh! | :doh:

if like as "_asm{ movaps xmm1,xmm2 ...}" ,will Okey!(I'm sorry for my poor English)

Paul Conrad14-Jul-07 18:51

14-Jul-07 18:51

Have you been able to do inline assembly with SSE instructions under VC6 before?

"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus

KevinXLi14-Jul-07 19:00

14-Jul-07 19:00

Paul Conrad wrote:
Have you been able to do inline assembly with SSE instructions under VC6 before?

Of course!

Paul Conrad14-Jul-07 19:02

14-Jul-07 19:02

Okay, cool. I'd start chipping away small bits with inline assembly and see where it goes.

"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus

Steve Echols14-Jul-07 18:21

Steve Echols

14-Jul-07 18:21

Which SSE do you want to use?

- S
50 cups of coffee and you know it's on!

Paul Conrad15-Jul-07 9:29

15-Jul-07 9:29

Honestly, I am not sure if trying to do this in SSE will help. With many of your if statements, you would have to unpack from the xmm1, ... registers and this may wind up costing more processor time.

"The clue train passed his station without stopping." - John Simmons / outlaw programmer

One Instance of class

Stan the man14-Jul-07 11:26

14-Jul-07 11:26

Hi.

I am not sure about this. I have a Cedit derived class in a DLL. In this I want to add a member of a keypad class I made. But I would like that EVERY CEdit derived class will only use ONE copy of this keypad. Can this be done just by declaring the keypad as a static member. Then when something it is entered into the keypad, it will be sent to the perspective Cedit class.

Can someone help me shed some light on this?

Thanks ahead of time.

Stan the man

Mark Salsbery14-Jul-07 11:32

Mark Salsbery

14-Jul-07 11:32

A static member would work well.

You could keep a static reference count as well which tracks how many edit controls are in
existence (initialize to 0). When an edit control is created increment the reference count. If
the count is now 1, create the keypad. When an edit control is destroyed, decrement the count,
and if it's 0, destroy the keypad.

The edit controls can set another static variable when they gain focus, so the keypad knows which
one to direct input to.

Mark

Mark Salsbery
Microsoft MVP - Visual C++

This episode brought to you by the number 3

Stan the man14-Jul-07 14:24

14-Jul-07 14:24

Is it possible for me to decalre the keypad class in the edit class with a static? I would like to have the edit class somehow manage the keypad.

Ex:

class Keypad
{

}

class Edit
{

static Keypad;

}
...

Is there someway to do that? Or do I have to manage the keypad in my mainfrm class or something?

This way, when I declare an edit class, the keypad is "built in" but only has one copy (for memory sake) even with many edit controls. The keypad will direct the inputs to the correct parent.

Thanks.

Mark Salsbery14-Jul-07 14:54

Mark Salsbery

14-Jul-07 14:54

Like you've shown it is what I was thinking...

class CKeypadWnd : public CWnd
{
};

class CKeypadEdit : public CEdit
{
static CKeypadWnd *pKeypadWnd;
static int KeypadRefCount;
static CKeypadWnd *pActiveKeypadWnd;
...
};
...
// In the CPP file:
CKeypadWnd *CKeypadEdit::pKeypadWnd = NULL;
int CKeypadEdit::KeypadRefCount = 0;
CKeypadWnd *CKeypadEdit::pActiveKeypadWnd = NULL;
...

Mark

Mark Salsbery
Microsoft MVP - Visual C++

This episode brought to you by the number 3

#realJSOP15-Jul-07 1:56

#realJSOP

15-Jul-07 1:56

There's only a couple of reasons I can think of to share a class this way:

1) You're sharing data between the various CEdit objects

2) There are a lot of your CEdit objects in existance at a time and you're concerned with memory usage, performance (the time to create the keypad object), or memory fragmentation.

I try to avoid static members unless the class is intended to provide static methods. If it were me, and if item 2 is the issue, I would dynamically create a single application global instance of the keypad and just use it wherever it's needed.

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Stan the man15-Jul-07 4:24

15-Jul-07 4:24

Actually, I do have lots of Edits. But I wanted to have a simple way to just declare each edit and then have the keypad function all built in without additionally allocating it again globally and then tie it to each Edit somehow.

Thanks for all the responses and comments!

#realJSOP15-Jul-07 5:43

#realJSOP

15-Jul-07 5:43

Well, once you allocate your CEdit iobject on the heap, everything inside it also resides on the heap, so you can declare your keybad object like so:

class CMyEdit { private: CMyKedPad m_KeyPad; };

...and then initialize it in the CMyEdit constructor.

At that point, there's no overhead involved in allocating that object on the heap, and you don't have to worry about delete/null it when your CMyEdit object cleans itself up. My guess is that your KeyPad object doesn't contain much data, so it's not like multiple instances is going to take up much space (probably less than 64 bytes).

I still see no need for a static object (which is my entire point).

Stan the man15-Jul-07 6:19