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
}
