July 2010 - Boost - lists.preview.boost.org

[serialization] patching 1.43 for the version numbering issue
by Ryan Gallagher 28 Jul '10

28 Jul '10

Hi Robert, As we were discussing the other day, I'd like to just patch my 1.43 release to fix the serialization library versioning issue so that my archives created with it won't need to have the utility run on them for 1.44+ to understand them. I just want to verify with you that changing the version number in serialization/src/basic_archive.cpp is all that's needed. In your recent trunk change you increased the version for 1.44 to '8': https://svn.boost.org/trac/boost/changeset/64157 However, the 1.43 source seems to have version '7' already. I must be missing something as I don't see how binary archived were using library version '6' for 1.42/43. Thanks, -Ryan

4 7

SGI rope in boost?
by Yakov Galka 28 Jul '10

28 Jul '10

Hello all, I can't use SGI's STL for several reasons: * It's incompatible with the standard library implementation shipped with my compiler (MVS). * Extracting only ropes is a headache, there are too much dependencies. * Unacceptable license. Were there any discussions about implementing ropes in boost? Yakov

4 4

Fisher Exact test in boost ?
by Jean-Baptiste Cazier 28 Jul '10

28 Jul '10

Dear all, I am brand new to this mailing list so I apologize in advance for the naivety of my request. I am looking for an implementation of the Fisher exact test in C/C++, and was somehow hoping to find one in boost. I have looked at the documentation of boost and and found many statistical tools, but not the one I am looking for. The closest I got was a discussion in the mailing archive in 2008 on the use of the hypergeometric distribution to perform such implementation Was any progress made since then ? Could I now get the cdf, pmf and sf from an hypergeometric distribution ? or even better a Fisher exact test directly ? Any help will be welcome Thanks Cheers ! Jean-Baptiste

2 4

Re: [boost] [GIL] bits64
by fabien.castan＠free.fr 28 Jul '10

28 Jul '10

> I have been promoting the idea of people contributing any new functionality > of GIL that they find useful by creating a GIL extension that is not > originally in boost. This allows for an opportunity for people to try their > code, flesh out some bugs, suggest changes to the design, etc. We can also > use this as a mechanism to see how popular certain functionality is and use > that to decide which functionality will make it into boost. That way, by the > time it is proposed for inclusion into boost, the code will be more solid. Yes, I have seen it, I use it, and hope to propose new things one day. But adding typedefs is not adding new functionalities. It's the normal usage of the library. If there is a bug here, it's a bug in gil itself not in the added code... So I define it in my code and use it without problem. Maybe we can add those typedefs at least in gil extensions ? If you want I can send you the code.

1 0

[context] user-context switching
by Oliver Kowalke 27 Jul '10

27 Jul '10

I've moved the context switching code from boost.fiber into a new lib - boost.context (uploaded to boost vault). The lib contains assembler for some platforms: i386, x86_64 and arm (aapcs-linux only). It could be used for code implementing cooperative scheduling (such as boost.coroutine and boost.fiber). Oliver

1 0

[gsoc][RFC] Pointer Plus Bits
by Brian Bartman 27 Jul '10

27 Jul '10

