>
> On 16.04.2010, at 22:19, [email protected] wrote:
>
> > Author: manolo
> > Date: 2010-04-16 13:19:09 -0700 (Fri, 16 Apr 2010)
> > New Revision: 7520
> > Log:
> > Improved the hierarchy of Fl_Device subclasses to allow separation of =
> platform-specific devices.
> > This introduces multiple inheritance.
>
> Oh no. I was too late answering to the original question. I am no fan
> at all of multiple inheritance. It regularly leads to chaos thanks to
> unexpected name resolution and internal pointer offsets when
> unexpectedly casting. My that's ust my opinion.
>
> Unfortunately the last commit was so huge that I did not see how and
> why the multiple inheritance was introduced. Manolo, could you please
> explain what you changed and why?
>
> Thanks,
>
> - Matthias=
OK. I certainly don't want to bring chaos. If it's bad, we can go
backwards.
The why is briefly explained in my other post "New hierarchy of
Fl_Device subclasses".
The new hierarchy is :
Fl_Device (all present and future devices)
Fl_Graphics_Device (Quartz, GDI, or Xlib depending on the platform)
Fl_Display_Device (above graphics system applied to display)
Fl_Printer (above graphics system applied to printing)
(Fl_Clipboard_Device -- would come here if it's adopted)
Fl_PS_Device (PostScript backend)
Fl_PSfile_Device (PostScript used in printing)
Fl_Abstract_Printer (a page-structured device)
Fl_Printer (a page-structured printing device)
Fl_PSfile_Device (a page-structured output sent to a local file)
Thus, two classes have double inheritance.
Fl_Printer inherits its drawing capabilities from Fl_Graphics_Device,
and its page structuration from Fl_Abstract_Printer.
Similar thing for Fl_PSfile_Device.
Under Xlib, the hierarchy is a little changed: Fl_Printer is a subclass
of Fl_PSfile_Device (it's exactly the same platform difference
as in the previous device hierarchy). So, there is a single instance
of double inheritance, for class Fl_PSfile_Device.
This is the only solution I found so that the same
Fl_Device::xxx() Quartz (or GDI) drawing function can be used both
by printing and by display-drawing classes.
Being on not page-structured is independant from using the
PostScript, Quartz, or GDI graphics backend. So, I see multiple
inheritance as very natural and pertinent here.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
