- Boost-users - lists.boost.org

[Boost.Multi-Index] ICE w/ VC7.1
by Marc Viala 31 Dec '06

31 Dec '06

I'm just trying to use Boost.MultiIndex in a large project but I'm not being able to compile this library with VC 7.1.6030: I've got an ICE in file "apply_wrap.hpp" of Boost.MPL. I've tried to change the headers order but without success. My environment is: - Windows XP - Boost 1.33.1 - VC 7.1.6030 To demonstrate this ICE, you will find hereafter a code snippet. Thanks in advance. Marc Viala // MultiIndex Container #include <boost/config.hpp> #include <boost/multi_index_container.hpp> #include <boost/multi_index/composite_key.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/key_extractors.hpp> // STL #include <string> using namespace boost::multi_index ; struct Item { const std::string& getCls() const { return _cls ; } const std::string& getId() const { return _id ; } std::string _cls ; std::string _id ; int _i ; int _j ; } ; void main() { typedef const_mem_fun< Item , const std::string& , &Item::getCls > key_cls ; typedef const_mem_fun< Item , const std::string& , &Item::getId > key_id ; typedef composite_key<Item,key_cls,key_id> ckey_clsid ; typedef composite_key< Item , ordered_non_unique<member<Item,int,&Item::_i> > , ordered_non_unique<member<Item,int,&Item::_j> > > ckey_ij ; typedef multi_index_container< Item, indexed_by< ordered_non_unique<key_id> , ordered_non_unique<key_cls> , ordered_unique<ckey_ij> > > ObjectContainer ; ObjectContainer c ; }

2 1

[serialization and asio] Trying to serialize asio IPs
by Eoin O'Callaghan 30 Dec '06

30 Dec '06

Hello, my name is Eoin O'Callaghan. I wasn't sure if this email should have been sent to ASIOs own mailing list or this Boost one, hopefully this was an ok place. My bit of bother is in trying to use Boost.Serialization to save some IP addresses stored internally as Boost.ASIO asio::ip::address_v4 and address_v6 classes. I wonder has anyone any pointers as my attempts thus far are not getting me anywhere? The IP classes can be constructed from, and exported to, boost::array<unsigned char, ##> types so a solution for boost::arrays would probably be one road to a solution but unfortunately I can't successfully write a serialize function for boost::array. I've held back from posting my own attempts to save myself from embarrassment. But will do so if someone wants to see what I've tried. Kind regards, Eoin. -- Eoin O'Callaghan <eoin(a)zl.vc>

3 3

[Thread] condition.cc test doesn't work..
by Giacomo Piccolo 29 Dec '06

29 Dec '06

Hello everybody, I've got a synchronization problem with two threads and I need a semaphore or a condition class in which a thread can wait on until that condition is verified. In other words i need to synchronize two or more threads and I need the wait() and notify() routines. I found some useful code in boost::thread libraries, but it seems I could not use it because it seems not completely built...or.. boh I don't really know. I tried also to build it lauching an executable builder I downloaded from the internet but I can't use it because don't have the root priviledges. I attach the source code and the errors I got. Is there anyone so kind to help me solving this little question? Thank you in advance! Giacomo

2 1

Boost threads + MSVSC + /Za + client code
by Sohail Somani 29 Dec '06

29 Dec '06

Hi, With Visual C++, I can't seem to determine why if I simply include boost/threads/once.hpp, I need to enable language extensions for that translation unit. I'm going to dig into this further today but I would appreciate if someone has figured out a solution short of allowing language extensions. I can understand requiring it for building boost threads (as windows.h seems to have some extended syntax) but I'm not sure of the logic behind requiring client code to use it as well. Thanks for listening :) Sohail

1 0

Solving a synch problem with the Boost::Thread library.
by luca 28 Dec '06

28 Dec '06

