- Boost-users - lists.boost.org

stream + file_descriptor_source + closing
by Tomasz Noiński 30 Jul '07

30 Jul '07

Hi, I'm trying to use boost::iostreams for a project I'm writing and I have a problem: It seems that the destructor of boost::iostreams::stream<boost::iostreams::file_descriptor_source> closes the file descriptor. I really need to be able to close this file descriptor manually and I can't find any way to do it. Note that file_descriptor_source has a constructor parameter specifying if the descriptor should be closed in file_descriptor_source destructor or not. It perfectly works - it's boost::iostreams::stream destructor that forces closing the description, not file_descriptor_source destructor. A short code illustrating this problem (for Linux): --- 8< --- #include <iostream> #include <boost/iostreams/device/file_descriptor.hpp> #include <boost/iostreams/stream.hpp> #include <cstring> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <errno.h> using namespace std; using namespace boost::iostreams; int main() { int fd = open("/etc/fstab", O_RDONLY); clog << "fd=" << fd << endl; { file_descriptor_source source(fd, false); stream<file_descriptor_source> strm(source); string s; strm >> s; clog << "first line: " << s << endl; } int closeRet = close(fd); int closeErrno = errno; clog << "closing result: " << closeRet << ", " << strerror(closeErrno) << endl; } --- 8< --- The behaviour I would expect is the close() at the end succeeding. However, it returns -1 with errno=EBADF. Is this the expected behaviour or a bug? TIA, Noix

1 0

boost thread read_write_mutex
by Fei Liu 30 Jul '07

30 Jul '07

Just a question, I don't see any big bold note that the related read/write mutex or locks should not be used...What's the story of reader/writer's mutex in boost::thread? Fei

2 1

[Boost.Graph] Compiler warning in dijkstra_shortest_paths
by Ewgenij Sokolovski 30 Jul '07

30 Jul '07

Hello. I use the Boost.Graph with the dijkstra_shortest_paths algorithm in my graph application. All works fine. But while compiling with the options -Wall -W I get a strange compiler warning: /usr/include/boost/graph/dijkstra_shortest_paths.hpp:80: Warning: »bfs_vis$m_decreased« is used in this function uninitialised This was the last line of the warning because it is quite long in its complete version. I translated the line above from German because I use a German version of g++, so maybe it sounds in the English version a little bit different. But the meaning remains the same:) Does anybody know what that is supposed to mean? Is something wrong with my program or is it a bug in dijkstra_shortest_paths? Here is the warning in the complete version: /usr/include/boost/graph/dijkstra_shortest_paths.hpp: In function »void boost::detail::dijkstra_dispatch2(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, DistanceMap, WeightMap, IndexMap, const Params&, ColorMap) [with VertexListGraph = boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::no_property, float, boost::no_property, boost::listS>, DistanceMap = float*, WeightMap = boost::adj_list_edge_property_map<boost::undirected_tag, float, float&, long unsigned int, boost::property<boost::edge_bundle_t, float, boost::no_property>, boost::edge_bundle_t>, IndexMap = boost::vec_adj_list_vertex_id_map<boost::no_property, long unsigned int>, Params = boost::bgl_named_params<boost::adj_list_edge_property_map<boost::undirected_tag, float, float&, long unsigned int, boost::property<boost::edge_bundle_t, float, boost::no_property>, boost::edge_bundle_t>, boost::edge_weight_t, boost::bgl_named_params<float*, boost::vertex_distance_t, boost::no_property> >, ColorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::vec_adj_list_vertex_id_map<boost::no_property, long unsigned int>, boost::default_color_type, boost::default_color_type&>]«: /usr/include/boost/graph/dijkstra_shortest_paths.hpp:80: Warning: »bfs_vis$m_decreased« is used in this function uninitialised Greetings Ewgenij -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

2 1

Problem Bjam
by question boost 30 Jul '07

30 Jul '07

Hi, using Code Blocks i got the folowing message: ld.exe "Cannot find -lboost_filesystem-mgw-mt-s-l_33_l". So I did :cd /jam source location/then build.bat Then, i put the following variables: path=C:\Program Files\CodeBlocks\bin BOOST_BUILD_PATH=C:\Documents and Settings\Administrateur\Bureau\boost_1_33_1\boost_1_33_1\tools\build\v2 BOOST_ROOT=C:\Documents and Settings\src\boost It is not the right things to do => i get the message again. My question is: What are the right things to do in order not to get the message any more? Thank You _________________________________________________________________ Windows Live Messenger vous offre 30 nouvelles émoticônes gratuites, installées directement dans votre Messenger ! http://www.emoticones-messenger.fr/

1 0

How to build only Boost.Iostreams with compression filter support on Windows XP using MinGW
by Benjamin Lau 30 Jul '07

30 Jul '07

