MFC new should throw
-
The C++ standard requires that the
newoperator throws upon failure, but MS for some unknown reason implemented their compiler otherwise: it will return 0 upon failure and not throw. In short, Visual C++ is not standard compliant, in this, and various other things, mostly related to templates. If you code platform-independent, you will have to specifically take care of these discrepancies, but since you are using MFC, I suppose that is not the case.In this case, the compiler is not at fault. Since VC2005, Visual C++ compilers have been good at adhering to the standard, and has largely been at par with the other compilers out there in that regard. In VC2008,
newthrows as it should, but the code in the question above is automatically generated, and that generator has apparently not been updated since the bad old days of VC6.0 Since Herb Sutter - the convener of the C++ standards committee - started working for Microsoft as an architect in the developer tools division, they have spent a lot of time and effort on becoming standards-compliant, and you do them a disservice to claim that the recent compilers are as bad as the steaming pile of wossname that VC6 is. -
In this case, the compiler is not at fault. Since VC2005, Visual C++ compilers have been good at adhering to the standard, and has largely been at par with the other compilers out there in that regard. In VC2008,
newthrows as it should, but the code in the question above is automatically generated, and that generator has apparently not been updated since the bad old days of VC6.0 Since Herb Sutter - the convener of the C++ standards committee - started working for Microsoft as an architect in the developer tools division, they have spent a lot of time and effort on becoming standards-compliant, and you do them a disservice to claim that the recent compilers are as bad as the steaming pile of wossname that VC6 is.Ah, good to know. I only recently switched from 2003 to 2010 and only knew this used to be at fault in VS 2003.
-
This is the code generated by the wizard, which is merely the user application skeleton that the user (i.e. you) modifies to their own requirements. What you have is the minimum necessary and it's up to you to change it to your own needs.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
I guess what I'm asking is why do they even check the pointer if MFC claims it will throw on an MFC (CObject derived class) new failure.
As mentioned elsewhere, this is just some wizard generated code that has not yet been updated. It's really the sort of thing you should be bringing to the attention of Microsoft rather than raising it here.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
As mentioned elsewhere, this is just some wizard generated code that has not yet been updated. It's really the sort of thing you should be bringing to the attention of Microsoft rather than raising it here.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
Richard MacCutchan wrote:
It's really the sort of thing you should be bringing to the attention of Microsoft rather than raising it here
Alrighty then. I'll get a hall pass next time before I start raising questions here :confused:
What is wrong with my suggestion? You are complaining about a Microsoft product, so the logical thing to do is to report it to Microsoft. How else are they going to discover how concerned you are?
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
What is wrong with my suggestion? You are complaining about a Microsoft product, so the logical thing to do is to report it to Microsoft. How else are they going to discover how concerned you are?
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
My question was not a complaint....And no, I don't think the logical thing to do when you have a question is to report it to Microsoft. :rolleyes:
Sorry dude, I'm going with Richard on this one.
Quote:
I guess what I'm asking is why do they even check the pointer if MFC claims it will throw on an MFC (CObject derived class) new failure.
Asking here what is going on in Microsoft's mind is not going to get any answers. Oh, there are a few out here that either claim to be psychic or claim to channel Bill Gates himself but really, if you want an answer to that question, ask Microsoft.
-
Sorry dude, I'm going with Richard on this one.
Quote:
I guess what I'm asking is why do they even check the pointer if MFC claims it will throw on an MFC (CObject derived class) new failure.
Asking here what is going on in Microsoft's mind is not going to get any answers. Oh, there are a few out here that either claim to be psychic or claim to channel Bill Gates himself but really, if you want an answer to that question, ask Microsoft.
Here let me rephrase my question so I can better understand if I'm doing things correctly in my existing MFC code... "Do you check the validity of a pointer to a CObject derived class after new? If so, can you tell me why it would be necessary? If not, can you tell me why it wouldn't be necessary? NOTE: I'm only focusing on MFC new since and including Visual C++ 2003.
-
My question was not a complaint....And no, I don't think the logical thing to do when you have a question is to report it to Microsoft. :rolleyes:
bob16972 wrote:
My question was not a complaint
Sure sounded like one.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
Here let me rephrase my question so I can better understand if I'm doing things correctly in my existing MFC code... "Do you check the validity of a pointer to a CObject derived class after new? If so, can you tell me why it would be necessary? If not, can you tell me why it wouldn't be necessary? NOTE: I'm only focusing on MFC new since and including Visual C++ 2003.
So I went into Visual Studio 2008 and found some code that uses
newand hit 'F1' and received this tidbit:Quote:
Remarks This form of operator new is known as scalar new, in contrast to the vector new form (operator new[]). The first form of this operator is known as the nonplacement form. The second form of this operator is known as the placement form and the third form of this operator is the nonthrowing, placement form. The first form of the operator is defined by the compiler and does not require new.h to be included in your program. operator delete frees memory allocated with operator new. You can configure whether operator new returns null or throws an exception on failure. See The new and delete Operators for more information. With the exception of throwing or no-throwing behavior, the CRT operator new behaves like operator new in the Standard C++ Library.
So, since you can apparently configure the action on failure, I'm guessing that the MFC / Wizard code is defending against the case where it *doesn't* throw an exception (wow, now I'm channelling Bill Gates). I didn't follow the links to *how* one would configure the behavior or what the default behavior is now-a-days. I suggest you set the behavior the way you want it (or take the default) and write your code accordingly.
-
So I went into Visual Studio 2008 and found some code that uses
newand hit 'F1' and received this tidbit:Quote:
Remarks This form of operator new is known as scalar new, in contrast to the vector new form (operator new[]). The first form of this operator is known as the nonplacement form. The second form of this operator is known as the placement form and the third form of this operator is the nonthrowing, placement form. The first form of the operator is defined by the compiler and does not require new.h to be included in your program. operator delete frees memory allocated with operator new. You can configure whether operator new returns null or throws an exception on failure. See The new and delete Operators for more information. With the exception of throwing or no-throwing behavior, the CRT operator new behaves like operator new in the Standard C++ Library.
So, since you can apparently configure the action on failure, I'm guessing that the MFC / Wizard code is defending against the case where it *doesn't* throw an exception (wow, now I'm channelling Bill Gates). I didn't follow the links to *how* one would configure the behavior or what the default behavior is now-a-days. I suggest you set the behavior the way you want it (or take the default) and write your code accordingly.
I had to dig around in MSDN and trace through a few MFC based allocation failures to find out how to change the MFC handler and came across AfxSetNewHandler which does (confirmed this) set the handler for allocation failures in an MFC application. The last time I checked this out (MFC allocation failures) was 7 years back and I only remember walking away with confirming what MSDN says about CMemoryException - "Memory exceptions are thrown automatically by new". Its probably good for one to revisit this topic every so often as I had been concerned that I had been protecting my new incorrectly all this time after seeing the wizard code. Thanks for helping me get to the bottom of this. :)
-
bob16972 wrote:
My question was not a complaint
Sure sounded like one.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
Nah. I was just trying to figure out what the Microsoft programmers were attempting to protect against as I hadn't contemplated the scenario that Chuck O'Toole brought up in a different post. He gave me a swift kick in the right direction and I think the mystery is now solved. Thanks for your time.