Now obviously you can't put stl everywhere.
I don't see kernel and low level C or C++ libs using boost or stl. any
time soon.
Afterall. No reasonable library uses it either due to binary incompatibilities.
But the idea behind smart-pointers is universal end equally relevant
in C and non stl world.
Idea of automatic cleanup even with unknown unhandled exceptions are
being thrown or unexpected control flows happen will be great addition
to driver development.
Idea that reducing the complexity of error handling reduces the amount
of bugs that developer can (and therefore will) make while making code
simpler more focused on program logic.
> Experience shows us that programmers want several different types of
> smart pointers in practice.
Most of those patterns in smart pointers are simple one-liners. ie
reference-counting plus automatic cleanup.
Also by combining them you create all kind's of troubles.
Ie then you must create all possible kombinations , uses copy,uses
move, can be stored in array
Just think about why majority of smart-pointers fail to be stored in
arrays or being efficient. (many use copy where you could use move).
Ie. all the things that you take for granted with simple pointers and
will take for granted with autocleanup added to them.
> (For example, your variant of smart pointers doesn't seem to help with
> pointers in struct fields, when those structs are stored in the heap.)
I think of following. probably not the best solution. But hey. It
pretty much copies functionalitythat is already there as part of
static objects support.
Each *~ and normal structure now has cleanup method generated. ie ~*
can't be void. when *~ goes out of scope and is not null cleanup of
that type is called. which calls cleanup on ~*/structure members again
etc.
So array of pointers is now just as simple to work with as array of
static objects. Ie.
struct Object2 {
Object3*~ array[1000];
};
struct Object1 {
Object2 array[1000];
};
struct Object {
Object1 array[1000];
};
{
Object*~ array[1000];
} // we left scope so 1000 cleanups are called for each *~;
>I don't see any reason to enshrine a
> particular variant in the compiler. Particularly when C++ already
> supports smart pointers.
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.
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 I think you will run for your life then.
Not everybody agrees that wrapping every single variable to macro like
templates and spreading simple code logic over zilion files is way to
go. But the main problem holding stl back is it's binary and header
incompatibilities.
Now think what would happen if today majority of great open source
libraries like libjpg libpng zlib started using stl.
That's right all hell will break loose.
So no I don't think stl is solution for no small part of c/c++ developers todey.
We all know performance difference of sorting array of objects stored
by pointers
compared to uber slow sorting or reallocations price with containers
storing values.
But many programmers that can't use stl are lazy or under time
pressure would rather store by value
just to not go thru cleanup hell with pointers containing pointers
cleanup hell. We had all seen that.
Not mentioning error handlig leaving half cleaned object trees or
deallocating things multiple times with bad thread code.
How many buffer ovreflows/exploits/security holes there were because
lazy programmer preferred fixed static array instead of dynamic just
so he doesn't need to implement proper manual cleanup for every exit
point his function has.
How many heap overflows for deallocating wrong object or some object
twice because cleanup code were not expecting threads or changed
controlflow by adding new functionality.
All of those problems were already solved with automatic cleanup in
static objects/arrays that are often unusable
for performance/size constrains. Plus we live in world that is dynamic
not static. Ie variable object count's and sizes.
So I think we sould have automatic cleanup for dynamic objects too and
we should not be punished for more efficient array of pointers just
because of manual cleanup statemachine headaches.
On Fri, Oct 5, 2012 at 6:38 PM, Ian Lance Taylor <i...@google.com> wrote:
> On Fri, Oct 5, 2012 at 9:08 AM, _ <neura...@gmail.com> wrote:
>>
>> 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
>
> Experience shows us that programmers want several different types of
> smart pointers in practice. I don't see any reason to enshrine a
> particular variant in the compiler. Particularly when C++ already
> supports smart pointers.
>
> (For example, your variant of smart pointers doesn't seem to help with
> pointers in struct fields, when those structs are stored in the heap.)
>
> Ian
