- Boost-users - lists.boost.org

nary_tree ... does one exist?
by Robert Dailey 15 Oct '08

15 Oct '08

Hi, I noticed that there's a Google SOC 2006 library called Boost.Tree, which has an nary_tree implementation in it. However, I'm finding that this code does not compile at all. Are there any containers in boost (or perhaps elsewhere) that support tree structures with any number of children? Thanks.

2 1

build variant output directory
by Sebastian Hauer 15 Oct '08

15 Oct '08

Hello, I was just wondering if there is some way of defining a variant's build output directory. The current build output directory nesting is just to deep for my project. Since I only have one debug variant and one release variant having a simple build output directory like: bin/debug bin/release would completely suffice. But instead boost build insists on storing everything in directories based on the selected feature set: bin\msvc-8.0\debug\threading-multi bin\msvc-8.0\release\debug-symbols-on\threading-multi Also notice the additional debug-symbols-on in the release build path since I selected to enable debug symbols for release builds. Regards, Sebastian

5 7

Re: [Boost-users] return type of boost::iostreams::stream<T>::read()
by Struebing, Axel, le-tex 15 Oct '08

15 Oct '08

Hallo Éric, although it is not an exact fit it will be of value in evaluating my options. kind regards Axel Strübing > > Reading the documentation about boost::iostreams library I could not > > find the information which return type the boost::iostreams::stream's > > class is giving me calling read(). > > > >From the documentation, a boost::iostreams::stream derives from an > > std::basic_[i|o]stream, depending on the model of its underlying Device. > > In your example, the device is a Source, so I guess that the stream > > derives from std::basic_istream, whose read(char*, streamsize) method > > returns a basic_istream, not a streamsize. > > The library offers the "streamsize read(stream, char*, streamsize)" > function template. Using it in your example yould give something like (not > tested): > > #include <boost/iostreams/stream.hpp> > #include <boost/iostreams/device/file.hpp> > #include <boost/iostreams/operations.hpp> > > int main(void){ > namespace bio = boost::iostreams; > bio::stream<bio::file_source> istr(std::string("in.pdf")); > char buffer[10]; > std::streamsize i = bio::read(istr,buffer,10); > return 0; > } > > > HTH, > > Éric Malenfant > --------------------------------------------- > Two wrongs don't make a right but three rights make a left. > --

1 0

compilation problem with intel 10.1 and boost
by Hicham Mouline 15 Oct '08

15 Oct '08

Hello, I have a similar problem to this post: http://lists.boost.org/MailArchives/ublas/2008/09/2979.php though i am not using ublas at all. Linux 2.6.18-53.1.19.el5 #1 SMP Tue Apr 22 03:01:10 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 5.1 (Tikanga) Intel(R) C++ Compiler for applications running on Intel(R) 64, Version 10.1 Build 20080312 Package ID: l_cc_p_10.1.015 i have the released 1.36, haven't patched anything, regards,

2 1

MPL: Arguments to transform metafunction
by Missing Rainbow 15 Oct '08

15 Oct '08

Hi All, I have a doubt regarding the arguments to the mpl::transform metafunction. In the MPL book (page 42), the mpl::transform is presented as follows: template <class Sequence1, class Sequence2, class BinaryOperation> struct transform; Here mpl::transform takes 2 sequences and a binary operation and it results in a sequence. But in a later portion of the book (page 124), while discussing about sequence building algorithms, the following is presented: typedef mpl::vector_c<int, 1, 2, 3> v123; typedef mpl::plus<_1, mpl::int_<5> > add5; typedef mpl::transform<v123, add5>::type v678; Here mpl::transform takes 1 sequence and a unary operation and it results in a sequence. How does mpl::transform supports such different arguments? Rgds, anna

2 1

boost::program options - why not allow_unregistered() for environmental variable parser?
by Ivan Godard 15 Oct '08

15 Oct '08

Vladimir Prus wrote: > > The environment seems to be the one place that is guaranteed to have > > unregistered options, because it is full of things (like > > $LD_LIBRARY_PATH) of no interest to the program doing the parsing. A > > call on parse_environment always throws on these. As far as I can see in > > the code, the way to avoid the throw is to pass parse_enviroment a > > function that checks for each of the options that are actually wanted > > and returns the null string for the rest. Of course, this duplicates > > what the parser just did. > > > > Is there a better way? > The recommended way is to use some name prefix for environment variables affecting your program -- say MY_PROG_. Then, pass this prefix to parse_environement and all variables without that prefix will be ignored. Does this help? - Volodya Unfortunately no. My code must interact with a large third-party application with a ton of environmental variables that follow no particular naming convention, and I wanted to integrate the probe for those variables with my own command line so I could accept the environment as default but overwrite them from the command line using the same names (which are already documented by the third party and mostly familiar to the users). Having no accept_unregistered precludes that approach, and I have to use getenv() and do it by hand instead. It's not a hard workaround, just a day or two of work, but lacking accept_unregistered for only one of the three kinds of parser seems odd given the general elegance of the rest of your library. Ivan

1 0

[program_options] maps as arguments
by Christoph Duelli 15 Oct '08

15 Oct '08

Does program_options somehow support something like --base x=hello --base y=world where the parsed "--base"s will be put in a std::map<std::string, std::string> (or std::map<X,Y> in the general case?) (At the moment I parse --base into a vector<string> and process the read strings after program_options has done its job.) Thank you, Christoph

2 1

[threads] How to test for running thread
by Koen Vermeer 15 Oct '08

15 Oct '08

Hi, Suppose I have a thread running, I issue an interrupt(), and the thread starts to perform its cleanup code. As this may take some time, I'd like to know when the thread actually is stopped. Is there some standard approach on how to do this? I was thinking about testing if the thread object equals Not-a-Thread, but I've yet to find out how... Thanks! Koen

2 4

how to expose an stl vector class porperty
by Massimiliano Bellomo 15 Oct '08

15 Oct '08

Dear all, i've a property of a class which is a std::vector<Foo*> that i would like to expose to python. Foo is a class already exposed. How do i implement the setter/getter methods for the vector property and declare them in the python module ? Many thanks, regards, Max -- --------------------------------------- Massimiliano Bellomo Dep. of Nuclear and Theoretical Physics INFN Pavia - +39 0382 987 234 ---------------------------------------

1 0

boost::program options - why no allow_unregistered() for environmental variable parser?
by Ivan Godard 15 Oct '08

15 Oct '08

The environment seems to be the one place that is guaranteed to have unregistered options, because it is full of things (like $LD_LIBRARY_PATH) of no interest to the program doing the parsing. A call on parse_environment always throws on these. As far as I can see in the code, the way to avoid the throw is to pass parse_enviroment a function that checks for each of the options that are actually wanted and returns the null string for the rest. Of course, this duplicates what the parser just did. Is there a better way? Ivan

2 1