March 2008 - Boost - lists.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[mpl] is there a or_seq like logical metafunction?
by vicente.botet 17 Jun '09

17 Jun '09

Hello, I needs calculate the mlp::or_ of a sequence of nullary logical metafunction. This seams quite simple. I have do the following: <code> template <typename Seq> struct or_seq; template <typename Seq, long N> struct or_seq_aux : mpl::or_< typename mpl::front<Seq>::type, or_seq<typename mpl::pop_front<Seq>::type> > {}; template <typename Seq> struct or_seq_aux<Seq, 1> : mpl::front<Seq>::type {}; template <typename Seq> struct or_seq : or_seq_aux<Seq, mpl::size<Seq>::value> {}; </code> Is there a boost or_seq like logical metafunction? Is there a better way to do it? I would be extremely interested in any suggestions. Best regards --------------------------- Vicente Juan Botet Escriba

5 34

manipulators for filtering_stream s
by Roland Schwarz 22 Jan '09

22 Jan '09

Surprisingly I was not able to find on the net code that would give me a smart way to indent a stream. So I wrote a little filter based on the boost iostreams library. My first attempt was: boost::iostreams::filtering_ostream out; indent_filter ind(4); out.push(ind); out.push(std::cout); However trying to control it via e.g. ind.in() ind.out() turns out to be problematic interface since, 1) out.push() takes a copy of ind 2) the interface ind.in() is suboptimal. With my attached example it is possible to: #include "indent.hpp" ... boost::iostreams::filtering_ostream out; indent_filter::push(out,2); out.push(std::cout); ... And use it like so: out << "Hello Filter!\n" << indent_in << "this is\n" << "indented\n" << indent_out << "until here\n" ; Which will result in output: Hello Filter! this is indented until here The state is stored in the ios base class of the stream, by way of the pword mechanism. Consequently the filter stream even may be downcast to a basic_ostream, and the indenter will still work. E.g. with out defined as above: ... foo(out); ... void foo(std::ostream& out) { out << indent_in << "out is a downcast filter_stream\n" << indent_out << "end of indentation\n" ; } If you want to try it out, you just need to include the header indent.hpp. If someone thinks the snippet is usable either as an example for the iostreams library or the filter streams manipulator idea is worth generalizing to make it usable for other filters too, I would be glad to hear from you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

5 17

Proto<markus>::review()(proto::accept);
by Markus Werle 30 Aug '08

30 Aug '08

Hi! I think Proto should be accepted for inclusion into boost. A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today. - What is your evaluation of the design? Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!) Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality. Proto covers the most important aspects of an ET library, sometimes in very elegant ways. Proto's design adressed compile time issues. That's a value in itself. OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail. There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does. - What is your evaluation of the implementation? None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it. - What is your evaluation of the documentation? The quality varies from excellent to hard to read. I agree with all what David writes about the docs. There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead. - What is your evaluation of the potential usefulness of the library? We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks - Did you try to use the library? A couple of hours, but only for some of the examples. - With what compiler? VC8, Intel 10.1 - Did you have any problems? Nope. Eric-faster-than-lightning fixed those before I could run into them ... - How much effort did you put into your evaluation? I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design. - Are you knowledgeable about the problem domain? I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto. Markus P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future. (*) I'd like to have an extra review on _every_ boost library in a 2-year-cycle. By this boost::multi_array could probably be forced to model assignable like any other STL container and ::_1 from boost::bind will move into its own namespace - just to mention my two favourite change requests ...

3 3

Re: [boost] UTF-8 conversion etc. (Sebastian Redl) (Sebastian Redl)
by Graham 28 Aug '08

28 Aug '08

>> As I said to Phil, Rogier and I completed a Unicode character library >> for >> >> Release under boost, but never submitted it to Boost as we had intended >> to >> >> release it with a string library built on it, and never had time to do >> the >> >> second part of the work. >> >Post it, and we'll do the second part. It's open-source. > >Sebastian Sebasian, As requested, I have posted a Unicode character support library in the boost vault as Unicode_lib.zip. Please feel free to use this under the boost license. It would be great if somebody had the time to develop the existing character support to ad the string wrappers that we had intended to - but ran out of time doing. It should be well documented, but if you want any questions answered, please feel free to ask and I'll try and help! Thanks. Yours, Graham

