Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » External resources » Static OOP (C++...) vs Dynamic OOP (CLOS...)
Re: Static OOP (C++...) vs Dynamic OOP (CLOS...) [message #437 is a reply to message #435] Sun, 01 January 2006 14:34 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13980
Registered: November 2005
Ultimate Member
gprentice wrote on Sun, 01 January 2006 07:04


Well I think he's correct when he says this.

Quote:

But C++ is hard to use, and requires an inordinate investment in time to avoid memory leaks (that result in poor performance and random crashes) and to tackle exception handling problems.



though it seems use of Garbage collection is becoming more common in C++ and people use new/delete much less than they used to, even without GC. There's still a large amount of discussion goes on in C++ newsgroups about exception safety.



Actually, both problems are very aggressively addressed in U++.

Resource management is resolved by following "everything belongs to some scope" principle. Together with U++ containers, there are no more resource management problems.

Exception handling problem is pragmatically resolved by ignoring out-of-memory exceptions;) If you go out-of-memory, app simply stops and that is all. I believe that most applications that put effort into solving this are unable to deal with out-of-memory anyway, as there is no reasonable way how to debug such condition. Plus, any application with recursion is prone to similar "out of stack" problem that cannot be solved using exceptions.

 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: dynamically updating programs....
Next Topic: opinions about FOX-TOOLKIT
Goto Forum:
  


Current Time: Sun Jun 02 00:26:03 CEST 2024

Total time taken to generate the page: 0.01629 seconds