Le mar, avr 10, 2001, à 11:21:00 +0200, Hans Breuer a écrit:
> If you look deeper into it, it's simply a way to avoid as
> much code duplication as possible for "my" export filters,
> without loosing type-safety.
Well, I saw mostly code which was good for renderers ; I didn't pay close
attention to renderer_draw_ellipse_by_arc though.
> With a more modern programming language it would include the
> base class defineing the abstract interface of a renderer.
sure ; objects would probably be much lighter too.
> >Can't renderer_draw_ellipse_by_arc be defined in a better place (and once,
> >by the way) ?
> >
> IMO there are some more renderer functions which should probably be defined
> by some sort of base class (approximating beziers by lines, as done in
> render_gdk.c etc.) and implemented by calling virtual functions. But this
> is just another thing to wait for GObject ...
What about putting all these routines in lib/whatever.c and let the
(dynamic) linker handle the references ? renderer_draw_ellipse_by_arc would
be a good candidate, if lib/whatever.c was something like
lib/renderer_helper.c
> >Basically, this thing gets in my way of loosing all warnings...
> >
> If you could give the exact warning message to get rid I could try to
> improve renderer.inc
Sure:
../renderer.inc:122: warning: enderer_draw_ellipse_by_arc' defined but not
used
(happens in wpg/wpg.c ; build fails in hpgl.c (I think) if this is commented
out).
Normally, gcc/ld should eliminate that code if it's really "defined but not
used" (as it's static), but I wouldn't trust its cleverness...
-- Cyrille
--
Grumpf.
