I get the following warning when building and using a thread_group in MSVC
70 with boost 1.30
...\boost\boost\thread\thread.hpp(79) : warning C4251:
'boost::thread_group::m_threads' : class 'std::list_Ty,_Ax' needs to have
dll-interface to be used by clients of class 'boost::thread_group'
My
Thnx!
Will you please keep me posted/updated?
Regards
/Michel
Jeff Garland wrote:
I get the following error when trying to compile
date_time/microsec_time_clock.hpp from the current CVS with
cygwin/gcc.
C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44:
parse
error
I get the following error when trying to compile
date_time/microsec_time_clock.hpp from the current CVS with cygwin/gcc.
C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse
error
before `;' token
+ -c -Wall -ftemplate-depth-100 -g -O0 -fno-inline
Is shared_count scheduled to come out from the detail namespace and be
publically available and maybe a bit documented?
I don't think we should encourage users to use things from detail namespace?
/Michel
Phil Nash wrote:
Peter suggested I use shared_count when I first started talking about
Another thing is I think it is important to get at least one
non-Sockets-based network API in the mix right at the beginning to
make
sure the design is truly flexible. I recommend Apple's OpenTransport,
not because it will be around much longer, but because it is quite a
bit different from
Anyone who was working on it - what's the current state of play? The
flurry of mail on here a while back seemed to fizzle out. Is that
because development has stalled?
If I can help out with what limited time and knowledge of the subject
I have I will. I really want to see this library in
The idea is that all alarms should share on timer thread and a thread
pool and a priority queue (or maybe these things should be in an
alarm_queue class which an alarm is associated with, but there should be
a system default if an
alarm_queue class isn't given). There are some thorny issues
Ok! Actually the only reason for me to want the old style is that it
will take longer for me to adopt 1.30 and later because I would have to
convince my CM guys to remake install and packaging, but thats more of a
political hurdle than a technical one. So it's ok. The only nitpick is
that
Hello!
Any chance of an additon of David Moores thread pool implementation to
boost.threads to the next release or another implementation of some kind of
thread pool concept. Also some kind of alarm or timer would be useful. Or
how does the priority and wishlish for boost.threads look like. I
Depends on the time frame of the next release and how fast I can finish my
work on the library. If it's not in 1.30.0, it will be in 1.31.0. In the
mean time, if it's important enough to you, you can track the work in
progress in the thread_dev branch in CVS.
Thanks! Will check out.
Also some
If you are interested, please comment on it. I would especially like to
know if the benefits of an Acceptor/Connector pattern would outweigh the
additional complexity involved (specifically, how much more complicated
the sample test.cpp file would get). Thanks!
Basically the beginning would
1. getaddrinfo is thread-safe. And not all OS provide those
functions like gethostbyname_r
2. getaddrinfo resovle one name to multiaddresses, especially a
name with both IPv4 addresses, and IPv6 addresses.
Just as a side note. getaddrinfo is only supported on Windows XP and
So I think we should be careful to keep it simple. I think it is
interesting that in Hugo's current implementation, no library is
required. Very nice. I won't be surprised if we need a real
library at some point, but it won't be anything like the size of
ACE.
I think we should try to
Hello!
I've made some suggestions on the following pages. Outlining new interfaces
for address and data_sockets concept (or data_connections as I called the
concept for now).
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/A
ddressConcept
Separation of resolving and
14 matches
Mail list logo
