|
Hi,
I have a application developed in VC++(MFC).Its a MDI application.I am very new to Unit testing. So i need to use a Unit testing framework\tool for it's unit testing.
Kindly any one please suggest any Unti testing tool and also if you have any demo of that suggested Tool's implementation for MFC code, Then it will be easier to catch easier . If that testing tool is a Free like GoogleTest(gtest) then it'll be more prefarable.
I searched a lot, but i didn't get idea as per my requirement(exspecially for MFC code unittesting).So need help.Please suggest.
Thanks
|
|
|
|
|
|
Thanks _Superman 
Hoping this CPPUNIT will support all typeof VC++ App[MFC ,Win32]including COM,DCOM .
In future if i get any more docmunets related to MFC untitestng i'll update here. Again hoping the same from you too.
|
|
|
|
|
pk jain wrote: In future if i get any more docmunets related to MFC untitestng i'll update here. Again hoping the same from you too.
better write a small tip and post it on CP. your message may lost here!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
|
Hi
I am getting the above mentioned error in all my .cpp files I don't see any where I am using DAO classes
maybe they are some how included in stdafx,h yes I am compiling as 64 bit code
Thanks
|
|
|
|
|
Search your project files for afxdao.h and remove the include statements.
|
|
|
|
|
ForNow wrote: I don't see any where I am using DAO classes
Well we certainly can't without a lot more information. You need to look at where this message is produced and try to find out how it is including such references.
Use the best guess
|
|
|
|
|
1>ClCompile:
1> HERC_CMD.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> MainFrm.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> MyBaseEvent.cpp
1> Myexception.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> progDebug.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> progdialog.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> Progedit.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> Show_storage.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> SockCLeintThread.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> SockCLient.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1> stdafx.cpp
1> StorageRange.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxdao.h(15): fatal error C1189: #error : DAO Database classes are not supported for Win64 platforms
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:22.35
|
|
|
|
|
Well it's pretty clear that afxdao.h is being pulled into your compilations for some reason, so you need to examine your project to find out why. As a first step, try a Clean & Rebuild to see if that clears it.
Use the best guess
|
|
|
|
|
I a clean & re-build nothing I then did a search on "My Computer" and the only place afxdao.h came up with
Was I. The include directories of mfc
Thanks for your help
|
|
|
|
|
ForNow wrote: I then did a search on "My Computer"
Why? I suggested you investigate your project to find out where and why this header is getting included. Somehow, somewhere you have a setting that causes this header to be referenced, and since it is happening on every source file it is most likely to be one of your header files, or some project setting. Beyond that it is not easy to suggest anything.
Use the best guess
|
|
|
|
|
From this, it looks like something is including it in stdafx.h
Comment out includes in this file until you find it.
It's likely a third party library header, or a header file that is local to you project.
|
|
|
|
|
ForNow wrote:
maybe they are some how included in stdafx,h yes I am compiling as 64 bit code
What does that file look like?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Suppose this scenario: I refer to a third party lib in my C++ app, but I don't want the third party lib to use my physical memory at all. Instead, I want it to only allocate memory from hard disk. I don't know source codes of third party lib, however as it run in the Windows platform, so I think it's possible to control the memory management with Win32 API.
My problem is how to avoid thrid party lib to allocate memory from physical memory.
Am I going in the wrong direction? Anybody can help me?
PS: I'm using Visual C++ 2010.
|
|
|
|
|
You can't. The library will do what its code is designed to do, and without the source code you cannot alter that.
Use the best guess
|
|
|
|
|
Richard MacCutchan wrote: The library will do what its code is designed to do,
Actually it's not just the library, but the OS as well. And as jschell wrote, if the library allocates memory through a DLL, that DLL could in theory be replaced by one that does what the OP intends. That said, I doubt that it can be easily achieved.
More importantly I doubt that is actually what the OP needs: his requirement to have the library (or any part of an application) "allocate memory from hard disk" simply doesn't make sense. Data needs to be in memory in order to be processed, so you have to load them to memory eventually. More to the point: the allocation of memory always happens in memory (big surprise!). Depending on the reasons for this requirement, there may be another solution altogether - forcedly moving library allocations to hard disk is definitely not the solution, even if it were feasible with a reasonable amount of effort.
|
|
|
|
|
I'm not sure what this has to do with OP's question. He asked how to modify a DLL without the source code.
Use the best guess
|
|
|
|
|
If you're dynamically creating the objects in your app, you can overload the 'new' operator.
But that's not really going to do the trick. As others have mentioned data has to be in memory to be used.
|
|
|
|
|
I don't think you meant to post this to me, or (maybe) even to this thread.
Use the best guess
|
|
|
|
|
I meant it for the thread anyway...
|
|
|
|
|
thank you for the suggestion. yes, i'm going in the woring direction. i have to find another solution.
|
|
|
|
|
What is the problem that you are trying to solve?
|
|
|
|
|
i'm trying to solve "out of memory" problem, it's the no-source third party lib who eat up my memory. but i'm rather my usage is right, and i have to do this way. so, i'm trying to find a way to make the third patry lib occupy less memory.
|
|
|
|
|
If the leak is due to a bug in a third party library then there may be no workaround to your issue. The operating system already caches out memory to a page file on disk. If you're exceeding the 1 or 3gig limit set by the linker, then you're hitting the wall on addressable memory.
You can't allocate more memory than you can address. With 32 bit pointers the theoretical limit is 2^32 bytes or 4gig. In practical terms it's less because some of the bits in the upper end of the pointer can have a special meaning.
I've seen server side systems live with leaks like this, by periodically restarting.
If you can prove that the third party library is leaking the memory with a simple test case, then I would raise this issue with your vendor.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
