Hello Mattias, Note: WRun is probably the least of your concerns, as it is only one function and you can even implement your own version. The entire API of Wt is C++.
While name-mangling used to vary between gcc compiler versions in the past, it has stabilized a lot for a while now. Therefore, I think that on Linux, a single wt library may be shared for programs that are compiled with different compiler versions. There is however no compatibility between Wt library versions: an app compiled against wt 3.1.0 will not work with a 3.1.1 so (nor will it the other way around). And on Windows, you'll need different .dll's per compiler because MS's runtime libraries are incompatible between compiler versions, which has nothing to do with name mangling. That is the case for both C++ and C libraries. As the library frequently frees objects allocated by the caller, the Wt library must be compiled with the same compiler as the program that uses it. Add to that that Wt DLLs are not backward compatible, and you will indeed conclude that in practical situations, every Wt application will be shipped with its own DLLs. There is no C front end for wt libraries that I know of. Best regards, Wim. 2010/2/23 Mathias Laurenz Baumann <[email protected]>: > 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 > ------------------------------------------------------------------------------ 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
