Hello Dirk,
On 02/07/2011 05:11 PM, Dirk Reiners wrote:
> On 02/07/2011 04:07 PM, Carsten Neumann wrote:
>>
>> hmm, not sure about that, we still have the vector (well, it's a
>> std::deque<>), but that does not make much of a difference for the
>> amount of memory, only that it does not require a large _contiguous_
>> chunk of memory...
>
> I haven't looked at the implementation, but given that all the objects are
> destroyed I would that it frees empty blocks.
uhm, no, because as far as the deque is concerned the blocks are not
empty. We can't call deque::erase(), because that would change the
indexing (just like it does for a vector) and the index is used to map
from container id to actual container :(
>> I think the biggest obstacle in changing this is the disaster that is
>> trying to get a hash_map/unordered_map implementation on the common
>> platforms. We could use boost::unordered_map, but that only made it into
>> boost 1.36, RHEL 5 comes with 1.33 AFAIK :-/
>
> Hm, that might be a problem, given that RHEL 5 will probably be with us fora
> while. Not sure what the best solution would be. :(
hmm, just noticed we have a OSGDeprecatedCPP.h that might make that not
too bad of a nightmare, I'll give it a try.
Cheers,
Carsten
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