Hello, I previously sent out an email to the list about a pointer plus bits like data structure and received some feedback about a pointer plus bits data structure. After taking into consideration all of the different points of view, comments and concerns voiced by the Boost community I have implemented an extension to my bitfield_tuple which allows the user to easily store parts of a pointer and use the extra bits for storage. Here is a basic overview of the bitfield_tuple: Its a tuple like data structure which stores bitfields instead of whole types inside of single tuple. This allows the user to skirt packing limitations of structs and classes in C++ and create bitfields over the storage type of their choice OR leave that decision up to the data structure (the behavior for selecting the storage type is to select the smallest possible unsigned integral type which will hold the all of the bitfields). example of basic bitfield_tuple declaration. #include<boost/integer/bitfield_tuple.hpp> struct red; struct green; struct blue; using namespace boost; using namespace boost::bitfields; typedef bitfield_tuple< member<unsigned char, red, 5>, member<char, green, 6>, member<unsigned int, blue,5> > rgb565_t; The bitfield_tuple takes ordered named template parameters (In the case of the storage type order is ignored. IE no matter where you put the storage< type > template the ending result will be the same). the bitfield_tuple supports the following template named template parameters (all of the templates which follow are located within the boost::bitfields namespace): bit_align< std::size_t> -> increases the offset of the next field to an offset which is divisible by the supplied value unless the current index is divisible by the supplied value then there is no increase. filler<std::size_t> -> bits to be skipped. member<typename, typename, std::size_t> -> this is a basic bitfield parameters it takes are the type the bitfield is to return, a naming type and the width of a bitfield flag<typename> -> boolean version of member. storage<typename> -> uses the supplied type for internal storage. pointer<typename, typename, typename> -> NEW described below. Pointer Member Information: The pointer member takes three template parameters. 1) The type you would like to make a pointer to. 2) The name which can be used (instead of an index, index is also still available to use) to access the pointer. 3) This is an integral_constant or integral_constant like type which is used to make a mask over the value bits of the pointer. This has a default value to leave the last two bits open. You can use leading or ending bits of the pointer for storage by supplying a different mask. Reasoning behind allowing for leading storage bits. There are some systems which do low address allocations and then store values within the higher part of the address. While this is much more rare then the use case of stuffing two bits inside of the end of a pointer I felt that it would be best to provide a way to actually do this. Reasoning behind restricting the mask to an integral_constant or integral_constant like type. The intent for this is to associate a non deduced type with the mask itself, however if people feel better simply using hex to specify the mask I could change the behavior to do that. There are mask creation utilities which can be used to create the mask from a higher level the simply supplying hex. Here are some examples of how to declare a bitfield_tuple with a pointer member: #include <boost/integer/bitfield_tuple.hpp> #include <boost/assert.hpp> using namespace boost; using namespace boost::bitfields; struct ptr; struct color; struct i1; struct i2; typedef bitfield_tuple< pointer<int, ptr> > ptr_1; typedef bitfield_tuple< pointer<int, ptr>, flag<b1>, flag<b2> > ptr_plus_two_bools; typedef bitfield_tuple< pointer<int, ptr>, member<unsigned int,color,2> > ptr_plus_two_bit_color; int main() { ptr_1 p1; int i = 10; p1.get<0>() = &i; BOOST_ASSERT(*p1.get<ptr>() == 10); ptr_plus_two_bools p2; p2.get<ptr>() = &i; ptr.get<b1>() = true; ptr.get<2>() = false; ptr_plus_two_bit_color p3; p3.get<ptr>() = &i; p3.get<color>() = 3; return 0; } The pointer does NOT have to be the first parameter of the bitfield tuple one can simply place things in front of the the pointer and the value mask of the pointer will not be affected. The only thing which is different when this is done is the offset of the pointer within the bitfield_tuples storage, this only changes the location of the bitfield where the pointer is actually being stored. That being said you will always receive the value bits of the pointer in the exact same way they were taken from inside the pointer. -- thanks, Brian Bartman

4 16

Question about boost license
by Marc Elias 27 Jul '10

27 Jul '10

Hello, Allow me to introduce myself, my name is Marc and I would like to use the boost libraries to perform some work on a software with commercial profit. I have some questions about Boost License Policy I would like to know. As I can read in your webpage, most of the Boost libraries are under a single license that allows me to use the libraries for commercial purposes following the instructions you provide in the webpage. You also inform in the webpage that some libraries are under their own licenses. I would like to know, if it's possible, which libraries are under particular licenses and which are these specific licenses. Is it possible to have this information? Thanks a lot for your help. MARC _________________________________________________________________ Accede a tu Hotmail en un solo clic ¡Descárgate Internet Explorer 8 y empieza a disfrutar de todas las ventajas! http://www.ayudartepodria.com/

5 4

Review request: XInt
by Chad Nelson 26 Jul '10

26 Jul '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am officially requesting a formal review for the Extended Integer library (a arbitrary-length integer math library). The final review version is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). Thanks to everyone who offered suggestions and comments. It's a lot better for them, and likely a lot more useful. Here's hoping for a positive and speedy review. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw9BTYACgkQp9x9jeZ9/wQX+gCgi1N29anc96B6EX+pZ5rgrvyu d8wAnjfHyu5JQVMVu6BFQPtYExG3SbZR =25L3 -----END PGP SIGNATURE-----

2 3

New name of bjam.exe
by Vladimir Prus 26 Jul '10

26 Jul '10

