irrAllocator unnecessary?

[zenaku]

I'm looking through the code for 1.1 and I see this new template class, 'irrAllocator'. IMO it is completely unnecessary.

Code: Select all

//!	Very simple allocator implementation, containers using it are able to
//! be used it across dll boundaries

You only need to do this if you are linking the C++ libraries statically, which irrlicht does .

A much easier solution is to link the shared C++ libraries.

Configuration-> C/C++ -> Code Generation -> Runtime Library -> Multi-threaded DLL (/MD)

Even though irrlicht is not multithreaded, linking against the multithreaded DLL libraries allows you to use 'new' in one dll and 'delete' in another becuase the c runtimes are shared.

No need for irrAllocator, IMO. It's like including the kitchen sink!

[elander]

But what about Irrlicht for mingw compiler, linux and macosx?

[hybrid]

Linux and OSX don't have separate memory handlers for libraries, so there's never been a problem on those systems.

[zenaku]

But what about Irrlicht for mingw compiler, linux and macosx?

The majority of Linux distribution moved to shared libraries a long time ago. I'm pretty certain macosx and mingw are also based on shared libraries.

With gcc you do:

Code: Select all

gcc -shared -fPIC ...

If you want the .so file to be loadable from the current directory instead of having to install to /usr/lib or /usr/local/lib, you add:

Code: Select all

gcc -shared -fPIC -Wl,-E -Wl,-rpath,'${ORIGIN}'

A dumb mistake I made is that if you set -rpath,'${ORIGIN}' in a Makefile you need to use two $$'s (make eats one of them).

Hope this helps.

[elander]

There may be other reasons for the use of an allocator. The std c++ library also uses allocators for strings and other containers.

[zenaku]

There may be other reasons for the use of an allocator. The std c++ library also uses allocators for strings and other containers.

I guess my question is, why does Irrlicht need it? STL uses allocators because, well, it's the STL . Irrlicht is a "lighting fast realtime 3d engine", not a generic template library.

I just don't see the point of re-inventing the wheel. Having irrlicht do memory management makes irrlicht grow beyond the scope of a rendering engine or even a game engine.

irrAllocator might be really useful if only used internally by Irrlicht. That would make irrlicht more portable. As a developer, I would never use it. I would use the STL functions or some other library.

Irrlicht already does enough memory management with grab() and drop(), IMO.

[Eternl Knight]

Having irrlicht do memory management makes irrlicht grow beyond the scope of a rendering engine or even a game engine.

Sorry to burst your bubble but nigh on everything needs to do memory management unless it is written in a language which takes care of it (and even then - ignoring memory management becomes a problem for all but the smallest applications).

Adding an allocator allows Irrlicht to be used by multiple runtime libraries on multiple platforms. Your method (while a nice workaround) does not solve the problem for all uses of Irrlicht (I for example am using Irrlicht outside the "game engine" context most people like it for).

Whenever an application starts growing beyond a certian size - it is always useful to have a central location for overriding memory allocation (if only for debugging/logging). An allocator makes this easy (as one simply overrides the implementation with your new features).

Besides which, a game/graphics engine need not create it's own templated arrays, lists, etc. Where does one draw the line?

--EK

[zenaku]

Where does one draw the line?

I think that is where the problem is. Where is irrlicht headed?