Yeah, that's close to how I'd do it, when writing for performance
(otherwise, embind might be more concise).

You can replace the EM_ASM_INT with a direct call to malloc, though.

And instead of getValue, accessing the typed array directly is much faster
(Module.HEAP32[buffer + i*nByte >> 2], note that you need to do the >>2
yourself manually).

On Wed, Oct 26, 2016 at 11:35 AM, Philipp Gloor <[email protected]>
wrote:

> I see.
> If you have a function that on the C++ side returns a double array, what
> would be your preferred way to make this accessible in JS? I don't know the
> length of the array beforehand.
>
> I played around with EM_ASM_INT.
>
>     JSHelper fillRandomArray()
>     {
>         int len = rand()%10 + 10;
>         int pointer = EM_ASM_INT({
>             var buffer = Module._malloc($0 * 4);
>             return buffer;
>         }, len);
>         int* a = (int*)pointer;
>         for (int i = 0; i < len-1; i++)
>         {
>             a[i] = i*3;
>         }
>         JSHelper js;
>         js.pointer = pointer;
>         js.length
>         return js;
>     }
>
> and in my .js file
>
>         var nByte = 4;
>         var charByte = 1;
>         var jsInfo = Module.fillRandomArray();
>         var buffer = jsInfo.pointer;
>         for (var i = 0; i < jsInfo.length; i++)
>         {
>             console.log(Module.getValue(buffer + i*nByte, 'i32'));
>         }
>
> This works but this seems a bit too complicated for something (seemingly)
> simple. I've also tried a version where I return just a std::vector which
> works just fine but our C++ code base tries to avoid using STL for some
> reasons. Is this a reasonable solution?
>
>
> On Wednesday, 26 October 2016 19:37:06 UTC+2, Alon Zakai wrote:
>>
>> It depends what you mean. A pointer in emscripten (in general) is just an
>> integer. So it's fine to pass pointers into and out of compiled code,
>> including WebIDL glue. The WebIDL glue does add functionality on top, by
>> converting a return value of a wrapped class into a JS object wrapper. It
>> also handles an input parameter that is a JS object wrapper, converting it
>> into the integer for the compiled method underneath (it's also fine to just
>> pass that integer as a parameter).
>>
>> On Tue, Oct 25, 2016 at 10:32 PM, Philipp Gloor <[email protected]>
>> wrote:
>>
>>> ​OK thanks. And did I understand correctly that pointers only work for
>>> non-primitive data types?​
>>>
>>> On 26 October 2016 at 00:11, Alon Zakai <[email protected]> wrote:
>>>
>>>> Yes, WebIDL focuses on simple types that map directly to JS (numbers,
>>>> pointers, etc). embind has more functionality for sophisticated mappings of
>>>> C++ classes, like std::vector.
>>>>
>>>> On Tue, Oct 25, 2016 at 2:39 PM, Philipp Gloor <[email protected]>
>>>> wrote:
>>>>
>>>>> I have a C++ function that should return a vector of doubles but on
>>>>> the WebIDL doc page
>>>>> <https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/WebIDL-Binder.html>
>>>>>  I
>>>>> found nothing that could help me.
>>>>>
>>>>> The header file:
>>>>>
>>>>> #ifndef __JSAPI_H__
>>>>> #define __JSAPI_H__
>>>>>
>>>>> #include <string>
>>>>> #include "annotation.h"
>>>>>
>>>>> class JSAPI
>>>>> {
>>>>>     Annotation* annotations;
>>>>> public:
>>>>>     char* getAnnotContent(int annotID);
>>>>>     std::vector<double> getAnnotRect(int annotID);
>>>>>
>>>>> };
>>>>>
>>>>> #endif
>>>>>
>>>>> And the implementation
>>>>>
>>>>> #include "jsapi.h"
>>>>>
>>>>>
>>>>> char* JSAPI::getAnnotContent(int annotID)
>>>>> {
>>>>>     return annotations[annotID].content;
>>>>> }
>>>>>
>>>>> std::vector<double> JSAPI::getAnnotRect(int annotID)
>>>>> {
>>>>>     return annotations[annotID].rect;
>>>>> }
>>>>>
>>>>> And I'm looking for the proper definition of
>>>>>
>>>>> interface JSAPI
>>>>> {
>>>>>     void JSAPI();
>>>>>     DOMString getAnnotContent(long annotID);
>>>>>     std::vector<double> getAnnotRect(long annotID);
>>>>> };
>>>>>
>>>>> Is something like this even possible? Or do I need to switch to embind
>>>>> for this?
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "emscripten-discuss" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "emscripten-discuss" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>> pic/emscripten-discuss/18GjJeGOq08/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to