On Mar 12, 4:13 am, Alex Iskander <[email protected]> wrote:
> Yes, right
> here:http://bazaar.launchpad.net/%7Ealex.iskander/create/trunk/files/head%...
> It has projects to compile on both Windows (using VC++ Express) and
> Mac (using XCode).
i only do *nix OSes :)
<background history snipped>
> All of that is really pretty simple.
Wow, finally someone who can write as long a post as i can! :-D
> The most complicated part is the part dealing with C++ native types. I
> wanted the wrapping to be completely transparent, so that, for any
> type, you could still just call $(myObject) and wrap it. To do this, I
> have a few things:
>
...
> 2. A type tree, used to determine the most derived type known for any
> object. This allows passing a base class pointer to JavaScript and
> getting in JavaScript the derived object.
Doh, good point. i need to look into that for my own wrappers as well.
> Now what? Say you have a D2DDerived (a class derived from D2Derived).
> Let us assume it is named d2dd. If you call myNative = $(d2dd), the
> engine will attempt to find an appropriate SNative wrapper (note that
> these wrappers do not handle function calls, properties, etc.; they
> are just containers).
Okay, that's weird. i'll have to take a closer look to grok that.
> To find this object, the system would first check its cached map
> (which I have, unfortunately, not coded yet), and if it cannot find
> the object type (currently always the case), it
> loops through each C++ sub-type, checking via dynamic_cast if the
> object is of that type.
Last night i managed to get member function wrapping working without
requiring an intermediary call forwarder object (that is, the call
mapping/forwarding needs no dynamic memory - only stack). As part of
that i work i had to implement just such a cache, which ended up with
this trivial implementation:
/**
An internal helper type for only use by
WeakJSClassCreator.
Actual must be WeakJSClassCreator::WrappedType.
*/
template <typename Actual>
struct WrapperTypeChecker
{
typedef Actual WrappedType;
typedef std::pair<WrappedType *,Persistent<Object> >
ObjBindT;
typedef std::map<void const *,ObjBindT > OneOfUsT;
static OneOfUsT & Map()
{
static OneOfUsT bob;
return bob;
}
};
Source:
http://code.google.com/p/v8-juice/source/browse/trunk/src/include/v8/juice/WeakJSClassCreator.h
> If it is, it then recursively checks all sub-
> types of that type, and so on, until it finds the most derived type.
As Vader once said, "Most Impressive" (it sounds nicer when he says
it, though). That's way beyond my ambitions.
> Finally, let me provide you with a sample of wrapping an object (an
> ostream, constructable):
> ScriptBaseNative(std::ostream);
>
> SWrap(ostreamWrapper, std::ostream)
> {
<snip>
> };
That's actually quite elegant. :) It's clear while reading it what
it's for and much of the noise is filtered out.
> //register type
> context->registerType<std::ostream>(new ostreamWrapper());
This is especially interesting. Hmmmm. i'll need to think about
whether i can steal that idea for other uses.
> And that's about it. It's overly complicated, and still a work in
> progress, but it works and fulfills my needs splendidly.
My related work is documented here:
http://code.google.com/p/v8-juice/wiki/CreatingJSClasses
it's not as ambitious as yours (e.g. no tricky parent type lookups
aside from what JS does internally), but (as you say) "fulfills my
[v8] needs splendidly."
> /* This native is declared a-special so that we can add automatic
> destruction
> in a way that is transparent to derived objects.
i implemented that by requiring that the user specialize a certain
traits-like template type for his Type, and he provides the ctor/dtor
implementations in that specialization.
> SCRIPT_NATIVE<Bind::Mem> class. This is a big benefit as I have a very
> large number of classes, all inheriting from each other and ultimately
> from Mem, that I may want to wrap with minimal difficulty.
"Minimal difficulty" is, i guess, quite relative, given the difficulty
of implementing what you've done so far!
> Smart pointers were a complete necessity as a native object could be
> referenced from C++, JavaScript, or both simultaneously, and would
> need to stay in memory until neither referred to them anymore.
There are other ways around this, too, but i get to leave work in 7
minutes and don't wanna get started on another long post in that
time :).
> Hope I haven't overwhelmed you with meaningless technical details,
By no means, i'm thrilled to see that i'm not the only one here who
writes long posts :)
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
