digitalmars.D - Proof of Concept: Binding to and extending C++ objects via a metric
- downs (27/27) Dec 09 2009 I've just committed a module to tools (tools.cpp, http://dsource.org/pro...
- BCS (1/1) Dec 09 2009 please tell me the subject is a freudian slip (or just a typo).
- downs (2/5) Dec 09 2009 Considering the amount of abuse me and the compiler put each other throu...
- retard (2/7) Dec 09 2009 Why are these needed? Because of compiler bugs?
- Nick Sabalausky (4/5) Dec 09 2009 It's a very precise figure:
- Bernard Helyer (2/9) Dec 10 2009 Though I suppose in metric it would be a fucktonne. :D
- g (1/1) Dec 09 2009 omg
- g (3/40) Dec 09 2009 if you have problems seeing the first link:
- downs (2/44) Dec 09 2009 Oops. Sorry for that. (Never a post without an error!)
- dsimcha (18/45) Dec 09 2009 http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that shou...
- downs (3/49) Dec 09 2009 Nontemplates only. C++ templates require a C++ compiler.
- Don (14/31) Dec 10 2009 At http://www.agner.org/optimize/, you can find a document
- Tim Matthews (3/5) Dec 10 2009 Does 'any' c++ library even include the ones in c++ namespaces? If so
- downs (2/11) Dec 12 2009 I don't know about namespaces, but that's a problem with mangling and th...
- Denis Koroskin (5/18) Dec 12 2009 What's the wrapper performance penalty (if any)?
- BCS (3/25) Dec 12 2009 Given he works with bullet physics, I'd say being the only one who under...
I've just committed a module to tools (tools.cpp, http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should enable linking and using any C++ library with D programs without creating a C wrapper for it. The code has been tested with a simple multiple-inheritance sample: http://paste.dprogramming.com/dpv8hpjp The D code to bind to this is http://paste.dprogramming.com/dphlv1ot . It requires a symlink to the tools folder in its directory. Caveats: - D1 - Only works on g++4's "newapi" layout and mangling (but should be reasonably portable). - Diamond pattern is untested and unsupported. - Class protection is completely unsupported - public only. - RTTI must be generated manually (normally the compiler would do this). See the D half of the sample. - Dynamic casting from and to generated classes is not implemented. - The C++ code that does this is long and full of special cases, so - For the example, I ended up hardcoding a manual translation between A and B. - If you need dynamic casting, I recommend hardcoding the required paths based on classinfo pointer comparisons. - The C++ DSL parser is not very tested. Occasional bugs may occur. - When building with LDC, fixup_vtable() needs to be called for every newly created C++ class object. - This is because LDC does not yet support initialization from global variable addresses. Building the sample is a two-step process: g++ test.cpp -c -g -o test.o gdc -J. cpp_demo.d tools/cpp.d tools/base.d tools/smart_import.d tools/ctfe.d tools/compat.d tools/text.d tools/tests.d tools/log.d test.o \ library path as appropriate Writing this also gave us what I believe to be a fair contender to Most Horrifying Statement of D Ever Written: fndefs ~= `mixin("extern(C) `~t~` "~`~mname~`~"`~fnparams~`; ");`~'\n'~ `mixin("`~fn~`("~refToParamList("Params!(typeof(&"~`~mname~`~"))", isRef!(typeof(mixin("&"~`~mname~`))))~") { return "~`~mname~`~"("~refToValueList(isRef!(typeof(mixin("&"~`~mname~`))))~"); } "); `; --downs
Dec 09 2009
please tell me the subject is a freudian slip (or just a typo).
Dec 09 2009
BCS wrote:please tell me the subject is a freudian slip (or just a typo).Considering the amount of abuse me and the compiler put each other through in the course of writing this, including such gems as incorrect tuple lengths, incorrect tuple slices, endless errors without line numbers, spurious template instantiation errors with nonsensical parameters, and at least one case where T[0] evaluated to T, necessitating the workaround Tuple!(T[0])[0], it felt appropriate.
Dec 09 2009
Thu, 10 Dec 2009 01:01:34 +0100, downs wrote:including such gems as incorrect tuple lengths, incorrect tuple slices, endless errors without line numbers, spurious template instantiation errors with nonsensical parameters, and at least one case where T[0] evaluated to T, necessitating the workaround Tuple!(T[0])[0], it felt appropriate.Why are these needed? Because of compiler bugs?
Dec 09 2009
retard wrote:Thu, 10 Dec 2009 01:01:34 +0100, downs wrote:Apparently, in certain very specific corner cases, my version of GDC believes that when I say "T[0]", I really mean "T". In that case, "Tuple!(T[0])[0]" is like saying "really very the first element". :)including such gems as incorrect tuple lengths, incorrect tuple slices, endless errors without line numbers, spurious template instantiation errors with nonsensical parameters, and at least one case where T[0] evaluated to T, necessitating the workaround Tuple!(T[0])[0], it felt appropriate.Why are these needed? Because of compiler bugs?
Dec 09 2009
Hello downs,retard wrote:I call it a Bug. Do you have a test case?Thu, 10 Dec 2009 01:01:34 +0100, downs wrote:Apparently, in certain very specific corner cases, my version of GDC believes that when I say "T[0]", I really mean "T". In that case, "Tuple!(T[0])[0]" is like saying "really very the first element". :)including such gems as incorrect tuple lengths, incorrect tuple slices, endless errors without line numbers, spurious template instantiation errors with nonsensical parameters, and at least one case where T[0] evaluated to T, necessitating the workaround Tuple!(T[0])[0], it felt appropriate.Why are these needed? Because of compiler bugs?
Dec 10 2009
"BCS" <none anon.com> wrote in message news:a6268ffdff18cc46f7aa8b7a32 news.digitalmars.com...please tell me the subject is a freudian slip (or just a typo).It's a very precise figure: 1 metric fuckton == 1,000 meteric shitloads
Dec 09 2009
On 10/12/09 14:41, Nick Sabalausky wrote:"BCS"<none anon.com> wrote in message news:a6268ffdff18cc46f7aa8b7a32 news.digitalmars.com...Though I suppose in metric it would be a fucktonne. :Dplease tell me the subject is a freudian slip (or just a typo).It's a very precise figure: 1 metric fuckton == 1,000 meteric shitloads
Dec 10 2009
downs Wrote:I've just committed a module to tools (tools.cpp, http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should enable linking and using any C++ library with D programs without creating a C wrapper for it. The code has been tested with a simple multiple-inheritance sample: http://paste.dprogramming.com/dpv8hpjp The D code to bind to this is http://paste.dprogramming.com/dphlv1ot . It requires a symlink to the tools folder in its directory. Caveats: - D1 - Only works on g++4's "newapi" layout and mangling (but should be reasonably portable). - Diamond pattern is untested and unsupported. - Class protection is completely unsupported - public only. - RTTI must be generated manually (normally the compiler would do this). See the D half of the sample. - Dynamic casting from and to generated classes is not implemented. - The C++ code that does this is long and full of special cases, so - For the example, I ended up hardcoding a manual translation between A and B. - If you need dynamic casting, I recommend hardcoding the required paths based on classinfo pointer comparisons. - The C++ DSL parser is not very tested. Occasional bugs may occur. - When building with LDC, fixup_vtable() needs to be called for every newly created C++ class object. - This is because LDC does not yet support initialization from global variable addresses. Building the sample is a two-step process: g++ test.cpp -c -g -o test.o gdc -J. cpp_demo.d tools/cpp.d tools/base.d tools/smart_import.d tools/ctfe.d tools/compat.d tools/text.d tools/tests.d tools/log.d test.o \ library path as appropriate Writing this also gave us what I believe to be a fair contender to Most Horrifying Statement of D Ever Written: fndefs ~= `mixin("extern(C) `~t~` "~`~mname~`~"`~fnparams~`; ");`~'\n'~ `mixin("`~fn~`("~refToParamList("Params!(typeof(&"~`~mname~`~"))", isRef!(typeof(mixin("&"~`~mname~`))))~") { return "~`~mname~`~"("~refToValueList(isRef!(typeof(mixin("&"~`~mname~`))))~"); } "); `; --downsif you have problems seeing the first link: http://dsource.org/projects/scrapple/browser/trunk/tools/tools/cpp.d
Dec 09 2009
g wrote:downs Wrote:Oops. Sorry for that. (Never a post without an error!)I've just committed a module to tools (tools.cpp, http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should enable linking and using any C++ library with D programs without creating a C wrapper for it. The code has been tested with a simple multiple-inheritance sample: http://paste.dprogramming.com/dpv8hpjp The D code to bind to this is http://paste.dprogramming.com/dphlv1ot . It requires a symlink to the tools folder in its directory. Caveats: - D1 - Only works on g++4's "newapi" layout and mangling (but should be reasonably portable). - Diamond pattern is untested and unsupported. - Class protection is completely unsupported - public only. - RTTI must be generated manually (normally the compiler would do this). See the D half of the sample. - Dynamic casting from and to generated classes is not implemented. - The C++ code that does this is long and full of special cases, so - For the example, I ended up hardcoding a manual translation between A and B. - If you need dynamic casting, I recommend hardcoding the required paths based on classinfo pointer comparisons. - The C++ DSL parser is not very tested. Occasional bugs may occur. - When building with LDC, fixup_vtable() needs to be called for every newly created C++ class object. - This is because LDC does not yet support initialization from global variable addresses. Building the sample is a two-step process: g++ test.cpp -c -g -o test.o gdc -J. cpp_demo.d tools/cpp.d tools/base.d tools/smart_import.d tools/ctfe.d tools/compat.d tools/text.d tools/tests.d tools/log.d test.o \ library path as appropriate Writing this also gave us what I believe to be a fair contender to Most Horrifying Statement of D Ever Written: fndefs ~= `mixin("extern(C) `~t~` "~`~mname~`~"`~fnparams~`; ");`~'\n'~ `mixin("`~fn~`("~refToParamList("Params!(typeof(&"~`~mname~`~"))", isRef!(typeof(mixin("&"~`~mname~`))))~") { return "~`~mname~`~"("~refToValueList(isRef!(typeof(mixin("&"~`~mname~`))))~"); } "); `; --downsif you have problems seeing the first link: http://dsource.org/projects/scrapple/browser/trunk/tools/tools/cpp.d
Dec 09 2009
== Quote from downs (default_357-line yahoo.de)'s articleI've just committed a module to tools (tools.cpp,http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should enable linking and using any C++ library with D programs without creating a C wrapper for it.The code has been tested with a simple multiple-inheritance sample:http://paste.dprogramming.com/dpv8hpjpThe D code to bind to this is http://paste.dprogramming.com/dphlv1ot . Itrequires a symlink to the tools folder in its directory.Caveats: - D1 - Only works on g++4's "newapi" layout and mangling (but should be reasonablyportable).- Diamond pattern is untested and unsupported. - Class protection is completely unsupported - public only. - RTTI must be generated manually (normally the compiler would do this). Seethe D half of the sample.- Dynamic casting from and to generated classes is not implemented. - The C++ code that does this is long and full of special cases, so - For the example, I ended up hardcoding a manual translation between A and B. - If you need dynamic casting, I recommend hardcoding the required pathsbased on classinfo pointer comparisons.- The C++ DSL parser is not very tested. Occasional bugs may occur. - When building with LDC, fixup_vtable() needs to be called for every newlycreated C++ class object.- This is because LDC does not yet support initialization from globalvariable addresses.Building the sample is a two-step process: g++ test.cpp -c -g -o test.o gdc -J. cpp_demo.d tools/cpp.d tools/base.d tools/smart_import.d tools/ctfe.dtools/compat.d tools/text.d tools/tests.d tools/log.d test.o \librarypath as appropriateWriting this also gave us what I believe to be a fair contender to MostHorrifying Statement of D Ever Written:fndefs ~= `mixin("extern(C) `~t~` "~`~mname~`~"`~fnparams~`; ");`~'\n'~ `mixin("`~fn~`("~refToParamList("Params!(typeof(&"~`~mname~`~"))",isRef!(typeof(mixin("&"~`~mname~`))))~") {return"~`~mname~`~"("~refToValueList(isRef!(typeof(mixin("&"~`~mname~`))))~");} "); `; --downsAwesome! One quick question. This may be a stupid question, as I don't understand at all yet how this works: Can you instantiate C++ templates with this thing, or does it work only w/ non-templated C++ code?
Dec 09 2009
dsimcha wrote:== Quote from downs (default_357-line yahoo.de)'s articleNontemplates only. C++ templates require a C++ compiler. If you instantiate them in C++ code, you can then use them in D code, but I haven't looked into how the mangling would look like for this.I've just committed a module to tools (tools.cpp,http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should enable linking and using any C++ library with D programs without creating a C wrapper for it.The code has been tested with a simple multiple-inheritance sample:http://paste.dprogramming.com/dpv8hpjpThe D code to bind to this is http://paste.dprogramming.com/dphlv1ot . Itrequires a symlink to the tools folder in its directory.Caveats: - D1 - Only works on g++4's "newapi" layout and mangling (but should be reasonablyportable).- Diamond pattern is untested and unsupported. - Class protection is completely unsupported - public only. - RTTI must be generated manually (normally the compiler would do this). Seethe D half of the sample.- Dynamic casting from and to generated classes is not implemented. - The C++ code that does this is long and full of special cases, so - For the example, I ended up hardcoding a manual translation between A and B. - If you need dynamic casting, I recommend hardcoding the required pathsbased on classinfo pointer comparisons.- The C++ DSL parser is not very tested. Occasional bugs may occur. - When building with LDC, fixup_vtable() needs to be called for every newlycreated C++ class object.- This is because LDC does not yet support initialization from globalvariable addresses.Building the sample is a two-step process: g++ test.cpp -c -g -o test.o gdc -J. cpp_demo.d tools/cpp.d tools/base.d tools/smart_import.d tools/ctfe.dtools/compat.d tools/text.d tools/tests.d tools/log.d test.o \librarypath as appropriateWriting this also gave us what I believe to be a fair contender to MostHorrifying Statement of D Ever Written:fndefs ~= `mixin("extern(C) `~t~` "~`~mname~`~"`~fnparams~`; ");`~'\n'~ `mixin("`~fn~`("~refToParamList("Params!(typeof(&"~`~mname~`~"))",isRef!(typeof(mixin("&"~`~mname~`))))~") {return"~`~mname~`~"("~refToValueList(isRef!(typeof(mixin("&"~`~mname~`))))~");} "); `; --downsAwesome! One quick question. This may be a stupid question, as I don't understand at all yet how this works: Can you instantiate C++ templates with this thing, or does it work only w/ non-templated C++ code?
Dec 09 2009
downs wrote:I've just committed a module to tools (tools.cpp, http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should enable linking and using any C++ library with D programs without creating a C wrapper for it. The code has been tested with a simple multiple-inheritance sample: http://paste.dprogramming.com/dpv8hpjp The D code to bind to this is http://paste.dprogramming.com/dphlv1ot . It requires a symlink to the tools folder in its directory. Caveats: - D1 - Only works on g++4's "newapi" layout and mangling (but should be reasonably portable).At http://www.agner.org/optimize/, you can find a document (calling_conventions.pdf) which gives full details of the C++ name mangling schemes for various compilers.Writing this also gave us what I believe to be a fair contender to Most Horrifying Statement of D Ever Written: fndefs ~= `mixin("extern(C) `~t~` "~`~mname~`~"`~fnparams~`; ");`~'\n'~ `mixin("`~fn~`("~refToParamList("Params!(typeof(&"~`~mname~`~"))", isRef!(typeof(mixin("&"~`~mname~`))))~") { return "~`~mname~`~"("~refToValueList(isRef!(typeof(mixin("&"~`~mname~`))))~"); } "); `;Ugh, that's unreadable. I found that with a little function called string enquote(string s), which changes s into "s", this kind of stuff looks much less terrible. In particular you get rid of the nasty mix of ` and ". fndefs ~= "mixin(" ~ enquote("extern(C)" ~ t ~ " ") ~ "~" ~ mname ~ "~" ~ enquote(fnparams ~ ";") ~ ");" ~ "mixin(" ~ .... // etc
Dec 10 2009
downs wrote:I've just committed a module to tools that should enable linking and using any C++ library with D programs without creating a C wrapper for it.Does 'any' c++ library even include the ones in c++ namespaces? If so good job thanks.
Dec 10 2009
Tim Matthews wrote:downs wrote:I don't know about namespaces, but that's a problem with mangling and thus, fixable. I'm currently wrestling with bullet physics, which doesn't use namespaces, so this isn't priority right now :pI've just committed a module to tools that should enable linking and using any C++ library with D programs without creating a C wrapper for it.Does 'any' c++ library even include the ones in c++ namespaces? If so good job thanks.
Dec 12 2009
On Sat, 12 Dec 2009 15:25:53 +0300, downs <default_357-line yahoo.de> wrote:Tim Matthews wrote:What's the wrapper performance penalty (if any)? And can the code be a bit sanitized? As it is, I believe it is impossible to maintain by anyone except the original author, which is a bad thing.downs wrote:I don't know about namespaces, but that's a problem with mangling and thus, fixable. I'm currently wrestling with bullet physics, which doesn't use namespaces, so this isn't priority right now :pI've just committed a module to tools that should enable linking and using any C++ library with D programs without creating a C wrapper for it.Does 'any' c++ library even include the ones in c++ namespaces? If so good job thanks.
Dec 12 2009
Hello Denis,On Sat, 12 Dec 2009 15:25:53 +0300, downs <default_357-line yahoo.de> wrote:Given he works with bullet physics, I'd say being the only one who understands it qualifies as a "Bad Thing".Tim Matthews wrote:And can the code be a bit sanitized? As it is, I believe it is impossible to maintain by anyone except the original author, which is a bad thing.downs wrote:I don't know about namespaces, but that's a problem with mangling and thus, fixable. I'm currently wrestling with bullet physics, which doesn't use namespaces, so this isn't priority right now :pI've just committed a module to tools that should enable linking and using any C++ library with D programs without creating a C wrapper for it.Does 'any' c++ library even include the ones in c++ namespaces? If so good job thanks.
Dec 12 2009