C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  purpose of function try blocks Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Andrei Alexandrescu Guest Posted: Wed Dec 10, 2003 11:25 am    Post subject: purpose of function try blocks Could anyone point me to a reference on what the intent of function try blocks was? I found http://www.c-view.org/tech/pattern/cpptips/ctor_fail_except, but that's Herb's realizations, not necessarily exactly the same as what the designers intended. Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Wed Dec 10, 2003 4:12 pm    Post subject: Re: purpose of function try blocks On 10 Dec 2003 06:25:59 -0500, "Andrei Alexandrescu" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote: Quote: Could anyone point me to a reference on what the intent of function try blocks was? I found http://www.c-view.org/tech/pattern/cpptips/ctor_fail_except, but that's Herb's realizations, not necessarily exactly the same as what the designers intended. I don't know what the designers meant, but here's some non-Parroting input on the cited article. It has a certain armwaving quality. For example, <quote> Constructor function-try-blocks have only one purpose -- to translate an exception. (And maybe to do logging or some other side effects.) They are not useful for any other purpose. </quote> "side effects" presumably includes any purpose whatsoever one might consider, within the bounds of the language (i.e., not referring to members of the object that was but, uh, in retrospect wasn't). So the conclusion that apart from any purpose whatsoever "[function-try-blocks] are not useful" is trivially true but misleading. Herb then builds on that non-conclusion to conclude further, that <quote> Since destructors should never emit an exception, destructor function-try-blocks have no practical use at all. ... even if there were something to detect because of evil code, the handler is not very useful for doing anything about it because it can not suppress the exception. </quote> Well, what about the "maybe logging" or "other side effects"? This doesn't make sense at all. It's an elevation of a set of guidelines with some limited scope, to universal technical truth, which is incorrect. In light of the above the question of intended purpose seems to be a good one. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Wed Dec 10, 2003 4:24 pm    Post subject: Re: purpose of function try blocks In article <br5thc$29grgf$1 (AT) ID-14036 (DOT) news.uni-berlin.de>, Andrei Alexandrescu <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes Quote: Could anyone point me to a reference on what the intent of function try blocks was? I found http://www.c-view.org/tech/pattern/cpptips/ctor_fail_except, but that's Herb's realizations, not necessarily exactly the same as what the designers intended. As I recall function try blocks were introduced specifically to cope with issues concerning ctors. There is no practical purpose to their use elsewhere. However once you place them in the grammar (for the benefit of ctors) it would require an explicit constraint to restrict their use to ctors (I do wish that C++ had accepted that ctors and dtors are not functions rather than applying a whole range of special constraints because they are not really functions). No useful purpose seems to be accomplished by explicitly forbidding the use of function try blocks for functions that are not ctors. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Travis Spencer Guest Posted: Wed Dec 10, 2003 8:14 pm    Post subject: Re: purpose of function try blocks Also, regarding the design of try blocks: I have wondered why try and catch blocks must be enclosed in braces even if the body is only a single line. Unlike the other constructs, a one-liner like the following wont compile unless it is braced off: try ; // Handle error here in one line catch (std::exception ex) throw ex; It is the same way in Java, so I think it might be a compiler design issue. If anyone can tame my curiosity I would really appreciate it. -- Regards, Travis Spencer Portland, OR USA "Andrei Alexandrescu" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote in message news:br5thc$29grgf$1 (AT) ID-14036 (DOT) news.uni-berlin.de... Quote: Could anyone point me to a reference on what the intent of function try blocks was? I found http://www.c-view.org/tech/pattern/cpptips/ctor_fail_except, but that's Herb's realizations, not necessarily exactly the same as what the designers intended. Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andrei Alexandrescu Guest Posted: Thu Dec 11, 2003 11:41 am    Post subject: Re: purpose of function try blocks "Travis Spencer" <travislspencer (AT) hotmail (DOT) com> wrote Quote: Also, regarding the design of try blocks: I have wondered why try and catch blocks must be enclosed in braces even if the body is only a single line. Unlike the other constructs, a one-liner like the following wont compile unless it is braced off: try ; // Handle error here in one line catch (std::exception ex) throw ex; It is the same way in Java, so I think it might be a compiler design issue. If anyone can tame my curiosity I would really appreciate it. Oh that's a classic. Simple statements make it hard to match catches to trys. Consider: try try a = "hello"; catch (Exc&) b = 1; catch (...) b = 2; It's hard to tell whether the second catch binds to the inner or the outer try. It's much like the "dangling else" problem, except that multiple catches associated to a try make things even more confusing. Any decision could be incorporated in the compiler, the problem is reading code. Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Eugene Alterman Guest Posted: Thu Dec 11, 2003 11:42 am    Post subject: Re: purpose of function try blocks "Andrei Alexandrescu" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote in message news:br5thc$29grgf$1 (AT) ID-14036 (DOT) news.uni-berlin.de... Quote: Could anyone point me to a reference on what the intent of function try blocks was? I found http://www.c-view.org/tech/pattern/cpptips/ctor_fail_except, but that's Herb's realizations, not necessarily exactly the same as what the designers intended. Seems like that is in agreement with Bjarne Stroustrup who demonstrates this construct in "14.4.6.1 Exceptions and Member Initialization" of his "The C++ Programming Language". Why? I bet you came up with some groundbreaking technique that utilizes that in different context. Confess! ;-) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andrei Alexandrescu Guest Posted: Thu Dec 11, 2003 11:44 am    Post subject: Re: purpose of function try blocks "Francis Glassborow" <francis (AT) robinton (DOT) demon.co.uk> wrote Quote: In article <br5thc$29grgf$1 (AT) ID-14036 (DOT) news.uni-berlin.de>, Andrei Alexandrescu <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes Could anyone point me to a reference on what the intent of function try blocks was? I found http://www.c-view.org/tech/pattern/cpptips/ctor_fail_except, but that's Herb's realizations, not necessarily exactly the same as what the designers intended. As I recall function try blocks were introduced specifically to cope with issues concerning ctors. My question is: which issues, exactly? Translating from std::exception to MyException (or vice versa)? Because it turns out there's little more one can do than that. My thinking is, adding a feature is an endeavour with a very high fixed cost; so if you add a feature, at least make the addition worth it. Quote: There is no practical purpose to their use elsewhere. However once you place them in the grammar (for the benefit of ctors) it would require an explicit constraint to restrict their use to ctors (I do wish that C++ had accepted that ctors and dtors are not functions rather than applying a whole range of special constraints because they are not really functions). No useful purpose seems to be accomplished by explicitly forbidding the use of function try blocks for functions that are not ctors. I see. My upcoming CUJ article had (while in draft form) a scathing review of this feature. A friend convinced me to mellow it down, so I said I best go out there ans ask people who've worked on it. Is it that they wanted such a crippled feature, or something else? Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Thu Dec 11, 2003 9:04 pm    Post subject: Re: purpose of function try blocks In article <br95i9$mu8g$1 (AT) ID-14036 (DOT) news.uni-berlin.de>, Andrei Alexandrescu <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes Quote: As I recall function try blocks were introduced specifically to cope with issues concerning ctors. My question is: which issues, exactly? Translating from std::exception to MyException (or vice versa)? Because it turns out there's little more one can do than that. My thinking is, adding a feature is an endeavour with a very high fixed cost; so if you add a feature, at least make the addition worth it. IIRC the major problem was in ctor init lists. These days we tend to handle issues of exception safety by use of smart pointers etc. But seven years ago this was less common so providing a mechanism that at least seemed to address the problem of releasing resources acquired during an aborted construction seemed sane. I guess that these days we do not code in that style so they actually serve very little purpose. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Thu Dec 11, 2003 9:10 pm    Post subject: Re: purpose of function try blocks "Travis Spencer" <travislspencer (AT) hotmail (DOT) com> wrote Quote: Also, regarding the design of try blocks: I have wondered why try and catch blocks must be enclosed in braces even if the body is only a single line. Unlike the other constructs, a one-liner like the following wont compile unless it is braced off: try ; // Handle error here in one line catch (std::exception ex) throw ex; Maybe because Stroustrup didn't want to extend earlier errors:-). Perhaps he was thinking of what you can do with switch when he decided that the braces should be necessary. Seriously, I think it is an issue of clean programming. You don't want something like: try int* p = new int[ 100 ] ; catch ( ... ) // p in scope here... Quote: It is the same way in Java, so I think it might be a compiler design issue. Or maybe just that Java copied C++, without giving it too much thought. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Thu Dec 11, 2003 9:25 pm    Post subject: Re: purpose of function try blocks "Andrei Alexandrescu" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes: Quote: "Francis Glassborow" <francis (AT) robinton (DOT) demon.co.uk> wrote in message news:puvb9hDOJy1$Ewq5 (AT) robinton (DOT) demon.co.uk... I see. My upcoming CUJ article had (while in draft form) a scathing review of this feature. A friend convinced me to mellow it down, so I said I best go out there ans ask people who've worked on it. Is it that they wanted such a crippled feature, or something else? It's my impression that there were a few "wouldn't it be nice if..." features added to C++ EH whose consequences nobody really thought through completely. Exception-specifications come to mind. FWIW, I think it's likely that function try blocks are similar and someone thought they were going to solve a problem they don't. You can't say that, however, without some proof ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Richey Guest Posted: Fri Dec 12, 2003 2:06 am    Post subject: Re: purpose of function try blocks "Andrei Alexandrescu" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote Quote: "Francis Glassborow" <francis (AT) robinton (DOT) demon.co.uk> wrote in message news:puvb9hDOJy1$Ewq5 (AT) robinton (DOT) demon.co.uk... In article <br5thc$29grgf$1 (AT) ID-14036 (DOT) news.uni-berlin.de>, Andrei Alexandrescu <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes Could anyone point me to a reference on what the intent of function try blocks was? I found http://www.c-view.org/tech/pattern/cpptips/ctor_fail_except, but that's Herb's realizations, not necessarily exactly the same as what the designers intended. As I recall function try blocks were introduced specifically to cope with issues concerning ctors. My question is: which issues, exactly? Translating from std::exception to MyException (or vice versa)? Because it turns out there's little more one can do than that. My thinking is, adding a feature is an endeavour with a very high fixed cost; so if you add a feature, at least make the addition worth it. There is no practical purpose to their use elsewhere. However once you place them in the grammar (for the benefit of ctors) it would require an explicit constraint to restrict their use to ctors (I do wish that C++ had accepted that ctors and dtors are not functions rather than applying a whole range of special constraints because they are not really functions). No useful purpose seems to be accomplished by explicitly forbidding the use of function try blocks for functions that are not ctors. I see. My upcoming CUJ article had (while in draft form) a scathing review of this feature. A friend convinced me to mellow it down, so I said I best go out there ans ask people who've worked on it. Is it that they wanted such a crippled feature, or something else? Function try blocks in constructors do fill a real need. The type of exceptions that may be emitted from a function are logically part of the interface for that function. Given a class A with private bases or members whose constructors may throw exceptions, function try blocks are the only way for the designer of A to control the set of exception types that may be emitted from A's constructor. Consider the following: class A : private B { public: class Exception; A(); // Will only throw exceptions of type A::Exception; // ... private: C c_; }; The designer of class A wants to enable the following usage: try { A anA; // do something with anA } catch ( A::Exception const & ) { // do something without anA } Without function try blocks, the designer of A has no way to enforce the constraint that A's constructor will only emitted exceptions of type A::Exception. Clients of A would need to know that A's constructor may also emit the set of exception types that B's and C's constructors emit. Yet the facts that A is derived from B and has member of type C are implementation details of A. Changing those details would affect all clients of A that need to know the set of exception types that may be emitted from A's constructor. David Richey [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Fri Dec 12, 2003 9:37 am    Post subject: Re: purpose of function try blocks Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> writes: Quote: In article <br95i9$mu8g$1 (AT) ID-14036 (DOT) news.uni-berlin.de>, Andrei Alexandrescu <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes As I recall function try blocks were introduced specifically to cope with issues concerning ctors. My question is: which issues, exactly? Translating from std::exception to MyException (or vice versa)? Because it turns out there's little more one can do than that. My thinking is, adding a feature is an endeavour with a very high fixed cost; so if you add a feature, at least make the addition worth it. IIRC the major problem was in ctor init lists. These days we tend to handle issues of exception safety by use of smart pointers etc. But seven years ago this was less common so providing a mechanism that at least seemed to address the problem of releasing resources acquired during an aborted construction seemed sane. I guess that these days we do not code in that style so they actually serve very little purpose. I don't think it's a question of style, Francis. They're not actually *capable* of much other than exception translation, no matter what your stylistic bent. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andrei Alexandrescu Guest Posted: Fri Dec 12, 2003 9:50 am    Post subject: Re: purpose of function try blocks "David Richey" <drichey93065 (AT) yahoo (DOT) com> wrote Quote: I see. My upcoming CUJ article had (while in draft form) a scathing review of this feature. A friend convinced me to mellow it down, so I said I best go out there ans ask people who've worked on it. Is it that they wanted such a crippled feature, or something else? Function try blocks in constructors do fill a real need. [snip] Thanks for the explanation. I didn't contend that. What I said was that this feature does *only* this one thing, but doesn't address any other problem related to exceptions occuring in construction. And again, the cost of adding *any* feature is so high, you really want to make it worth it. Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Dec 12, 2003 6:25 pm    Post subject: Re: purpose of function try blocks In article <uhe07atne.fsf (AT) boost-consulting (DOT) com>, David Abrahams <dave (AT) boost-consulting (DOT) com> writes Quote: IIRC the major problem was in ctor init lists. These days we tend to handle issues of exception safety by use of smart pointers etc. But seven years ago this was less common so providing a mechanism that at least seemed to address the problem of releasing resources acquired during an aborted construction seemed sane. I guess that these days we do not code in that style so they actually serve very little purpose. I don't think it's a question of style, Francis. They're not actually *capable* of much other than exception translation, no matter what your stylistic bent. It was my understanding that; mytype::mytype():i_ptr(new int){} would leak if the ctor failed but: try{ mytype::mytype():i_ptr(new int){} } catch(...){delete i_ptr; throw;} works. (I may have the syntax slightly wrong because I have never elected to use a raw pointer in the presence of exceptions) -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit or http://www.robinton.demon.co.uk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Fri Dec 12, 2003 7:11 pm    Post subject: Re: purpose of function try blocks On 12 Dec 2003 04:50:11 -0500, "Andrei Alexandrescu" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote: Quote: "David Richey" <drichey93065 (AT) yahoo (DOT) com> wrote in message news:ef718f74.0312111002.7e4a2dd3 (AT) posting (DOT) google.com... I see. My upcoming CUJ article had (while in draft form) a scathing review of this feature. A friend convinced me to mellow it down, so I said I best go out there ans ask people who've worked on it. Is it that they wanted such a crippled feature, or something else? Function try blocks in constructors do fill a real need. [snip] Thanks for the explanation. I didn't contend that. What I said was that this feature does *only* this one thing, but doesn't address any other problem related to exceptions occuring in construction. And again, the cost of adding *any* feature is so high, you really want to make it worth it. OK, I think with Francis' explanation of how function try-blocks for ordinary functions and destructors were just a consequence of avoding extra special cases, it's now possible to do a little analysis, see what pops out. Bear with me for first rehashing well-known things; it might just be that my understanding is less than perfect ( ), and so an opportunity for learning. First, a call of a constructor V sans function try-block can be split into phases separated by logical points: Phase 0: Whatever led to this call. Point A: Phase 1: Execution of base class constructors. Point B: Phase 2: Execution of member variable constructors. Point C: Phase 3: Execution of V body. If normal return, jump to point F. Point D: Phase 4: Execution of member variable destructors (only those fully constructed, and in reverse order of construction). Point E: Phase 5: Execution of base class destructors (only those fully constructed, and in reverse order of construction). Point F: Phase 6: Internal goings-on, such as memory deallocation for 'new'. Point G: Phase 7: Return to calling code, or exception in calling code. Constructor V can use the ordinary try-catch to take charge of exceptions in phase 3, but not in phases 1, 2, 4 or 5. A function try-block inserts exception handling code HandlerCode at point F or possibly at point G (it's not important so I haven't checked further): $15.3/11 The fully constructed base classes and members of an object shall be destroyed before entering the handlers of a function try-block. At this point HandlerCode has access to the constructor arguments, §15.3/12 The scope and lifetime of the parameters of a function or constructor extends into the handlers of a function try-block. and HandlerCode has access to the thrown exception, to static members, and to namespace scope things. Presumably HandlerCode also has access to the this-pointer, although it now points to just a chunk of raw memory (I didn't find relevant text in the std). Just to be thorough, here is a list of things HandlerCode has access to: * The constructor arguments. * The thrown exception. * Static members. * Namespace scope things. * The (useless) this-pointer -- at least I think it's got access to that. As a feature of function try-blocks the exception is automatically rethrown if execution flows off the end of HandlerCode. Notwithstanding Francis' comment, here is a difference for ordinary functions on the one hand, and constructors and destructors on the other. Auto rethrowing is _not_ performed for ordinary functions, as per §15.3/16 -- so there's a little question of intention (why the special case?) right there -- but let's forget it... ;-) So, what can HandlerCode _not_ do? It can not suppress the fact that there is an exception, that is, that there is some exception, without terminating the program, and it can not perform additional cleanup on the destroyed object. But that's about it regarding what HandlerCode cannot do: it can do anything else. First, what can HandlerCode do without using access to anything? It can (1) execute a breakpoint. That's not a part of the C++ standard, of course, but on the other hand a C++ implementation that did not allow debugging would probably never succeed in the marketplace. So HandlerCode, even if it were without ability to do anything at all, has a function as an aid to debugging. With HandlerCode in place one can determine whether there is an exception, and if so, which exception, and when. What can HandlerCode do with (only) the thrown exception? It can (2) clean up _the exception_ in the case of badly designed exceptions requiring internal cleanup, such as MFC's CException. This example is not a historically correct example in the sense that function try-blocks were actually used for cleaning up MFC CExceptions (Microsoft, you know). But it illustrates what HandlerCode can do. And it can (3) translate that exception, that is, throw some other exception, which it probably must do if it does exception cleanup. These two actions, (2) and (3), are strongly coupled. Translation usually implies exception cleanup (in the case of standard exceptions exception cleanup is a no-op), and vice versa. What can HandlerCode do with (only) the constructor arguments? It can (4) change data referenced by the arguments. Now I don't know of any practical application (4), but that does not mean it doesn't exist. It can (5) execute code referenced by the arguments. Some practical applications of (5) might conceivably be dynamic parameterization of logging and debugging. And it can (6) destroy objects referenced by the arguments. (6) is an abhorrent notion in modern C++, but as others have remarked in this thread, smart-pointers were not all that common in 1996 or thereabouts. What can HandlerCode do with (only) static members? It can (7) provide a stronger exception guarantee than a base class by cleaning up side-effects established by a base class constructor, when those side-effects are not cleaned up by the base class destructor. And it can ( accumulate information about number of failed constructor calls and failure causes etc. (this can not be done in the body of V). What can HandlerCode do with (only) namespace scope things? It can (9) call any namespace scope function, create objects, etc., just about anything at all, but the question is of course to what purpose. Some possibilities are logging, as in (, static cleanup, debugging support. HandlerCode is in a unique position to do such things because only here is the knowledge of a failed construction available at one central point, so if that knowledge is to be disseminated to other parts of the system, or acted upon, here's the only single place to do so. Finally, what can HandlerCode do with (only) the this-pointer, assuming it's got access? There is a possibility that it can support debugging by memcopying some recognizable bit-pattern into the memory chunk, but I think that would be undefined behavior as far as the standard is concerned; it would be compiler-specific. Summing up, it seems that HandlerCode is restricted to * support debugging (ref 1) as being a place where e.g. a breakpoint might be placed -- the only such place where the knowledge of construction failure is available at a single point, * clean up badly designed exceptions (ref 2, and that does not mean cleanup of things done before the exception, but cleaning up the exception iself), * translate the exception (ref 3), * change data referenced by the constructor arguments (ref 4), although this is of dubious utility, * execute code referenced by the constructor arguments (ref 5), ditto, although some could-be-practical possibilities present themselves, * destroy objects referenced by the constructor arguments (ref 6), in modern C++ replaced by other techniques such as smart-pointers, * provide a stronger exception guarantee than a base class (ref 7), which again assumes building on or encapsulating badly designed code, and * accumulate information about failed constructions and their causes (ref 8 and 9). Paring that down to usefulness in modern C++ programming: A A constructor function try-block can be a debugging and logging aid, providing a single point where knowledge of construction failure is available. B A constructor function try-block allows exception cleanup and translation. C A constructor function try-block allows for wrapping of badly designed base classes, e.g. strenghtening exception guarantees. Of these, only (A) seems to not be possible to achieve by other means. (B) and (C) can be achieved by simple refactoring: not using inheritance but encapsulation, not using direct members but smart-pointers. So I disagree with the view that function try-blocks are there for exception translation -- it's not at all the only possibility, and furthermore it's not the one possibility that cannot easily be achieved by other means. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.