- Boost-users - lists.boost.org

[thread] bug: thread::sleep can't 'Idle'
by Daniel Winsor 11 Oct '06

11 Oct '06

#include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> #include <Windows.h>//for sleep void ExecuteThread() { for(;;) { boost::xtime time; time.nsec = 0; time.sec = 1; boost::thread::sleep(time); //Sleep(1000); } } int main() { boost::thread thread1(ExecuteThread); boost::thread thread2(ExecuteThread); thread1.join(); thread2.join(); return 0; } When this program is run with Sleep() instead of boost::thread::sleep(), and there are no other cpu intensive programs running, Task Manager shows 99% of the cpu (dual core) is idle. However, when it is run with boost::thread::sleep(), 99% of the cpu is being used by the program! This is a problem because powersaving features no longer work. When this program with boost::thread::sleep() is run with another program that is cpu intensive, Task Manager reports the other program uses 99% of the cpu, so there is no problem there. I am using an overclocked Intel Core 2 Duo 6400 if that matters.

1 0

boost::interprocess linking on vc-7_1
by Andrea Carbone 11 Oct '06

11 Oct '06

The linker complains about not founding libboost_date_time-vc71-mt-s-1_33_1.lib by far, I don't have a clue about what option to pass to bjam in order to build such configuration I have data_time library in al fashion exept the required one .. Does anybody has some advice?

3 5

[multi_index]Got warnings in VC7.1
by ShenLei 10 Oct '06

10 Oct '06

Hi, I used multi_index in the simple way: int<->int unique mapping. But in VC7.1, warning level 4, I got many warnings for: \boost_1_33_1\boost\multi_index\detail\ord_index_node.hpp(453): warning C4510: 'boost::multi_index::detail::ordered_index_node<Super>' : default constructor could not be generated. I have read the doc of multi_index, and tried to turn off "\Gm", but the problem is still. When compiled it in VC8.0 under warning level 4, these warnings disappeared. It seems that, the template support in VC7.1 is not so good. My test code is listed in the end of this article. How to get rid of them? (...>_<... The webpage argues me about top-posting, so I cannot put them on). Another thing is about compile time. If multi_index is employed, the compile time will be greatly increased (slower 10 times in VC7.1, 3 times in VC8.0). Furthermore, the message generated by compiler is extremely long. I usually get lost in it. ^_^ Is there any way to simplify them? Such as using struct T:S rather than typedef in multi_index library? Finally, I have a question on the design of template<class Class,typename Type,Type Class::*PtrToMember> struct member; In practice, the user of "member" should provide the SAME type of PtrToMember to the template arguments(Class & Type). If feeded with some wrong types, errors message for the hell will be sent out. ^_^ Is there any way to improve it? Such as simply member<T* PtrToMember>, and let the compiler to deduce the type of this memberpointer? Thank you. ShenLei

2 2

[graph] reading GraphML
by Jens Müller 10 Oct '06

10 Oct '06

I'm trying to write a testcase for graphml.hpp/.cpp from graph-tool. I have the following: #include <boost/graph/adjacency_list.hpp> #include <boost/property_map.hpp> #include <boost/dynamic_property_map.hpp> #include <iostream> #include <boost/graph/graph_traits.hpp> #include <map> #include "./graphml.hpp" enum edge_length_t { edge_length }; namespace boost { BOOST_INSTALL_PROPERTY(edge, length); } int main(int argc, char* argv[]){ // create a typedef for the Graph type using namespace boost; typedef boost::adjacency_list<vecS, vecS, bidirectionalS, no_property, property<edge_length_t, double> > Graph; Graph g; std::ifstream input(argv[1]); boost::dynamic_properties properties; typedef graph_traits<Graph>::vertex_descriptor vertex_descriptor; std::map<vertex_descriptor, double> coord1; boost::associative_property_map< std::map<vertex_descriptor, double> > coord1_map(coord1); properties.property("coord1", coord1_map); std::map<vertex_descriptor, double> coord2; boost::associative_property_map< std::map<vertex_descriptor, double> > coord2_map(coord2); properties.property("coord2", coord2_map); // typedef graph_traits<Graph>::edge_descriptor edge_descriptor; properties.property("length", get(edge_length, g)); boost::read_graphml(input, g, properties); } It runs fine, but when I compile it, I get the following warning: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/ext/new_allocator.h: In member function 'std::pair<boost::any, bool> boost::mutate_graph_impl<MutableGraph>::do_add_edge(boost::any, boost::any) [with MutableGraph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::no_property, boost::property<edge_length_t, double, boost::no_property>, boost::no_property, boost::listS>]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/ext/new_allocator.h:106: warning: 'p$m_value' is used uninitialized in this function I suppose this is nothing bad? Is there a good way to use a "dummy map" which does not store anything? Any comments on the code are highly appreciated ...

3 4

Re: [Boost-users] [BOOST] Lots of warnings with custom config
by Guy Létourneau 10 Oct '06

10 Oct '06

