Date: 2001-09-07 08:03:41
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "William Kempf" <williamkempf_at_h...>
> > From: "Peter Dimov" <pdimov_at_m...>
> > >condition.cpp does not compile when the macro NOMINMAX is not
> > I'll add the macro before the includes.
> > >This program:
> > >sometimes prints 1, 2, ..., 7 (note absence of 0) and sometimes
> > >machine. (I'm using MSVC.) This happens only in Release builds,
> > >Debug; I suspect that 0 is not printed because the catch(...)
> > >thread.cpp eats the access violation. The problem is probably in
> > What access violation?
> The access violation. Weird, I know. It happens somewhere in
> boost::call_once(init_cleanup_key, once) in tss.cpp, AFAICS, but I
> wrong. It's very difficult to debug on 9x since you never know
> be Big Red Button time.
OK, hopefully I have enough info to try and diagnose this. Didn't
find the time last night and won't until tonight, but I'll get to it
> > I also don't see any use of call_once in the above?
> thread_specific_ptr<> uses call_once internally to initialize its
> handler std::set. (Why isn't it a std::map, BTW? Looks like you
> a map with a set?)
Ahh. That helps to.
As for why I didn't use a map... chalk it up to a very long day of
trying to get this concept to work at all ;). I'll fix that while
I'm at it.
> > This is very similar to code used in the test harness, which
passes for me
> > in both Debug and Release (the one difference being the use of
> > which I don't suspect as a problem). This perplexes me. I'll
have to try
> > it out myself later and see if I can diagnose any errors.
> Perplexed me, too.
May take a while, but if there's a bug I'll fix it :).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk