Greetings, I've had a look at the header and saw that the WRun function was declared as extern, not as extern (C). This means (if I am not mistaken) that only compilers that use the same name-mangling method will find that function in the resulting .so (or .dll) file. This again means, that it would be the best, if everyone builds her own version of the library and ship it along with any Wt-based application that one might has. Or link statically of course.
Why am I mentioning this? I was curious how exactly the communication between host-app and library works, because I plan to write a D (from digital mars, also included to make finding this post in the search easier) binding for Wt. D can use c-libraries, I was hoping you would use some kind of c-based middle layer to keep your binaries compatible to different compilers and different version of the same compiler (there are ways to do that and still keep using classes). Now, do you have any valuable information for me how I could write that binding? Would I need to write a c-based middle layer to link it with D compilers? I've read through the mailing list archive, and at some point someone mentions that using c++ as an API is.. well read for your self, I quote from http://article.gmane.org/gmane.comp.web.witty.general/2447/match=bindings "It is a common misconception that a C api is easier to write language bindings against than a C++ api. However, I personally think we can get better results using C++ apis as a basis as long as they are not too heavy on templates (like boost for instance). Qt-like apis, such as Wt map very nicely onto other languages." I think (for the reasons I stated in the first paragraph) that this is pretty wrong. Aside from that, what I saw from Wt so far looks very nice and well designed. I am looking forward to actually use it :) Greetings, --Marenz ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
