Daniel wrote:
>
> Are you certain the 'this' pointer is not available?
Yes.
>
> example:
>
> class frame : public widget {
> public:
> frame( ... ) : widget( ... ) {};
> }; // end frame
>
> class control : public widget {
> public:
> control( widget* p, ... ) : widget( ... ) { ...; p->add( this ); };
> }; // end widget
>
> class aframe : public frame {
> public:
> aframe( ... ) : frame( ... ) {
> new control( this, ... );
> new control( this, ... );
> };
> }; // end aframe
>
>
> In the constructor for 'aframe' isn't the 'this' pointer valid for use?
Yes, it is valid.
But, in your own example, the 'this' pointer in control is still
undefined when called from aframe (or only partially defined for
control, not for aframe), so your p->add() may or may not work as you want.
Any sort of dynamic casting to aframe on it will fail, for example,
until the constructor of aframe is done.
FLTK's design allows it to also avoid dynamic casting, which is a minor
benefit.
Note also that matthias' example did not use pointers at all, but
instantiated the elements of a composite widget within the class itself,
making the class "fatter" if initialized on the stack but the code much
cleaner inside the class (no pointer math) and a tad smaller when used
with new.
If you want to see why FLTK's approach is better, I suggest you take a
look at Fox. Fox uses the method you like. The price you pay for that
is more verbosity and, in the case of Fox, creation and destruction of
composite widgets also has to be done explicitly due to the this pointer
issue.
Threading issues are indeed a concern, but since, afaik, all OS gui
toolkits are not really thread safe, fltk's approach is currently not
creating any additional issues.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
