September 2007 - 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

[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

Review Request:boost.lexer
by Ben Hanson 01 Feb '08

01 Feb '08

Hi There, I have posted boost.lexer to the Boost File Vault and would like to request a review. Hartmut has integrated my library 'lexertl' into Spirit already, so this is the boost version of that library. Thanks, Ben Hanson

3 2

Strings tagged with their character set
by Phil Endecott 10 Jan '08

10 Jan '08

Dear All, Something that I have been thinking about for a while is storing strings tagged with their character set. Since I now have a practical need for this I plan to try to implement something. Your feedback would be appreciated. The starting point is the idea that the character set of a string may be known at compile time or at run time, and so two types of tagging are possible. First compile-time tagging: template <character_set> class tagged_string { ... }; tagged_string<utf8> s1; tagged_string<latin1> s2; Some typedefs would be appropriate: typedef tagged_string<utf8> utf8string; Now run-time tagging: class rt_tagged_string { private: character_set cs; public: rt_tagged_string(character_set cs_): cs(cs_) ... ... }; rt_tagged_string(utf8) s3; (Consise-yet-clear names for any of these classes would be great.) I propose to implement conversion between the strings using icode and/or GNU recode. It would be easy to allow this conversion to happen invisibly, but it might be wiser to make conversion explicit. I'm not sure what the 'character_set' that I've used above should be. It needs to be some sort of user-extensible enum or type-tag. We need character types of 8, 16 and 32 bits. wchar is not useful here because it's not defined whether it's 16 or 32 bits. So I propose the following, modelled after cstdint: typedef char char8_t; typedef <implementation-defined> char16_t; typedef <implementation-defined> char32_t; I then propose a character_set_traits class: template <character_set> class character_set_traits; template <> class character_set_traits<utf8> { typdef char8_t char_t; const bool variable_width = true; ... }; For the fixed-width, compile-time-tagged strings I think it makes sense to inherit from std::basic_string< character_set_traits<charset>::char_t >. The only problem I can see with this is that latin1string s1 = "hello world"; s1.substr(1,5) <--- this returns a std::string, not a latin1string If latin1string has a constructor from std::string (which is its own base type) that's fine, i.e. we can still write: latin1string s2 = s1.substr(1,5); but unfortunately we can also write latin2string s3 = s1.substr(1,5); which is not so good. So a different approach is to define a set of character-set-specific character types, and build string types from them: typedef char8_t latin1char; typedef char8_t latin2char; For variable-width character sets, the methods of std::string are less useful (though far from useless). I understand that there's already a utf8 iterator somewhere in Boost, can it help? For run-time character sets, is there any way to provide e.g. run-time iterators? I imagine these strings being used as follows: - Input to the program is either run-time or compile-time tagged with any character set. - Data that is not manipulated in any way it just passed through. - Data that will be processed will first be converted to a suitable, compile-time-tagged, character set, and if appropriate converted back afterwards. So the absence of (useful) string operations on run-time-tagged or variable-width character set data is not a problem. For conversions, there is the question of partial characters in variable-width character sets. If a program is processing data in chunks it may be legitimate for a chunk boundary to fall in the middle of a UTF8 character. IIRC, icode has a method to deal with this which we could expose in a stateful converter: charset_converter utf8_to_ucs4(utf8,ucs4); while (!eof) { utf8string s = get_chunk(); ucs4string t = utf8_to_ucs4(s); send_chunk(t); } utf8_to_ucs4.flush(); - but many applications may only need a stateless converter. I will be working on this over the next couple of weeks, so any feedback would be much appreciated. Regards, Phil.

16 55

[IOStreams] Opinion on test case needed
by Frank Birbacher 06 Jan '08

06 Jan '08

Hi! I had problems using iostreams::stream<file_descriptor> with Windows and MSVC 8 Express. The file_descriptor had a bug and failed seeking. But the error had gone unnoticed. Because of this I wrote a test case for this in hope to discover an error in IOStreams (source: see below). I did not discover one. Instead the test runs fine on linux/gcc 4.1.2 but fails on Windows/MSVC8Express (test run: see below). I based the test on "Standard C++ IOStreams and Locales" (Langer&Kreft), Section 1.3 "The Stream State". And I found the IOStreams library is just using std::iostream for handling the errors. So is MSVC buggy in this regard? Or am I missing something? Source of test case in Trac SVN Browser: http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iost… Result of test case on platform Windows/MSVC 8 Express: > ...using <p..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug>error_test.exe... > testing.capture-output ..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug\error_test.run > ====== BEGIN OUTPUT ====== > Running 12 test cases... > error_test.cpp(81): error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) > error_test.cpp(66): error in "wrap_nothrow <&test_seekg>": stream still good > error_test.cpp(68): error in "wrap_nothrow <&test_seekg>": stream did not set badbit > error_test.cpp(69): error in "wrap_nothrow <&test_seekg>": stream did not fail > error_test.cpp(71): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator void* > error_test.cpp(66): error in "wrap_throw <&test_seekg>": stream still good > error_test.cpp(68): error in "wrap_throw <&test_seekg>": stream did not set badbit > error_test.cpp(69): error in "wrap_throw <&test_seekg>": stream did not fail > error_test.cpp(71): error in "wrap_throw <&test_seekg>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_throw <&test_seekg>": stream does not report failure by operator void* > unknown location(0): fatal error in "wrap_throw_delayed<&test_seekg>": std::runtime_error: bad seek > error_test.cpp(73): last checkpoint > error_test.cpp(81): error in "wrap_nothrow <&test_seekp>": exception thrown by function(stream) > error_test.cpp(66): error in "wrap_nothrow <&test_seekp>": stream still good > error_test.cpp(68): error in "wrap_nothrow <&test_seekp>": stream did not set badbit > error_test.cpp(69): error in "wrap_nothrow <&test_seekp>": stream did not fail > error_test.cpp(71): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator void* > error_test.cpp(66): error in "wrap_throw <&test_seekp>": stream still good > error_test.cpp(68): error in "wrap_throw <&test_seekp>": stream did not set badbit > error_test.cpp(69): error in "wrap_throw <&test_seekp>": stream did not fail > error_test.cpp(71): error in "wrap_throw <&test_seekp>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_throw <&test_seekp>": stream does not report failure by operator void* > unknown location(0): fatal error in "wrap_throw_delayed<&test_seekp>": std::runtime_error: bad seek > error_test.cpp(73): last checkpoint > > *** 24 failures detected in test suite "Master Test Suite" > > EXIT STATUS: 201 > ====== END OUTPUT ====== Any opinions on this? Any suggestions on what to do about it? Frank

