Re: Proposing switch -fsmart-pointers

[Ladislav Nevery <neuralll at gmail dot com>]

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 <aph@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
}