| Re: [AD] Proposal for first step towards new api |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> this makes much sense to me, however in the spirit of prefixing thing i'd
> prefear that internals were prefixed with alint_ rather than _al_. don't
> you think so too?
_getpixel() is not an internal, but the inlined version of getpixel() and
thus part of the API. So I think al_getpixel()/_al_getpixel() is
unavoidable.
As for true internals, I agree with you: they must be easily distinguishable
too. Currently most of them (all ?) are prepended with an underscore, so
_alint_ would perhaps be better than alint_ .
> Also, all defines and variables will need to be prefixed of course. but if
> we just al_ prefix them or do alvar_variablename or aldef_definename or
> something simmilar can be discussed. it's perhaps a good idea if it can
> make generation of export definitions simpler?
Yes, I also think we may have a chance to simplify (and fix) the DLL
compatibility problem. Javier let me know some days ago that MSVC can link
to DLL symbols by name only if the symbols to be exported are declared (or
defined ? it's not very clear) with the __declspec(dllexport) attribute. We
might switch to this mechanism while prefixing the API.
> I'm afraid it's a bit harder than that. END_OF_MAIN() does two things. it
> renames the users main function to mangled_main and then it defines it's
> own OS specific entry point which in turn calls mangled_main. I will see
> what I can do about rewriting the existing hack to use al_main() and
> eliminate the need for END_OF_MAIN().
You're right: the entry point is the problem, especially under Windows. But
we could merge the END_OF_MAIN() macro in a new al_main() uber-macro.
> be careful about removing too much here. think objective: what can be
> useful to have here as a game programmer for instance to code os-specific
> workarounds or to code optimalisations for mmx processors or different
> generations of intel compatibles?
I'm too for keeping the cpu/os detection flags. We could simplify them
again though.
--
Eric Botcazou
ebotcazou@xxxxxxxxxx