6 7

[asio]: extending asio
by Andreas Pokorny 17 Aug '08

17 Aug '08

Hello, I would like to add more asynchronous event sources to asio, like: - input events for mouse, keyboard and joystick .. - window exposure, move, resize events in some generic form, - generic "quit" events - file alteration With directFB/X11/Unix/Linux most of that can be done directly through select or epoll. But since reading the message and parsing events is mostly done by a third party library, I would only need the reactor part for these. Is this possible with asio? According to msdn it seems to be possible to create so called event objects for direct input devices. I am no win32 expert so I do not know if one can combine that with completion ports? Regards Andreas Pokorny

7 16

Why I hate subversion
by Eric Niebler 02 Aug '08

02 Aug '08

U boost/indirect_reference.hpp U boost/parameter.hpp svn: In directory 'boost' svn: Can't move 'boost/.svn/tmp/foreach.hpp.2.tmp' to 'boost/foreach.hpp': Permission denied ericne@ericne-xps ~/boost/org/trunk $ svn up svn: Checksum mismatch for 'boost/.svn/text-base/enable_shared_from_this.hpp.svn-base'; recorded: '12d8c5183a709a7699c13b312073c36c', actual: 'c89a6b23045ff8c89d2de74213d1649a' Does this ever happen to anybody else? I get this random corruption of my local subversion repository about once a month. -- Eric Niebler Boost Consulting www.boost-consulting.com

11 15

Mac OS universal builds: testers needed
by Mat Marcus 25 Jul '08

25 Jul '08

