Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibility to undeclare types? #21

Closed
Weeena opened this issue May 9, 2016 · 4 comments
Closed

Possibility to undeclare types? #21

Weeena opened this issue May 9, 2016 · 4 comments
Assignees
Milestone

Comments

@Weeena
Copy link

Weeena commented May 9, 2016

We consider using ponder in the following way: Assume that our application should be extensible. Further assume that extension clases should derive from a base class that is declared by our application. We would like to use the extension classes in connection with ponder in the following way:

  • Load some dll containing an extension class. When the dll is loaded, the dll has to declare the extension class to ponder.
  • Knowing the extension class's ponder name (through some meta information like an XML file containing a description for the dll) we let ponder construct an object of this class and cast it to our base class. We make use of this object by calling the base class's virtual interface functions.
  • After we are finished using that extension object, we would like to destroy it and unload the dll.
    When we work as described, we get an exception when our application exits. (We do not get the exception at application exit if we do not unload the dll.) It seems to us that in the destruction code of ponder it is tried to destruct something that has recided in the dll but is now not anymore available since the dll has been unloaded.
    What could be a solution to this problem? Is there the need for the possibility to explicitly undeclare types?
@billyquith billyquith self-assigned this May 15, 2016
@billyquith
Copy link
Owner

If you have definitely deleted all of the objects created by the DLL them this might be a destruction order problem. E.g. the DLL's memory is destroyed before Ponder and some corruption occurs. As you say, it would make sense to unregister things before terminating the app.

@billyquith billyquith added this to the 1.1 milestone May 16, 2016
billyquith added a commit that referenced this issue May 16, 2016
@billyquith
Copy link
Owner

Undeclared is added in v1.1.

@Weeena
Copy link
Author

Weeena commented May 18, 2016

Thank you very much for your quick response to our issues. We have successfully verified that both issues (#16, #21) are working as expected in V1.1.

We are still evaluating if we can use ponder in one of our applications. Unfortunately, it seems that we would like to use ponder for something it was not designed for. Nevertheless, I hope you don't mind if we possibly open some more issues that describe our wishes to ponder.

@billyquith
Copy link
Owner

I'm interested in having a pragmatic library. I currently don't need this functionality, but I can see how it would be useful. If you have any further suggestions please open another issue ticket.

billyquith added a commit that referenced this issue May 24, 2016
* '1.1' of https://github.com/billyquith/ponder: (39 commits)
  Boost not required.
  No magic sizes.
  Note on undeclare.
  Fix non-constant expression.
  Ability to undeclare Enums.
  Ability to undeclare classes - See issue #21.
  Add string.h for Linux.
  Add changelog.
  Add placement new feature to construction.
  Tweak heading style.
  Tweak doc code style.
  Linux requires this for strcmp().
  Can get sizeof() class via type or name. - As per #16.
  Object creation unit test. - + fixes.
  Make construction of UserObject explicit. - Correct docs.
  Include pondertype.hpp where we declare. - Pretty much always want this.
  Use for-range iterator.
  Check type to string.
  Fix. Increment index.
  Reorder. Constructors first.
  ...

# Conflicts:
#	include/ponder/class.hpp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants