irrlicht way of returntypes

Nox · Post by **Nox** » Tue Mar 10, 2009 3:05 pm

Hi,

i took a closer look to the source and wondered, why there are const references to local stored return_datas_container returned by many methods. After some time i figured out that this is due to the heap problem (there are 2 heaps. One for the lib and one for the exe).
My question:
Is not there a better way than storing the datas local in the instances and returning a reference to them? I understand that you do not want to use the dynamic runtimelibrary. But for example std::list solve this heap problem by avoiding the "simple new" operator.

hybrid · Post by **hybrid** » Tue Mar 10, 2009 9:50 pm

I don't understand a thing here. Could you please give an example?

Nox · Post by **Nox** » Tue Mar 10, 2009 11:48 pm

I have added some methods to CGUIFileOpenDialog and created a testcase which calls them.

Methods:
core::string<c16> getDirectoryName()
const core::list<core::stringw>& getFileNames1()
core::list<core::stringw> getFileNames2()

core::string<c16> s = getDirectoryName()
works because core::string use a own allocator

core::list<core::stringw> l = getFileNames1()
works because i give a reference to a object which remains to irrlicht

core::list<core::stringw> l = getFileNames2()
crashs because list is created inside of irrlicht, given to exe and then destroyed by the exe ->heapcrash.

"simple" way to avoid this: apply irrAllocator to core::list

EDIT: Same for core::map

JP · Post by JP » Wed Mar 11, 2009 8:29 am

well what's the implementation of getFileNames2? If you've implemented it yourself and it crashes then that's your fault, not irrlichts...

bitplane · Post by **bitplane** » Wed Mar 11, 2009 9:48 am

JP wrote:well what's the implementation of getFileNames2? If you've implemented it yourself and it crashes then that's your fault, not irrlichts...

I guess it just returns the value, list and map don't use IrrAllocator so it crashes for the reasons Nox stated. If you remember, we had this problem with texture matrices a while back

Nox · Post by **Nox** » Wed Mar 11, 2009 10:01 am

It is irrlichts fault. irrList and irrMap uses delete and new directly -> used with two different heaps = crash
irrMap can not be copied so this will never happend as long as it has no copy c'tor but irrList has a copy c'tor. IrrArray and irrString are implemented quite more elegant with a irrAllocator. But just try it:

apply the patch and insert into an exe-code under windows using the dll:

Code: Select all

{
     core::list<core::stringw > test = device->foo();
}

EDIT: after that test, patch your irrlicht with https://sourceforge.net/tracker/index.p ... tid=540676 and this problem should be fixed. As allready mention irrMap does not use irrAllocator too, so the heap corruption bug may appeare there too.