- Boost - lists.boost.org

[program_options] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi Volodya, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for program_options. Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Review] Lockfree review starts today, July 18th
by Hartmut Kaiser 22 Jul '11

22 Jul '11

Hi all, The review of Tim Blechmann's Boost.Lockfree library starts today, July 18th 2011, and will end on July 28th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::atomic_int, an atomic integer class The library is accessible from here: http://tim.klingt.org/boost_lockfree.tag.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

9 17

[fusion] html docs woes
by Eric Niebler 21 Jul '11

21 Jul '11

I'm merging [72977] to release (<https://svn.boost.org/trac/boost/changeset/72977>) and am given a headache by the fact that Fusion has its HTML docs checked in. The docs are automatically generated from the qbk files so committing them to svn is strictly unnecessary, AFAICT. Why is this a problem? - Any change to any qbk file results in a huge number of diffs to the HTML docs (due to changed ids), resulting in a huge commit, long upload times, long download times, long merge times. - It makes viewing a changeset all but impossible because the meaningful changes are lost in the noise of meaningless diffs to automatically generated files. - It leads to unnecessary merge conflicts when merging commits from trunk to release. I'm going to have to regenerate the docs on the release branch and upload them all ... for no benefit! Can Fusion be changed to build its html docs as a normal part of Boost's doc build procedure like other Boost libraries? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

8 27

[lexical-cast] Help with documentation required
by Antony Polukhin 21 Jul '11

21 Jul '11

I've added Qickbook documentation for lexical_cast to libs/conversion/doc/lexical_cast.qbk and a Jamfile.v2 file to build it. Meanwhile, there is an old HTML documentation for lexical_cast in libs/conversion/lexical_cast.htm and file libs/conversion/index.html references it. The question is: How shall I update the lexical_cast.htm/index.html, doc/html/ folder? Best regards, Antony Polukhin

3 8

Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string
by Artyom Beilis 21 Jul '11

21 Jul '11

--- On Thu, 7/21/11, Beman Dawes <bdawes(a)acm.org> wrote: > From: Beman Dawes <bdawes(a)acm.org> > > You can't create working > > > > std::basic_ostringstream<char16_t> stream; > > > > Because stream << 1245 would not work due to > lack of std::locale facets. > > > > You can't create requires facets as for example they > are specialized > > in many standard libraries. > > Emulation via simple uint16_t and uint32_t typedefs doesn't > work for > all use cases. So only use it when it does work. > And Boost.Filesystem.v3 is one of these specific use cases. Boost.Filesystem uses codecvt facet? You can't create them, at least with gcc/linux because existing codecvt facets are specialized for each type of character - and you have to derive from it. For example this code would not link with Linux/gcc-4.6 #include <locale> class real_facet : public std::codecvt<char16_t,char,std::mbstate_t> { }; class simulated_facet : public std::codecvt<unsigned short,char,std::mbstate_t> { }; int main() { std::locale l1(std::locale::classic(),new real_facet()); std::locale l2(std::locale::classic(),new simulated_facet()); } With errors like: undefined reference to `std::codecvt<char16_t, char, __mbstate_t>::do_in(__mbstate_t&, char const*, char const*, char const*&, char16_t*, char16_t*, char16_t*&) const' --- : undefined reference to `std::codecvt<unsigned short, char, __mbstate_t>::do_max_length() const' > > Even existing Microsoft's VC2010 does not work if you > compile application > > with /MD or /MDd > > I'll retest just to be sure, but I'm fairly sure that some > of my tests > have used those switches. > MSVC2010 does not provide specialization for std::locale::id for these new facets and they are undefined in the dll. If you want I'll provide a fault case for MSVC10 as well. And all these with compilers that **declare** support of charXX_t. So you may try to put an effort in implementing some emulation but at these points char16_t/char32_t are broken with modern compilers. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

1 0

[interprocess][1.47] Mismatched PP directives?
by John Maddock 20 Jul '11

20 Jul '11