4 16

[fusion] list/detail/at_impl.hpp, Suggest recrusive elem_at_c instead of recursive apply
by Larry Evans 24 Oct '07

24 Oct '07

In boost/fusion/.../list/detail/at_impl.hpp the apply is recursive; however, the only reason for the recursion is to "find the right element type". The other reason for apply is the same as that of the apply in.../vector/detail/at_impl.hpp. "find the right element type" in vector's at_impl is done with mpl::at. The similarity between list and vector at_impl would be more apparent if: template <typename Sequence, int N> struct elem_at_c { typedef typename mpl::eval_if< mpl::bool_<N == 0> , mpl::identity<typename Sequence::car_type> , elem_at_c<typename Sequence::cdr_type, N-1> >::type type; }; were used to find the right element type. Then the frist part of list::at_impl::apply would be: template <typename Sequence, typename N> struct apply { typedef elem_at_c<Sequence, N::value> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type; which is very similar to the counterpart in vector: template <typename Sequence, typename N> struct apply { typedef mpl::at<typename Sequence::types, N> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type;

2 3

For inclusion to boost::function
by Preston A. Elder 23 Oct '07

23 Oct '07

(repost, I accidentally posted this to boost::build list ... ugh). I have written code to solve this problem: I have class foo, like so: class foo { boost::function<void (foo *)> func_ptr; void call() { func_ptr(this); } }; I want func_ptr to be either a free-standing function (or class static), OR a class member function of a derived class, so: void bar(foo *f) { ... } OR: class baz : public foo { public: baz() { func_ptr = &baz::doit; } void doit() { } }; The obvious problem with the latter is that it needs to be downcast implicitly, and some kind of exception thrown if the wrong type is passed. I have created a boost::function proxy class to handle exactly this problem. It uses a lot of boost::function's own tricks with the pre-processor and such. I also had to use another suggestion I saw on this list to work around the fact boost::function does not accept member function pointer syntax (argh! That took a lot to figure out). My solution is this: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils… Which is included by a boost preprocessor iteration here: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils… As I mention, I use a lot of boost::function's own tricks. I think this would be a lot cleaner if done as part of boost::function, rather than me re-implementing the same macros and such. I have made sure my implementation works, and more importantly, has all the tests you would expect (ie. that the return value arguments except the class are the same, that the class is derived from the original function typedef's first argument, and so on). Here is my test case: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/test/schedul… Any way, feedback is as always appreciated, but if someone could look at this for an addition to boost::function it would really be great PreZ

3 2

[soc] Boost.extension/reflection project advances
by Mariano Gabriel Consoni 16 Oct '07

16 Oct '07

Hi Community...! As some of you may know, I'm working on a SoC project called "Boost.extensions and reflection". This mail is just to keep you informed about the project advances. At this time, we have very good news. The library is now near completion, and we expect submitting it for revision in the next days. We've been worked the last two weeks in the following tasks: - Code style: continued improving the code style according Boost guidelines. - Build: improved the Jamfiles to work well in more platforms. - Boost::function: migrated some code to (optionally) use boost::function. - Benchmarks: made new benchmarks to test the new integrations. - Performance analysis: documented the results of the benchmarks. - Preprocessor: replaced a lot of boiler-plate code with (optional) boost::preprocessor macros. - Dependencies flags: documented the optional dependencies and how to enable them. As I have finished all the tasks planned in my proposal (and a lot more :) ) I will advance to Reflection part and Jeremy (Pack, original author) will finish some remaining tasks of Extension. Bye! -- Mariano

