error: undefined reference to 'aiScene::~aiScene()' on Android when using delete myAiScene; about assimp HOT 9 CLOSED

This is the verbose log for the make file:
https://gist.github.com/mastro/6194183

from assimp.

Do you have to use importer.GetOrphanedScene()? That should really only be used as a last resort; I don't believe aiScene::~aiScene is exported by the library.

I would recommend just using importer.GetScene(), and if necessary create separate importers if you need multiple scenes loaded simultaneously.

from assimp.

@jdduke yes I now store the Importer and use GetScene()

but I do not see why you are not exporting aiScene::~aiScene

you give the GetOrphanedScene() with a comment to say: be very careful and delete it when its not used anymore, but then don't give a way to delete it.. makes no sense to me.

I think the ~aiScene should be exported for that very reason.

from assimp.

I did not write the code, so no need to get feisty :)

I would argue that the cleaner solution would be to simply remove Importer::GetOrphanedScene() completely. Leaving it as an option will inevitably lead to abuse, undefined behavior and user issues like those you've experienced. I wonder... does assimp have a formal way of deprecating public API's?

from assimp.

@jdduke didn't meant to be feisty! :) English is not my main language, I don't know why I sounded mean but didn't meant to ;)

Even if I find a way around using GetOrphanedScene I'm personally against removing it.
Id rather publish the destructor for aiScene.
The comment is already enough to discourage the usage of that method.

I wanted to use it for being able to load multiple scene with the same importer keeping them. The only other way to do it is storing multiple importers.

To make it public it is enough to modify include/assimp/scene.h changing:

struct aiScene
{

to

struct ASSIMP_API aiScene
{

from assimp.

Exporting is easy... what's not as easy is debugging the undefined behavior that inevitably results from allocating objects in one library (assimp) and deleting them in another.

The Importer class provides a copy constructor with which you can easily copy all of the settings from a given importer (without copying the owned aiScene). I would highly recommend creating your desired Importer, and duplicating it where necessary to load multiple aiScenes. The Importer itself is relatively lightweight, so you won't be losing anything, and you'll be gaining security and happy coworkers. Another option would be to add a static method to Importer that would let you free the orphaned scene (i.e., "class Importer { .... static FreeScene(aiScene* orphanedScene); ... };".

It's really a shame naked pointers are used everywhere (backwards compatibility?); unique_ptr would do the codebase a lot of good =/

from assimp.

It would. In fact, I sometimes thought about rewriting from scratch, but I just don't think it is worth the effort.

Assimp's codebase has grown over the past 6 years, and the initial code quality was just not very high. Since then it has improved a lot, but the core - a very Cish data structure - has not changed.

If there was a rewrite, we would probably use a C++ish scene data structure (which would get us rid of at least 30% of the code and also the bugs for the importers) and copy over to a plain C structure.

from assimp.

@jdduke @acgessler using the importer is ok. But if you need custom IO you have to create multiple instances of them too.

I'd ++ every effort of removing a C++ data structure in favor of a C structure, I never liked C++.

sorry for the late reply, was on holyday

from assimp.

Deprecated!

from assimp.