|
Hi All,
I need the link to the Hierachy chart for MFC8.0.
I tried to google and searched in MSDN also. But couldnt find it.
Please help!
Priya Sundar
|
|
|
|
|
Priya_Sundar wrote: I tried to google and searched in MSDN also. But couldnt find it.
It could be a bug in the documentation. They might have missed it out!
If you need the chart for version 9, it's here[^].
The three part chart after you've installed the feature pack for VS 2008 is here[^] (the PDF version of the same is available for download here[^])
|
|
|
|
|
Do you need to Microsoft Foundation class Library version 9.0?
|
|
|
|
|
I have read many articles about 'Busy Waiting' prevention in thread synchronization.
I am wondering if busy waiting is really a big problem with processors available nowadays.
What is your opinion - is busy waiting just a theoretical problem or it really affects system performance?
Thank you.
|
|
|
|
|
Daniel Kanev wrote: I am wondering if busy waiting is really a big problem with processors available nowadays.
IMHO wasting time is an issue regardless of processor speed.
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]
|
|
|
|
|
Daniel Kanev wrote: I am wondering if busy waiting is really a big problem with processors available nowadays
Suppose that you have a loop in which you constantly check the value of a variable (and do something if the variable is true), no sleep or wait, only an 'endless' loop. This loop will consume the maximum resources it can use on the processor on which it is running. So, even if you have a faster processor, you will only loop faster. But all other process will still be slowed down because of that. So, yes, busy waiting is bad, even if you have the fastest processor in the world.
|
|
|
|
|
Yes, it's a big problem on a multitasking OS.
Steve
|
|
|
|
|
Looking into the MSDN, found the functions of lstrlen and _tcslen are the same,
If _tcslen is enough, why does lstrlen exist?
Please help me unlock my mind!
|
|
|
|
|
When your project settings are MBCS, tcslen and lstrlen are same. You
should not use lstrlen on a UNICODE string. _tcslen will work on a
UNICODE string as well as MBCS.
If you dont know what MBCS/UNICODE are, use _tcslen
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
Hi all,
When I try to use the _beginthread method, I receive the following error: error C2664: '_beginthread' : cannot convert parameter 1 from 'void (__stdcall *)(void *)' to 'void (__cdecl *)(void *)'
Function definition: void performActionsOnReader(void* par)
Begin Thread Call: _beginthread(performActionsOnReader, 0, NULL);
It's a dll project with the following preprocessors:
#ifdef STATIC_LIBRARY
#define DLL_IMPORT_EXPORT
#else
#ifdef WIN32
#ifdef DLL_SOURCE_CODE
#define DLL_IMPORT_EXPORT __declspec(dllexport) __stdcall
#else
#define DLL_IMPORT_EXPORT __declspec(dllimport) __stdcall
#endif
#else
#define DLL_IMPORT_EXPORT FAR PASCAL
#endif
#endif
#ifdef __cplusplus
#define NoMangle extern "C"
#else
#define NoMangle
#endif
Could the preproccesors cause the problem or am I doing something wrong?
The only programmers that are better that C programmers are those who code in 1's and 0's
Programm3r
My Blog: ^_^
|
|
|
|
|
The error occurs since the exported function use the __stdcall linkage while _beginthread expects the __cdecl one (see, for instance [^]). As a workaround your application may wrap the DLL function, for instance:
void wrapPerformActionsOnReader(void* par)
{
performActionsOnReader(par);
}
and then pass the wrapper to _beginthread .
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]
|
|
|
|
|
|
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]
|
|
|
|
|
Hi All,
Can anyone tell me some links that tell the differences or comparision between MFC6 and MFC8?
I tried to google, but couldnt find it.
Kindly help!
Priya Sundar
|
|
|
|
|
Priya_Sundar wrote: MFC6 and MFC8?
Do you mean VS6.0 and VS8.0
AFAIK there is nothing like MFC6 or MFC8 that may be the reason you don't find anything on google related with it
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: AFAIK there is nothing like MFC6 or MFC8
*sigh*
Actually, there *is* MFC 6.0 and MFC 8.0
|
|
|
|
|
Thanks for the update.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
No, that wasn't an update; it didn't happen all of a sudden - those versions of MFC were already existent. Having worked on MFC for several years (your profile), I was shocked you didn't know it. I would guess that you probably were emphasizing more on Win32, ATL or something else.
|
|
|
|
|
ATL/COM. On another note I like to see and build code in MFC .
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
modified on Monday, July 28, 2008 4:47 AM
|
|
|
|
|
Another member of the MFC 's not-fan club, maybe!
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]
|
|
|
|
|
Possibly. But, did you check out the additions to MFC via VS 2008 feature pack? I'm very impressed. The new additions are awesome; it would make a lot of articles on "How to do this extra thing with MFC" obsolete, as almost everything is now a part of MFC and is implemented in a much more elegant way.
|
|
|
|
|
Rajesh R Subramanian wrote: it would make a lot of articles on "How to do this extra thing with MFC" obsolete, as almost everything is now a part of MFC and is implemented in a much more elegant way.
I strongly doubt about: they simply stole the content of CP 's articles.
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]
|
|
|
|
|
I would agree if you say they stole the "idea" (not the content). Because most articles are published under a license that prevents them from using it for commercial purposes. Besides that, the code for new additions is from BCGSoft.
|
|
|
|
|
CPallini wrote: Another member of the MFC's not-fan club, maybe!
Unfortunately no. Read his updated message.
|
|
|
|
|
With every new release of MFC, there are additional security features, additional classes, more methods added to existing classes, etc., I don't know if you will be able to find a document which would do a side by side comparison between two versions of MFC.
If you need to know the new features of a specific version of MFC, just Google for "What's new MFC X.0", X being the version of your interest (or even better, try looking into MSDN?!).
Besides that, these links may be of your interest:
http://www.codeguru.com/cpp/v-s/devstudio_macros/visualstudionet/article.php/c10147/[^]
http://blog.kalmbachnet.de/?postid=70[^]
|
|
|
|