Cross library string problem. New to Irr. (But not coding)

[primem0ver]

I am not sure which forum to put this in. It is definitely an advanced programming question but I am brand new to Irrlicht which is why I need to ask it.

I am using Qt with Irrlicht and developing an object manager that manages objects from BOTH libraries. Many objects (including qt widgets) are going to need to be searchable and accessible from scripting so I must name them. The problem is that the string types for each library are incompatible. The "nice" thing about Qt (actually... it's a double edged sword) is that its QLatin1String class is a thin wrapper around a char*. It became a pain to deal with because not even the copy constructor creates a duplicate object. It simply passes the pointer to a new object. The reason it is "nice" is because it allows me to use it in my own class without allocating extra memory. That is why I created my own class to keep the actual data.

After a brief look at the source, the Irrlicht engine however seems to always reproduce the string rather than wrap the pointer. I wouldn't care for copy constructors but since I have my own object name class, this presents a problem. If I am correct/don't find a solution, All objects that inherit an Irrlicht class will by nature have TWO memory locations allocated for the same name (because from what I can tell the = operator creates a copy so even if I feed the equal operator a char*, it will still copy the char array).

Is their a way around this problem using the native Irrlicht classes so that I can just feed a char* to the core::stringc class without it allocating extra memory space? I can guarantee that by the time the pointer is assigned to the name it will be permanent. The only other option I can think of is to have ALL named objects in my project use the stringc class defined in irrlicht whether they are related to graphics or not. (Which means I will have to import the irrlicht library in every single class... whether or not it is related to the engine).

[primem0ver]

I have a solution to this problem... but I would still like to know the answer to the above question because my solution is a workaround (even if it is "elegant").

I decided to not have a base string object and make the base class "name" function abstract (at least for now):

Code: Select all

virtual char* objectName() const = 0;

This way the derived object (whether from the Qt library or from the Irrlicht library) can return the appropriate char* using library specific methods without having to duplicate the object.

[CuteAlien]

irr::string always excepts to handle the memory itself, I don't think that can be avoided. But I don't understand what exactly you are trying to do. Are you trying to have some rtti like function where you have one string per class or is this to search objects at runtime - so you have one string per object? Such stuff is easier to follow if we can see some actual code showing what's going than an abstract description of code in words.

[mongoose7]

I think what he is talking about is a smart pointer. He certainly doesn't seem to get that stringc *stores* a string.

[CuteAlien]

I think it's not about the storing, but about the memory management.

[primem0ver]

It is primarily for looking up objects at runtime.

He certainly doesn't seem to get that stringc *stores* a string.

Yes.. I do get the idea that stringc not only stores but memory manages the string. That is the problem. If I assign a pre-existing string object to the stringc, a copy is made rather than simply wrapping the data. So instead of having an object class that manages its own names I must now have an object class that points to a name in another class because I cannot simply wrap the pointer inside the stringc object.

[CuteAlien]

What I don't get is why you even have to pass your string to Irrlicht? If you are wrapping objects from different libraries together I assume you have your own base-class for your objects anyway. And that can use any kind of string you want to have.

[primem0ver]

The problem is that if I manage the string from my object... then assign that string to the stringc, stringc will make a copy of the string object and waste memory. Irrlicht already keeps a name for each object from what I can tell. So I don't want to create two names and waste the memory.

[CuteAlien]

Yeah - but why do you pass that string to Irrlicht in the first place? It's not like Irrlicht needs the string except for object management. Which you seem to do yourself - so you don't need that.

Anyway - as mentioned Irrlicht string class does handle memory of it's strings. Not really much more I can say about that.

[primem0ver]

The nature of my project makes it necessary. ALL objects are defined in xml and must have the name they are assigned in order to have access to them in scripting. Many of the things that are done in my software are done by way of scripts. Particularly animations. (Not object animation but animation around the screen). In addition, gui controls will need to be modified (mostly disabled and enabled) from scripting. It is true that irrlicht doesn't always need the names but if the object is going to have a name anyway, then it seems pointless for me to have my own name for the object. From what I have seen. even cameras have names. (which is fine with me.... more control and a multitude of cameras will be very advantageous in some situations.). SO regardless of whether the object is an irrlicht 3d object; a 2D HUD object, a camera, light, or even a GUI widget from the hosting Qt GUI, I need to be able to access the name of the object so that I can hide it, show it, or shut it on and off (for Qt and some HUD objects) OR all of the previous things and moving it when it comes to some HUD and 3D objects. All from scripting.

[CuteAlien]

Well, Irrlicht has names - which are useful if you use the Irrlicht object management. But it sounded a lot like you do your own object management and in that case it might be easier to have the names in your class as well. But it's your design, I can't really comment on that. Can't help with the string-copies - maybe put a getName function in your base-class which does automatic string conversions.

[primem0ver]

Well yeah... that is what I am resorting too. My virtual function in my second post (reposted here) does that. For all Irrlicht objects, this will grab the data() pointer in the stringc object.

Code: Select all

    virtual char* objectName() const = 0;

[sash]

then it seems pointless for me to have my own name for the object.

And if you'll need more than just a name ? It seems like you will.
I believe this is very reasonable to have your own manager and store any data entities there (including name and pointer to Irrlicht object).
This is exactly what I'm doing in my applcation: my manger controls my objects (each in turn controls Irrlicht nodes) and Irrlicht renders. Everyone is happy

[primem0ver]

And if you'll need more than just a name ? It seems like you will.

Well yeah... I will but I still want to minimize as much memory use as possible. This will be a decent sized program in memory when it is finished and it needs to run on multiple platforms. I am hoping it will run on tablets as well... though the use of Qt may hamper that a bit (since it is such a large library).

I believe this is very reasonable to have your own manager and store any data entities there (including name and pointer to Irrlicht object).
This is exactly what I'm doing in my applcation: my manger controls my objects (each in turn controls Irrlicht nodes) and Irrlicht renders. Everyone is happy

Yeah... thats the idea.

[CuteAlien]

Just from experience - the thing costing memory in 3D applications is always the textures. Everything else pales in comparison.