|
1. you have two functions : FunctionA and FunctionB.
2. you call FunctionA with a pointer to FunctionB.
3. FunctionA calls FunctionB as part of its processing, usually in a loop.
Software | Cleek
|
|
|
|
|
...Additionally callback functions can be very useful in event notification purposes.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
#pragma pack(push|pop)
From what I remember...the last time I read up on what this pragma does was long time. 
Anyways...my understanding is that it forces a even byte alignment of structures, it's mebers, etc.
I've seen it used often in a structure and like I said...my understanding is that it causes data members to fall on quad byte boundries or whatever...for faster access times...
I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers???
Sp my question is this...assuming I am correct in my above thinking...
Would it make a logical difference if I were to remove pragma's like this??? I find them annoying...and despite making code more efficient I'm not sure I think it's worth the harder to read code (I like things easy).
If this is the case...one more question:
The pragma surrounds structs which are then used in a MFC CArray...to holds potentially 1000's of elements...
So does this pragma make sure each of those elements will be accessed on an even byte boundry???
Or I guess...would it atleast make sure the first struct item in array was on an even byte boundry, so the rest that followed???
One more question: 
If a struct was 5 bytes would this pragma actually allocate 8 bytes for a single element, in this case using more memory in the trade off of speed in access times???
so 2 elements would actually consume 16 bytes instead of 10? wasting 3 bytes, but causing each to fall on even byte boundries???
Just curious...hope i'm on the right track here 
Thanks in advance
It's frustrating being a genius and living the life of a moron!!!
|
|
|
|
|
Hi
I agree with your concern about unnecessarily optimizing the runtime memory layout of C++ entities, and that byte-alignment in this case should enjoy less limelight than more important issues of software development.
However, I've had the need to use the packing pragma - typically in scenarios where I'm overlaying a C++ struct on a data byte array. For example, receiving a packet over the network - it's packed tightly by another program that is not necessarily concerned with extra byte-padding - and overlaying a C++ struct on top of that in order to interpret the elements contained in the data. Another example would be reading byte streams from a file.
Unless you're responsible for both consumer and provider of such byte sources, you'll have to be careful that the not-so-obvious extra padding of default byte-alignment doesn't cause problems (getting byte streams and C++ struct members out of sync) - because they are very tricky to find.
HTH
Martin
|
|
|
|
|
Yes that is example when pragma pack's are needed. I need them when I'm reading some structure from disk file. If i would not pack it, variables in the structure would have 'byte gaps' between themselves, and structure would be read incorrectly.
|
|
|
|
|
its typically used to 'pack' a structure into a certain byte alignment because otherwise the structure gets padded out automatically and things either use up more memory than necessary OR saving and loading mechanisms (particularly on cross platform code or tool development (e.g. 16 bit machines etc.)) end up reading in the wrong amount of data and so the struct it loads is full of rubbish.
However, my experience with #pragma pack is that its the most idiotic compiler directive i have seen. You can specify a struct with size 16 bits (using bit fields of type 'unsigned') specify a #pragma pack directive of 2 bytes (so the size of the struct should be 2 bytes in memory) and yet it fails badly and instead aligns it on a 4 byte boundary ! ! Change the unsigned type to unsigned short and it chucks it on a 2 byte boundary, hooray ! !
My verdict :
Its absolute rubbish.
"When I left you I was but the learner, now I am the master" - Darth Vader
|
|
|
|
|
"I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers???"
That's correct and the P4 is really horrendous at it. P3s and AMD processors have an easier time of it.
Actually, the default packing of data structures is to the size of the item ie., doubles are aligned to the nearest eight-byte boundary, ints on a four-byte boundary, and shorts on a two-byte boundary.
From MSDN : "If you use #pragma pack without an argument, structure members are packed to the value specified by /Zp. The default /Zp packing size is /Zp8."
I do a lot of work with communications in various manners and we often use pack(1) insure that the data that we transfer is aligned correctly. If the processor has difficulties with that then we just have to deal with it.
|
|
|
|
|
Hi,everyone:
i access my data of Doc using following code:
<br />
CMainFrame* pMainFrmWnd = (CMainFrame*)AfxGetMainWnd(); <br />
ASSERT(pMainFrmWnd != NULL); <br />
<br />
CWnd* pchildWnd = pMainFrmWnd->GetWindow(GW_CHILD);<br />
ASSERT(pchildWnd->GetSafeHwnd() != NULL);<br />
<br />
CvcydcjView *pMyView = NULL; <br />
while(pchildWnd->GetSafeHwnd() != NULL)<br />
{<br />
ASSERT(pchildWnd->GetSafeHwnd() != NULL);<br />
if(pchildWnd->GetRuntimeClass()->m_lpszClassName == "CvcydcjView")<br />
{<br />
pMyView = (CvcydcjView*)pchildWnd;<br />
break;<br />
}<br />
pchildWnd = pchildWnd->GetWindow(GW_HWNDNEXT);<br />
}<br />
ASSERT(pMyView != NULL);<br />
<br />
CvcydcjDoc *pMydoc;<br />
pMydoc=pMyView->GetDocument();<br />
ASSERT(pMydoc != NULL);<br />
<br />
pMydoc->MyData="demo";<br />
but when i use it in a thread, it didn't work, it seems stopped at
pMydoc=pMyView->GetDocument();<br />
can you give me some suggestions? Thx!
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
|
I don't have the answer to your question but a little suggestion. When you create your thread, why don't you pass the document (through the use of the LPVOID pParam) to the thread function and then use it there ?
|
|
|
|
|
Thank you for your suggestion.
i create the thread in my view class with following code:
<br />
m_hCallthread = CreateThread(<br />
NULL,
NULL,
CallOut,
NULL,
0,
NULL
);<br />
could you tell me how to pass the pointer? thx? i try replace last NULL with this, it didn't work. 
sorry, i'm a new bie of vc... wait for your answer... Thank you very much!
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
|
Create your thread like that (supposed you have a pointer to your document that is called pDoc):
m_hCallthread = CreateThread(<br />
NULL,
NULL,
CallOut,
pDoc,
0,
NULL
);<br />
Then in your thread function you'll need to cast your void pointer to your document again:
CYourDoc* pDocument = (CYourDoc*)pParam;
|
|
|
|
|
Thank you very much! It works 
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
|
Dick.leeSolucky wrote:
can you give me some suggestions?
Using MFC documents/windows in a thread is not recommended. In fact, most of the time it simply won't work. You'll have to pass a pointer to your data to your thread routine.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you for your reply.
we need have a thread dealing with something(like initialize drives,and connect to voice_board and dial ...) and our main functions are all in View class, for example: displaymessage... we store the data in doc class.
may i create the thread in my doc class or view class? then i can access the data easiler, but it seems if we create the callout function in view class,we get these errors:
<br />
D:\VC YDCJ\vcydcjView.cpp(431) : error C2664: 'CreateThread' : cannot convert parameter 3 from 'int (void)' to 'unsigned long (__stdcall *)(void *)'<br />
None of the functions with this name in scope match the target type<br />
thank you and waiting for your reply... thx!
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
|
Hiall,
I want to know cpu usage of a running program?
Please tell me how?
Best Wishes.
Thanks.
|
|
|
|
|
|
You can also see the discussion here.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi everiyone,
I have a problem, I'm using WinXp Pro, when I set's the "Right aligned text" to a List Box control works fine.
But when run this program on Windows 98 the property does not work.
Why?
how I can do it?
Thanks in advance.
Pd. I'm using VC++ 6.0 SP5 on WinXP Pro
Ivan Cachicatari
www.latindevelopers.com
|
|
|
|
|
I believe that that style was not introduced/implemented back in Win98. So, if you really need right-aligned text, you'll need to implement an owner-drawn list box and draw the strings right-aligned yourself.
onwards and upwards...
|
|
|
|
|
|
how to find the process name if i know the process ID. Is there any straight forward function? or pliz forward me a link
|
|
|
|
|
Try this:
char szProcessName[MAX_PATH];
HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION|PROCESS_VM_READ,FALSE, processID);
if (NULL != hProcess )
{
HMODULE hMod;
DWORD cbNeeded;
if ( EnumProcessModules( hProcess, &hMod, sizeof(hMod), &cbNeeded) )
{
GetModuleBaseName( hProcess, hMod, szProcessName, sizeof(szProcessName) );
}
}
Still Alone in this beautiful world 
My Articles
|
|
|
|
|
Hello Friends,
What's is the main advantage of having virutal destructors? Why don't we have virtual constructor?
Thanks in advance.
Neelesh K J Jain.
|
|
|
|
|
That's a good question .
In fact if we don't need virtual constructor, it's because when you instanciate your pointer, you ALWAYS know what class you instanciate. So take the example of one base class (CBase) and one child class (CChild). If you have an uninstancied pointer to the base class:
CBase* pPointer;
If you instanciate it into a child class:
pPointer = new CChild;
the compiler knows exactly that you want to create a child class (first the compiler creates a child class and then it stores the pointer into the uninstancied pointer).
So know you've done a lot of things with this pointer and you want to destroy it:
delete pPointer;
The compiler just knows that the pointer is from type CBase (that's how it has been declared) without knowing that it has been instancied as a child class. So, in this case your destructor must be virtual so that the compiler will call the destructor of your child class and not from the base class.
Hope this helps
|
|
|
|
|
I like this question. The other posting did a good job of explaining why the virtual destructor is needed. The reason you don't need a virtual constructor is that you are specifically telling the compiler what you want to instantiate.
You write
int i = 10;
CBase* pPointer;
pPointer = new CChild(i);
The concept of virtual functions is also described as dynamic run time binding. So the idea is that you call a function on the fully instantiated object and the system is smart enough to realize that since a function is virtual, the child class version of the function is called first. Then the child class can execute it's own code and may or may not ivoke the base class version of the function as well.
So virtual functions don't make sense during the construction process. The child class has to call the constructor for the base class from within it's own constructor. Once the construction of the class is complete, you can use the base class pointer to call virtual functions. If you tried to call any virtual functions from either of the constructors, I'm not sure what would really happen. I wouldn't recommend trying this as it really makes no sense. Seems like it would be an undefined operation that may or may not cause a crash.
Shawn
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
