November 2010 - Boost-users - lists.preview.boost.org

Conversion warning from boost/functional/hash/detail/hash_float_generic.hpp
by Greg Ward 11 Dec '10

11 Dec '10

Hi all -- I'm getting a strange warning from <boost/functional/hash/detail/hash_float_generic.hpp>. What's strange is not the warning, but the circumstances: if I use the boost headers installed in /usr/include, no warning. But if I make a copy of /usr/include/boost and tell the compiler to use the copy, I get a warning. I can reproduce this on CentOS 5 using our custom build of GCC 4.4.4 and boost 1.44.0, and on Ubuntu 10.04 (lucid) using Ubuntu's builds of GCC 4.4.3 and boost 1.40.0. It doesn't take much code to reproduce the problem: $ cat test.cpp #include <boost/functional/hash.hpp> First, a good build using Ubuntu /usr/bin/g++ (4.4.3) and /usr/include/boost (1.40.0) $ /usr/bin/g++ -Wall -Wconversion -c test.cpp -o test.o [no warnings] Now let's make a copy of the boost headers and use the copy: $ mkdir include $ cp -rp /usr/include/boost include/. $ /usr/bin/g++ -Wall -Wconversion -I include -c test.cpp -o test.o In file included from include/boost/functional/hash/detail/hash_float.hpp:30, from include/boost/functional/hash/hash.hpp:15, from include/boost/functional/hash.hpp:6, from test.cpp:1: include/boost/functional/hash/detail/hash_float_generic.hpp: In function ‘size_t boost::hash_detail::float_hash_impl2(T) [with T = float]’: include/boost/functional/hash/detail/hash_float_generic.hpp:84: instantiated from ‘size_t boost::hash_detail::float_hash_impl(T) [with T = float]’ include/boost/functional/hash/detail/hash_float.hpp:74: instantiated from ‘size_t boost::hash_detail::float_hash_value(T) [with T = float]’ include/boost/functional/hash/hash.hpp:282: instantiated from here include/boost/functional/hash/detail/hash_float_generic.hpp:59: warning: conversion to ‘float’ from ‘size_t’ may alter its value include/boost/functional/hash/detail/hash_float_generic.hpp:84: instantiated from ‘size_t boost::hash_detail::float_hash_impl(T) [with T = float]’ include/boost/functional/hash/detail/hash_float.hpp:74: instantiated from ‘size_t boost::hash_detail::float_hash_value(T) [with T = float]’ include/boost/functional/hash/hash.hpp:282: instantiated from here include/boost/functional/hash/detail/hash_float_generic.hpp:71: warning: conversion to ‘float’ from ‘size_t’ may alter its value I get the same behaviour if include/boost is a symlink to /usr/include/boost. Changing "-I include" to an absolute path ("-I `pwd`/include") makes no difference. If I repeat the experiment on my CentOS 5 machine with custom builds of more recent versions of GCC (4.4.4) and boost (1.44.0), I see the same thing. The line numbers are slightly different: In file included from include/boost/functional/hash/detail/hash_float.hpp:30, from include/boost/functional/hash/hash.hpp:15, from include/boost/functional/hash.hpp:6, from test.cpp:1: include/boost/functional/hash/detail/hash_float_generic.hpp: In function ‘size_t boost::hash_detail::float_hash_impl2(T) [with T = float]’: include/boost/functional/hash/detail/hash_float_generic.hpp:82: instantiated from ‘size_t boost::hash_detail::float_hash_impl(T) [with T = float]’ include/boost/functional/hash/detail/hash_float.hpp:74: instantiated from ‘size_t boost::hash_detail::float_hash_value(T) [with T = float]’ include/boost/functional/hash/hash.hpp:315: instantiated from here include/boost/functional/hash/detail/hash_float_generic.hpp:56: warning: conversion to ‘float’ from ‘size_t’ may alter its value include/boost/functional/hash/detail/hash_float_generic.hpp:82: instantiated from ‘size_t boost::hash_detail::float_hash_impl(T) [with T = float]’ include/boost/functional/hash/detail/hash_float.hpp:74: instantiated from ‘size_t boost::hash_detail::float_hash_value(T) [with T = float]’ include/boost/functional/hash/hash.hpp:315: instantiated from here include/boost/functional/hash/detail/hash_float_generic.hpp:69: warning: conversion to ‘float’ from ‘size_t’ may alter its value but obviously the trace through the header files is basically the same. Any clues? Google did not turn up any similar problems from anyone else. Oh yeah: if you're wondering why I want to use a copy of (or symlink to) the real boost installation, it's because we need to support building many different versions of our software, and they don't all use the same versions of boost or gcc (or various other 3rd-party components). So each build tree has a bunch of local symlinks pointing to exactly the right versions of gcc, boost, etc. Thanks! Greg