Boosters, I am sure that most of you got accustomed to typing "bjam" in console whenever you want to build things. This name is old, and derives from a tool named "jam", which is even older (around for maybe 20 years). However, this name is probably no longer good. First, having a single project be identified by both "Boost.Build" and "bjam" names proves inconveninent from "marketing" and conveninence standpoints, to the point where many users try to read documentation for Boost.Jam, don't find anything there, and become upset. Second, users get the idea that Boost.Build is somehow related to "Classic Jam", which is not true. For those reasons, Rene and I have decided that "bjam.exe" should go. We're thinking about naming the executable simply "build.exe", since no other build tool bothered to take it. Does anybody have comments, or better suggestions? Thanks, Volodya

39 62

[1.44] Snapshot available
by Beman Dawes 26 Jul '10

26 Jul '10

The daily release snapshots are working fully again. That's important because the releases are based on the snapshots. See http://boost.cowic.de/rc/ --Beman

1 0

Bugs in program_options library
by Jorge Lodos Vigil 26 Jul '10

26 Jul '10

Hi The function options_description::find_nothrow throws an exception when there are at least 2 exact matches. Since this function is in the public interface this could be considered a bug (it must not throw). Please note that this function is used several times within the implementation without try clauses. The exception thrown might be being used by callers of the method find, so you cannot just remove it. It is best to implement find and find_nothrow as follows: const option_description& options_description::find(const std::string& name, bool approx, bool long_ignore_case, bool short_ignore_case) const { shared_ptr<option_description> found; vector<string> approximate_matches; vector<string> full_matches; // We use linear search because matching specified option // name with the declared option name need to take care about // case sensitivity and trailing '*' and so we can't use simple map. for(unsigned i = 0; i < m_options.size(); ++i) { option_description::match_result r = m_options[i]->match(name, approx, long_ignore_case, short_ignore_case); if (r == option_description::no_match) continue; if (r == option_description::full_match) { full_matches.push_back(m_options[i]->key(name)); found = m_options[i]; } else { // FIXME: the use of 'key' here might not // be the best approach. approximate_matches.push_back(m_options[i]->key(name)); if (!found) found = m_options[i]; } } if (full_matches.size() > 1) boost::throw_exception( ambiguous_option(name, full_matches)); // If we have a full match, and an approximate match, // ignore approximate match instead of reporting error. // Say, if we have options "all" and "all-chroots", then // "--all" on the command line should select the first one, // without ambiguity. if (full_matches.empty() && approximate_matches.size() > 1) boost::throw_exception( ambiguous_option(name, approximate_matches)); if (!found) boost::throw_exception(unknown_option(name)); return *found; } const option_description* options_description::find_nothrow(const std::string& name, bool approx, bool long_ignore_case, bool short_ignore_case) const { try { const option_description& d = find(name, approx, long_ignore_case, short_ignore_case); return &d; } catch(const std::exception&) { return NULL; } } This modification uncovers a bug in function cmdline::finish_option (cmdline.cpp) where find_nothrow is being called assuming that no exception will be thrown. The first part of this function might be modified to: void cmdline::finish_option(option& opt, vector<string>& other_tokens, const vector<style_parser>& style_parsers) { if (opt.string_key.empty()) return; const option_description* xd; try { // First check that the option is valid, and get its description. xd = &m_desc->find(opt.string_key, is_style_active(allow_guessing), is_style_active(long_case_insensitive), is_style_active(short_case_insensitive)); } catch(const std::exception&) { if (m_allow_unregistered) { opt.unregistered = true; return; } throw; } const option_description& d = *xd; // Canonize the name opt.string_key = d.key(opt.string_key); ........ } Now it can throw the correct exception thrown by the find method. This is the only way callers could know the correct exception. It was apparently working before because find_nothrow was throwing exceptions not captured within cmdline::finish_option. You may chose to eliminate the xd variable altogether and initialize and use d within the try clause. What is important is to call find instead of find_nothrow. The following test would have detected these problems and the one solved in https://svn.boost.org/trac/boost/ticket/4159: // Multiple arguments test_case test_cases2[] = { {"--fname file --fname2 file2", s_success, "fname: file fname2: file2"}, {"--fnam file --fnam file2", s_ambiguous_option, ""}, {"--fnam file --fname2 file2", s_ambiguous_option, ""}, {"--fname2 file2 --fnam file", s_ambiguous_option, ""}, {0, 0, 0} }; test_cmdline("fname fname2", style, test_cases2); This test may be added at the end of the test_guessing function in cmdline_test.cpp. I have created the ticked 4469 (https://svn.boost.org/trac/boost/ticket/4469) with this information. Thank you. Best regards Jorge

1 0

[chrono] [thread] boost.chrono changes to boost::condition_variables
by Morgan Henry 26 Jul '10

26 Jul '10

Hello, I've been exploring the boost.chrono candidate library as a basis for some fixes to boost::condition_variables::timed_wait(). I have some questions: 1) What is the current state of the chrono library, and its likely path into boost? 2) Are the chrono API changes to boost::condition_variables likely to be accepted into the boost.thread library in their current form? (i.e introduction of wait_for(), wait_until(), and the introduction of a new explicit dependency from boost/thread/condition_variables on chrono::time_point etc...) 3) Are there any other planned changes to boost::condition_variables::timed_wait to allow use of POSIX clocks other than CLOCK_REALTIME? My ultimate goal is to provide an implementation of boost::condition_variables that allows access to the POSIX clock CLOCK_MONOTONIC for use through boost::condition_variables::timed_wait(). Specifically, providing an implementation that uses pthread_condattr_setclock(&attr, CLOCK_MONOTONIC) at boost::condition_variables initialisation, and use of pthread_cond_timedwait(..., &t) with clock_gettime(CLOCK_MONOTONIC, &t) in boost::condition_variables::timed_wait() and friends This change would provide reasonable behaviour of boost::condition_variables::time_wait() in presence of ongoing changes to the system clock. boost.chrono contributes to this goal by providing a clock abstraction and accessors to the appropriate POSIX clocks through class monotonic_clock, class system_clock, etc... Further to this, changes to boost::condition_variable::timed_wait() and similar would be required to use clock_gettime(CLOCK_MONOTONIC, &t) rather than boost::get_system_time() for calculations when the monotonic_clock is specified. I'm currently considering whether to trust that the boost.chrono API changes to the boost::condition_variables API are robust, and likely to persist for the future. Or to propose alternative changes localised to boost::condition_variables that achieve the goals above without the strong dependency on boost.chrono. Thanks for any comments or information about the above. Morgan http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.

3 5

Re: [boost] Phoenix3 port to proto complete
by Thomas Heller 26 Jul '10

26 Jul '10

Doug Gregor wrote: > On Fri, Jul 23, 2010 at 11:14 AM, Thomas Heller > <thom.heller(a)googlemail.com> wrote: >> Mathias Gaunard wrote: >> >>> On 23/07/10 14:18, Thomas Heller wrote: >>>> Ladies and Gentlemen, >>>> I proudly announce that the port of phoenix3 is completed! All >>>> testcases pass! (some with minor modifications) >>>> >>>> So, What is next? Here is my proposed schedule: >>>> - fix some minor issues >>>> - improve boost.bind compatibility: make all boost.bind testcases pass >>>> - implement all boost.lambda testcases and make them pass, as far as it >>>> is >>>> reasonable >>>> - add support for C++0x lambdas >>>> - make interoperability testcases for std::function, boost::function >>>> - adapt the documentation >>>> - clean up code (some parts are a little messy as of now) >>>> - improve compile time >>>> >>>> Did I miss something? >>> >>> I would quite like to know how Phoenix 3 compares to Phoenix 2 in terms >>> of compile speed, even if you haven't fully optimized it yet. >> >> Let me give you a small example of what situation we currently have: >> >> For this test i used the core/primitives_test.cpp test and g++ 4.5 >> >> Phoenix3 total compile time: 3.421s >> Phoenix3 preprocess time: 1.755s >> Phoenix3 compile time of preprocessed code: 1.835s >> >> Phoenix2 total compile time: 1.891s >> Phoenix2 preprocess time: 0.745s >> Phoenix2 compile time of preprocessed code: 1.106s >> >> comparing with clang: >> >> Phoenix3 total compile time: 3.901s >> Phoenix3 preprocess time: 2.738s > > Ouch! The Clang guys will be looking into this > preprocessor-performance issue to see if we can do better. Thanks for > reporting this! > > - Doug Thanks for looking into this! FYI, I was able to identify one bottleneck for the preprocessor. It was by including boost/fusion/include/vector.hpp. I instead included the different boost/fusion/container/vector/vectorN.hpp and was able to reduce compile-time by one second. New timings for the above test are: thomas@sunshine ~/programming/boost $ compile-time g++ -I. libs/phoenix/test/core/primitives_tests.cpp complete compile time: real 0m2.385s user 0m2.253s sys 0m0.120s preprocessing time: real 0m1.254s user 0m1.230s sys 0m0.017s compile time without preprocessing: real 0m1.234s user 0m1.157s sys 0m0.067s thomas@sunshine ~/programming/boost $ compile-time clang++ -I. libs/phoenix/test/core/primitives_tests.cpp complete compile time: real 0m2.709s user 0m2.337s sys 0m0.340s preprocessing time: real 0m1.765s user 0m1.417s sys 0m0.337s compile time without preprocessing: real 0m1.011s user 0m0.913s sys 0m0.080s

1 0

boost-trunk compile failure gcc 4.4.3
by Gaetano Mendola 25 Jul '10

25 Jul '10

current trunk has a compilation failure, the following diff solves it Index: boost/optional/optional_io.hpp =================================================================== --- boost/optional/optional_io.hpp (revision 64315) +++ boost/optional/optional_io.hpp (working copy) @@ -74,12 +74,12 @@ else { if ( d != '-') - in.setstate( ios::failbit ); + in.setstate( std::ios::failbit ); d = in.get(); if ( d != '-') - in.setstate( ios::failbit ); + in.setstate( std::ios::failbit ); v = optional<T>() ; } Regards Gaetano mendola

2 1

Property tree bug
by OvermindDL1 25 Jul '10

25 Jul '10

I am attempting to use a recent boost trunk due to updates I need, however propertytree has a build bug that has already been submitted a few days ago, what is the status of this? The fix is already in the bug ticket. https://svn.boost.org/trac/boost/ticket/4459

2 2

Conflict with patent
by Francisco José Tapia 24 Jul '10

24 Jul '10

I am a teacher of programming in a Technical Professional Training School in Madrid ( Spain). I had wrote a counter balanced red-black tree in C++. The balanced trees have a counter in each node, which represent the number of nodes under it including itself. This counter permit to access to the nodes by their position in the tree. Due to this you can use a counter tree as a vector, access by position and insert and delete by position. Of course, the iterators of this trees have random access, an you can add or decrement the iterators any value . vector_tree<int>::iterator Alfa, Beta ; Alfa = Beta + 17 ; The algorithms are built from zero,without any book or article, because you need in each operation , not only modify the pointers, you must modify the counters too. The speed is good. In the worst case the delay respect to the equivalent STL functions is around 20%. I had checked in windows ( Visual Studio ) and Linux (GCC). My version have a 5 classes interface : vector_tree : This class is a counter balanced red-black tree and have the same interface than the STL class vector. The insertion , deletion and access to elements are log(N) operations. The other four classes are set , multiset , map and multimap. Internally they have a vector_tree. They have the same interface than the STL classes, plus the access by position and the random access iterators. My idea is to send you to examine , and if you think useful, make a new boost library. Today is finished to 95% . I hope have all finished by the first weeks of September. I am writing you because today, looking for other think I discovered a US patent “Positional access using a B-tree” ( US patent Number 7,120,637B2 Oct, 10, 2006), and I don't know if this patent prevent the publication of the code in your library, because you can consider the red-black trees an simplification of B-trees If prevent, and you don't have an idea about the utility of the code, I will stop the develop, and I will spend my time with new ideas The idea about the counter trees you can find in “The art of computer Programming “ Donald Knuth, and I have a previous version of this code wrote 10 years ago and presented in my exposition in the Oposiciones a Catedrático de Informática ( Madrid 2001) If you are interested in the code, mail me and I will send you. Francisco José Tapia E-Mail : fjtapia(a)gmail.com

11 15

[Serialization] Query
by Alapkumar Sinha 23 Jul '10

23 Jul '10

Hi, I am trying to use the serialization library in the following scenario. 1. I create one instance of an object in one process 2. Serialize it either with binary/text archive 3. Then send it through unix local socket to another process where the process deserializes Whatever examples available, it shows just archiving like below std::ofstream ofs("filename"); // use it to build and archive boost::archive::text_oarchive oa(ofs); // write class instance being pointed to // to the archive oa << g; /************/ But after this 1. I would like to copy the archived data to a buffer 2. Send the buffer throught a socket something like boost::asio::write(socket, boost::asio::buffer( buffer, sizeof(buffer)); Can someone help on how I can get this done. One more question: does the call boost::asio::write does serialization internally? If yes, still I would need how to get the buffer as mentioned in the query above a my transmission mechanism might change. Thanks, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

2 1

[Query] __sync_val_compare_and_swap_4
by Alapkumar Sinha 23 Jul '10

23 Jul '10

Hi , I am trying to use the Boost Interposes, specifically the message queue. When Im doing cross compiling boost libraries on Cronus mips board, I am getting below error undefined reference to `__sync_val_compare_and_swap_4' Upon analysis we found that in boost/interprocess/details/atomic.hpp, was throwing this error. I found the solution. I replaced this returned statement ( __sync_val_compare_and_swap_4 ) and included assembly language code in atomic.hpp. (volatile boost::uint32_t *mem, boost::uint32_t with, boost::uint32_t cmp) { /* return __sync_val_compare_and_swap(const_cast<boost::uint32_t *>(mem), cmp, with);*/ boost::uint32_t result; asm volatile(".set\tpush\n\t" ".set\tnoreorder\n\t" ".set\tnomacro\n\t" "1:\n\t" "ll\t%[result],0(%[mem])\n\t" "bne\t%[result],%[with],2f\n\t" "move\t%[result],$0\n\t" // delay slot "move\t%[result],%[mem]\n\t" "sc\t%[result],0(%[mem])\n\t" "beq\t%[result],$0,1b\n\t" "nop\n\t" // delay slot "2:\n\t" ".set\tpop" : [result] "=&r" (result) : [mem] "r" (mem), [cmp] "r" (cmp), [with] "r"(with) : "memory"); return result; } After this I was able to execute the message queue program successfully on the mips platform. Can someone confirm if this is the right solution? Regards, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

2 1

[interprocess] x86-64 bug?
by Bartosz Marcinkiewicz 23 Jul '10

23 Jul '10

Hello, I have modified a little an example doc_complex_map.cpp in order to use vector of integers which is a member (int_vector_) of structure stored as a shared map value (complex_data). Program works as expected on x86 (32bits). I get core dump on x86-64: (gdb) bt #0 0x000000000041ecfe in boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0ul>, boost::interprocess::iset_index> > >::priv_push_back (this=0x7f3435ae9260, x=@0x7fff77fe9eac) at /home/bma/opt/include/boost/interprocess/containers/container/vector.hpp:1239 #1 0x000000000041ed57 in boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0ul>, boost::interprocess::iset_index> > >::push_back (this=0x7f3435ae9260, x=@0x7fff77fe9eac) at /home/bma/opt/include/boost/interprocess/containers/container/vector.hpp:904 #2 0x0000000000401cf1 in operator() (this=0x7fff77fea0ee, x=@0x7f3435ae9218) at doc_complex_map.cpp:109 #3 0x0000000000401e8c in main () at doc_complex_map.cpp:146 Valgrind output is: [bma@dev2 example]$ vg ./doc_complex_map ==18738== Memcheck, a memory error detector. ==18738== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==18738== Using LibVEX rev 1804, a library for dynamic binary translation. ==18738== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==18738== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==18738== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==18738== For more details, rerun with: -v ==18738== ==18738== Invalid write of size 4 ==18738== at 0x41ECFE: boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0l>, boost::interprocess::iset_index> > >::priv_push_back(int const&) (vector.hpp:1239) ==18738== by 0x41ED56: boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0l>, boost::interprocess::iset_index> > >::push_back(int const&) (vector.hpp:904) ==18738== by 0x401CF0: main::test_struct::operator()(complex_data&) (doc_complex_map.cpp:109) ==18738== by 0x401E8B: main (doc_complex_map.cpp:146) ==18738== Address 0x104c0f989 is not stack'd, malloc'd or (recently) free'd This is on boost 1.43. I am attaching source code. Thanks for any hints. -- Bartosz Marcinkiewicz e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl

1 1

boost::bind result type
by David Sankel 23 Jul '10

23 Jul '10

I'm wondering if there's a way I can generically get the result type of boost bind. I'd like to write something along these lines: template< typename StreamT, typename Sink > typename boost::result_of< boost::Bind( StreamT, boost::arg<1>, Sink ) >::type apSink( StreamT t, Sink sk ) { return boost::bind( t , _1 , sk ); } I'm not interested in a boost::function solution because I require that uses apSink's result can be inlined. Any ideas? Perhaps one of these other bind-like libraries has an answer to this. Thanks, David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

5 15

Problem in proto library
by Jorge Lodos Vigil 23 Jul '10

23 Jul '10

Hi The addition of macro BOOST_PROTO_EXTENDS_USING_ASSIGN in literal.hpp broke compilation with /clr option in MSVC. The problem is that the macro is used as BOOST_PROTO_EXTENDS_USING_ASSIGN(literal) and literal is a variable modifier for managed C++. Adding a private typedef: typedef literal<T, Domain> literal_t; and replacing the macro parameter with: BOOST_PROTO_EXTENDS_USING_ASSIGN(literal_t) solves the problem for us. Tested with VS2008. Please note that this problem prevents compilation of xpressive and any other library that uses proto with /clr. Thank you for boost and particularly for proto and xpressive :-) Best regards Jorge

2 1

[GIL] bits64
by fabien.castan＠free.fr 22 Jul '10

22 Jul '10

Hi, 64 bits pixels are interesting for accumulation buffers or internal computations. I think it could be a good thing to add these typedefs in gil. Is there any reason not to do it? Best regards, Fabien Castan

3 2

Re: [boost] [GIL] scoped_channel_value type
by fabien.castan＠free.fr 22 Jul '10

22 Jul '10

>> So if you want to extract this, you will have to special-case >> scoped_channel_value anyway. So in this case you don't need a typedef >> inside. >> You can just define a specialization like this: >> >> Template <typename ChannelValue> >> Struct base_channel_value { >> typedef ChannelValue type; >> }; >> >> Template <typename ChannelValue, typename MinV, typename MaxV> >> Struct base_channel_value<scoped_channel_value<ChannelValue, MinV, MaxV> > >> { >> typedef ChannelValue type; >> }; >> > >I really have to write that one down. I keep on forgetting this trick. Thanks ! Maybe this utility structure can be added (like channel_type, etc.) ?

1 0

[GIL] scoped_channel_value type
by fabien.castan＠free.fr 22 Jul '10

22 Jul '10

Hi, I would like to get the value type of the channels depending on an image view. So I can get the scoped channel type, from MyView type, like this: typedef typename boost::gil::channel_type<MyView>::type MyScopedChannel; But I can't get the primitive type used by the scoped channel. For example, if the type is scoped_channel_value<float,float_zero,float_one>, I can't get the float type. /// \ingroup ScopedChannelValue /// \brief A channel adaptor that modifies the range of the source channel. Models: ChannelValueConcept template <typename BaseChannelValue, // base channel (models ChannelValueConcept) typename MinVal, typename MaxVal> // classes with a static apply() function returning the minimum/maximum channel values struct scoped_channel_value { typedef BaseChannelValue base_channel_t; //< missing typedef //... } So this will allows to use: typedef typename boost::gil::channel_type<MyView>::type::base_channel_t ChannelBaseType; Are you agree to add this typedef ? Best regards, Fabien Castan

3 3

fixed size vector in boost::numeric::ublas?
by Markus Grabner 22 Jul '10

22 Jul '10

Hi all! In boost::numeric::ublas, there exist different vector variants (unbounded and bounded). All of them can be resized dynamically (up to a maximum size defined at compile time in the case of the bounded vector). Therefore the vector class (or the underlying storage array) have a size member which indicates the current size of the vector. However, it would be extremely useful to have a vector of fixed size, i.e., one which can't be resized dynamically, but has its size statically defined at compile time. Such a vector does not require a size member and only consumes N*sizeof(T) bytes of storage, where N is the (static) vector size and T the value type. Many libraries dealing with geometric data (OpenGL and OpenInventor being prominent examples) store their data in compact arrays in their native data types, e.g., the values (x0,y0,z0,x1,y1,z1,x2,y2,z2) stored in consecutive memory locations define three points in 3D space. By means of a fixed size vector, the entire boost::numeric::ublas functionality could be applied to such arrays by a simple reinterpret_cast on each element. This is not possible with the bounded or unbounded vectors since the vector must be constructed before with its size member properly initialized, and the actual vector data must therefore be copied explicitly before use. I tried to create a fixed_array class to implement this proposal (see attachment), it can be used, e.g., to create the equivalent of the OpenInventor "SbVec3f" data type as follows: typedef boost::numeric::ublas::vector<float,fixed_array<float,3> > vec3d_t; It is probably not the cleanest solution, and I skipped the serialization stuff altogether, but it demonstrates an approach how this can be done. What do you think about adding such an extension to improve boost's interoperability with other libraries? Thanks & kind regards, Markus -- Markus Grabner Institute for Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria WWW: http://www.icg.tugraz.at/Members/grabner

2 1