IRC Log Viewer » #firebreath » 2013-06-20

IRC Nick Time (GMT-7) Message
Guest87233 04:06 hello guys
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 06:06 Hi
diorcety1 08:06 taxilian: hi !
taxilian 08:06 good morning
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
taxilian 08:06 which platform
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?
diorcety1 09:06
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 , conversion going out is
diorcety1 09:06 at the end, a try/catch must be present somewhere ..
tonikitoo| 09:06 awesome!
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
diorcety1 09:06 ^^
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?
tonikitoo| 09:06 chromium
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)
err, efficiently*
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
and it throws an exception to javascript
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
diorcety1 09:06 ok
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