Quote from LeeD:
I understand you solved the problem. So, it's not a pressing issue.
In case it helps... I'm sure you know that in Visual Studio 2005 and higher a C++ project has compilation options on the per-file basis. Each file can be compiled as C++, C++/CLI, or C. Then the linker makes sure all of these 3 types work together. Have you tried if the libgretl compiles as C?
I will give your idea a try. Half of the problem is getting the code to compile, but there is a second big hurdle. When Gretl was a console app, it looks like the core calculation code was in libgretl. when they went GUI, the separate was lost. When I look at the data structures, they have a mixture of core data, current model structure, and GUI state.
I was following the strategy of starting with a couple of source code files which had good stuff in them. Change them to get them to compile (things like void * casting, function pointer casting, namespaces, ....) Then look to see what was missing in the linkage. Add in a couple of files with missing function calls. Comment out stuff that, hopefully, isn't needed. And repeat.
If it were just a contained function like a numerical method, I am sure I could pull it all together, but thing needs its complex modeling structure. For example, if on an earlier run, you find that a certain variable has a very small weight in some factor, then you can setup by configuration to optimize the system with that factor constrained to be zero. Ok, cool, but sometimes that coefficient happens to fall to be the thing by which you are renormalizing the vector. Thus more logic to look for a better choice.
Then with GUI stuff getting pulled in, it was just too much for a side project on a resume/demo site.
Thank you for the suggestion though. I will try it if I give it another crack. Being able to compute cointegration all in C++ without OLE transitioning would make such a huge performance difference.
Another day, thanks though.
