Date: 2001-09-10 22:04:19
--- In boost_at_y..., "Dale Peakall" <dale.peakall_at_b...> wrote:
> Not really a review. Haven't made enough use of it yet to provide
> Boost.Threads fails to compile on VC6 SP5 with either or STLPort-
> the last snapshot (before 4.5's release at the weekend).
> Compilation fails on line 127 of tss.cpp. Not exactly sure what's
> on here, some sort of conversion problem according to the compiler
I expect this will probably be corrected in the latest code in CVS,
though I don't have STLport to verify.
> A number of additional warnings are produced.
> C4290 warning (C++ exception specification ignored). It would be
> for this to be #pragma'd out in the Boost.Threads cpp files.
What line causes this?
> C4244 warning in timeconv.inl (line 83). conversion from '__int64'
> 'unsigned int'; possible loss of data.
> C4018 warning in condition.hpp (lines 82 and 132) - signed/unsigned
I need to evaluate this a little better tomorrow.
> The examples included in the documentation appear to all be broken:
> In the mutex documentation:
> create() should be create_thread() and shouldn't take 2 args.
> should the thread funcs take a void* arg. I missed the decision
> provide a facility for passing data into a thread func (except by
> a functor). A rational wouldn't be missed for this in the docs (as
> pthreads and win32 threads provide this functionality).
Reported by others and fixed.
> Same for recursive_mutex.
> In the condition variable example:
> The typedef from boost::mutex::lock needs to be changed to
> The constructor name needs to match the name of the class
> Again the thread funcs shouldn't take any args and the constructor
> the threads shouldn't try and provide one.
> The finished variable doesn't exist.
> The thread_specific_ptr example:
> Missing template type in typedef. Should be
Problem with < > usage. Reported earlier and fixed.
> In thread_proc() should be value.reset() rather than value.set().
Reported earlier and fixed.
> In main(), create() should be create_thread(). Should return 0.
The create() was reported earlier and fixed. Strictly speaking main
() need not return 0. VC++ produces an erroneous warning here, but
the behavior is well defined by the standard.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk