First problems with 1.30.0
I am trying new 1.30.0 release and got couple of problems on MSVC6 SP5. First of all, compiling #include <boost/date_time/gregorian/gregorian.hpp> int main() { boost::gregorian::from_string( "" ); return 0; } yields warning: I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_stream<int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char>
::operator <<(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &)'
Much bigger problem is that compiling simple #include <boost/random/uniform_01.hpp> int main(){return 0;} fails with: I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp(44) : error C2275: 'std::numeric_limits<`template-parameter258'>::is_integer' : illegal use of this type as an expression I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp (95) : see reference to class template instantiation 'boost::uniform_01<UniformRandomNumberGenerator,RealTyp e>' being compiled I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp(44) : error C2027: use of undefined type 'STATIC_ASSERTION_FAILURE' I:\SW\EXTERNAL\BOOST_1_30_0\boost/static_assert.hpp(29) : see declaration of 'STATIC_ASSERTION_FAILURE' I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp (95) : see reference to class template instantiation 'boost::uniform_01<UniformRandomNumberGenerator,RealTyp e>' being compiled
I am trying new 1.30.0 release and got couple of problems on MSVC6 SP5.
First of all, compiling
#include <boost/date_time/gregorian/gregorian.hpp> int main() { boost::gregorian::from_string( "" ); return 0; }
yields warning:
I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_stream<int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char>
::operator <<(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &)'
I'm not sure what this would do on 1.29 b/c there have been lots of changes to lexical_cast. Of course I'm assuming this is an 'example' because with a blank string your program will core dump with an unhandled exception that occurs when it tries to construct a date from a blank string. Jeff
--- In Boost-Users@yahoogroups.com, "Jeff Garland" <jeff@c...> wrote:
I'm not sure what this would do on 1.29 b/c there have been lots of changes to lexical_cast. Of course I'm assuming this is an 'example' because with a blank string your program will core dump with an unhandled exception that occurs when it tries to construct a date from a blank string.
Yes, it was a stripped down example. Obviously replacing string constant with something meaningful will not affect compilation anyhow.
In article <b5d5s1+mve4@eGroups.com>, klapshin <klapshin@yahoo.com> writes
I am trying new 1.30.0 release and got couple of problems on MSVC6 SP5.
First of all, compiling
#include <boost/date_time/gregorian/gregorian.hpp> int main() { boost::gregorian::from_string( "" ); return 0; }
yields warning:
I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_stream<int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char>
::operator <<(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &)'
Is the runtime behaviour correct? Have you been able to reproduce the warning with a smaller example based just on lexical_cast? Thanks, Kevlin. ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________
Dear Group, trying for several days, I simply don't get the correct usage of internal property maps and the connected_components algorithm. My graphs are very large (about 600 000 vertices), so that I am using internal instead of external property maps. Looking at one of Jeremy's postings (http://lists.boost.org/MailArchives/boost/msg15114.php) I defined my graph as follows: namespace boost { enum vertex_component_t {vertex_component = 113 }; BOOST_INSTALL_PROPERTY(vertex, component); } typedef typename boost::adjacency_list< boost::listS, //edges boost::listS, //nodes boost::undirectedS, //vertex properties boost::property<boost::vertex_name_t, std::string, //the name of the protein boost::property<boost::vertex_component_t, int > > > // no edge properties > Graph; The code that uses internal property maps as an argument to compute_components comes below (actually, I am not sure whether this is a connected_components problem at all). typedef boost::property_map<Graph, boost::vertex_component_t>::type ComponentPropertyMap; ComponentPropertyMap component = boost::get(boost::vertex_component,g); int components_num = boost::connected_components(g,component); This looks quite straightforward and is in line with what Jeremy has posted. But I get the following compiler errors (using Boost 1.29 and gcc 3.2): [snip] /project/algorithmics/include/boost/property_map.hpp:344: no match for `const __gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >& + const boost::detail::error_property_not_found&' operator What is going wrong? Do I have to use a color_type_t (Why? How?)? Any help is very welcome... Many thanks in advance Martin -- ----------------------------------------------------------------------------- Martin Okrslar MPI for Molecular Genetics phone: ++ 49 + 30 / 8413-1166 Computational Molecular Biology Fax: ++ 49 + 30 / 8413-1152 Ihnestrasse 73 email: okrslar@molgen.mpg.de D-14195 Berlin URL: http://cmb.molgen.mpg.de -----------------------------------------------------------------------------
On Friday 21 March 2003 08:49 am, Martin Okrslar wrote:
typedef typename boost::adjacency_list< boost::listS, //edges boost::listS, //nodes boost::undirectedS, //vertex properties boost::property<boost::vertex_name_t, std::string, //the name of the protein boost::property<boost::vertex_component_t, int >
// no edge properties
> Graph; [snip] /project/algorithmics/include/boost/property_map.hpp:344: no match for `const __gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >& + const boost::detail::error_property_not_found&' operator
What is going wrong? Do I have to use a color_type_t (Why? How?)?
The connected components algorithm uses a color map for internal storage. If you don't supply a color map, it tries to build a default color map using the vertex index property. That's where this is failing: when the vertex list type is listS, there is no default vertex_index property, so the code fails. There are a few fixes to this: 1) [the easy way]. Use a vector for the vertices, with a Graph definition like this: typedef typename boost::adjacency_list< boost::listS, //edges boost::vecS, //nodes boost::undirectedS, //vertex properties boost::property<boost::vertex_name_t, std::string, boost::property<boost::vertex_component_t, int > // no edge properties > Graph; 2) [the slightly harder way]. Add a vertex_index property for vertices, and keep that updated. So the Graph definition would look like this: typedef typename boost::adjacency_list< boost::listS, //edges boost::listS, //nodes boost::undirectedS, //vertex properties boost::property<boost::vertex_name_t, std::string, boost::property<boost::vertex_component_t, int, boost::property<boost::vertex_index_t, int> > > // no edge properties > Graph; But you'll have to manually assign the vertex indices: Graph::vertex_iterator v,ve_end; int i = 0; for(boost::tie(v, v_end) = vertices(g); v != v_end; ++v, ++i) { put(boost::vertex_index, g, *v, i); } 3) [slightly harder yet way]. Create your own color map, where the key type is a Graph::vertex_descriptor and the value_type is boost::default_color_type. Doug
Thanks a lot for your help! But (just in order to learn more about my beloved BGL):
The connected components algorithm uses a color map for internal storage. If you don't supply a color map, it tries to build a default color map using the vertex index property. That's where this is failing: when the vertex list type is listS, there is no default vertex_index property, so the code fails.
Is there any way I could have known that from the documentation? I mean, this is by no means an accusation, but I'd just like to be able to learn to work through the BGL without having to anoy the list with lots of question. I still think that I missed something. If this is so, please let me know. By the way: BGL saved me so much time... I can't even tell you...
all the best Martin -- ----------------------------------------------------------------------------- Martin Okrslar MPI for Molecular Genetics phone: ++ 49 + 30 / 8413-1166 Computational Molecular Biology Fax: ++ 49 + 30 / 8413-1152 Ihnestrasse 73 email: okrslar@molgen.mpg.de D-14195 Berlin URL: http://cmb.molgen.mpg.de -----------------------------------------------------------------------------
On Mon, 24 Mar 2003, Martin Okrslar wrote:
Thanks a lot for your help!
But (just in order to learn more about my beloved BGL):
The connected components algorithm uses a color map for internal storage. If you don't supply a color map, it tries to build a default color map using the vertex index property. That's where this is failing: when the vertex list type is listS, there is no default vertex_index property, so the code fails.
Is there any way I could have known that from the documentation? I mean, this is by no means an accusation, but I'd just like to be able to learn to work through the BGL without having to anoy the list with lots of question. I still think that I missed something.
It's there, but it's not obvious. Under the "named parameters" section there is a UTIL parameter called color map. UTIL parameters are neither input nor output, but are needed for the algorithm to execute. The default for color_map is an iterator_property_map that uses the IN parameter vertex_index_map. The default for vertex_index_map is get(vertex_index, g), which returns an invalid property map for your graph. Not obvious at all :) Doug
--- In Boost-Users@yahoogroups.com, Kevlin Henney <kevlin@c...> wrote:
Is the runtime behaviour correct? Have you been able to reproduce the warning with a smaller example based just on lexical_cast?
I have not tried to run program yet because of much bigger problems with random library -- it simply fails to compile (see my original post). Reproducing warning with lexical cast is straightforward: #include <boost/lexical_cast.hpp> #include <iostream> int main() { std::cout << boost::lexical_cast<int>("7") << std::endl; return 0; } reports the same warning I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_stream<int,char *>::operator <<(char *const & )' Runtime behaviour of this program is correct. The warning is rather innocent, but annoying. Moreover the warning is abolutely correct -- returning stream from method with bool return type will convert void* to bool. Also it should be rather easy to fix, by explicitely casting it to bool.
From: "klapshin" <klapshin@yahoo.com>
--- In Boost-Users@yahoogroups.com, Kevlin Henney <kevlin@c...> wrote:
Is the runtime behaviour correct? Have you been able to reproduce the warning with a smaller example based just on lexical_cast?
I have not tried to run program yet because of much bigger problems with random library -- it simply fails to compile (see my original post).
Reproducing warning with lexical cast is straightforward:
#include <boost/lexical_cast.hpp> #include <iostream> int main() { std::cout << boost::lexical_cast<int>("7") << std::endl; return 0; }
reports the same warning
I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) I:\SW\EXTERNAL\BOOST_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_stream<int,char *>::operator <<(char *const & )'
Runtime behaviour of this program is correct. The warning is rather innocent, but annoying. Moreover the warning is abolutely correct -- returning stream from method with bool return type will convert void* to bool. Also it should be rather easy to fix, by explicitely casting it to bool.
This issues has also been reported on the developer list, and I've mentioned the same possible fix there (explicit cast). Regards, Terje
participants (7)
-
Douglas Gregor -
Douglas Paul Gregor
-
Jeff Garland -
Kevlin Henney -
klapshin -
Martin Okrslar -
Terje Slettebø