RE: [AD] Header splitting proposal

["Vincent Penquerc'h" <Vincent.Penquerch@xxxxxxxxxx>]

Title: RE: [AD] Header splitting proposal

> same here. but the various include files should have standard
> prefixes or be
> split into subdirectories. example groups: internal, api,
> platform-specific...

Yup. I have non-prefixed names for the user-visible includes
(eg maths.h) and "i"-prefixed names for internal ones, mainly
what was before in alinline.h (eg imaths.h)

> if not the scripts who scans them for DLL exports will be
> ugly. grouping the
> includes will also allow me to clean up the 'install' target in the
> makefiles. currently 'make install' simply installs everything. we can
> discuss the details later but if you're first going to do
> this change, put
> some efforts into doing it good.

Best way would probably be to have a tree looking like:
include/
  -> allegro.h
include/allegro/
  -> the new user-visible split-up headers, like gui.h, maths.h, etc
include/allegro/internal
  -> what previously was in include/allegro/, plus the internal split-up
     headers, like igui.h, imaths.h, etc
Does this sound ok ?

eg:
In place of:
#include <allegro.h>
One would:
#include <allegro/unicode.h>
Which is the reason I actually started the thing :)

> btw vincent. i think your sincos patch will look better if
> you return both
> the sin and cos values through pointers instead of returning
> sin on the
> stack and cos through a pointer. just a small matter of
> taste. and IIRC

That is what is usually done, but I thought the compiler would be
able to optimize better with a returned value, since passing stuff
through pointers usually stops the optimizers in their tracks
(due to aliasing problems). And since this routine was added as
an optimization, those using it probably were concerned about speed.

> newer pentiums has a sincos function built in. perhaps we can
> use this to
> our advantage?

Heh, this just told me why the sincos functions in my libc were
not visible :) They are only available when compiling for pentium
or newer ...
In any case, I'll let someone else do the asm stuff, I don't know
the AT&T syntax at all.

Cheers

--
Vincent Penquerc'h