While building the PDF docs for 1.47 I noticed a bunch of Doxygen warnings about mismatched PP directives in the Boost.Interprocess source - warning messages below - should I/we be concerned, or this just a Doxygenism? Thanks, John. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:55: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:68: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:70: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:96: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:98: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:109: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:111: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:131: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/containers/containers_fwd.hpp:40: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/intrusive_ptr.hpp:294: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/scoped_ptr.hpp:168: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/shared_ptr.hpp:388: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_barrier.hpp:115: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_mutex.hpp:148: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_recursive_mutex.hpp:158: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_semaphore.hpp:119: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/named_mutex.hpp:235: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/named_semaphore.hpp:242: warning: More #endif's than #if's found.

2 1

RFC: type erasure
by Steven Watanabe 20 Jul '11

20 Jul '11

AMDG Over the last few months I've re-done my type erasure library from scratch, fixing a lot of the bad design decisions I made originally. Here's a basic sample of what you can do with it: simulate boost::any: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<> > > x(10); simulate boost::function<void(int)>: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<>, callable<void(int)> > > f(foo); The code is available from the Vault: http://tinyurl.com/3z9jcwp The library is nearly complete. I've included pre-built html documentation in the zip. Questions, comments, and criticism are welcome. In Christ, Steven Watanabe

7 22

Re: [boost] [Boost-users] [Review] Lockfree review starts today, July 18th
by Klaim - Joël Lamotte 20 Jul '11

20 Jul '11

On Wed, Jul 20, 2011 at 18:51, Tim Blechmann <tim(a)klingt.org> wrote: > >> If Boost.Lockfree will be accepted, it won't be merged into trunk before > >> Boost.Atomic is accepted. > > > > That seems unnecessary. Can't Boost.Lockfree simply include (a version > > of) Boost.Atomic as an implementation detail for now? > > this would somehow mean to fork boost.atomic, move everying to a `namespace > detail'. might introduce some maintenance overhead to keep it in sync with > the > original library. > > Excuse me if it's common knowledge around here, but I've seen several libraries relying on boost.atomic that have been reviewed, so may I ask : why haven't Boost.Atomic been reviewed yet? It looks like it's already finished and reliable... Joël Lamotte

2 1

[fusion] make_fused arity > 10
by Mario Mulansky 20 Jul '11

20 Jul '11

Hi We are using Boost.Fusion quite heavily in our library [odeint] and I just came across some problem that took me several hours to solve so I decided to let you know about the issue. We use boost::fusion::make_fused to make functor applicable to fusion sequences and as we occasionally deal with long vectors we increased the limits as described here: http://www.boost.org/doc/libs/1_47_0/libs/fusion/doc/html/fusion/functional… At first we used 10 as maximum (also changing FUSION_MAX_VECTOR_SIZE and the ..INVOKE.. constants, of course). However, today I extended the library and had to increase these values to 16. Unfortunately, that did not work - compiling still failed at functors with arity 11. So I digged into Boost.Fusion and after quite some time I realized that it relies on boost::result_of which has an upper limit of 10. So additionally changing BOOST_RESULT_OF_NUM_ARGS to 16 made everything work, eventually. I think the point here is that defining BOOST_FUSION_UNFUSED_MAX_ARITY > 10 without also defining BOOST_RESULT_OF_NUM_ARGS accordingly will break the code in a rather confusing way - I think at least adding a note in the docs could be very helpful here. Regards, Mario

3 2

FW: On #5644 (tellg returns different results for gnu libstd++ and others standard libraries for codecvt_null)
by Michael Kochetkov 20 Jul '11

20 Jul '11

I am terribly sorry for reposting this message but the situation with the https://svn.boost.org/trac/boost/ticket/5644 issue problem becomes urgent for me as the time is passing away. Please could anyone just comment on the issue if it is valid defect or not? Thank you in advance, -- Michael Kochetkov -----Original Message----- From: Michael Kochetkov [mailto:Michael.Kv@gmail.com] Sent: Wednesday, July 06, 2011 1:17 AM To: 'boost(a)lists.boost.org' Subject: On #5644 (tellg returns different results for gnu libstd++ and others standard libraries for codecvt_null) Hello, please can anyone comment on https://svn.boost.org/trac/boost/ticket/5644 issue? I am really stuck with the problem and need just a resolution if it is a defect or not. And if it is then I would appreciate an approximate estimate when it is to be fixed. Thank you in advance, -- Michael Kochetkov

2 1