Thanks John, removing -Wundef from the central build script does the job. Guy -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Tuesday, October 10, 2006 1:42 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [BOOST] Lots of warnings with custom config Guy Létourneau wrote: > I'm using Boost in an embedded environment (eCos). The processor > architecture is Power PC. Since this target is not one of the > "basic" targets supported by Boost, I had to skip the automatic > configuration using bjam (I'm doing cross-compilation using Eclipse, > and a custom version of gcc targeting eCos). I managed to have Boost > work on my hardware but I'm getting a lot of warnings (> 200) when > compiling my project. These warnings are all of the same type: > > > > ../boost_1_33_1/includeFiles/boost/aligned_storage.hpp warning: > "BOOST_MSVC" is not defined > > ../boost_1_33_1/includeFiles/boost/archive/add_facet.hpp warning: > "BOOST_DINKUMWARE_STDLIB" is not defined > > ../boost_1_33_1/includeFiles/boost/detail/call_traits.hpp warning: > "__BORLANDC__" is not defined > > ../boost_1_33_1/includeFiles/boost/function.hpp warning: "__IBMCPP__" > is not defined > > > > And so forth. Because I didn't use bjam, all those prepro variables > aren't defined. I'm using BOOST_NO_CONFIG in user.hpp as this setup > seems to work fine in my environment (except for the warnings). > Bottom line, I would like to know how to define those variables > and/or what switch in the Boost config would be necessary so that my > compiler stops complaining about them. It's probably an easy one for > you Boost gurus but I still haven't found the correct way to solve > that. You should *not* be defining those: they are compiler specific defines, the only way to suppress those would be to change the warning level of your compiler: there should be an option in gcc to disable that warning. John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[BOOST] Lots of warnings with custom config
by Guy Létourneau 10 Oct '06

10 Oct '06

Hi, I'm using Boost in an embedded environment (eCos). The processor architecture is Power PC. Since this target is not one of the "basic" targets supported by Boost, I had to skip the automatic configuration using bjam (I'm doing cross-compilation using Eclipse, and a custom version of gcc targeting eCos). I managed to have Boost work on my hardware but I'm getting a lot of warnings (> 200) when compiling my project. These warnings are all of the same type: ../boost_1_33_1/includeFiles/boost/aligned_storage.hpp warning: "BOOST_MSVC" is not defined ../boost_1_33_1/includeFiles/boost/archive/add_facet.hpp warning: "BOOST_DINKUMWARE_STDLIB" is not defined ../boost_1_33_1/includeFiles/boost/detail/call_traits.hpp warning: "__BORLANDC__" is not defined ../boost_1_33_1/includeFiles/boost/function.hpp warning: "__IBMCPP__" is not defined And so forth. Because I didn't use bjam, all those prepro variables aren't defined. I'm using BOOST_NO_CONFIG in user.hpp as this setup seems to work fine in my environment (except for the warnings). Bottom line, I would like to know how to define those variables and/or what switch in the Boost config would be necessary so that my compiler stops complaining about them. It's probably an easy one for you Boost gurus but I still haven't found the correct way to solve that. Thanks for your help, Guy Letourneau

2 1

Statistical Distributions / Mathematical Special Functions: revised URL's
by John Maddock 10 Oct '06

10 Oct '06

Since some people have had problems accessing the previous URL's given, the library is now available from the following locations: www.johnmaddock.co.uk/toolkit Or http://freespace.virgin.net/boost.regex/toolkit/index.html Or Go to the Boost Vault at http://boost-consulting.com/vault and cd into the "Math - Numerics" directory. Note that the code and documentation are separate downloads. In addition there is the subset of Boost-1.34 used by the lib here: http://freespace.virgin.net/boost.regex/toolkit/miniboost.zip Please note that the lib will not build with Boost-1.33.1 since it uses some parts of Boost.TR1. And finally... Bleeding edge cvs access is available via the Boost-Sandbox: http://sourceforge.net/projects/boost-sandbox/ Once you have checked out the sandbox you will need to do a: cvs update -r math_toolkit at which point everything should disappear except the current math-toolkit code. Regards, John Maddock.

2 2

[Serialization]Why does serialization make use of two step initialization?
by tankbattle 10 Oct '06

10 Oct '06

I'm using boost::serialization now and, indeed, it is very powerful, especially in type identification and object tracking, which make me very convenient. However, I think the lack of construction-time deserialization a pitfall. Usually the semantic of constructor is that either the constructed object is valid or an exception is thrown. However, boost::serialization require programmers provide a default constructor to construct an empty object and a load method (or serialize) to really initialize the object. Such a mechanism cannot prevent from invoking load method other than one time. What’s more, the default constructor usually lacks information to completely initialize the object, sometimes, it is even impossible to initialize. For instance, class B { public: void operator() (){…} } class A { private: B* pB; boost::thread m_theThread;//make use of pB->operator() as the entry point }; In the code above, pB in A cannot be correctly initialized in default constructor, but m_theThread MUST be initialized there. What entry point should we provide to m_theThread? I think serialization mechanism (especially deserialization part) should be provided for constructors. A tricky problem is how can constructor-time deserialization be coherent with that in “load” method and however can we eliminate duplicate code is another issue.

2 1

#include directives
by Louis Lavery 10 Oct '06

10 Oct '06

Just curious as to why boost mixes its #include directives. For instance in boost/any.hpp we have... #include "boost/config.hpp" #include <boost/throw_exception.hpp> ...(this is from boost_1_32_0). Thanks, Louis.

3 5

Enforcing CRTP with the MPL?
by Stefan Schild 09 Oct '06

09 Oct '06

Hi there Having a templatized base class B template<class T> class B ..... is it possible to enforce that a class D can derive from B IF AND ONLY IF the curiously recurring template pattern is applied, that is class D1 : public B<D1> ... // ok, compile class D2 : public B<X> ... // not ok, do not compile ??? Thx Stefan

5 8