Ahh ... sorry for that incomplete mail. I lost my right hand in paragliding accident 2 months ago. And writing mail with one hand on tablet is kinda weird. Again sorry .;( Here is the complete version.
On Mon, Oct 8, 2012 at 5:17 PM, Andrew Haley <a...@redhat.com> wrote: > On 10/06/2012 11:59 AM, _ wrote: >> Not that I think that STL/Boost are not great solutions for many >> problems out there. >> But the fact is that there is and always will be c/c++ code that can't >> and will not use it. > > But surely the set of people refusing to use C++ smart pointers is the > same set that will refuse to use your -fsmart-pointers. > On 10/06/2012 11:59 AM, _ wrote: >> Not that I think that STL/Boost are not great solutions for many >> problems out there. >> But the fact is that there is and always will be c/c++ code that can't >> and will not use it. > > But surely the set of people refusing to use C++ smart pointers is the > same set that will refuse to use your -fsmart-pointers. It all boils down whether they are othodox or just simply pragmatic. I am optimist and belive in second :) > > Andrew. > >> C or C like templateless C++ code is still domain of most os / >> drivers source code out there. >> Just go agead and try to ask Linus to wrap all pointers to stl >> templates ;D > > And he'd have the same response to -fsmart-pointers. Face it, the > only real differences a compiler builtin would bring are: > > 1. A fossilized "smart pointer type". > 2. A different declaration syntax. > > Andrew. Now imagine you have 300 developers with varying experience or ability to work under pressure. You will have 100 libs to manage. And for each lot of patch reviews. Now Tell me which way you decide to go in those projects?. A or B? Way A: code is still C but with automatic cleanup like with static objects, 100% of time of code review you focus on code logic. ie code reviews are faster. Code is shorter faster to compile has the same speed and a lot of less places to make bugs Proc A { alloc resource 1 if problem exit process resource 1 If problem exit alloc 100 different resources if problem exit process 100 resources with resource 1 if problem exit release resources 1-50 process result with resources 50-100 and resource 1 if problem exit return success } Way B: manual cleanup. 30. pretty much 50% of time spend on patch review was spend on checking wheter no errors were made in releasing of resources in error handling. The time you could had spend reviewing other code logic. The code is unnecessary long it's logic is les obvious and takes more time to compile. Proc { alloc resource 1 if problem exit process resource 1 If problem release resource 1 exit alloc 100 different resources if problem release resource 1 and those that didn't fail and exit process 100 resources with resource 1 if problem release resource 1 and 100 resources and exit release resources 1-50 process result with resources 50-100 and resource 1 if problem release resource 1 plus resource 50-100 and exit release resources 50-100 release resource 1 return success }