Added import feature - Githubissues

klemens-morgenstern commented 8 years ago

Import features is in. Looks like this:

auto ovl = import_mangled<void(int), void(double)>(sm, "overloaded");
ovl(12);
ovl(5.0);

sm.add_type_alias<override_class>("some_space::some_class");

auto func = import_mangled<
        override_class, double(double, double), int(int, int),
        volatile override_class, int(int, int),
        const volatile override_class, double(double, double)>(sm, "func");

    override_class ov;
    volatile override_class &ovv = ov;
    const volatile override_class &ovcv = ov;

func(&ov, 3.,2.);
func(&ov, 1,2  );
func(&ovv, 10,2);
func(&ovcv, 9,2);

klemens-morgenstern commented 8 years ago

I forgot: this is utterly inefficient, because it copies everything around. But it sort-of matches your import structur.

klemens-morgenstern commented 8 years ago

And here's the prototype for a class import. Currently tested on mingw.

It's currently rather short, but can be used in the following way:

auto cl = import_class<class override_class, int>(sm, "some_space::some_class", type_size, 42);
//str at pos 2 is the type_alias, the third is optional. Since the signature is given this is optional.

auto i = cl.call<const override_class, int()>("get")();
cl.call<void(int)>("set")(42);

//implemented above
auto func = import_mangled<
        override_class, double(double, double), int(int, int)>(sm, "func");

(cl->*func)(3.,2.);
(cl->*func)(1 ,2 );

//alternate syntax:
auto func = cl.import<double(double, double), int(int, int)>("func");

I changed the type_index values to the ctti-variant so incomplete types can be used as type-aliases.

klemens-morgenstern commented 8 years ago

Alright, so there's also no way to allow type_aliases with an incomplete type in a portable manor. gcc works fine with ctti_type_info (which allows that) but msvc doesn't.

klemens-morgenstern commented 8 years ago

Elsewise I think, we would now have a basis to discuss the basic design. And really: except for the vtable, we now have everything you can get out of a dll.

klemens-morgenstern commented 8 years ago

Ok, so i got the class import to work with incomplete types. At least with gcc. MSVC crashes for some reason at constructor-call, I don't get the reason there.

I also built-in a check before the move-ctor test, to see if the DbgHelp version is new enough. I actually did NOT test it with another version then 4.0, but this one doesn't know the move-semantic demangling!

apolukhin commented 8 years ago

I've just cherry-picked the dbghelp.hpp from your fork. Hopefully, it will be moved to Boost.WinAPI soon.

The deadline for breaking changes in Boost is near, so probably I'll merge this pull request only after the Boost 1.61 release. This gives you a lot of time to polish and experiment with the functionality (here's a Boost's schedule http://www.boost.org/development/index.html)

klemens-morgenstern commented 8 years ago

Well, considering the insanity of my code that makes sense. It's currently more a proof-of-concept implementation, so I'd be really happy if you could look over that.

I'll remove the DbgHelp.h as soon as it get's merged into winapi. Since I had to change a few details the current msvc is broken. It tends to do that.

This is because the way I adapted the api_version structure doesn't fit the rest of the winapi-library.

klemens-morgenstern commented 8 years ago

Ok, he denied the dbghelp. Now I could put it into my fork, but I think that wouldn't be the smartest thing to do, since you probably want the issue fixed before the 1.61 release. If you move it into dll/detail, you might want to use this version because it is consistent with the winapi stuff.

EDIT Ok it got in...

klemens-morgenstern commented 8 years ago

Ok, this is rather strange behaviour, actually the tests pass: https://ci.appveyor.com/project/klemens-morgenstern/boost-dll/build/1.61.22-develop https://travis-ci.org/klemens-morgenstern/Boost.DLL/builds/109211865

I would need feedback on that, if you expect me to implement more. The basically works, though you might dislike the syntax or have additions.

klemens-morgenstern commented 8 years ago

Ok, I looked over the mangled import stuff again, it looks alright to me - though that might be bcause I wrote it. The template stuff is weird, but I think sufficiently understandable. Again: I'd need some feedback.

I added a test for the type_info just to realize that I did not implement that properly in MSVC, now I have a version which works locally by looking through the vtable, which is rather frightening. Seems to be different on 64-Bit, I'll try to find a fix.

coveralls commented 8 years ago

Coverage increased (+0.2%) to 93.122% when pulling a03d85ee7b5422e8d601d745343b80c8fa88cd23 on klemens-morgenstern:develop into 4bfb5a151d66abdfa38b05a42b69b6c11873317d on apolukhin:develop.

klemens-morgenstern commented 8 years ago

The error seems to come from boost.filesystem.

coveralls commented 8 years ago

Coverage increased (+0.2%) to 93.122% when pulling 8d9944f1b1425fee3758b16858d82f000c3e1b3d on klemens-morgenstern:develop into 279e323ac23ccb1a9b77a95b6c9c85e88e28f250 on apolukhin:develop.

klemens-morgenstern commented 8 years ago

I only merged your changes, so the Appveyor rebuilds - the error was an issue in boost/core od boost/filesystem. Thus it works. We can remove the DbgHelp, since the undname does work and provides the rvalue references because it is in the current runtime - not another tool. So if you do not like the class import, we should at least use the undname feature.

apolukhin commented 8 years ago

Ok, time to watch regression tests and polish the code :)

klemens-morgenstern commented 8 years ago

Awesome! If you'd like so documentation, please tell me. Did you actually tell the boost community about that feature? Because people might miss it, and it wouldn't be tested.

apolukhin commented 8 years ago

I'd appreciate documentation for new features and a few usage examples :)

A few more things to tune:

smart_library is actually smart, but it's unclear what does it do from it's name. Probably it must be renamed into shared_library_mangled/mangled_library/cpp_shared_library. Any naming ideas are welcomed.
is it possible to implement smart_library::get_mem_fn() using shared_library::get()? shared_library::get() must be capable of loading member functions, if it fails it must be fixed in shared_library code.

apolukhin commented 8 years ago

After new features will be well tested and stabilized and documented a note could be sent to G+ or Boost lists. And of course note about new features will appear in Boost's 1.62/1.63 changelog.

klemens-morgenstern commented 8 years ago

Ok, I'll add some doc, probably on the weekend

I'd just name it cpp_library if necessary, but then again, I would've just named it library not shared_library because the sharing part is rather obvious. The full descriptive name would be something like demangling_and_overload_considering_library, that's why I named it smart. But since the shared_library imports C-Declarations and the smart_lib C++, cpp_library would probably be the most fitting.
Looks to me like that's done , but it does require the overload in shared_library

apolukhin / Boost.DLL

Added import feature #19