Re: Re:

[Krzesimir Nowak <qdlacz gmail com>]

2011/1/28 Culpian Camilo Martin <camiloculpian gmail com>:
> El vie, 28-01-2011 a las 15:11 +0100, Krzesimir Nowak escribió:
>> 2011/1/28 Culpian Camilo Martin <camiloculpian gmail com>:
>> > El vie, 28-01-2011 a las 14:46 +0100, Krzesimir Nowak escribió:
>> >> 2011/1/28 Culpian Camilo Martin <camiloculpian gmail com>:
>> >> > ok, i'll try it, i have had some troubles doing this:
>> >> >
>> >> > class foo
>> >> > {
>> >> >        static ref_ptr<foo> create
>> >> >        (
>> >> >                return ref_ptr<foo>(new foo());
>> >> >        );
>> >> >        foo();
>> >> >        ~foo();
>> >> >        ref_ptr<foo> set_something()
>> >> >        {
>> >> >                //set something
>> >> >
>> >> >                return ref_ptr<foo>(this);
>> >> >                //for using foo->set_something()->set_something();
>> >> >                // oviously the ref_ptr delete "this", and cause a segfault
>> >> >                // any idea how can avoid this?
>> >> >        }
>> >> > }
>> >>
>> >> Would be good to show what is this ref_ptr class...
>> >>
>> >> If the below code segfaults then maybe copy constructor of ref_ptr
>> >> does not increment reference count.
>> >>
>> >> ref_ptr<foo> f = foo::create();
>> >> f->set_something()->set_something();
>> >
>> > the problem is not when i do this:
>> >
>> > ref_ptr<foo> f = foo::create();
>> > f->set_something()->set_something();
>> >
>> > the problem is when i do this:
>> >
>> > class foo_b : public foo
>> > {
>> >        static ref_ptr<foo_b> create()
>> >        {
>> >                return ref_ptr<foo_b>(new foo_b());
>> >        }
>> >        foo_b();
>> >        ~foo_b();
>> > }
>> >
>> > when i do:
>> >
>> > foo_b foob = foo_b::create();
>> > foob->set_something(); //here ref_ptr delete the object member class
>> > foo... this is what i can't do right.
>>
>> Now I see. An option would be:
>> 1. returning void instead of ref_ptr to this.
>> 2. coding the reference count inside foo_b, instead of in ref_ptr.
>>
>> I would opt for first solution.
> yes, but if i extend from Glib::Object, and i use Glib::RefPtr, wouldn't
> be a better and elegant solution? or it is not possible?
>

And just for sake of some fancy reference counting and methods
returning a smartpointer to 'this' you would bring Glib + whole GType
system and C++ bindings on top of it? I'd say it is not worth it. Why
I opt for first solution? Just a principle of designing methods and
classes to do clearly defined and separated actions and nothing more.
Let set_something () just set that 'something' and that's all. Let
create() return a smartpointer to object. There's no need to burden
methods with more than one task.

If you really want to bring it all then you method would look like this:

Glib::RefPtr<Foo> set_something()
{
  // set something
  Glib::RefPtr<Foo> reffed_this (this);
  reffed_this->reference ();
  return reffed_this;
}

'Peak of utmost elegance', I'd say - invoking reference() manually
defeats Glib::RefPtr purpose of relieving programmer from
memory/reference count management of GObjects.