On Friday 07 April 2006 19:44, [EMAIL PROTECTED] wrote: [...] > > Basically, just don't assume that a pointer is 32 bits, and you're > > but those bytecode interpreters of pd and such just assume, that int > and pointer are the same size...
Yeah, it's tempting to do it that way... I'm not doing any of that in EEL though, and that's using a byte code VM too. It definitely helps to have portability in mind all the way from the design stage, especially with that kind of code. (Inherently messy, in a way...) > well... perhaps it would work ok, if the integer was changed to > int64 also... > > dont ask me. i did not look at the code... Are they using computed gotos or similar, or is this a struct/union problem? Either way, I can't see why it couldn't be fixed, but I can see a few design styles that would require some 32/64 #ifdefs. Could be a bit hairy to track all spots down if the pointer size is implicitly built into the code. (Something I try to avoid in general. You never know when, why or what you might want to change down the road.) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'
