BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  try/finally Goto page 1, 2, 3, 4, 5  Next          BorlandTalk.com Forum Index -> C++ Builder (Language C++) View previous topic :: View next topic   Author Message JD Guest Posted: Wed Dec 07, 2005 4:25 am    Post subject: Re: try/finally "Zach Saw" <mail (AT) mail (DOT) com> wrote: Quote: [...] try/finally is still convenient in constructs such as: criticalSection->Enter(); try { // do something } __finally { criticalSection->Leave(); } 'convenient' isn't a word that I'd use. The only time one needs that construct is when something might throw and if that construct is used, exceptions are passing unhandled. Certainly, one could use that construct within try/catch block but what would be the point unless the try/catch wraps multiple try/finally? Even then I'd have issues with it because of legacy code where I've has to filter through the stack unwinding all over the place. While someone here might be able to produce a real-world (usesful) example, I can't think of any benifit to using it at all because if you want to allow the stack to unwind, you can just rethrow or throw your own which is certainly more useful when it comes to debugging. ~ JD Back to top Zach Saw Guest Posted: Wed Dec 07, 2005 5:05 am    Post subject: try/finally There has been discussions in the past on whether try/finally should even be necessary in C++. While it's easy to use RAII for resource cleanup, try/finally is still convenient in constructs such as: criticalSection->Enter(); try { // do something } __finally { criticalSection->Leave(); } My question: Is there a way to get rid of try/finally completely for the above while keeping its simplicity? Thanks in advance. -- Zach Back to top Zach Saw Guest Posted: Wed Dec 07, 2005 5:36 am    Post subject: Re: try/finally [...] While someone here might be able to produce a real-world Quote: (usesful) example, I can't think of any benifit to using it at all because if you want to allow the stack to unwind, you can just rethrow or throw your own which is certainly more useful when it comes to debugging. ~ JD Can you suggest another way of doing that? I want to make sure a critical section exits if an unhandled exception is thrown... I know I can use try/catch, but any other ways besides the above? Back to top Remy Lebeau (TeamB) Guest Posted: Wed Dec 07, 2005 6:56 am    Post subject: Re: try/finally "Zach Saw" <mail (AT) mail (DOT) com> wrote Quote: Is there a way to get rid of try/finally completely for the above while keeping its simplicity? RAII can be applied to any acquisition/release idiom, not just memory allocation/deallocation. For example: class CritSecLock { private: TCriticalSection *cs; public: CritSecLock(TCriticalSection *src) : cs(src) { if( cs ) cs->Enter(); } ~CritSecLock() { if( cs ) cs->Leave(); } }; { CritSecLock lock(criticalSection); // do something } Gambit Back to top Remy Lebeau (TeamB) Guest Posted: Wed Dec 07, 2005 6:57 am    Post subject: Re: try/finally "Zach Saw" <mail (AT) mail (DOT) com> wrote Quote: Can you suggest another way of doing that? I want to make sure a critical section exits if an unhandled exception is thrown... I know I can use try/catch, but any other ways besides the above? Use RAII. See my other reply for an example. Gambit Back to top Rob Guest Posted: Wed Dec 07, 2005 7:19 am    Post subject: Re: try/finally Zach Saw wrote: Quote: RAII can be applied to any acquisition/release idiom, not just memory allocation/deallocation. For example: [...] Gambit Thanks :) But in terms of convenience, I think it still doesn't beat try/finally? So the keyword is still arguably a useful addition to the language? Just my 2 cents. I disagree. THe advantage of Gambit's approach or (even better) the variation posted by Torsten Fran is that it is reusable with little effort -- after the class is written, that it can be reused anywhere as a one liner when needed, and is guaranteed to work every time. Using a try/finally may be more convenient as a one-off. But try doing the same thing in ten different functions that need to lock critical sections for their duration, and ensure unlocking occurs no matter what happens. Those ten functions will each be harder to read than they will be with using a RAII technique. One of the reasons that the C++ standard does not support finally is an argument like the above. Back to top Zach Saw Guest Posted: Wed Dec 07, 2005 7:46 am    Post subject: Re: try/finally Quote: RAII can be applied to any acquisition/release idiom, not just memory allocation/deallocation. For example: [...] Gambit Thanks :) But in terms of convenience, I think it still doesn't beat try/finally? So the keyword is still arguably a useful addition to the language? Just my 2 cents. Back to top Torsten Franz Guest Posted: Wed Dec 07, 2005 7:48 am    Post subject: Re: try/finally Quote: Is there a way to get rid of try/finally completely for the above while keeping its simplicity? RAII can be applied to any acquisition/release idiom, not just memory allocation/deallocation. For example: class CritSecLock { private: TCriticalSection *cs; public: CritSecLock(TCriticalSection *src) : cs(src) { if( cs ) cs->Enter(); } ~CritSecLock() { if( cs ) cs->Leave(); } }; { CritSecLock lock(criticalSection); // do something } I would suggest to use a reference instead of a pointer to the critical section. This would even more simplify the class, because the checks for validity would not be required. class CritSecLock { private: TCriticalSection& cs_; public: CritSecLock(TCriticalSection& cs) : cs_(cs) {cs_.Enter();} ~CritSecLock() {cs_.Leave();} }; .... { CritSecLock lock(*criticalSection); // do something } Back to top Alisdair Meredith [TeamB] Guest Posted: Wed Dec 07, 2005 8:02 am    Post subject: Re: try/finally Zach Saw wrote: Quote: But in terms of convenience, I think it still doesn't beat try/finally? So the keyword is still arguably a useful addition to the language? Just my 2 cents. I find RAII vastly more convenient than try/finally, but more importantly it puts the responsibility for 'finally' handling in the right place. As a library author, I provide RAII objects to handle all my resources, and the library users has nothing to get wrong - no bugs of omission, no dangling resources, etc. As a library user, the code is far simpler to work with, generally initializing a variable vs several statements split across my routine nesting new scopes in the process. When maintaining or learning another code base, the code is much cleaner as there is simply less code to read, that is often more correct. Remember - there is no clean-up to forget, therefore no clean-up to worry about. It also correctly handles management of multiple resources, or do you routinely nest your try/finally blocks, one per resource acquired in your routine? Finally, you can make the nature of ownership a policy of your RAII object, a shared_ptr vs a scoped_ptr for instance. This improves the self-documenting nature of your code, and changing the policy means changing the type - something the compiler will catch for you. That kind of change is entirely down to developer observation with try/finally, finding all the affected corners of the code. try/finally is only really useful when working with badly designed code in the first place, and when you don't want to wrap it with a better designed layer of your own. It means you can continue writing bad code with less thought, and the illusion of a safety-net. -- AlisdairM(TeamB) Back to top Thomas Maeder [TeamB] Guest Posted: Wed Dec 07, 2005 8:23 am    Post subject: Re: try/finally "Zach Saw" <mail (AT) mail (DOT) com> writes: Quote: But in terms of convenience, I think it still doesn't beat try/finally? Why not? One expressive line of code rather than seven not so expressive ones seem like a very good bargain to me. Quote: So the keyword is still arguably a useful addition to the language? Could be. I have yet to see a convincing argument, though. Back to top Zach Saw Guest Posted: Wed Dec 07, 2005 10:25 am    Post subject: Re: try/finally Quote: I find RAII vastly more convenient than try/finally, but more importantly it puts the responsibility for 'finally' handling in the right place. As a library author, I provide RAII objects to handle all my resources, and the library users has nothing to get wrong - no bugs of omission, no dangling resources, etc. [...] It also correctly handles management of multiple resources, or do you routinely nest your try/finally blocks, one per resource acquired in your routine? Erm, I only use try/finally for things like critical section enter and leave. I use RAII for others... But thanks for the explanation (to everyone who contributed) -- I agree completely now that try/finally is an inferior solution in any case. Thanks, Zach Back to top Bruce Salzman Guest Posted: Wed Dec 07, 2005 2:07 pm    Post subject: Re: try/finally "Alisdair Meredith [TeamB]" <alisdair.NO.SPAM.PLEASE.meredith (AT) uk (DOT) renaultf1.com> wrote Quote: try/finally is only really useful when working with badly designed code in the first place, and when you don't want to wrap it with a better designed layer of your own. It means you can continue writing bad code with less thought, and the illusion of a safety-net. There's a nice summary of VCL programming <g>. -- Bruce Back to top Rudy Velthuis [TeamB] Guest Posted: Wed Dec 07, 2005 5:03 pm    Post subject: Re: try/finally At 09:23:49, 07.12.2005, Thomas Maeder [TeamB] wrote: Quote: "Zach Saw" <mail (AT) mail (DOT) com> writes: But in terms of convenience, I think it still doesn't beat try/finally? Why not? One expressive line of code rather than seven not so expressive ones seem like a very good bargain to me. First the RAII class must be written and tested. For one-off situations, try/finally would be more convenient. The alternative is to have a library of RAII classes that account for all kinds of possible situations. IMO, there are situations where try/finally is more convenient, especially when you cna use the new live templates in Delphi. Of course, Delphi has no real alternative, so it will have to do with try/finally. Oh, one can write RAII implementations using interfaces in Delphi, but due to the much coarser notion of scope (usually the highest resolution is the function level) and to some other circumstances, these are not so generally applicable as in C++. In .NET, the interface approach will not work at all, since there is no determined destruction of classes. I do hope that C++/CLI has an answer for that. -- Rudy.Velthuis {TeamB} http://velthuis.homepage.t-online.de/ "While we are postponing, life speeds by." - Seneca (3BC - 65AD) Back to top Alex Bakaev [TeamB] Guest Posted: Wed Dec 07, 2005 5:12 pm    Post subject: Re: try/finally Zach Saw wrote: Quote: Thanks :) But in terms of convenience, I think it still doesn't beat try/finally? So the keyword is still arguably a useful addition to the language? Just my 2 cents. I don't think so. You just have to declare a variable on the stack - that's it. Less typing and a *lot* cleaner code. ..a Back to top Alex Bakaev [TeamB] Guest Posted: Wed Dec 07, 2005 5:17 pm    Post subject: Re: try/finally Torsten Franz <FirstName_LastName at agilent dott wrote: Quote: I would suggest to use a reference instead of a pointer to the critical section. I would provide a generic template, lets say template class that would perform locking and unlocking in the constructor/destructor and also had lock/unlock methods. This way the sync primitive could be changed easier. ..a Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> C++ Builder (Language C++) All times are GMT Goto page 1, 2, 3, 4, 5  Next Page 1 of 5   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  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.