Tomasz, I'm not suspecting everyone around me. I am constructively trying to generate hypotheses and check them out. The facts are: output from the DLL is stable and accurate but output from AmiBroker is not, which indicates some kind of interaction from the DLL into AmiBroker. I can only think of two general kinds of ways this could happen,
1) Heap corruption
2) Configuration incompatibility
I'm open to others possibilities. To check heap corruption I removed all heap operations from the DLL. Since the problem persists, and I can't imagine AmiBroker is mismanaging its heap, I'm wondering about configuration issues partly because while researching the problem I ran across this in MSDN,
where it warns about a configuration incompatibility that could cause heap corruption in the application. I think I'm very reasonably asking whether I might inadvertently be impacting AmiBroker in this or similar sort of way.
FWIW, I have a neighbor who is a .NET developer. He's looked at the code and his advice was I should contact the application developer.
---In amibroker@yahoogroups.com, <nickhere@...> wrote :
Could the issue be running afl in multitasking mode.
I always had doubt with that returns
Nick
On 4/6/2016 5:36 AM, Tomasz Janeczko groups@... [amibroker] wrote:
I always had doubt with that returns
Nick
On 4/6/2016 5:36 AM, Tomasz Janeczko groups@... [amibroker] wrote:
Hello,
Thank you very much for your e-mail.
You are suspecting everyone around you (the compiler, #pragmas, AmiBroker), yet dozens of people created their DLLs
and they working fine and they all did that without any single problem. Isn't that interesting?
If you can't find errors in your code, hire some *experienced* programmer (locally so he can , not remote over internet) to find errors for you.
Best regards,
Tomasz Janeczko
amibroker.com
Hi Tomasz,I just made the code change and configured VS to use "precise" for float instead of "fast". These changes made no difference. The plugin function is just doing divide-by-zero protection and there is no other plugin code exposed to AmiBroker. The code changes I made were to immediately copy all float * values returned by AmiBroker functions to a class with an embedded compile-time array, and do all processing on that class before copying values back to AmiBroker. Other than copy-to and copy-from operations, the code never touches an AB float *. It is the only plugin code exposed to AmiBroker at all and a small enough code segment to easily watch.It's weird the plugin is returning correct results but AmiBroker becomes flakey. What's more mysterious, the plugin passes unit tests -- it returns stable, correct results when called on its own, even in a loop. It is AmiBroker AFL which starts giving unstable results when I pass results around during more intense processing. Are you sure there can't be a compiler or pragma-type issue I need to address? It's so bizarre, if it's not a pointer issue, it makes me think something basic is incompatible between AmiBroker and the DLL.BTW, I'm using the sample.dll files and haven't touched plugin.h, plugin.cpp, sample.h or sample.cpp. I have noticed VS is giving a bunch of "function definition not found" messages on a group of PLUGINAPI prototypes in the plugin.h file. I assume this is normal?Just as an FYI, the code for my exposed function is below. There's a preceding two-argument function which just catches the call from AmiBroker and passes the arguments from the ArgsTable along to this function. It's just a safe division routine, which gives the user an option to specify the value to substitute for zero and a value to use if both numerator and denominator are zero. It's not rocket science. In fact, it's so simple I can do the whole thing as a series of constructor calls.The first two float * arguments to it come from the ArgsTable passed by AmiBroker and are immediately copied to the class I mentioned, which wraps an embedded array. Similarly with the float * returned by calls to AlmostEqual and IIF. After it returns result, the receiving class copies its contents to an AmiVar and sends it off to AB. Those are all the operations with pointers being done.ABArray SafeDiv(float *num, float *denom, float safeDenom, float numZero) {//// Exchange zeros for small number before dividing//ABArraynumm(num),denomm(denom),nZero(ab_AlmostEqual(numm,0.0f)),dZero(ab_AlmostEqual(denomm,0.0f)),dblZero(ab_And(nZero,dZero)),safeD(ab_IIF(dZero,safeDenom, denomm)),result(ab_IIF(dblZero,numZero, ab_Divide(numm, safeD)));returnresult;} // End SafeDiv
__._,_.___
Posted by: rosenberggregg@yahoo.com
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (12) |
Have you tried the highest rated email app?
With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email app on the market. What are you waiting for? The Yahoo Mail app is fast, beautiful and intuitive. Try it today!
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
.
__,_._,___
EmoticonEmoticon