Hey Asif,
> > > On Mon, Aug 22, 2011 at 1:36 PM, asif saeed
> > > > I read the following tutorial yesterday - it creates class
> > > members on stack
> > > > - that is, it does not make them pointers and allocate them
> > > using new():
> > > >
> > > > http://www.fltk.org/doc-2.0/html/example3.html
> > > >
> > > > I have also gone through examples that create members on
> > > heap - that is,
> > > > the members are pointers - not values/objects. I have read
> > > in docs that
> > > > Fl_Group automatically deletes the children, that you add,
> > > upon exit. What
> > > > is the difference between creating members on stack and on
> > > heap? Don't you
> > > > think creating them on stack will automatically release
> > > them that could
> > > > cause Fl_Group to release non-existing memory?
> >
> >
> > Why do you think that would happen?
> >
>
> The docs say that the groups automatically add whatever children get created
> after them - they automatically issue a begin or something like that -
> apparently each widget adds itself to the group in its constructor. I read
> that while reading about creating members on heap using new(). I also read
> that the groups automatically delete the children. Now if you create
> children on stack then they will first be released via stack pop and then
> the group will delete them - and here the group will delete something that
> will have already been deallocated through stack unwinding.
>
So, two things:
1) You've posted a link to fltk2.0 documentation -- and judging by some of your
comments in a few threads, seem to be referencing 2.0 classes -- but are
talking about Fl_Group and the 1.3 counterparts. These are not the same, so
please don't confuse yourself here. What 1.3 does and what 2.0 does are two
different things (unfortunately, at least until we all get fltk3 off the
ground).
In any case, their Group's behave similarly, so I'll answer your question from
a common, C++ standpoint.
A variable that is just "generally" declared (i.e. not declared static / auto /
<insert a few keywords here>) is defined as "automatically" allocated. A
variable that has had operator new used is defined as "dynamically" allocated.
If you need proof that the current system works -- and will always work -- it
follows as such:
The really cool thing about C++ is that you can't call operator delete on any
variable that's not dynamically allocated. In the case of items that you add as
a child of the group that is automatically allocated, you can't actually delete
this object. It just won't work; programs will segfault wildly and the world
will explode. "delete"-ing an object calls the deallocation function (i.e. the
class' operator delete). If this doesn't exist (which it doesn't, for FLTK
classes), it calls the global operator delete. This global operator _will not_
operate on objects and will *only* operate on pointers -- any attempt to
operate on an object will throw a compile error. As above, non-dynamically
allocated memory will segfault *every single time* on most OS's.
You also don't have your deallocation ordering strictly correct. The stack
unwind will always be the last-constructed order - so if you declare a Fl_Group
above a Fl_Widget, the Fl_Widget will be destructed *before* the Fl_Group.
Hopefully this answers your question. The group will never delete anything that
has been deallocated via the stack, and vice versa. How this is done is more up
to the implementation, but this double-deletion can't *ever* occur in a
well-formed program!
Ben
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
