You should note to yourself that D2 should support *some *C++
import<http://www.digitalmars.com/d/2.0/cpp_interface.html>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
