The reason is that I want to identify what property GetPrototype() returns, and to help me make the instanceof work on objects that were not directly created by the given function. In the native bindings I implement I can return an object created in C++ without going through the js constructor callback, but I still need these objects to be identified as created by the ctor function, to identify their type.
Is there a way to get to the real object pointer, so that I can uniquely print an unique identifier of an object contained in a handle. Is it possible to do this? On Mar 14, 2:54 pm, Vyacheslav Egorov <[email protected]> wrote: > operator* defined on a v8::Handle<T> does not return a pointer to an > object but rather a pointer to place which contains that pointer. > > Why do you actually want to get a raw pointer to an object? > > -- > Vyacheslav Egorov > > > > > > > > On Wed, Mar 14, 2012 at 1:44 PM, avasilev <[email protected]> wrote: > > Seems this approach will lead to nowhere - two absolutely identical, > > consequent C++ calls which query the same property, return different, > > consequent pointers. Seems in C++ there is also some internal > > shadowing and pointers (at least not *Handle<Object>) don't uniquely > > identify objects. > > > On Mar 14, 2:29 pm, avasilev <[email protected]> wrote: > >> I,m trying to write a C++ app to test these values, I print C++ > >> pointers and implement a js function, taking an object, and print this > >> object's pointer, so that I have a picture both what Js and C++. > >> However, I discovered a strange thing - the function's arguments, > >> transformer like this: *(args[0]->ToObject()) always appear as the > >> same pointer between function calls. If I try to print two object > >> arguments in the same call, these are consecutive addresses. So it > >> seems v8 passes different objects than the actual ones, somehow > >> shadowing the real object. The addresses are quite different than > >> these that I get in C++, which leads me tho thing they are allocated > >> on the stack. This all makes sense, but how is the shadowing mechanism > >> implemented, and is there a way to reach the original objects from > >> within the function? > > >> On Mar 13, 4:06 pm, Matthias Ernst <[email protected]> wrote: > > >> > On Tue, Mar 13, 2012 at 3:00 PM, avasilev <[email protected]> wrote: > >> > > Thanks, > >> > > I was just thinking that as there is GetPrototype() and SetPrototype() > >> > > for objects, which access '__proto__', there should be also for > >> > > 'prototype'. > > >> > Well, GetPrototype() has slightly different semantics, at least > >> > judging from the documentation WRT hidden prototypes. > > >> > > I'd like to use the topic to ask - what does GetPrototype() actually > >> > > return on a function object then? Is it func.prototype.__proto__? > > >> > I'd expect func.__proto__. > >> > In the Chrome console this evaluates as such: > > >> > (function() {}).__proto__ > >> > function Empty() {} > > >> > Matthias > > >> > > On Mar 13, 3:50 pm, Matthias Ernst <[email protected]> wrote: > >> > >> On Tue, Mar 13, 2012 at 2:26 PM, avasilev <[email protected]> > >> > >> wrote: > >> > >> > Hello, > >> > >> > Is there a way to get a function's prototype, equivalent to the > >> > >> > function's 'prototype' property, e.g.: > > >> > >> > function Func() > >> > >> > {} > >> > >> > var a = Func.prototype; > > >> > >> > Using Object::GetPrototype() does not do the same and returns a > >> > >> > different value. Setting an object's prototype via SetPrototype() to > >> > >> > the property value gives the desired effect of instanceof > >> > >> > recognizing > >> > >> > the object as constructed by the function. Setting the prototype to > >> > >> > the function's GetPrototype() does not achieve this. > >> > >> > From the doc I don't see a way to access the "prototype" property > >> > >> > of a > >> > >> > function, besides getting it as an ordinary property via func- > >> > >> >>Get(String::New("prototype")); > >> > >> > Am I missing something? > > >> > >> I don't think you are. Why should there be another way, apart from > >> > >> convenience? If JS specifies it as a property, especially not even a > >> > >> special one, then use the property accessor. You may of course argue > >> > >> that it's inconsistent with, say, Array::Length. > > >> > >> > Greetings > >> > >> > Alex > > >> > >> > -- > >> > >> > v8-users mailing list > >> > >> > [email protected] > >> > >> >http://groups.google.com/group/v8-users > > >> > > -- > >> > > v8-users mailing list > >> > > [email protected] > >> > >http://groups.google.com/group/v8-users > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
