[Bf-committers] MEM_CacheLimiter breaks msvc6 compile
unrepairable - *Ping*
stealthapprentice at yahoo.com
Thu Feb 9 18:28:04 CET 2006
The STL that comes with gcc & MSVC 7+ are both
STLPort hasn't been updated since 2004, and has subtle
deviations from the spec, particularly with
implementations of allocators.
The gcc/MSVC STLs are thoroughly vetted with regards
multi-threading, reentrancy, & the MSVC version is
properly adorned for DLL export, and I expect that the
gcc version will be too as the new ABI is rolled out.
I used STLPort for years, but stopped using it when
the out of the box STL's surpassed it. The portability
and standards/compliance issues weren't worth it.
In addition I am not in favor of introducing a big new
dependency like STLPort to Blender.
--- Peter Schlaile <peter at schlaile.de> wrote:
> Hi Simon,
> > Regarding the STL errors, would STLport
> (www.stlport.org) help here?
> No. It is a problem with the MSVC-6 compiler
> supporting allocators
> > If necessary, this could become an official
> requirement as it provides a
> > cross-platform STL implementation. Alternatively,
> (and perhaps
> > preferably) couldn't our classes be rewritten to
> remove these allocator
> > problems? Peter, any ideas?
> Interesting. The allocator is needed to use the
> guardedalloc of blender on
> stl-containers. This was requested by Ton since he
> did not want to have
> STL memory management mixed with Blender's internal
> There were two ways to accomplish this: write my own
> list class (yiieeks)
> or add an allocator (nice way).
> What bugs me: I do not understand why MSVC-6 does
> not like my code.
> I don't use rebind. But see thread below.
> Bf-committers mailing list
> Bf-committers at projects.blender.org
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the Bf-committers