Hello all, I have a set of modules (ie classes, say the Module class and some Module derived classes) which calculate (or generate) data, and two different module instances could be connected together: one would use as input data the output of the other one. I have also a class which manages (say the ModulesManager class) the interconnections of those modules and it triggers the calculation of all the modules. The calculation is triggered in an worker boost::thread at a given rate (i.e. when the ModulesManager::trig () method is called). The modules have an internal state (upon which its calculation is based on), which could be changed by another thread calling some method of the Module class, say Module::setOffset(int offset). The problem is that I would like that any change to the internal state of any module happen not when the network of modules is being triggered by the ModulesManager, but it could be possible only between a call to trig() and its subsequent call. I would like to have a suggestion on how to modelize that in an elegant way. I thought about using something like the following: struct ModulesManager { ModulesManager::trig () { recursive_mutex::scoped_lock (*mutex); for (each Module mod) { mod->calculate (....); }//for } shared_ptr<recursive_mutex> ModulesManager::getMutex () const {return mutex;} } Then any thread could change the internal state of any Module just by using a code such as: AnyClassRunningInAnotherThread::setModuleXInternalState () { recursive_mutex::scoped_lock (*modulesManagerInstance->getMutex ()); moduleX->setOffset (newOffset); } Thanks in advance for any better proposal, Luca

1 0

Re: [Boost-users] help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

boost-users-bounces(a)lists.boost.org wrote: > Ok the mist is rasing ;-) > > There should be no problem mixing pthread and Boost.Thread. > I.e. your inherited lib can use pthread while your new code > can use Boost.Thread on the native API. I agree. But I have to deal with a great fear factor here. People think there will be a problem and the only way to deal with it is to (truthfully) say that everything is using the win32 port of pthreads. It is the only approach that will be accepted :-( > > But if on the other hand for whatever reason you want to take > the additional (IMHO unnecessary step) to build boost thread > on top of pthread you can. Here is how we go: > > Open the file BOOST_ROOT/libs/thread/build/threads.jam > Follow the instructions found there and set up your > environment variables accordingly. Excellent. This is exactly what I was looking for. Thanks very much, I will give this a try. > Again the whole mess isn't worth doing it. Technically, I agree. Politically......deep sigh....... The build is now in progress and it is time for me to go home and eat more mince pies :-) I will pick up on this again in the New Year. Many thanks again and Happy New Year! -Andrew Marlow ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

1 0

Re: [Boost-users] help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

boost-users-bounces(a)lists.boost.org wrote: > Andrew Marlow wrote: >>> 1) Building the boost library on top of pthread instead of native >>> WinThreads? >> >> Yes. Once the boost libs (and a few examples) have built ok I will >> then release these as prebuilts. > > Sorry this does not make sense to me, as this would imply > your project will be using the boost library: Boost.Thread. Yes it will. > So normally you wouldn't want to have them use the pthread > implementation in turn. Things are not normal here. My app has to use an in-house lib that was coded using pthreads. When that lib had to be available on windoze they did it by using the win32 port of pthreads. My app has to use this in-house lib, hence I have to link with the win32 port of pthreads. But I also want to do my own threading. I want to do it in a platform-independent way so I choose boost threads. > The only exception I can think of is > when you are doing some performance testing. Nope. > Usually the Boost.Thread on native windows API will be faster > than on top of pthreads, since there is one emulation layer less. Agreed. And if it was not for the in-house lib being built on the win32 port of pthreads then we would probably use boost threads throughout with a default build that uses the win32 api. But that is not an option. We do not want any apps to contain a mixture of win32 pthreads and win32 API threads. > >> I will have to do this for a number of versions of Visual Studio. >> Then for VC71 I will use the prebuilt boost lib to build my own >> project. It will be developed using the VC71 IDE but will be built >> overnight by a perl script that uses msdev in command line mode. >> This overnight job will not build boost, it will pick up the boost >> prebuilt. > > So I assume you are attempting to build the boost library? Yes, but I want to build it with a version of the win32 port of pthreads that lives in a special (non-std place). > If so, simply read the getting started from the boost > homepage and then precompiler your library, which basically > has to be done from the boost root directory: bjam > -s"TOOLS=vc-7_1" install which will install to C:\Boost directory by > default. (The above is for version 1.33, upcoming 1.34 is different. ) I don't think that works. I already tried it and it builds to the WIN32 API, not to the win32 port of pthreads that I have. > As an alternative you might also download the prebuilt binary > versions of the lib. I thought of that, but that won't work either. The boost that I wind up with MUST be one that is built wrt the win32 port of pthreads that comes with this in-house lib. Even if there was a prebuilt version of boost built with the win32 port of pthread even that would not do. It must be the particular version of the win32 port of pthreads that the in-house lib was built with. Wot a pain, eh? -Andrew M. ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

2 1

Re: [Boost-users] help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

boost-users-bounces(a)lists.boost.org wrote: > Andrew Marlow wrote: >> I am trying to build boost 1.33.1 on Windoze using Visual Studio .NET >> 2003 (aka vc71). This seems to be build just fine using the default >> settings (bjam -sTOOLS=vc-7_1) but I need to do the build such that a >> win32 port of pthreads can be picked up. >> I need some help with this please. > > What do you want to achieve? > > 1) Building the boost library on top of pthread instead of > native WinThreads? Yes. Once the boost libs (and a few examples) have built ok I will then release these as prebuilts. I will have to do this for a number of versions of Visual Studio. Then for VC71 I will use the prebuilt boost lib to build my own project. It will be developed using the VC71 IDE but will be built overnight by a perl script that uses msdev in command line mode. This overnight job will not build boost, it will pick up the boost prebuilt. > Please try to precise as possible, describing what you are > trying to do, since there are a lot of possible scenarios to > use the boost libraries. Hopefully this is a bit clearer now.... -Andrew ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

2 1

help needed picking up pthread.h with Visual Studio .NET 2003
by Andrew Marlow 28 Dec '06

28 Dec '06

I am trying to build boost 1.33.1 on Windoze using Visual Studio .NET 2003 (aka vc71). This seems to be build just fine using the default settings (bjam -sTOOLS=vc-7_1) but I need to do the build such that a win32 port of pthreads can be picked up. I need some help with this please. Eventually I hacked boost/config/platform/win32.hpp, and added "#define BOOST_HAS_PTHREADS". Is this what we are expected to do? I could find no help in this particular area of configuration. This hack does indeed make it try to #include <pthread.h> but I don't know how to tell the build where to look for this header. Hence, I now get loads of compilation errors. My app uses a proprietary library that is built on the win32 port of pthreads. So in order for my app to use boost I need it to work with the win32 port of pthreads that the proprietary library was built with. This means picking up pthread.h from the proprietary library source directory, rather than picking it up from std places. How is this done please? Regards, Andrew Marlow ---- There is an emerald here the size of a plover's egg! Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

2 1

fail to pick up win32 port of pthreads lib at link time
by Andrew Marlow 28 Dec '06

28 Dec '06

I am still stuck on building boost with the win32 port of pthreads. After hacking win32.h to turn on pthreads I hacked msvc-tools.jam, adding an include option to the compilers command line, telling it in which directory pthread.h may be found. So now it all compiles. But it fails to link. I do not know enough about how boost jam works to be able to do a similar tweak to the linkers command line. And I am very uneasy at having to do these sorts of hacks. Surely there must be a better way. Can anyone help please? Regards, Andrew Marlow ---- There is an emerald here the size of a plover's egg! Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

1 0