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

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

[Boost.bcp] Runtime error while parsing regular expression
by Jakub Skowron 20 Jul '11

20 Jul '11

Boost 1.47.0 file: \tools\bcp\licence_info.cpp function: std::string format_authors_name(const std::string& name) In regex literal (^)?[^-(<a-zA-Z�-�]+(([(<].*)?$)? there are some characters from unknown character set (byte value above 127). This causes runtime error while running "bcp shared_ptr foo": "boost Found a closing ) with no corresponding openening parenthesis. The error occured while parsing the regular expression fragment:" I am using English version of Windnows XP, but locale are Korean (Control Panel->Regional and Language Options->Advanced->Language for non-Unicode programs). Default toolset was used to build boost (that is msvc). I have Microsoft Visual Studio 2005 installed.

1 0

[TTI] Review for The Type Traits Introspection library by Edward Diener **extended**
by Joel Falcou 20 Jul '11

20 Jul '11

The Type Traits Introspection library by Edward Diener started friday 1st have been *extended* to july 17. Comments and reviews are welcome. =========== What is it? =========== The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. =================== Getting the library =================== The library is available at http://svn.boost.org/svn/boost/sandbox/tti/. The HTML documentation is available at http://svn.boost.org/svn/boost/sandbox/tti/libs/tti/doc/html/index.html and the PDF documentation is available at http://svn.boost.org/svn/boost/sandbox/tti/libs/tti/doc/TypeTraitsIntrospec…. =================== Writing a Review =================== The reviews and all comments should be submitted to the developers list, and the email should have "[TTI] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.

6 30

[accumulator] median absolute deviation
by Phil Bouchard 20 Jul '11

20 Jul '11

Hi, I see the median absolute deviation (MAD) is not provided by the accumulator library. Perhaps this is a feature that could be added. Thanks, -Phil

2 2

[contract] oldof failure not in N1962?
by lcaminiti 20 Jul '11

20 Jul '11

Hello all (and especially N1962 authors), As far as I can see, N1962 does not say what to do in case of a failure while evaluating and copying an oldof expression. For example, what shall Contract Programming do if there is a memory error while taking a copy of size() to later check the following postcondition? size() == oldof size() + 1 Given that oldof copies are taken just after preconditions are checked and before the body is executed, I am tempted to treat the oldof failure as a precondition failure and call the precondition_broken handler. An alternative would be to to treat the oldof failure as if it happened within the body. However, in this case the body will raise more errors (e.g., throw more exceptions) that it will raise without the oldof contracts so I don't think this is a good approach. In summary: 1) oldof expressions belong to the contract therefore I think oldof failures should result in calling one of the contract failure handlers (precondition_broken or postcondition_broken). 2) Given that eventual oldof failures happen before the body is executed (and just after the preconditions are checked), I think precondition_broken should be called (instead of postcondition_broken) in case of an oldof failure. The counter argument is that precondition failures indicate a bug in the caller. However, oldof failures indicate a system-level exception in the code that programs the program-- oldof failures are not bugs in neither the caller (precondition_broken) nor in the body implementation (postcondition_broken)... but if you follow this argument, you need to give up 1)... What do you think? Thank you. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-oldof-failure-not-in-N196… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 9

[Boost] [GSoC] Checks project - prototype hesitation
by Pierre Talbot 20 Jul '11

20 Jul '11

Hello community. I'm a GSoC student who is assigned to the checks library. I currently design the prototype of a function and I would like to have your opinions. Description. --------------- The function must return true or false if the number is correct (or not). This leads me to this prototype : template <typename mod10_iter> bool check_mod10 ( const mod10_iter &begin, const mod10_iter &end, unsigned int nbr_digits = 0) ; But each digits in the functions may have a weight. So I must passed a sequence of unsigned int to the function. template <typename mod10_iter> bool check_mod10 ( const mod10_iter &begin, const mod10_iter &end, const boost::array<unsigned int> &weight, unsigned int nbr_digits = 0) ; The parameter "weight" should be optional, if the size is equal to 0, the algorithm will consider a weight of 1 for all the digits. The const of weight is a problem if the size is equal to 0, we should make a copy of this argument. Do you have any ideas, suggestions about this prototype ? Thank you very much. Pierre Talbot.

3 4