RE: [Boost-Users] Re: pool_allocator problems on VC7.1 (real rele ase)
Some command-line tools ship with their DDK, so I do have a version of "cl.exe" that reports "13.00.9176" - no idea how this fits in with the VC versions, though. And the DDK doesn't include an STL anyway. There is one "common" failure case with some implementations of STL containers: passing 0 to Allocator::deallocate. When used with std::allocator, the 0 is passed through to operator delete() which of course ignores it. When used with pool_alloc, this generally causes a segfault. IIRC, STLPort's std::vector will do this if you construct & destroy an empty vector. Since I don't have the VC STL, could you do that test case for me? Thanks, -Steve
--- In Boost-Users@yahoogroups.com, scleary@j... wrote: the VC
versions, though. And the DDK doesn't include an STL anyway.
Unfortunately that's not it (it's the final beta); You want 13.10.3077.0.
ignores it. When used with pool_alloc, this generally causes a
segfault.
I can test this for you tomorrow (I'm about to go drinking now). In return, could you possibly tell me how to change pool_allocator so that it uses my own tag? My goal is to have a totally local allocator for some special parts of the code. Why, BTW, does it have to use the Singleton pool interface instead of the object pool interface? The latter, I think is what I'm after. I'll reply here with the results of my test. jh
--- In Boost-Users@yahoogroups.com, "John Harris" <john.harris@t...> wrote:
I'll reply here with the results of my test.
I tried several variations on vectors and lists with pool_allocators, constructed with ints and basic_strings (themselves with pool_allocators), in both debug and release builds, and had no crashes on VC7.1 Release. jh
participants (2)
-
John Harris -
scleary＠jerviswebb.com