On Wed, Sep 23, 2009 at 3:24 AM, Phil Dawes <[email protected]> wrote:
> Clashes with the T that is factor's 'true' (gcc barfs).

Ok.

> Because you can't pass member functions as pointers. (Or maybe I'm
> missing a trick here?)

In a few places I started converting such 'higher order functions' to
use templates instead. This generates faster code and avoids type
issues such as this.

> This was to help with debugging memory issues - I could switch from
> struct vars to global vars with a macro switch, which was handy for the
> period when master win32 wouldn't build and I wasn't sure if struct was
> causing problems or not. It should go now as win32 is working.

Ok, it should be removed then.

> Ok, do you have any issue with using regparm(3) for all VM_ASM_API
> operations? Is there a performance implication that I don't know about?

No.

> I'm not 100% sure the best way to remove them from the vm struct since
> the platform #includes need to go before the vm.hpp so there would be
> dependency issues with using inheritance. Will have a think about this.

What if platform-specific methods were split off into a separate class?

I'm not a fan of inlineimpls.hpp either...

Slava

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to