4 6

[serialization] Proposal for an extension API to the Archive concept
by "JOAQUIN LOPEZ MU?Z" 15 Oct '07

15 Oct '07

Reviewing the discussion in the thread entitled "[serialization][trunk] please bring us archive helpers back" at http://lists.boost.org/Archives/boost/2007/09/127065.php , I've been thinking about the design issues raised there and I'd like to make a proposal for a seamless extension API that I think can solve the practical concerns originating the discussion while addressing Robert's policy of keeping the Archive concept simple. The last proposal Robert made regarding the helper API and special support for shared_ptr can be summarized in the following points: 1. The Archive concept does not include any extra requirement concerning special support for shared_ptr and/or a helper API. 2. There are naked_* archive implementations which conform to the bare requirements of the Archive concept. 3. The traditional archive implementations (without the "naked_" prefix) inherit from naked_ as well as from a class shared_ptr_helper and a class named, say, helper_api so that special support for shared_ptr and a helper API are provided. This approach has pros and cons: pros: the Archive concept is not polluted by impure considerations such as those accomodating shared_ptr and helpers, thus helping keep the conceptual design and the work of archive implementers simple. cons: A naked archive implementation, while conforming with the concept requirements, will fail to handle shared_ptr and any type relying on the helper API. My point of view is that this solution is just a half-baked one: having a conformant archive which fails to handle shared_ptrs would come as a surprising (and annoying) fact to users of B.S. So, how to make B.S provide shared_ptr and helper support whitout polluting the archive concept with too specific provisions? My proposal is to add a single "hook" to the Archive concept which is as agnostic as possible and can be leveraged in the future for unforeseen necessities beyond shared_ptr and helper support. Add the following requirement to the Archive concept (both Saving and Loading): a.get_extension_obj(p); a.set_extension_obj(p); Returns and sets, respectively, an internal object of type shared_ptr<void>. This object is default initialized upon archive construction and is destroyed along with destruction of the archive. These expressions are reserved for the internal usage of Boost.Serialization and thus must not be called by user code. >From the point of view of the implementer of an Archive, satisfying this new requirement is as simple as having an internal member of type shared_ptr<void> and granting access to it through member functions as described above. That's all the extra burden put on the Archive concept. So far, the concept is not polluted with considerations on shared_ptrs, helpers or anything. How can Boost.Serialization leverage this extension API to *universally* provide helper and shared_ptr support for any Archive type? The following is an skectch of the procedure: B.S can define an internal type resembling this: class extension: public shared_ptr_helper, public helper_api {}; where shared_ptr_helper is more or less like the currently existing class and helper_api will package the helper API functions formerly present in Boost 1.34 (lookup_helper, insert_helper, etc.) Now, B.S can publicly provide the following helper API to user code: namespace boost{ namespace serialization{ template<typename Archive> void lookup_helper( Archive& ar, const extended_type_info* eti, shared_ptr<void> & sph); // rest of the helper API ... } } which is implemented along the following lines: template<typename Archive> void lookup_helper( Archive& ar, const extended_type_info* eti, shared_ptr<void> & sph) { // get the extension object or create a new one if this // is the first time shared_ptr<void> ext_obj=ar.get_extension_obj(); if(!ext_obj){ ext_obj.reset(new extension); ar.set_extension_obj(ext_obj); } extension& ext=*ext_obj; // forward to the extension object ext.lookup_helper(eti,sph); } and similarly for the other helper API and shared_ptr support functions. What do we gain with this? 1. The Archive concept is kept almost intact, and the required extension is both trivial to implement and totally agnostic. 2. We can provide support for shared_ptr and helpers *universally*, without putting the burden of its implementation to the writers of Archive classes. This extra functionality will be called using a notation boost::serialization::foo(ar,...); instead of ar.foo(...); but this is the only drawback (if it can be considered a drawback.) 3. Future functionality can be added by Boost.Serialization to Archives by adjoining it to the internal extension class without the Archive concept or its implementation needing any revision at all. How do you like it? Your feedback is greatly appreciated. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 15