2 3

Range - Char literal question
by Rao, Anant 10 Dec '10

10 Dec '10

Hi, I need to iterate thru strings (For various reasons, I can't use string or vector<char> containers). I found that boost::range exactly fits the bill for me. I get all the convenience of an iterator (from as_literal.hpp). I have a piece of code char* char_s = "I am fine"; char *cp; std::size_t sz = strlen(char_s); const char* str_end1 = str_begin( char_s ) + sz; for (cp = str_begin(char_s); cp != str_end(char_s); ++cp) cout << *cp; I have couple of questions: 1. In the loop, boost::range seems to be calling strlen every iteration. This is an overhead. I was wondering if there's a way I can pass in the length myself so that boost::range would use it and avoid calling strlen(). 2. If it's not possible, is there a way for me to use iterators (boost or non-boost) over char strings? Thanks so much in advance for your help, Anant The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message.

7 15

[statechart] optional<event> - warning
by Igor R 07 Dec '10

07 Dec '10

Hello, When I define optional<my_event>, I get a warning (MSVC10): warning C4291: 'void *boost::statechart::event<MostDerived>::operator new(size_t,void *)' : no matching operator delete found; memory will not be freed if initialization throws an exception In class statechart::event I see 2 overloads of operator new: void * operator new( std::size_t size ) void * operator new( std::size_t, void * p ) But only 1 operator delete: void operator delete( void * pEvent ) i.e., no placement delete. Is this intentional? Thanks.

2 4

Runtime identity
by Robert Jones 04 Dec '10

04 Dec '10

I'm not sure if this is a stupid question, but is there a runtime equivalent of boost.mpl's identity metafunction? Something that just returns it's single argument, eg., template <typename T> T identity( T t ) { return t; } I think it's trivially simple to write, but I wonder if it already exists in Boost or indeed the STL? (I need this because I need to pass a function object which simply returns an object I already have - maybe I've missed a more obvious method?) Thx, Rob.

5 7

[Spirit 2] Questions related to generating grammars meta-dynamically
by Max Motovilov 03 Dec '10

03 Dec '10

I'm trying to create a serialization facility that builds the underlying Spirit grammars based on a data model extracted from user-supplied types (I guess meta-dynamically ought to be the right word :) ). In doing so, I seem to quickly run out of documentation coverage and accumulate questions that are not easily answered by perusing the source code. Here are the more painful members of that collection, posted in the hopes that someone more informed might answer them for me: - What are the respective scopes of the rule and the grammar? Specifically, within a parser expression (situated within a grammar's constructor, according to the pattern established in the examples) which of the locals<> can I refer to in the sub-expressions specifying explicit parser parameters and semantic actions? - I'd like to write a functor that selects one of the grammars from a list (Fusion sequence), and passes an argument (inherited attribute) to it; the [parser-like] result returned by this functor would then be used in an enclosing parser expression. Is there an easily computable type that such a functor can return? I have noticed that the implementations of grammar<>::operator() return a very intricate construct that would be hard to replicate outside Spirit code -- proto::terminal< spirit::qi::parameterized_nonterminal< start_type, supplied-argument-types... > > -- but maybe there is a simpler front-end type the above is convertible to and that will still work as a component of parser expression? Thanks in advance, ...Max...

4 6

[Units] unary minus on units is counter intuitive (or a bug)
by alfC 03 Dec '10

03 Dec '10

Hi, I found this counterintuitive result of applying the unary minus operator to a unit "- si::meter" is the same as "si::meter" (or any other unit). or worst std::cout << - si::meter*1. << std::endl; // prints 1*m i.e. the minus is explicitly ignored. The root of the problem is this curious line in boost/units/unit.hpp /// unit runtime unary minus template<class Dim,class System> typename unary_minus_typeof_helper< unit<Dim,System> >::type operator-(const unit<Dim,System>&) { typedef typename unary_minus_typeof_helper< unit<Dim,System> >::type type; return type(); } a more intuitive result (but not completely elegant) could be attained by defining instead: template<class Dimension, class System> quantity<unit<Dim, System> > operator-(unit<Dim, System> const& u){ return -1.*u; } This is a definition that I could add BUT it will conflict with the original definition. Another way, could be to specialize unary_minus_typeof_helper<...>::type to be something that is not a unit but holds the negative "direction" and the cast to Type(-1)*unit quantity but it seems overly complicated for the purpose. Note aside: Why would I need "minus units" in the first place? The original code that produced the confusion was - kB*T which appears commonly in physics. kB is the "atomic" unit of entropy/ specific heat (atomic::heat_capacity) and T is a temperature quantity. This was parsed as (-kB)*T and then as kB*T i.e. the minus sign was ignored all together. In my opinion unary operator- should not be defined for units in the first place. The current definition only makes things worst, by creating a counter intuitive result AND making the fix conflict with the definition. Thoughts? Thank you, Alfredo

3 2

mpi non-blocking communication
by Kraus Philipp 02 Dec '10

02 Dec '10

Hello, I have some problems with the MPI non-blocking communication, but I can be a thinking error. The CPU 0 (rank 0) creates a loop with this: while (true) { std::string l_str; p_com.irecv( mpi::any_source, LOGGER_MPI_TAG, l_str ); } p_com is the commuicator object. All other CPUs (!= 0) can send a message to CPU 0, which should be received. The CPUs (!=0) can send a message, but they need not, so I would create this with non-blocking communication. At this time my l_str is alway empty, so it seems that the message, that are send, not transmittet, received or not inserted into l_str. I hope the problems is described in a clear way. I would like that the CPU 0 can receive message of there are some and all other CPUs can send messages. Thanks Phil

3 14

Valgrind false positive in make_shared
by Dave Steffen 01 Dec '10

01 Dec '10

> Date: Thu, 18 Nov 2010 19:51:55 +0200 > From: "Peter Dimov" <pdimov(a)pdimov.com> > > Dave Steffen wrote: > > I got this bad behavior with GCC 4.4.4. It goes away with GCC 4.2.4. > > What is the definition of std::forward in GCC 4.4.4? What happens if you > > change boost::detail::sp_forward in make_shared.hpp:150: > ::new( pv ) T( boost::detail::sp_forward<Arg1>( arg1 ), > > boost::detail::sp_forward<Args>( args )... ); > > to std::forward, do you get a compile warning on this line and does > Valgrind still warn? Hi Coming back to this issue after a week or two... trying the above made no difference: no compiler warnings, and no change in Valgrind's error messages. Any thoughts? Thanks! -- Dave Steffen, Ph.D. - Software Engineer Numerica Corporation <http://www.numerica.us> 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 x 227 direct (970) 612-2327 Email: dave.steffen(a)numerica.us fax (970) 461-2004 This message and any attachments are intended only for the individual or entity to which the message is addressed. This is a private message and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify me immediately by returning this email to me and deleting it from your computer.

2 4

[BGL] Searching for a convenient way to combine predicates for filtered_graph
by Cedric Laczny 01 Dec '10

01 Dec '10

Hi, I was wondering if there is a convenient (and to some extent intuitive) way to combine several predicates used in filtering a graph? The idea is to have some predicates defined and arbitrarily combine them so that the filtered_graph will check for compliance of each individual predicate and either make this vertex/edge visible or not. Of course, the predicates should be specific to vertices or edges, respectively, when being combined. When using std::vector or such, they would need to be all of the same type which does not seem very nice/feasible IMHO. Also defining a "big" predicate having a multitude of "smaller" predicates as members is not really an option as this is very restricted. Something like big_predicate = predicate1 || predicate2 || predicate3 (syntax should just illustrate the idea) maybe? Best, Cedric

3 9

[BGL] reverse_graph and filter_graph does not compile on 1.45
by gast128 01 Dec '10

01 Dec '10

Hello all, we got here a situation on VS2008 which did compile on 1.44 with a reverse graph of a filtered graph. I get constantly a f*cking 'You seem to be top-posting. Don't do that.' error from gmane, so I give up to include a reproducable case. It's easy to do it urself by making a construct like 'boost::make_reverse_graph (fgraph), where fgraph is a fitlered graph.' Anyone?

2 4