quote:

---

Original post by Anonymous Poster

Search for the Factory pattern over the net.There is something in www.Flipcode.com, in one of the author´s columns.

Do yourself a favour and buy this book: "Dessign Patterns", Addison-Wesley,Erich Gamma...

---

heh, i got the book last month as a matter of fact. Very interesting read, and The factory pattern is definitely really cool, however, it is not feasable in my current situation.

I will end up creating a factory, of course, its just that the library I am working on requires a more direct and non-abstracted method of creating structures, because each structure has a very different use, etc.

Someone also suggested to me a factory method pattern, which intrigues me a bit more, but again, i''d need to totally recode the way my existing hierarchy is designed.

===============================================
Have I no control, is my soul not mine?
Am I not just man, destiny defined?
Never to be ruled, nor held to heel!

From the C++97 standard (I cant find any newer versions):

part 15: Exception Handling

quote:

---

3 A function-try-block associates a handler-seq with the ctor-initial-
izer, if present, and the function-body. An exception thrown during
the execution of the initializer expressions in the ctor-initializer
or during the execution of the function-body transfers control to a
handler in a function-try-block in the same way as an exception thrown
during the execution of a try-block transfers control to other han-
dlers.

---

int f(int); class C { int i; double d; public: C(int, double); }; C::C(int ii, double id) try : i(f(ii)), d(id) { // constructor function body } catch (...) { // handles exceptions thrown from the ctor-initializer // and from the constructor function body }

apparently VC6 Professional does not support function-try blocks. Interesting.

Stoffel: I didn''t have time to look over your mfc example (I''ll look into it when i get home, lab is closing in a minute), but does it take into account the throw in a new situation?

eh, later for now.

===============================================
Have I no control, is my soul not mine?
Am I not just man, destiny defined?
Never to be ruled, nor held to heel!

From VC++ documentation:
Note Microsoft C++ does not support exception-specifications, as described in section 15.4 of the ANSI C++ draft. In addition, it does not support function-try-block described in section 15 of the ANSI C++ draft.

So you''re SOL and will have to move your try/catch block to the code that tries to instantiate the object. Either that, or change your embedded objects into pointers and dynamically allocate them in the ctor, where you are free to try/catch exceptions.

Yes, my example covers new. And apparently, the memory is deallocated for a new object at the point where the throw in the ctor occurs but before the catch handler is entered (at least, that''s what it looks like when watching the memory window).

I love this topic. Stroustrup (C++ originator) says go ahead thow exceptions in constructors to your heart''s content. Meyers (Effective C++) says whoa nelly. Stroustrup even goes so far as to say that the destructor for the object will be called in all cases. Meyers says no, compilers won''t call a destructor for an object that wasn''t fully constructed, and the best you can do there is catch the exception locally in the ctor, clean up any memory you allocated, and rethrow it. There seems to be disagreement too on whether the memory allocated by new will be deleted when the exception is thrown

try
{
SomeObject* pObj = new SomeObject;
}
catch(...)
{

}

since the ctor for SomeObject threw, the assignment was never done, so there is certainly no way you can delete pObj. Everyone seems to agree on that one. The C++ standard says that it should be freed automatically by the system if any exceptions are thrown in the ctor for SomeObject. Meyers states that many C++ compilers do not support this. I know for a fact that the MFC literature I have read advises against this exact thing. Maybe this has been changed in MFC recently. Dunno

Has anybody actually managed to catch an std::bad_alloc under Visual C++ 6? I was under the impression that the Microsoft compiler never threw this exception, even after a failed call to the new operator.

- Matt

MSVC does not throw std::bad_alloc.
I am guessing this will be fixed in version 7 (.NET).

http://support.microsoft.com/support/kb/articles/Q167/7/33.ASP

Yes I think you are right.

yeah, VC doesnt throw bad_alloc.

however, I always check the major allocations for null, and if I see it, i throw bad_alloc manually. I did this to make sure my code was ansi compliant later on.

Well, Here''s the results of my experiments:


I manually traced through the entire throw/catch phase of my demonstration, and the debugger never called delete or free...

however, I decided to place a breakpoint on the delete operator, and guess what?

Execution stopped at the delete operator, immediately after the throw call was executed. I don''t know why my debugger wouldn''t show me a trace into delete, but I''ve confirmed that MSVC6 does, indeed, delete memory allocated from new, but whose constructor throws an exception.

Excellente!

Whether or not this happens in other compilers, I do not know, but for now I am using VC6 and will investigate this matter later when use of a different compiler is required.

Thanks for all the great inputs, guys.

===============================================
Have I no control, is my soul not mine?
Am I not just man, destiny defined?
Never to be ruled, nor held to heel!

One more thing:

Does anyone think this feature should be included in release code:

I''ve been putting try/catch blocks in EVERY function which might call something that causes an exception, with the intent that the catch block will add the name of the current function to the exception''s stack and rethrow. (this is essentially keeping track of the call stack. I havent been able to find any C++ method that automatically does this)

Its a very effective method of finding out exactly what is causing the exception (hell, an exception caused 50 levels deep from another function is no help whatsoever in finding the problem), and I figured that since a try is only 1 layer of overhead, I can sweat it for debug mode.

The question is, should this stuff be removed for final production code? I am afraid that it beefs up some of the inline stuff too much and causes the compiler to un-inline it sometimes.

===============================================
Have I no control, is my soul not mine?
Am I not just man, destiny defined?
Never to be ruled, nor held to heel!