Good evening, Pardon my ignorance, or my poor documentation reading skills, but I am unable to build Boost.Iostreams with compression filter support on Windows XP using MinGW. I am using Boost 1.34.1, zlib 1.2.3 and bzip2 1.0.4. I tried the following command lines but to no avail: bjam --toolset=gcc -sNO_COMPRESSION=0 -sNO_BZIP2=0 -sBZIP2_LIBPATH=C:\bzip2-1.0.4 -sBZIP2_SOURCE=C:\bzip2-1.0.4 -sNO_ZLIB=0 -sZLIB_LIBPATH=C:\zlib-1.2.3 -sZLIB_SOURCE=C:\zlib-1.2.3 stage or bjam --toolset=gcc --NO_COMPRESSION=0 --NO_BZIP2=0 --BZIP2_LIBPATH=C:\bzip2-1.0.4 --BZIP2_SOURCE=C:\bzip2-1.0.4 --NO_ZLIB=0 --ZLIB_LIBPATH=C:\zlib-1.2.3 --ZLIB_SOURCE=C:\zlib-1.2.3 stage I searched through the Boost.Iostreams documentation, the Boost.Jam documentation, and the Boost.Build V2 documentation. Boost.Jam documentation indicates that the former should work, but Boost.Build V2 seems to use very little of or not at all of the -s flag for Boost.Jam, so I tried the latter. The result of both commands were the same, Boost.Iostreams was built without the compression filters. However, I do get 12 "warning: Unable to construct ./stage-unversioned" as the first output from Boost.Jam, after which it says "...patience..." and continues with the building process. Thank you in advance for assisting me in my problem, and in case I have missed out something critical yet obvious, and hence resulting in my failure, I apologise for not reading carefully enough. Thank you and have a nice day Benjamin Lau

2 2

Zhang has Tagged you :)
by Zhang Shenpeng 29 Jul '07

29 Jul '07

2 1

[asio] when deadline_timer::cancel() returns
by Yuval Ronen 29 Jul '07

29 Jul '07

The Asio docs for deadline_timer::cancel say that "This function forces the completion of any pending asynchronous wait operations against the timer". Let's say I have a thread executing io_service::run, and is now invoking a completion handler of a deadline_timer. While this completion handler is underway, a second thread is calling cancel() on that deadline_timer. Is the cancel() call supposed to block until the completion handler is finished? To my best understanding, both according to the docs, and according to what seems to be logical to me, the answer is "yes, it should block". However, it doesn't. Is it a bug, or by design? Yuval

1 1

[mpl] what is not a placeholder expression
by "JOAQUIN LOPEZ MU?Z" 29 Jul '07

29 Jul '07

According to the MPL reference, a placeholder expression X<a1,..,an> must satisfy (among others) the following condition: "All of X's template parameters, including the default ones, are types." According to that the following should then compile without errors: #include <boost/mpl/apply.hpp> #include <boost/mpl/assert.hpp> #include <boost/type_traits/is_same.hpp> using namespace boost; using namespace boost::mpl; template<typename T,int=0> struct foo { template<typename Q> struct apply{ typedef Q type; }; }; typedef apply1<foo<_1>,int>::type t1; BOOST_MPL_ASSERT((is_same<t1,int>)); int main(){} However, I've tried with GCC 3.4.4 and the static assertion fails! I'd like to know: 1. Whether I'm right in assuming that the code above should compile without assertion failures. 2. What the behavior is for other versions of GCC and compilers: reports most welcome!! 3. Whether this is a known problem specific to GCC or, more generally, what the status of this issue is. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5

Trac / Register User
by Olaf van der Spek 28 Jul '07

28 Jul '07

On 7/27/07, Chris Weed <chrisweed(a)gmail.com> wrote: > > Where are the links to Trac from http://boost.org/? > > I've been trying to find Trac before but didn't succeed. > > Report Bugs -> Bug tracking facility > > http://svn.boost.org/trac/boost/report Thanks. But where is the register user link? I only see login.

2 3

[BGL] Parameter: CompareFunction - dijkstra_shortest_paths
by Leandro T. C. Melo 28 Jul '07

28 Jul '07

Hello all. It is clear for me the reason for template parameter CombineFunction in dijkstra_shortest_paths. For instance, prim_minimum_spanning_tree makes use of it to correct compute the MST. Basically, in Dijkstra's it is something like this: distance = distance of vertex v + weight of edge e; And in Prim's only the weight is considered: distance = weight of edge e; This is reflected on the argument used for the CombineFunction in Prim's function (from file prim_minimum_spanning_tree.hpp): prim_minimum_spanning_tree(...) { typedef typename property_traits<WeightMap>::value_type W; std::less<W> compare; detail::_project2nd<W,W> combine; dijkstra_shortest_paths(...); } Where _project2nd is: template <class U, class V> struct _project2nd { V operator()(U, V v) const { return v; } }; However, it is not clear the reason of the CompareFunction template parameter (which is a predicate). First, because, I don't see a situation where not using std::less<Some_type> would make any sence, because of the way the Dijkstra's algorithm is constructed. Second, because the value_type of the DistanceMap must be the same of the value_type of WeightMap (according to the documentation). Therefore, why the following two lines of code in Prim's implementation (from the function I pointed at beginning of the email)? typedef typename property_traits<WeightMap>::value_type W; std::less<W> compare; Since, in Dijkstra's algorithm the only difference is that DistanceMap is used as an argument for the definition of the value_type from property_traits. Am I loosing something here? If yes, would anyone explain it to me? Thank you, Leandro.

1 0