This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposing switch -fsmart-pointers

On Sat, Oct 6, 2012 at 11:47 PM, Oleg Endo <> wrote:
> On Sat, 2012-10-06 at 20:59 +0200, _ wrote:
>> 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.
> It seems that your proposed fix to that is as binary incompatible as
> using std::unique_ptr or std::shared_ptr.  What happens when you link a
> library that was compiled with '*~' pointers enabled, with a library
> that was compiled without those pointers, and both exchange
> data/objects?

I have no idea ;D I am just crazy programmer with crazy idea. And on
top of it kinda bad programmer too.
There probably will be problems. Problems that I most probably I will
have no idea how to solve because my experience and skill in c/c++ or
gcc is not anywhere near of yours or anyone in this group. Well..
probably excluding the viagra spammer guy I saw in mailinglist archive
Point of the switch proposal was if there are other crazy enough
people out there wishing to see/play with this switch or willing to
help with this experiment. because it is what it is. Crazy experiment.
And as optional switch it's harmless to rest of gcc.
I have no idea how to even start adding it in gcc as optional switch
so it would probably take me ages when doing it alone.

Now about your binary compatibility question.
*~ pointers that destroy themself when leaving scope are mainly
usefull as structure members or for local computations in members
functions. ie temporary array of pointers that needs to be sorted etc.
For objects that need to be passed around there are standard pointers
like before.
In other words  *~ pointers would probably be of no use in library
interface headers anyway..
And since interfaces should be stable using standard pointers in
interface header of such lib should keep them linkable like before  I

>> 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.
> Have you asked him for his opinion on your proposed solution?

I wouldnt' call it solution. Let's call it experiment.
Actually this morning I attempted just for fun ;D. But I guess it's
pretty much impossible to hear his opinion. Linus has god like status
in my eyes considering what he achieved. But.. Maybe that's a good
thing ;D What if he said that having automatic cleanup also for some
dynamic objects is "dumbest idea he ever heard". Then my little switch
experiment in gcc would be probably doomed. But you are right
I shouldn't had sayed it. Now I am kinda scared if he will find out ;D

>> 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.
> Adding a non-standard compiler extension most likely will not be and
> improvement for those problems.

It's no different to let's say using  -funsigned-char. Code not
expecting it will break too.
So why not try? C++ evolves yet C stays pretty much dormant. Maybe
it's good thing but having optional switch that can reduce bugs and
memory leaks in c as it already does in c++ will probably not hurt.

> But if you really want to try it out, you can do it by writing a custom
> preprocessor that triggers on '*~' and replaces the preceding token with
> std::unique_ptr< token > or std::shared_ptr< token >.

Interesting idea to find potential pitfalls sooner probably. Thx.
So far I had been testing only my stupid Scope idea
Since simulating scope for dynamic objects was all that I was able to
do without adding compiller functionality..
I hate that derive and Scope object. But it' different kind of
problem than implementing pointer *~ in gcc

struct Object : Scope::Obj {

Scope global;
// entering scope
void proc() {
    Scope local;
    char*  text = strdup(local,"text"): // malloc based memory have
automatic cleanup too

    Object* obj = new(global) Object(); // obj will get destructor
called on program exit

    Object* array[1000]={0};            //sorting pointers is fast
compared to array of objects
    for(int i=0;i<1000;i++) {              // on item 500 exception
causes leaving of scope and cleanup
        array[i] = new(local) Object(); // creates object associated
with "local" scope
// we left scope so "Scope local" and all associated object /memory
// gets destructors called/freed in proper order

> Cheers,
> Oleg

crazy unemployed programmer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]