- Boost - lists.boost.org

[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

Boost Asio io_service as global?
by Philip Bennefall 20 Jul '11

20 Jul '11

Hi all, I am just beginning to learn how to use Boost Asio in a multithreaded environment, and one thing struck me when looking at the various examples. I have not been able to find an answer to this in the documentation, but in case it is explained somewhere that I've missed I apologize in advance. Taking the asynchronous echo server as my base I am writing a multithreaded server that handles connections in a thread pool. My question is simply, why is the io_service object always passed around between class instances as a reference in the constructor? Why can one not store it as a global variable? I cannot see how this makes a difference, and a global seems to make things a lot easier. Is there a particular reason why I should not do this? Thanks in advance for any help. Kind regards, Philip Bennefall

3 3

Which compilers are not supported for 1.48 ?
by Antony Polukhin 20 Jul '11

20 Jul '11

Are really old and broken compilers still supported? Do we need them? For example VC++6. It gives thousands of warnings on type_traits and boost PP headers. Tests for VC++6 do not compile. Nobody tested boost libraries on that compiler for years. May be we shall get rid of compilers, that do not support template partitial specialization, ADL or SFINAE? If not, shall we try to make the tests pass (or at least compile) for them? Best regards, Antony Polukhin

15 16