|IRC Nick||Time (GMT-7)||Message|
I have the problem related to function pointer in firebreath
May i ask the problem related to function pointer in firbreath here?
I have created the function pointer in C++CLI wrapper as typedef str::sting(*GetCallBack callback)(std::string message) in my Wrapper.h file then in the Wrapper.cpp file,I have one method as AddEvent(GetCallBack callback)
This builds successfully.
Now I implemented the void AlgebraAPI::NameChangeEvent() in my AlgebraAPI.cpp which includes the implementation as
AddEvent(&AlgebraAPI::AddFuctionPointer) where std::string AlgebraAPI::AddFuctionPointer(std::string message) is the method implemented above NameChangeEvent()
whose return type and arguments are same as that of function pointer
but still it throws the error C2664: 'UnmanagedNameEvent::AddEvent' : cannot convert parameter 1 from 'std::string (__thiscall AlgebraAPI::* )(std::string)' to 'GetCallback' where UnmanagedNameEvent is my C++ class.
Could you please help me for this error if you have any idea?
I am trying to solve this error from three days but still not succeeded to solve it.Please suggest an idea for solution
|diorcety1||08:06||taxilian: hi !|
|diorcety1||08:06||good afternoon from here
i fall on a strange crash
|taxilian||08:06||looks like it's crashing while trying to convert a string
is your string valid utf8?
or did you try to shove some weird binary stuff in it?
|diorcety1||08:06||don't know … i have a minidump file|
|diorcety1||08:06||internet explorer 9 on Windows 7|
|taxilian||09:06||you may be able to load the dmp in vsiual studio and see|
|diorcety1||09:06||yes yes :)
but i haven't the arguments of functions :s
|taxilian||09:06||? if you loaded the dmp file you should be able to see everything in the stack?|
but some arguments are incomplet
at first maybe we have to catch somewhere the exception
|taxilian||09:06||if it's at all consistent, that's definitely where I'd start
you can set it to throw a breakpoint on exceptions
|diorcety1||09:06||i talk about delayedInvoke … maybe we have to add a catch
because it's not normal that a utf8 to utf16 conversion crash the plugin
|tonikitoo|||09:06||hi there. when passing a big string from JS to FB, where does the conversion to a std::string take place within FB?
I am basically trying to figure out if my bottle neck is currently the IPC (I am on chromium) or the conversion..
|taxilian||09:06||tonikitoo|: it depends on the browser
for NPAPI: conversion coming into the plugin from JS is https://github.com/firebreath/FireBreath/blob/master/src/NpapiCore/NpapiBrowserHost.cpp#L233 , conversion going out is https://github.com/firebreath/FireBreath/blob/master/src/NpapiCore/NPVariantUtil.h
|diorcety1||09:06||at the end, a try/catch must be present somewhere ..|
taxilian, can I assume that this piece of code takes care of both string and wstring?
|taxilian||09:06||coming in it comes as a string
and is converted to a wstring
on activex it comes in as a wstring and is converted to a string
|tonikitoo|||09:06||taxilian, so if I pass in my big string, and it takes time for this function only to get called, can I assume that it is the IPC my bottleneck?|
|taxilian||09:06||what browser are you on?|
|taxilian||09:06||probably ipc is the biggest
also we copy the string into a std::string so that you don't have to deal with npapi memory management
but a string copy — even a big one — is not likely your biggest bottleneck
|tonikitoo|||09:06||I tend to agree, taxilian. Have you guys adviced anyone about how to effectively pass big data using FB (I understand FB is not the problem here)
|taxilian||09:06||yeah; pass it as a string
there just isn't a good way to pass big data
|diorcety1||09:06||taxilian: maybe put a "null object" in variant list if the conversion fails?|
|taxilian||09:06||diorcety1: in which case are you referring?|
|diorcety1||09:06||taxilian: anycase .. if the conversion fails .. what we have to do? crashing is not the best way to handle that :D
remplace the caracter by ?
replace the character by ?
|taxilian||09:06||well, in most cases there is a try .. catch
except if you're doing a convert_cast yourself
|diorcety1||09:06||not it this case
because it comes from native side
|taxilian||09:06||so basically I wasn't aware that it was possible to pass in a value that would crash this|
|taxilian||09:06||it's probably not a bad idea to add a try .. catch
because you're right — crashing is never acceptable
|diorcety1||09:06||so we have to catch exception when calling asyncall no?|
|taxilian||09:06||async calls should be wrapped in a try / catch, I believe
but I haven't ever seen it throw an exception that wasn't from user code
|tonikitoo|||09:06||taxilian, my big data is a string already
about 4million length long, in the worst case