Hi Guys

By proposing switch I think no c++ standard is threatened. We allready
have switch for unsigned char etc.

Looking at most of effort being pushed to STL and all kinds of
smart-pointer templates to produce more resilient code.
I think C/kernel developers deserve some love too.
I strongly belive That automatic cleanup should be provided also for
dynamic data on C/C++ low level language level.
Imagine specially declared ointers being freed when leaving scope.
So normal recovery in case of exception/error without memory leaks or
double deallocations are possible without error prone duplicate
copy-paste cleanup statements.
This will result to simpler and safer but not slower code.

First current state example

void proc() {
  Object* object_ptr;
  // zillion error/exception handlers zillion ways to messup cleanup
}

Let smart pointer declaration be for example
type *~ variable;

void proc() {
  Object*~ object_ptr;
  // zillion error/exception handlers but destructor/free is
automatically called when not null  and leaving scope just like with
static objects
}

Another important example

struct A {
  Object*~ object_ptr;
  Object*~ array[1000]; // during creation of array element [500]
exception happens yet resources are properly freed like with static
objects
}

// when stuct is destroyed all non null pointers have free called/
destructors where appropriate

Now those of you sayng that it is too complex to be done. I already
implemented it.
You can test it here.
http://www.codeproject.com/Articles/468126/new-local-for-safer-and-simpler-code-with-no-need

Unfortunately I have no idea how to do it in gcc. Is someone fluid
with gcc or it's plugins willing to hlep me ?
I would be more than thankfull.

I thing it would be best to implement it as compiller switch -fsmart-pointers
not requiring scope object and derive statement for objects. ie we
need equal flexibility and freedom like have today with static objects


What you guys think about this? I don't belive in stl solves all
especially in low level land.
Many heap spray exploits live only from improper cleanup from
complicated error handlers.
And there is really no need to have complicated and error prone code
anymore with this switch.

Regards
Ladislav Nevery [Unemployed]

Reply via email to