I've made a number of changes to my universal-binary supporting darwin.jam patch (shipping with the Adobe Source Library) in order to address the concerns raised by Rene and others at http://svn.boost.org/trac/boost/ticket/989 : My current version supports invocations like: bjam architecture={combined,x86,power} link={shared,static} address-model={64,32} That is, universal builds are now supported, along with 64 bit builds. I'd like to ask for the help from a few volunteers who'd be willing to test it out, before I submit my patch for consideration. Anyone interested in helping me test it? If so, please contact me off list and I'll send you a couple of boost build files to replace. I still have a bit of cleanup to do. Specifically, on the mac, if a build doesn't specify an -arch parameter, the architecture (and perhaps the address model) of the host machine is used. I'm not really comfortable with the same folder path meaning different things on different machines. So, I plan to do something like the following in darwin.jam (in invented pseudo code) SWITCH(on result of /usr/bin/arch) { # host machine's architecture CASE(ppc) use <architecture>power/<address-model>32 as the default CASE(i386) use <architecture>x86/<address-model>32 as the default CASE(ppc64) use <architecture>power/<address-model>64 as the default CASE(x86_64) use <architecture>x86/<address-model>64 as the default DEFAULT error, unknown arch Thanks, Mat

3 2

[dynamic_bitset] bug in to_ulong() in dynamic_bitset.hpp
by Boris Gubenko 05 Jul '08

05 Jul '08

A failure of dynamic_bitset library test dyn_bitset_unit_tests3 on Tru64/cxx and HP-UX/aCC revealed what appears to be a bug in <boost/dynamic_bitset/dynamic_bitset.hpp> introduced after Boost 1.34. The bug affects platforms where 'long' type is larger than 'int'. On both Tru64 and HP-UX, 'int' is a 32-bit type. On Tru64, 'long' is a 64-bit type. On HP-UX, 'long' is a 64-bit type in 64-bit data model (+DD64, which is how Boost testing is done on this platform) and 32-bit type otherwise. The test also fails on other platforms and while I cannot verify it, from the test output it apears that these platforms are affected by the same bug. What fails is the two testcases below in b.to_long() suite in boost/libs/dynamic_bitset/dyn_bitset_unit_tests3.cpp invoked with run_test_cases<unsigned int>() : { std::string str(ul_width - 1, '1'); boost::dynamic_bitset<Block> b(str); Tests::to_ulong(b); } { std::string ul_str(ul_width, '1'); boost::dynamic_bitset<Block> b(ul_str); Tests::to_ulong(b); } The code in <boost/libs/dynamic_bitset/bitset_test.hpp> converts dynamic_bitset<unsigned int> argument to unsigned long and checks that the appropriate bits in the result are set: result_type num = lhs.to_ulong(); // Be sure the number is right if (sz == 0) BOOST_CHECK(num == 0); else { for (std::size_t i = 0; i < sz; ++i) BOOST_CHECK(lhs[i] == (i < n ? nth_bit(num, i) : 0)); } This check fails for the bits in the upper half of the result. Here is an excerpt from dynamic_bitset<Block, Allocator>::to_ulong() function in <boost/dynamic_bitset/dynamic_bitset.hpp> in the trunk: result_type result = 0; for (size_type i = 0; i <= last_block; ++i) { assert((size_type)bits_per_block * i < (size_type)ulong_width); result |= (m_bits[i] << (bits_per_block * i)); } In our case, last_block = 1 and bits_per_block = 32. m_bits[i] has 'unsigned int' type. On the second loop iteration, a 32-bit integer is left-shifted by 32 bit positions. This triggers undefined behaviour. From 5.8 - Shift operators [expr.shift] : "The behavior is undefined if the right operand is [...] greater than or equal to the length in bits of the promoted left operand." With cxx and aCC, such shift results in zeroing of all bits of the left operand. Here is the code from <boost/dynamic_bitset/dynamic_bitset.hpp> in Boost 1.34 : unsigned long result = 0; for (size_type i = 0; i <= last_block; ++i) { assert((size_type)bits_per_block * i < (size_type)ulong_width); // gps unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); } Here on the second loop iteration, a 64-bit long is left-shifted by 32 bit positions which yields the intended result. x.cpp below illustrates the difference between trunk and Boost 1.34: x.cpp ----- #include <stdio.h> #include <limits.h> int main() { unsigned int m_bits[] = { UINT_MAX, UINT_MAX }; unsigned int bits_per_block = sizeof(int) * CHAR_BIT; unsigned long result = 0; for(int i = 0; i <= 1 ; ++i) { #ifndef Boost_1_34 result |= (m_bits[i] << (bits_per_block * i)); #else unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); #endif printf("result = %llx\n", result); } } cxxosf.zko.hp.com> cxx x.cpp && a.out result = ffffffff result = ffffffff cxxosf.zko.hp.com> cxx x.cpp -DBoost_1_34 && a.out result = ffffffff result = ffffffffffffffff cxxosf.zko.hp.com> Replacing result |= (m_bits[i] << (bits_per_block * i)); with unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); on the trunk makes the test succeed: verified on Tru64/cxx and on HP-UX/aCC. In <http://lists.boost.org/Archives/boost/2007/12/131126.php> I said: > It looks like a regression in boost/dynamic_bitset/dynamic_bitset.hpp > introduced in 1.35, but even in 1.34.1, it seems to me that the code in > to_ulong() is relying on undefined behaviour. What I was referring to is the code in 1.34 applying bitwise shift operator to a long operand. It would trigger an undefined behavior in C where "The operands shall have integer type", but it is legal in C++ where "The operands shall be of integral or enumeration type". So, I no longer claim that the code in 1.34 is relying on undefined behaviour. And the last thing: why the bug affects only platforms where 'long' type is larger than 'int'? Because if they are the same, as is the case on VMS or HP-UX in 32-bit data model, last_block = 0 and the single iteration of the for loop just assigns m_bits[0] to the result: the right operand of the shift operator is zero. To fix the problem, I suggest to replace the buggy code in <boost/dynamic_bitset/dynamic_bitset.hpp> in the trunk with that in 1.34. If there are no objections, I can do it. Thanks, Boris

3 3