|
I don't know what your "array" is, but you can't put objects of different types in a C++ array or in an STL container. You can put pointers to objects in the same inheritance hierarchy in, but then you know what the base class is.
Evidently, your array is some special container you wrote or found somewhere. It isn't clear how it works or what the return type of array[] is. It obviously can't be A*, B*, or C*. Knowing this is necessary to figuring out how to deal with it. Some possibilities are a discriminated union or boost::any.Please do not read this signature.
|
|
|
|
|
Sorry for not being too clear. Actually, both B and C are derived from A and they both have their own derived classes.
std::map<int, a*=""> m;
class A { };
class B : A { };
class C : A { };
class BDerived: B { };
class CDerived: C { };
B* pBDerived = new BDerived();
m[key1] = pBDerived;
C* pCDerived = new CDerived();
m[key2] = pCDerived;
A* pA = m[key1];
The map m holds A*, B*, C*, BDerived*, CDerived* objects. I'm trying to figure out if the object(pA) in the map is derived from either B* or C*. I hope that's a little clearer.
|
|
|
|
|
OK, that gives me a different picture of what is going on.
It is, of course, preferable to try do things using polymorphism and not have to make this distinction.
Failing that, I believe this is what you are looking for:
{
class A { };
class B : public A { };
class C : public A { };
class BDerived: public B { };
class CDerived: public C { };
std::map<A*> m;
...
A* pA = m[ key1 ];
B* pB = dynamic_cast<B *>( pA );
C* pC = dynamic_cast<C *>( pA );
if ( pB )
{
...
}
else if ( pC )
{
...
}
else
{
...
}
}Please do not read this signature.
|
|
|
|
|
Yes, that is exactly what I'm looking for. Thanks!
|
|
|
|
|
In Actual scenario, we don't need the base class name usually.
So can u be clear with the need of doing so  Величие не Бога может быть недооценена.
modified on Tuesday, March 16, 2010 1:06 AM
|
|
|
|
|
I'm at my wit's end trying to track down a crash problem that only one person is seeing, but he sees it on BOTH his computers. I can't reproduce it, even after installing the same OS he's running (XP SP3), and neither can any of my other beta testers.
I'm using XCrashReport to produce minidumps that he can send me when it crashes. It usually crashes on this line in InitInstance, which checks if there is a recently used file to load:
if (m_pRecentFileList->m_nSize > 0 && !m_pRecentFileList->m_arrNames[0].IsEmpty())
I have gone through the code in InitInstance line by line and I don't see any problems. Every global variable is initialized. Return codes are checked for every function call. I changed all my strcpy's to strncpy to make sure there aren't any overflows.
Weirder yet, when I compile the program - exact same code, line-for-line - in VC++ 6 rather than Visual Studio 2008 - he doesn't get the crash. SAME CODE!! The only difference is that with Visual Studio 2008 I link MFC in statically because I'm running Windows 7 (64-bit) and he doesn't have the DLLs on XP.
I installed XP SP3 on a computer and did not get the crash. Two other testers have XP SP3 and do not experience the crash. I asked him to use msconfig to disable Startup programs. He did, and it still crashed. I asked him to use msconfig to reboot into diagnostic mode. He did, and it still crashed. Doesn't that suggest it's my code and not a conflict with something on his system? But if it's such a bad bug, then why doesn't even one other person see it?
I don't know what to do at this point. I can't find it if I can't reproduce it. And not only can I not reproduce it, no one else who has run the beta can reproduce it. I'm tempted to ignore the problem on his system and move on, but what if I release the program and it starts crashing on 10% of systems?
How do I find this bug???
Any help would be greatly - hugely - appreciated. I've been working on this for a week, and I'm out of ideas.
|
|
|
|
|
|
No, I was linking statically instead. And now I've moved development over to VC++ 6 - seems easier when targeting 32-bit XP and above.
He doesn't experience the crash with identical code compiled under VC++ 6. This might suggest a DLL problem, but no one else experiences a crash on XP with the statically linked code that crashes on his computer. Most likely the bug has just temporarily shifted and will reappear at some later point in development.
Maybe I don't understand what you're saying - are you saying that NOT installing the redistribution package can cause a crash, or that installing it can cause a crash? Either way, why??
And why would the crash happen only on the computers owned by one person?? How is it possible that this is unrelated to the software on his system? And yet, if it's a conflict with other software, then why did it not go away when he used msconfig to boot into diagostic mode??
|
|
|
|
|
I would think that if the VCredist.exe is not installed you could get an error. Or maybe
even a compromised install of it could hassle. I normally create a dummy dll, that tries to load
VC8 CRT or VC9 CRT etc... A LoadLibrary on this DLL should fail if the VC8 CRT or 9 isn't present.
There could be other reasons for your crash, this is normally where id start looking. As default i always
add this type of check to my code. I learnt the hard way. Lol
Thanks
Louis
|
|
|
|
|
I already know he does not have this installed - and most of my customers for this program won't either. That's why I linked to MFC statically.
But after you mentioned this issue, I googled it and found that linking statically can cause crashes:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/b6badcd6-297d-4c73-a589-02507eb79548[^]
This has drawbacks.
- The CRT code is including more than once. Increasing the memory footprint of your application.
- Sharing the MFC in a DLL reduces the overall consumption of memory in the system
- MFC Extension DLL's are no longer supported.
- Allocating memory in one module (DLL,EXE) and freeing memory in another will cause a crash.
- Information like the locale are used in each module and are not shared. setlocale in the exe will not affect the locale in the DLL (this is good and bad depending on the design of the modules)
- There I heard rumors that there is a discussion to stop any support of statically linked version of CRT, MFC and ATL.
I do have two modules - an EXE and a DLL. I can't think of a case where I allocate memory in one and release it in the other, but I'm not 100% certain and maybe there are other hazards.
I asked my tester if he'd install the redistribution package. Maybe that's why the VC++ 6 compilation isn't crashing - that's dynamically linked rather than statically. If dynamic linking for VS2008 doesn't crash, then I'll continue development on VC++ 6 and stop worrying about it. I'm just very nervous about ignoring this without knowing why it's happening. In my experience, that always comes back to bite me in the butt.
|
|
|
|
|
No real answers, but for what it is worth ...
Have you gotten a list of all the programs that he has installed on each machine? Any programs on both that are not common? Or perhaps common, but dubious?
I had a real nasty situation once where the problem was some sort of interaction between AOL software and something else - I believe the HP printer driver. (Fortunately, it didn't make a difference if my software was installed.)
Anything notable about his hardware configuration? Limited RAM or something?
Is he close enough geographically that you could bring over a machine and put together a remote debugging setup?
One thing that I find surprising is that you are able to use the same source code under both VC++ 6 and 2008, considering the non-standard dialect of C++ used in version 6 and not in later versions.Please do not read this signature.
|
|
|
|
|
Avi Berger wrote: Have you gotten a list of all the programs that he has installed on each machine? Any programs on both that are not common? Or perhaps common, but dubious?
Not yet. It's a pain in the neck to do that, and I'm already asking a lot of him because his are the only computers on which it crashes. Instead, I asked him to try not loading stuff, but it still crashed. It crashed when he turned off all startup programs (in msconfig), it crashed when he booted into diagnostic mode (though msconfig), and it even crashed when he booted into safe mode and ran it!
I just noticed he said he got a blue screen crash after rebooting from msconfig, but he didn't say after which reboot. Either way, that makes it sound like there's something funny on his system. Why should NOT loading something cause a blue screen crash?
I just emailed him to ask what software he was running on both computers.
Avi Berger wrote: Is he close enough geographically that you could bring over a machine and put together a remote debugging setup?
I think he lives a few hundred miles away from me, so that would be a long trip.
Avi Berger wrote: One thing that I find surprising is that you are able to use the same source code under both VC++ 6 and 2008, considering the non-standard dialect of C++ used in version 6 and not in later versions.
It was originally written with VC++ 6 and then moved over to Visual Studio 20008, so it was pretty easy to move it back. I had to make some very small changes to make it work on both, but nothing much.
I just realized I did something pretty stupid when compiling - in fact, I'm not sure why it's working at all. I had it set for "Use standard Windows libraries" rather than "Use MFC in...((static or dynamic))". I just rebuilt it in two versions, one statically linking to MFC, one dynamic, and gave him a link to the redistributables (for dynamic linking). I haven't heard back yet. I wonder if, after all this pain, that's all it was. And yet, I still don't understand why it doesn't work for him and it works for everyone else.
|
|
|
|
|
Hi,
when a program runs fine on one system and not on another, there may be a difference in the environment, such as a missing DLL, or a different version of DLL. However, it may also indicate a simple bug in the program: running fine on a system is no proof of correctness.
Here are some ideas, the list is not complete!
- regional settings may be different, causing a conversion to sometimes fail. Example: date formatting could be dd-MMM-yyyy or MM/dd/yyyy, a string gets parsed fine in the one situation and not in the other. Now if the program also lacks decent error detection and reporting, you will be completely in the dark.
- some data gets stored somewhere, in a file, in registry, whatever; it is different on different systems and some values (or absence thereof) is not handled well. Example: assume a recent file list is kept in registry, it does not exist on some system, and as a result m_pRecentFileList->m_arrNames[0] is null (or undefined) and can not reliably be dereferenced.
Advice:
- check your code for proper error detection, reporting and handling;
- check your code dealing with inputs (registry, files, network locations, ...) as that is the greatest area of variance;
- check your system configuration, such as amount of memory.
|
|
|
|
|
Those are good points about the environment. Something like this would explain how it could be something specific about his system that isn't fixed by booting into Safe mode or not running Startup programs. I don't think it's date-format-related or it would be crashing on the computer of the Australian guy who's been testing the program, too. He's tried it on multiple systems with no problems.
I check return codes for everything - I went over every line of the startup code again.
Isn't the recent file list always stored in the registry for XP and above? My program targets XP and above. Anyway, I know it is on his system because my crash dump report includes the registry settings. I use this statement to enable and load the MRU files:
LoadStdProfileSettings(4);
My program does do a lot with input and output, and the InitInstance function mainly figures out paths for input and output. The input path is wherever the executable is. If the path ends up more than 260 characters, the program will put up an error message and terminate. Output is a subdirectory of MyDocs, which is created if it's not found. I check every return code and terminate cleanly if something goes wrong. I've traced through all the filename/path stuff in the debugger and it's working correctly.
He sent me some system specs from a diagnostic program he runs. I should look at it more carefully.
|
|
|
|
|
I am not familiar with LoadStdProfileSettings(4);. What does it return when there aren't any MRU files (in registry or where ever they get stored)?
one more typical mistake: one cannot store a file in a folder that does not yet exist.
|
|
|
|
|
It has no return code. Here's what Microsoft says about it:
http://msdn.microsoft.com/en-us/library/xbkh2k4h.aspx[^]
CWinApp::LoadStdProfileSettings
Call this member function from within the InitInstance member function to enable and load the list of most recently used (MRU) files and last preview state.
void LoadStdProfileSettings(
UINT nMaxMRU = _AFX_MRU_COUNT
);
I definitely create the output folder before I store anything in it.
|
|
|
|
|
I believe it is related to Heap Corruption.
Most probable reason is Buffer overrun.
Check for memory copy, memory concatenation etc in our code in that flow.
Some where in the code, you are using more memory than allocated.
These errors are hard to detect and crash on those machines, where it wont get that memory location, which is overrun from the allocation, because it might have benn already reserved.Величие не Бога может быть недооценена.
|
|
|
|
|
Are you in a position to be able to setup a remote debugging connection?
This allows you to step through the code on the target computer using the debugger on your PC.
There are some hoops to jump through to set it up, but it may be invaluable in helping to track down the root cause of the issue.If you vote me down, my score will only get lower
|
|
|
|
|
I've never done this and don't know how. What do you have to do to set it up?
|
|
|
|
|
I would recommend you do a search on the microsoft site for remote debugging in relation to the development platform your using. (Actually a straight google search for "remote debugging" should turn up what you need)
As the implementation of this has varied slightly over the years, I cannot give any direct description on how to perform it for your environment.If you vote me down, my score will only get lower
|
|
|
|
|
When I'm having issues that I cannot reproduce, then I use remote desktop/remote assistance to take control of the customer computer and install Windows Debug Tools (WinDbg).
WinDbg allows you to debug applications:
1) To see call stack while debugging then you need to upload Program Database files (PDB) generated with the EXE/DLL files.
2) To see source code then you need to upload the source used to compile the application.
3) To see values of variables (and not just addresses), then you need to compile the application without optimization turned on.
P.S. I would add the following to the problem line you have shown:
# Check that m_pRecentFileList != NULL
# Change m_arrNames to a proper container and check the size of that instead of using m_nSize
|
|
|
|
|
Yes, yes, and yes - thanks. I can see this is the direction I need to go.
I have WinDbg installed, but my knowledge of how to use it is minimal. I've used it to view crash dumps, but never for remote debugging and I don't know how that works. I need to google remote debugging for more detailed instructions.
Snakefoot wrote: I would add the following to the problem line you have shown:
# Check that m_pRecentFileList != NULL
# Change m_arrNames to a proper container and check the size of that instead of using m_nSize
Yeah, it's becoming clear to me that I need to check this pointer before trying to use it. The reason I didn't is that I didn't think there was any way it could be invalid after I'd made the call to LoadStdProfileSettings(4);. Could you tell me under what circumstances this structure might not be populated properly after this call? There's no return value to check with LoadStdProfileSettings.
I don't know what you mean by "change m_arrNames to a proper container". What is a "proper container". Confession: I learned to program in the pre-Windows DOS world (I am old) and I'm more adept with procedural programming than object-oriented programming.
|
|
|
|
|
A proper container is one that keeps track of its allocation like std::vector or MFC::CSimpleArray.
But I see that you are using CRecentFileList(), and it seems to be without such features.
|
|
|
|
|
I made a small change to the program, and now it's crashing on my own development system - which is sort of bad, but also sort of good.
The problem is not the line I quoted. It's crashing when it tries to run the app. I think I must have a buffer overrun somewhere, though I have no idea where. I looked at Bounds Checker but it costs $1500. Is there a cheaper alternative?
Geez - I am losing it, or I need more sleep or something. I deleted something crucial, that is all. Back to the original problem...modified on Wednesday, March 17, 2010 6:02 PM
|
|
|
|
|
Snakefoot wrote: A proper container is one that keeps track of its allocation like std::vector or MFC::CSimpleArray.
But I see that you are using CRecentFileList(), and it seems to be without such features.
I put in a check that the list exists, and for some reason I cannot fathom, it is not created properly on this one guy's system, though it works fine for everyone else.
I can't imagine what he can be doing on his computer that would prevent this standard MFC call from working properly. Does anyone know? I'd rather not do it all manually if I don't have to. I'd rather detect systems that don't support it, but I don't know of any reason why a system would not support it.
Can anyone make a guess on this?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
