[boost] 1.30 boost.threads warnings
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 guess is that is related to the warning thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' discussed before. And that it's ok as long as you are consistent with the usage of C runtime an STL versions across dlls and executables? /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problems compiling microsec_time_clock with cygwin/gcc
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 >>before `;' token > > I believe there are issues supporting the C interface used by the > microsec_time_clock on windows. We probably need some macros to fix > this... > > Jeff > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexical_cast woes
I get the following errors when compiling with the lexical_cast version in CVS on MSVC 7.0 do I have to enable wchar_t support on the command line or disable it via DISABLE_WIDE_CHAR_SUPPORT or whats the solution. I tried to read up on the new lexical_cast woes with the 1.30 release but failed to find something. C:\Packages\boost\work\boost\lexical_cast.hpp(161) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'std::basic_stringstream<_Elem,_Traits,_Alloc>::_Mystr' (or there is no acceptable conversion) with [ _Elem=wchar_t, _Traits=std::char_traits, _Alloc=std::allocator ] C:\Packages\boost\work\boost\lexical_cast.hpp(157) : while compiling class-template member function 'bool boost::detail::lexical_stream::operator >>(std::string &)' with [ Target=std::string, Source=boost::socket::port_t ] C:\Packages\boost\work\boost\lexical_cast.hpp(189) : see reference to class template instantiation 'boost::detail::lexical_stream' being compiled with [ Target=std::string, Source=boost::socket::port_t ] server_test.cpp(128) : see reference to function template instantiation 'Target boost::[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@ 2@@std@@G(Source)' being compiled with [ Target=std::string, Source=boost::socket::port_t ] btw boost::socket::port_t is unsigned short which gets mixed up with wchar_t. Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problems compiling microsec_time_clock with cygwin/gcc
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 -I"..\..\..\libs\soc ket\build" -I"C:\Packages\boost\sandbox" -I"C:\Packages\boost\boost" -I"C:\P ackages\boost\work" -o "..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-d ynamic\socket_option.obj" "../src\socket_option.cpp" ...failed gcc-C++-action ..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-dy namic\socket_option.obj... gcc-C++-action ..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-dy namic\default_socket_impl.obj In file included from C:/Packages/boost/work/boost/date_time/posix_time/posix_time_types.hpp:9, from C:/Packages/boost/sandbox/boost/socket/config.hpp:32, from C:/Packages/boost/sandbox/boost/socket/impl/default_socket_impl.hpp:19, from ../src/default_socket_impl.cpp:21: C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp: In static member function `static time_type boost::date_time::microsec_clock::create_time(timeval*)': 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 -I"..\..\..\libs\soc ket\build" -I"C:\Packages\boost\sandbox" -I"C:\Packages\boost\boost" -I"C:\P ackages\boost\work" -o "..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-d ynamic\default_socket_impl.obj" "../src\default_socket_impl.cpp" ...failed gcc-C++-action ..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-dy namic\default_socket_impl.obj... Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] date_time on gcc linux
Hello!
When compiling the following program on gcc 3.2 on a Linux box aginst the
boost in the CVS repository it fails
#include
int main(int argc, char** argv) {}
with
[EMAIL PROTECTED] michel]$ g++ i.c -I"/home/michel/boost/work"
In file included from
/home/michel/boost/work/boost/date_time/posix_time/posix_time_types.hpp:9,
from i.c:2:
/home/michel/boost/work/boost/date_time/microsec_time_clock.hpp: In static
member function `static time_type
boost::date_time::microsec_clock::create_time(timeval*)':
/home/michel/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse
error
before `;' token
adding
#include
#include
int main(int argc, char** argv) {}
or including
#include
works.
So I guess the config isn't included in all files? According to the docs
#include is an available
header file with definitions without io.
Regards
/Michel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: smart_ptr vs smart_resource
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 > smart_resource (or shared_resource as I was then calling it) over a > year > ago - so it's not a new thing :-) > > [)o > IhIL.. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Sockets - what's the latest?
>> At the very end of it, network programmers should be using a >> callback-driven interface and not have to worry about multiplexing at >> all, but I agree that for now a third layer should be deferred until >> the basic groundwork has been laid out. Yes the level 2 interface should be callback driven. And to some agree i guess the end user have to worry about multiplexeing. At least by declaring somekind of multiplexor (proactor, reactor) and driving the main multiplexing loop and letting the user of the library handle threading issues (apart from the library declaring that the multiplexing primitives are thread safe). > I believe we agree :-) BTW, I've been thinking for awhile that either > boost::function or boost::signal will provide us with core of that > callback framework that diverges from the traditional OO approach > taken by ACE and as is proposed currently on the Wiki. The asynch part in the sandbox uses boost.function as a completion callback mechanism. And i the reactor i envision would use boost.function to notify that a socket is ready. /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Sockets - what's the latest?
> 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 Sockets, and in order to support it we will have to > think outside of the Sockets domain. Particularly with issues like > multiplexing, this would put into perspective just what needs to be > done, rather than assuming we should just provide an analog for > select() and be done with it. How would you describe the differences between Apples OpenTransport and sockets with respects to especially api, options and multiplexings. I think the design proposed on wiki is rather socket centric the upside would be to be able to make an library in wich you could use a larger part of the common interface available with sockets the downside that other api:s would have to be forced into a socket centric one. Could you help out with an early OpenTransport port or at least an early review to evaluate the design with respect to this demand? What do you others have for view on this, isn't the problem domain hard enough with the differences in sockets implementations and multiplexing mechanism on different platforms or should we aim even higher and be able to incorporate other more "exotic" network apis which cannot easily be mapped to sockets? /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets - what's the latest?
>> Noone knows as there is no consensus on how the library's >> architecture should look like. There are different approaches and >> proposals at Boost Wiki and in the sandbox but what's still missing >> is the big picture. As far as there are no ideas of how to get a >> reasonable model which incorporates different things like >> blocking/non-blocking/multiplexing/asynchronous/extensible... there >> won't be much progress. I've been thinking about that and hope to >> come up with an idea in a few days. Actually I think we have come a bit on the design and could churn out something that could be use as a foundation for further discussion. I think whats missing is the reactor part for event notification using eg select. Actually I think that a select based reactor would be a sensible next step to make a proof of concept on the current design. > How about borrowing ideas from ACE, but implementing them in > modern C++? Or has that been discussed already? Or is the ACE > framework too obsolete-C++ to be a useful design? I have looked at that direction while experimenting with the design in the sandbox at least for the asynch parts (proactor, asynch_acceptor, asynch_data_socket). And for the layer 2 standard multplexing of events via select i think the reactor pattern would fit. I don't have a problem with a borrowing concepts from ACE or POSA2 (Pattern Oriented Software Architecture 2) to implement boost.sockets layer 2, do any other of you have strong opinions on patterns used in ACE and mentioned in POSA2? /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets - what's the latest?
> 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 boost, and I know > there are > many others who do. > Hugo Duncan and I have been juggling ideas about a socket library for boost and discussing on the boost wiki and partly on the list. And we have started with an rough sketch of how a socket library for boost could look like. It's currently checked in into the boost sandbox. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket contains some of the discussions and details. The work has not been progressing as much as I want due to a heavy workload on my daytime job. But we certainly like some feedback on the progress so far. Have we choosen a dead end or a viable path. The implementation in the sandbox has been compiled with gcc/cygwin, bcc and vc6.0 and vc7.0. So we need some input on porting to Unix especially the asynchrounous parts. So I would say that we have a long road to travel to finnish implementation, produce documentation test cases and all that. And when we have come that far there is the formal review and i guess there will be a lot of heat when that will come ;). So I wouldn't count on sockets to be a part of boost for some time (unless of course someone else submits another proposal or helps me and Hugo out on what we have so far to speed the progess). Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: boost.threads: Thread pool
>> 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 maybe a version number in the dll name would seem good (not the lib >> name). > >This should be happening with the stage rule, though I haven't confirmed. Ok! I built the current CVS in the beginning of this week and got an boost_thread.dll without version number. I didn't use boost.build v2 either so maybe there are some differences between the old an new jamfiles and bjam in this case, and it wasn't from the thread_dev branch. Will there also be different names for debug and release dlls? /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: boost.threads: Thread pool
>> 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 when >> implementing the alarm and alarm_queue class which is easy to get wrong >> therefore I think its general purpose enough and belongs in a thread >> toolbox. > >Maybe you should send me a prototype implementation then. Sure thing! >> Is it settled wether there will be some kind of portable id (preferably >> streamable) i often put thread ids in log file entries. > >Yes, though I'm still debating about whether or not the id will be >seperate from the boost::thread class itself. The current CVS state has >both. It would seem natural to be able to get it from the thread class but ill guess in that case you would need to get a pointer to the "current" thread instance and that might be hard if its from within a native thread. I guess this isn't a problem if its separate from the thread class. Maybe the current approach that allows both styles is good enough to gather experience? >>>* Addition of shared memory constructs. >> >> This is a needed one. Is there any preliminary sketches of what the >> interface will be like? > >Sort of. Dave Moore has been working on this, but I've not evaluated his >work in any way, so can't comment on whether or not there will be design >changes. Is it in the dev branch or in the sandbox or is it still a thing between you and Dave ;)? >It vastly simplifies the build process (now that we have a working >DLL implementation), and is the version most users have been asking for >any way. I did expect to get some static about this, so let the debate >begin. ;) Note, however, that it will be a little problematic to continue >with a build process that provides both a forms, and that the >threadmon.dll has been the source of a lot of confusion for users, so >there will have to be very compelling reasons to bring this build type >back. 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 maybe a version number in the dll name would seem good (not the lib name). Since there might arise situations where a product consist of application A by team A using boost 1.30 and another group B responsible for application B using 1.xy which isn't compatible and they should share the same directory which could cause problems, and this would be the most compelling reason to have a library version as well. I don't know what others have to say about this issue but I'll guess I will take the discussion internally since i certainly would like to use the latest release ;). /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost.threads: Thread pool
>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 kind of alarm or timer would be
>> useful.
>
>Not something in the todo hopper. Can you give a more concrete
>explanation of what you want, and why you think it's important for
>inclusion.
As a simple way to get a function called at regular interval, something i
often use for periodic polling of connection status eg for db connections or
other periodic tasks.
A simple interface like:
struct alarm
{
alarm();
// constructor setting alarm
alarm(function0 callback, xtime alarmTime, unsigned int
intervalMsecs = 0);
// will do a cancel to ensure callback isn't called after destruction of
alarm
~alarm();
// set alarm to go off (if intervalMsecs is 0 its a one shot alarm)
void set(function0 callback, xtime alarmTime, unsigned int
intervalMsecs = 0);
// stop alarm synchrounously no active callbacks after this point
// you must be abel to cancel alarm from all threads especially from
// within the callback.
void cancel();
}
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 when
implementing the alarm and alarm_queue class which is easy to get wrong
therefore I think its general purpose enough and belongs in a thread
toolbox.
>Right now, most of the work is being done on boost::thread itself. This
>includes a reference-counted implementation instead of a non-copyable
>implementation, the addition of attributes such as stack size/address and
>priority scheduling and the addition of cancellation. I'm getting close
>to completion of the design/implementation and will be asking for a peer
>review soon.
Is it settled wether there will be some kind of portable id (preferably
streamable) i often put thread ids in log file entries.
>* Final integration of Dave Moore's classes, including thread_pool,
>rw_mutex and barrier.
Great!
>* Addition of shared memory constructs.
This is a needed one. Is there any preliminary sketches of what the
interface will be like?
Ok!
Another question i noted that in the current boost CVS the boost.thread only
builds a dll version of the library and no static ones, in earlier release
you only needed the dll when using tss? Is it supposed to be that way?
Regards
/michel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost.threads: Thread pool
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 guess cancellation is at the top but it may be the hardest nut to crack of them all. /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost.threads: Thread pool
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 guess cancellation is at the top but it may be the hardest nut to crack of them all. /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: sockets library question
> 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 change to with the interface proposed by the
socket library proposal in the sandbox by Hugo and me.
address_info_list list("www.google.com", "http");
address_info_list::iterator ibegin=list.begin(), iend=list.end();
std::cout << std::distance(ibegin,iend) << " addresses found\n";
if (ibegin == iend)
{
std::cout << "No address found" << std::endl;
return -1;
}
connector<> connector;
connector<>::data_connection_t connection;
connector.connect(connection, ibegin->protocol(),
ibegin->address());
basic_socket_stream sock(connection);
... the rest unchanged...
The design is based around the overall requirements in
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/S
ocketRequirements
originally written by Beman Dawes. The design is layered so you it can
enable complex uses for both servers and clients as well as simple uses as
the one you sketch.
/Michel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: sockets library question
> There is a basic low level socket implementation (socket_base), > and Michel André has put together an extension of this for the > asynchronous methods on NT. Here we would need some help implementing lower lever asynch classes using unix aio or eqvivalent strategy for other platforms. > At this stage we need to decide what would be the scope of an > initial submission. Is the basic socket design useful in itself, > or would the proactor and reactor patterns be required for the > library to have any meaning? Is the level 1 design (without > reactor/proactor classes) sufficient for client usage? I think at least level1 is needed completed with some kind of reactor/selector/polling/multiplexor/proactor primitives for ordinary sockets. > Ultimately I would like to hope that we can build a framework > where the choice of procator, reactor and threading decisons > can be completely seperated from the application code, with > these decisions being implemented as policies. But that is > going to take quite a while to get right Well this is a though one and the solution i can see is to "emulate" asynch operations using ordinary sockets and select and use more effecient strategies on demand or if available. Some input on this side would be invaluable. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/A synchAcceptorConcept for what I had in mind. Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Socket Multiplexing
> I have not used async io, so I am a little out of my depth here. If we > were to create an interface that could be implemented using select or > aio what design constraints would that impose? > > I am guessing the callbacks would be free threaded. Is that right? The interaction model with async IO is completeley different from using select or WSAEventSelect based mechanisms. When using traditional select based youre getting notified when there is something to read or when you are able to write without blocking. Referring to POSA2 by Scmidth et all this is Reactive and therefore the name of the Reactor pattern. On the other hand async io you post reads and writes that may complete or may not complete together with some token or context (asynchrounous completion token) to the client state and the buffer to read or write from ie proactive (post a read in case somebody writes to you) and queue a write and get notification when its done regardless if the stack is ready to receive it. Referring to POSA2 by Scmidth et all this is proactive and therefore the name of the Proactor pattern for event multiplexing. The two strategies uses different sets of multiplexers and connection/acceptors/connectors than the more traditional interface. Therefore I think that an async io package will be a new addition to the socket library or a completely new library. I don't even now if its possible to implement async aio in a consistent manor on all platforms (or at least sufficient number) that is of interest to boost, but it could be simulated via another multiplex mechanism and threads I guess. And yes the callbacks should be free threaded, since if several threads is picking completions of the completion queue notifications will come on any of those threads. Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SocketAddress and Nameresolution
> > 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 > above, no 95/98/Me/NT/2000. yes thats true! The implementation should use gethostbyname if getaddrinfo is not supported. Actually its supported on some later service packs. And I guess the implementation would have to resort to finding the existence og getaddrinfo dynamically (via LoadLibrary and GetProcAddress on ws2_32.dll) and resort to gethostbyname if it's not found. gethostbyname is thread safe in winsock as one structure is allocated per thread. I don't know about the support for getaddrinfo on other platforms or the existence of threadsafe versions. Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Sockets
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 address, split address to end_point and address proposed a resolver interface. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/D ataSocketConcept Proposed an easier to use interface to avoid many misstakes and maybe not knowing as much about the underlying low level socket interface to use? BTW! How do we handle Wiki discussion with a discussion on this list? Is this appropriate or will all interested parties look on Wiki? /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: SocketSetConcept (fd_set wrapper)
> 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 minimize dependencies in boost header files to the systems/platforms socket implementation files for one thing Winsock2.h is quite an heavy include (including Windows.h if not already done). This would affect compile times for platform independent code. I also think this was one of the requirements from Bemans original document, since not all network headerfiles is good "citizens", Beman eg mentions macros named "send". See http://groups.yahoo.com/group/boost/files/sockets2/Sock-req.html. So I would like to see that we make the final version of this library a lib or dll to accomplish what we wan't ie insulate user from the lower layer interface completely (look at boost.threads that doesn't drag in any system files). Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Sockets!
How do i access the cvs sandbox? My win cvs window says CVSROOT: [EMAIL PROTECTED]:/cvsroot/boost-sandbox (password authentication) TCL is *not* available, shell is disabled cvs update -P (in directory C:\Packages\boost_sandbox\) cvs server: Updating . And i don't get anything. Thanks /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
