Maybe you should consider an idiomatic source-code translation of Wt, like we do for Java (JWt)? Then you should start to investigate if D is a suitable target for such a project.
Best regards, Wim. 2010/2/25 omer katz <[email protected]>: > You should note to yourself that D2 should support some C++ import but it's > quite limited. > > 2010/2/24 Wim Dumon <[email protected]> >> >> 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 > > ------------------------------------------------------------------------------ > 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
