Subj : Re: Performance Interfacing to C++
To   : netscape.public.mozilla.jseng
From : Thorsten R
Date : Fri Aug 27 2004 01:41 pm

Brendan,

first of all thank you for your time and efforts in caring for my question.

> Perhaps you could say more about your embedding and why you don't need
> the usual property lookup and value storage mechanism?

We have already existing C++ classes, which represent objects in a document,
e.g. class Frame, class Text, class Circle, etc.

We want to automate our application by JS, so the C++ objects are "exported"
to the JS runtime. This way the user could for example write in a script
(assuming the object "Box" is a C++ object of type "class Frame"):

Box.Left = 100;

which will set the left coordinate of the object in the document to 100.

Internally this will end up in a call to our function jsSetFrameProperty():

JSBool jsSetFrameProperty(JSContext *cx, JSObject *obj, jsval id, jsval *vp)
{
  if (JSVAL_IS_INT(id))
  {
    Frame *p = (Frame *) JS_GetPrivate(cx, obj);

    if (p)
   {
      int ival = JSVAL_TO_INT(*vp);

   switch (JSVAL_TO_INT(id))
   {
   case jsFrame_Prop_Left:
    p->Left = ival;
    break;
....
   }
  }
 }

    return JS_TRUE;
}

In the same way we have a function jsGetFrameProperty(), so we defined all
the getters and setters ourself to jump into the C-code. According to my
last mail the basic question is, if the JS engine also keeps the values of
these properties, i.e. it has it's own property "nLeft" and stores the value
internally within the runtime. I'm not sure if you understand me right. I
mean that the nLeft property is stored within our C++ class and a second
time within the JS runtime. This wouldn't make sense to me, because we
instructed the engine that our code cares for getting and setting (and
therefore storing and managing) the value of the property "nLeft".
Especially for properties with long strings this would be a waste of memory
and performance.

Maybe this makes my question a bit more clear.

Thorsten

.