[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat, Feb 26, 2000 at 06:54:28AM -0800, Burton Radons wrote:
> Grzegorz Adam Hankiewicz wrote:
> > On Fri, 25 Feb 2000, Burton Radons wrote:
> > > Why does this violation of modular segregation exist?
> >
> > Historic reasons. IIRC Shawn stated that if he was meant to write _now_
> > Allegro from scratch, he would have made Allegro more modular. But Allegro
> > is now very big, and I think that the effort to rewrite it wouldn't be
> > soooo terrifying useful to gain a few bytes.
>
> Actually, _midi_constructor just sets two statics and returns. That is
> not a good enough reason or a strong enough tie. The two statics should
> be moved into allegro.c and set directly from there.
That wouldn't help, though, because they're being initialised to
the addresses of some functions from that same file. AFAICS
this system is designed so that the user can override Allegro's
MIDI system, and set these variables before initialising the
sound system. Moving them into `sound.c' would mean that
`midi.c' is only included if `sound.c' is; they'd be initialised
to point at the standard MIDI system if they were still NULL in
the sound initialisation call. Or they could just have regular
initialisers, in their definitions.
> The other constructor is for initialising datafile types. If
> allegro_init can call it directly, then the constructor attribute use
> makes Allegro behave differently on different systems. It should be
> turned to the simple call and the last of those dinosaur constructors
> will be gone.
In this case, various datafile functions could be wrapped with
tests to see whether this function had been called yet. It's
not pleasant though.
> If users insist on playing with datafiles before calling allegro_init,
> the datafile functions can have init calls at their tops. It only costs
> 6 or 7 clocks if it fails and it's the only portable solution here.
I don't think that's the issue here really -- it's not the
constructor-nature of these things which is making the files get
included, it's just the fact that they're being referred to at
all.
George
--
Random project update:
03/02/2000: Libnet 0.10.5 uploaded -- now also supports Mingw32 and MSVC
http://www.canvaslink.com/libnet/