- Boost - lists.preview.boost.org

TTI library updated in the sandbox to version 1.4
by Edward Diener 25 Mar '11

25 Mar '11

I have updated the TTI library in the sandbox 'tti' directory to version 1.4. 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. Changes in this release include: * Some metafunction macro names and one nullary type metafunction name have changed to provide a better separation of introspection of functions using composite and individual type syntax. * Composite syntax macros are now only used to introspect member functions and static member functions. Individual type syntax now exists for introspecting member data and static member data. * Inclusion of specific header files for faster compilation is now supported. * Addition of macro metafunction name generating macros. * Shorten the names of the test files and test header files. * Added documentation topic about introspecting function templates. 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. There is a readme.txt in the top-level directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It may also work with other compilers. This is the last release in which breaking name changes will occur. I anticipate any further release will include only possible additions of functionality, but all current interfaces are now stable and the design is set. Questions, comments, suggestions, and bug reports are all welcome.

4 6

[config] Does it work with compilers in C mode ?
by Edward Diener 25 Mar '11

25 Mar '11

Is there any guarantee that the configuration files will work with a C compiler or a C++ compiler in C mode ? Is there anything in the configuration files which is C++ specific ? I am working on bringing my variadic macro data library into Boost PP, and I wanted to use the BOOST_NO_VARIADIC_MACROS in config, but Paul Mensonides was concerned that Boost PP should work with a C compiler and that config could have something that is C++ specific, and therefore be unusable for Boost PP. I would rather not reduplicate the logic of BOOST_NO_VARIADIC_MACROS in Boost PP, even though I was the one to add it to config, because it puts the same code in two different places.

3 6

[documentation] doxygen tags and ALIASES.
by Vicente BOTET 25 Mar '11

25 Mar '11

Hi, I have see that Boost.Local uses some aliases to tag some part of the doxygen documentation. ALIASES=" Params=\"Parameters: \" Param{2}=\"\\1\\2 \" EndParams=\"\" Returns=\"Returns:\" Note=\"Note:\" Warning=\"Warning:\" See=\"See:\" RefSect{1}=\"\\xmlonly \\1\\endxmlonly\" RefSect2{2}=\"\\xmlonly \\2\\endxmlonly\" RefClass{1}=\"\\xmlonly\\1\\endxmlonly\" RefMacro{1}=\"\\xmlonly\\1\\endxmlonly\" " For example /** * @brief This macro is used to specify the local function name. * * This macro must follow the local function body code block { ... } as * shown in the @RefMacro{BOOST_LOCAL_FUNCTION_PARAMS} documentation. * * @Params * @Param{name, * The name of the local function. This name cannot be the name of an operator * operator... and it cannot be the same name of another local function * declared within the same enclosing scope (i.e.\, it is not possible to * overload local function declarations) -- see the * @RefSect2{Advanced_Topics\, Advanced Topics} section. * } * @EndParams * * @See @RefMacro{BOOST_LOCAL_FUNCTION_PARAMS}, @RefSect{Tutorial} section, * @RefSect2{Advanced_Topics, Advanced Topics} section. */ Other use html valises directly. //! Effects: //! \code //! for (; first != last; ++result, ++first) //! new (static_cast(&*result)) //! typename iterator_traits::value_type(boost::move(*first)); //! \endcode //! //! Returns: result Is somewhere a guideline on how to tag the doxygen documentation for Boost libraries? Is there a list of ALIASES? If not, is there some interest in defining one? Thanks, Vicente

6 13

Re: [boost] [type_traits] MSVC rejects typename -- why?
by Lorenzo Caminiti 25 Mar '11

25 Mar '11

On Thu, Mar 24, 2011 at 3:58 PM, Vicente BOTET <vicente.botet(a)wanadoo.fr> wrote: > > Hi, > > > It seems the compiler is not seen it is inside an outer macro. > In this case it seems that we need another macro e.g.BOOST_NESTED_TYPENAME. You could try to follow the protocol of adding a new macro andpropose apatch to John. > > An other alternative: I suspect that the nested structure is code that you generate with your macros in Boost.Local orBoost.Contract. I propose you to define a nested template > > template > void f(T& x) { > template > struct s { > T g() { > typename boost::remove_reference::type i = 0; > return i; > } > }; > x = s().g(); > } Yes, for my application I can use class templates instead of function templates (this is actually not code generated by macros but just a Boost.Local example for the docs that shows how to use BOOST_LOCAL_TYPEOF). I'll leave it up to Boost.Config maintainers to decide if the introduction of BOOST_NESTED_TYPENAME is needed or not. Thanks a lot! -- Lorenzo

1 0

Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
by Brian Wood 24 Mar '11

24 Mar '11

Dave Abrahams: >At Wed, 23 Mar 2011 14:29:20 -0700, >Emil Dotchevski wrote: >> It is not independent matter because that is exactly what >> BOOST_THROW_EXCEPTION guarantees, except when the library contains >> try..catch or rethrows using throw without arguments, which are rare >> cases. I agree that going the extra mile to workaround those >> additional cases is usually unreasonable. > > I suppose that might be true, depending on your definition of "work > properly." There's no such thing as "working properly without > exceptions" if the library was coded for use with exceptions and you > really need a recoverable response to, say, resource exhaustion. > > That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a > good rule for Boost, and I wouldn't mind having something like it in > the inspect tests, provided that libraries with a legitimate reason > not to use it can be registered as exceptions to the rule. I think you are both more knowledgeable about exceptions and this Boost library than I am, but here's my thinking. In the last 2 or 3 months I added a try/catch and throw without arguments to a file in my library -- http://webEbenezer.net/misc/ReceiveCompressedBuffer.hh . That's the only one so it is rare for me but there are a lot of libraries that are bigger than my library. So I'm not sure it is rare in other libraries. It seems to me that as a library grow this restriction is just waiting for you to run into it. I guess it's a trade-off though if I understand correctly. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

2 1

[GSoC] SIMD proposal
by Mathieu - 24 Mar '11

24 Mar '11

Hello everyone, I'm a french student preparing a Master in Computer Science. I'm highly interested in participating in the 2011 GSoC with Boost. I'm particulary keen on working on the boost.simd subject. I think having SIMD abstraction in boost could be really beneficial (the first example which comes to mind is boost.math). However I have some questions about the subject in order to do my proposal, some of them have already been discussed with Joel Falcou and Mathias Gaunard on IRC, but here it is : One of the main concern I have is that nt2 relies heavily on cmake to detect various things like SSE instruction set support etc. From what I know (I ported nt2 to OpenBSD a while ago), depending on the architecture different methods are used, in order to be portable, like reading from sysctl in OSX or lauching a little executable which collect various informations using cpuid. So the question is : is bjam able to do everything we need to do, or will we need to do the detection in any other way? I use, and I kind of know bjam but I'm not an expert either, I believe Vladimir Prus will be able to help here. Another thing that is a bit blur for me at the moment, is what is the scope of boost.simd? I mean, from what I see the simd part is quite deep-rooted in nt2, has dependencies on several modules of it, so will boost.simd be a subset of nt2 simd module or will we need to rewrite part of it to avoid dragging huge dependencies (and well, end up doing boost.nt2). Mathieu Masson. Regards.

6 14

[type_traits] MSVC rejects typename -- why?
by Lorenzo Caminiti 24 Mar '11

24 Mar '11

Hello all, The following code compiles on GCC (v3.4.3) but it does not on MSVC (cl.exe v14): #include <boost/type_traits.hpp> template<typename T> void f(T& x) { struct s { T g() { // GCC needs this typename but MSVC does not -- why?? typename boost::remove_reference<T&>::type i = 0; return i; } }; x = s().g(); } int main() { int x; f(x); return 0; } MSVC does not accept the `typename` inside `s::g` because it says it's not within a template (but I think it is within a template...). GCC instead requires that `typename`. Which compiler is right? (What does the standard say?) How do I program this code so it works on all compilers? Thank you very much. -- Lorenzo

3 3

[type_traits] Most Unifying Proposal for operator names Was: Review Typetraits Extension.
by Joachim Faulhaber 24 Mar '11

24 Mar '11

Dear Frédéric, Operatorists, list, on occasion of the current naming discussion on operator traits I started a wiki page with an operator functor naming table that allows for an overview over names of operators, functors (and related concept names) across the standard and boost. I compared the name stems only, independent of the question of a 'has_' or 'has_operator_' prefix. Basically it's an extension of Frédéric's operator names table 1.7 from his docs, extended by proto and boost::operator names. Comparing the names I tried to find "Most Unifying Proposals" for names in column MUP: https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators Also I took a look at the current and new standard's functor class templates from header <functional>. I wonder why all the functors only use one template parameter, which restricts their use leaving out the interesting cases of functors for mixed type overloaded operators. template <class T> struct op_functor { ... } instead of template <class T, class U=T, class R=T> struct op_functor { ... } Also I don't understand, why inheritence form binary_function<T,U,R> is no longer declared, but instead of this, the redundant declaration of all associated types for every functor. Does this codereplication serve any purpose? Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 6

[bjam] auto linking fail
by Tal Agmon 24 Mar '11

24 Mar '11

Tested on windows Jamroot defines 1.47.0 outputs libs missing patch version causing auto link to fail.. -- Sent from my mobile device

1 0

[move] [ thread] ambiguous call to overloaded function
by Tal Agmon 24 Mar '11

24 Mar '11

Hello, Did anyone experience the following Revision 70494 tested on msvc2010 with headers the following headers: [code] #include< boost/thread.hpp> #include < boost/move.hpp > ... X x; boost::packaged_task<string_ptr_type> pt(boost::bind(&X::foo, boost::ref(x))); boost::unique_future<string_ptr_type> fs = pt.get_future(); boost::thread task(boost::move(pt)); fs.wait(); ... [code] outputs: .$(BOOST_ROOT)boost/move/move.hpp(304): could be 'boost::packaged_task<R> &boost::move<boost::packaged_task<R>>(T &)' or $(BOOST_ROOT)boost/thread/detail/move.hpp(44): or 'boost::detail::thread_move_t<T> boost::move<boost::packaged_task<R>>(T &)'

3 2

[XInt] CoW/Move Timings
by Chad Nelson 24 Mar '11

24 Mar '11

Below are the comparative timings with and without Copy-on-Write, and with and without Boost.Move. Times are measured in seconds, using two sets of ten integers (512, 2048, and 8192 bit). The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated modulus argument of the same size) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.5.1, under Ubuntu Linux 10.10. The build was non-debug and used -O2 optimization. Otherwise, the settings were left at their defaults. The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed. The tests show pretty conclusively that Copy-on-Write, alone or in conjunction with Boost.Move, provides a noticeable speed improvement on all three sizes. They also prove that Boost.Move can work well in conjunction with it. I'll leave any further analysis to people who are probably more qualified than I. Note that the Boost.Move numbers could be a little better. The integer_t classes are move-enabled, but the internal data class is not as yet. The data class only sometimes uses return values, so the difference isn't likely to be great. I will make the updated code available on request for anyone who wants to examine the changes. 512bit CoW, no Move: 0.48, 0.47, 0.47: 0.48 No CoW, no Move: 0.61, 0.61, 0.62: 0.61 (worst) No CoW, Move: 0.57, 0.57, 0.55: 0.56 CoW, Move: 0.44, 0.44, 0.44: 0.44 (best) Review code, CoW, no Move: 0.50, 0.47, 0.47: 0.48 2Kbit CoW, no Move: 4.69, 4.79, 4.89: 4.79 (best) No CoW, no Move: 5.01, 5.19, 5.06: 5.09 (worst) No CoW, Move: 5.18, 5.00, 5.01: 5.06 CoW, Move: 4.80, 4.79, 4.86: 4.82 Review code, CoW, no Move: 4.88, 4.85, 4.94: 4.89 8Kbit CoW, no Move: 68.0, 68.8, 68.9: 68.6 No CoW, no Move: 70.4, 70.4, 70.2: 70.3 (worst) No CoW, Move: 70.9, 69.8, 69.6: 70.1 CoW, Move: 68.4, 68.2, 67.8: 68.1 (best) Review code, CoW, no Move: 68.8, 68.4, 68.8: 68.7 -- Chad Nelson Oak Circle Software, Inc. * * *

26 37

[system] error_condition::message is unclear to me
by Jochen Wilhelmy 24 Mar '11

24 Mar '11

Hi! I looked at boost::system and some things are unclear to me: if error_code and error_condition are low level and abstract versions of the same category, then if error_condition::message simply returns |category().message( value() )| then how does category know that it's a condition value and not an error value? (error_code::message also returns| category().message( value() ))| currently error_condition appears quite useless to me since the values have to be the same as in error_code. by the way msdn tells us that error_code is for system errors and error_condition is for user-defined errors but this may be as true as unicode is equivalent to utf16 ;-) another problem I see in system_error::what(). i think it's common sense that what() should return - standarsized strings across platforms - english strings and is used only for lookup. but the current implementation returns the translated string of the underlying operating system. -Jochen

1 0

[GSoC] Boost.Polygon edge, polyline and edge set concepts
by monish gupta 24 Mar '11

24 Mar '11

Hello community I want work on project : Boost.Polygon edge, polyline and edge set concepts. Could anyone provide me some weblinks to learn about polyline and edge set algorithms? Monish Gupta

2 1

Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
by Oliver Kowalke 24 Mar '11

24 Mar '11

> This confuses me. > > I do understand that a default-constructed *context* object is useful > to be able to switch context from any place in the code. > > But I'm now asking about the usefulness of a default-constructed > *stack* object. A default-constructed *context* object is not passed a > stack object. because og the move-semantics supported by the stack class an default constructed stack instance means not-a-stack. It doesn't allocates memory. > If you're saying that a default-constructed context object must > nonetheless store a default-constructed stack object... this starts to > feel like an implementation detail leaking out into the API. It is not leaking - all classes providing move-semantics are used in this ways. Please look into boost.thread - boost::thread has a default ctor -> constructs a boost::thread instance that refers to Not-a-Thread. > In that case, what further Context work is needed to support Mac OS X? assembler implementation/fcontext - the source code has already an assembler file for MAC OS X (x86-64/i386). I wasn't able to test the code because I haven't a MAC OS X installation. Oliver -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0

Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
by Oliver Kowalke 24 Mar '11

24 Mar '11

> On Wed, Mar 23, 2011 at 4:07 AM, Oliver Kowalke <oliver.kowalke(a)gmx.de> > wrote: > > > I've published an alternative version of boost.context - the user can > decide in its code which implementation should be used. I think I follow Vicentes suggestion - boost.context provides only one class (boost::context<>) which preferes fcontext(asm) implementation if available otherwise ucontext/fiber. I'll implement a test-app in order to check how this design influences UNIX signal handling (hopefully the impact will be only to require not to change the UNIX signal mask in context<>). > I certainly wouldn't ask you to try to implement these higher-level > features in assembler. But I don't see why the library couldn't add > C++ header files providing such features wrapped around the (assembler > or native) underlying functionality. It would require to do an additional allocation and it might be that the higher implementations can do it more efficient/better suitable for there purposes/not required by some higher libs. Otherwise those libs would pay for the additional memory allocaton even if it would not be required. > We will want features such as templatized callables and exception > support in every higher-level library built on top of Context. Must > every such library provide its own redundant, inconsistent > implementation? The higher libs can implement what they want and how they want. > Here are two different objects initialized in different ways, > containing different state. Maybe they should be different classes? I think they should not be different - both do the same (jumping to other context). The difference is only the one does and the other doesn't manage a stack - but bot represent an execution context. > Perhaps you're saying that the same wrapper machinery that handles a > templated callable could provide an outermost try/catch(...). That > wrapper, guaranteed not to throw a C++ exception, will be executed by > the top-level function passed to Context. > > Again, every realistic consumer of Context will need this... I can add an additional trampoline function which has a try/catch-all block and issues an assertion if an exception was thrown. But this adds an additional indirection! > Okay, there's a default-constructed stack object which manages no > memory, a stack object managing a memory area which is potentially > useful for a processor stack, and a stack object managing a memory > area actually in use by a processor stack. I'm still unclear on the > usefulness of the first kind, a default-constructed stack object. The first is required to be able to jump from any position in the code to the second kind of context (which starts a new execution context). > Sure! As I said, unless one selects the 10.4u (or earlier) SDK, the > ucontext.h implementation should work. I haven't yet tried to build > the Context library; is the ucontext.h implementation header-only? yes regards, Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

GSoC Proposal Preparation For Encoding Awared String
by Soares Chen 24 Mar '11

24 Mar '11

Hi all, I am an undergraduate student from the National University of Singapore and I am interested to take part in this year's GSoC with the Boost community. Currently I am preparing my proposal to add support for encoding awareness in string through new/existing Boost project, but there are some questions I would like to ask to clarify the community's interest in such a project. The inspiration I get came from several lengthy discussions I found in the Boost mailing list archive, which happened recently from mid January to mid February. [5][6][7] For a brief overview according to my own understanding, the heated debates was mainly around different ways to ensure consistency between the encoding expected when library code accepts strings, and the actual encoding of strings passed by users. The problem arise because a small minority of developers use std::string in different encoding than UTF-8, and the implicit assumption of UTF-8 encoding for std::string brings inconsistency and causes numerous bugs that are outside the scope of the Boost library. >From the discussion, I found several proposals that have been made to solve the inconsistencies of std::string encoding: 1. Create new classes that warp around std::string, std::u16string, and std::u32string for each encodings and ensure encoding correctness simply through C++ type safety features. The classes are tentatively called the utf*_t classes (which many disliked the name) - Proposed by Chad Nelson with working prototype available. [1] 2. Continue to strongly enforce the assumption that all std::strings are UTF-8 encoded. Depreciate or make it hard to use other encodings in std::string. 3. Reinvent std::string and introduce boost::string. The new string class is proposed to be immutable but also delegate the encoding awareness to templated view<> classes that warp around boost::string, which IMHO the view<> classes share similarity with proposal (1). [7] Now I try not to go into the details and pros & cons of each proposal to avoid turning this thread into yet another string discussion. The original discussions have 542 messages in total, spanned a whole month, and I failed to find any conclusion that everyone could agree on. What I notice in the discussions is that there are several groups of people that have strong opinion on different ways to solve the problem and could not generally agree with each other. I also found that the discussions often drifted away and lose focus on the original problem, but every now and then someone would mention the problem again and proposed a solution that is similar to earlier proposals. Nevertheless, the discussion was extremely informative and insightful. I learned a lot by just reading through these discussions. But since I intend to start a GSoC project based on this subject, I hesitated on what I should really do in this project as I feel that there is no general agreement on how to solve this problem in the Boost community. Although I have some ideas and I personally lean towards proposal (1) by Chad Nelson, I think it'll be best if my project can fit in the interest of majority of the Boost community members. I think it is also best to avoid any further discussion on this topic to actively make the design decision, as the time period for GSoC is limited and the discussion tends to be never-ending. I think there are several options that I can choose for my project: 1. To use Chad Nelson's code as base, try to incorporate other ideas proposed in the mailing list, integrate with Boost.Locale, and make it Boost quality to submit for review. If this option is chosen, I wish that Chad Nelson can be my mentor. 2. To start a new code base, gather and compile ideas suggested in mailing list, final design decisions made by me and my mentor but not the community (to keep the project going on fast), make it Boost quality and submit for review. 3. To start the boost::string project, where another better string is reinvented and fix all the weaknesses of std::string. 4. Adopt different proposal, and improve on existing project such as Boost.Unicode [2] or Boost.Locale [3] such that it really solves the encoding awareness problem. 5. Any other suggestion? I hope to get feedback from you on what should I really focus on in this project. Of course I also hope that this subject is mature enough to be accepted as GSoC project as I can see great interest in the community to solve this problem. I would also like to clarify again that I do not intend to solve actual Unicode handling problems in this project - there are already excellent libraries such as Boost.Locale designed for it. My main objective is to design a set of interfaces that help to ensure encoding correctness and consistency when strings are being passed between different functions. I look forward for anyone that is interested in this project and is willing to be my mentor. Lastly, I apology for my grammar and any possible misunderstanding that caused by my bad writings. Please do correct me if I have missed anything or misunderstood some aspects. I will write a complete and formal proposal once I hear feedbacks from you. Thank you very much and hope that I can start contributing to the Boost community! Best Regards, Soares Chen National University of Singapore References: [1] The Oak Circle C++ (Unicode) Toolkit, by Chad Nelson. http://www.oakcircle.com/toolkit.html [2] Boost.Unicode, by Mathias Gaunard. http://mathias.gaunard.com/unicode/doc/html/ [3] Boost.Locale. http://cppcms.sourceforge.net/boost_locale/html/index.html [4] Should UTF-16 be considered harmful?, Stack Overflow. http://stackoverflow.com/questions/1049947/should-utf-16-be-considered-harm… [5] Always treat std::strings as UTF-8?, Boost Mailing List Discussion. http://groups.google.com/group/boost-developers-archive/browse_thread/threa… [6] What will string handling in C++ look like in the future, Boost Maling List Discussion. http://groups.google.com/group/boost-developers-archive/browse_thread/threa… [7] [string] proposal, Boost Mailing List Discussion. http://groups.google.com/group/boost-devel-archive/browse_thread/thread/f85… (Sorry for linking the mailing list archive to Google Groups, but I feel that Google Group provides better interface for reading archives for those who haven't read the discussions)

4 5

Asio - is it possible not to remove descriptor from epoll?
by Vlad Lazarenko 23 Mar '11

23 Mar '11

Guys, Is it possible to make ASIO keep descriptor in epoll and not remove it automatically after event is fired (and implement or emulate the same behavior for other mechanisms like select, kqueue etc)? My use case is very simple - I am reading data from multicast socket. One read at a time, always reusing the same buffer. The performance is very critical. Another use case is to give ASIO a null buffer and perform sync read yourself when data is available, in that case you can read from tcp/ip sockets as well. I know that libevent supports this but was not able to find out how to do it with Asio. If it is not available, would someone be able to assist in adding this feature? Thank you, Vlad -- *Vlad Lazarenko* *Lazarenko.me <http://lazarenko.me>* vlad(a)lazarenko.com <vlad(a)lazarenko.me>

2 3

polygon bugs with contains() and resize()
by Andy Ross 23 Mar '11

23 Mar '11

Hi Luke, I'm wondering if you've had a chance to look at some boost::polygon bugs I've submitted, or if maybe the trac bug database is the wrong spot: https://svn.boost.org/trac/boost/ticket/5312 (wrong result from contains()) https://svn.boost.org/trac/boost/ticket/5358 (bad output from resize()) https://svn.boost.org/trac/boost/ticket/5359 (very slow resize()) All are, hopefully, reasonably high quality bugs with short, dependency-free code included to exercise them. All have been confirmed vs. the code in subversion. The last two (and in particular 5358) are blockers for me right now. What I'm doing fundamentally requires resize(), and so I'm stuck without a solution to at least one of them. Thanks for your help, and let me know if you need any more information. Andy

1 0

[context review] Formal Review
by Artyom 23 Mar '11

23 Mar '11

Hello, This is my formal review. > Please always state in your review, whether you think the library should be > accepted as a Boost library! Yes, it should be a part of boost. (the alternative version with improved f/u-context support) However following issues should be addressed ASAP: 1. Documentation must be improved with much better description, rationale, examples and design notes and description of member functions, stack unwinding in case of context destruction and so on. See notes below. 2. Current build is too verbose. All relevant options should be configured automatically by default without user specifying them. I understand that it is limitation of BBv2 but it MUST be addressed in the official release. Now Full Review: ---------------- > What is your evaluation of the design? I had issues with Design of fcontext/ucontext but it was addressed by Oliver in very fast and I think correct way so I have no more problems with it. Also I have important concerns about verbosity of build system use. I've discussed this before. BBv2 improvements required. > What is your evaluation of the implementation? The heaviest part of implementation is in assembly so I can't say too much. C++ code looks fine. Current issues: Extern "C" required in context_ucontext.hpp typedef void ( * stack_fn)(); should be extern "C" you need to pass pointers to makecontext as extern "C" function. Asm implementations: Add "namespace" names like boost_get_context instead of get_context. It would prevent names collision and in general allows tools like BCP to rename namespace to use two versions of boost library. > What is your evaluation of the documentation? This is the weakest point of this library. The documentation is not sufficient. What do I miss: a) Context destruction and unwinding. When I tried to implement yield like iterator I had problem with unwinding the stack of auxiliary context when the program does not get execution. I should add some throwing in yield and some flags to make sure that stack is unwind in destruction of iterator. The behavior should be documented and examples should be provided. I explain more: Consider implementation like ... void iterate() { object foo; // may be not destroyed for(;;) { global_value = local_value++; if(local_value > 100000) return; else my_context.jump_to(other_context); } } ... int operator++() { other_context.jump(my_context); return global_value; } ... iterator it; while(it++ < 10) ; ... Now what happens when other_context does not return execution to my_context when gloabl_value becomes 10. Then foo object is not get destroyed. So I need explicity switch to my_context and throw something to make stack unwind procedure work and foo is not got destroyed. Such things should be documented and example how to use it should be provided (i.e. what is correct way to unwind the stack). b) Design rationale is missing c) I'd like to see comparison of features ucontext and fcontext provide. A table of limitations/implementations/platforms like Limitations\Methond ucontext fcontext Signals ... Performance ... d) Description of member functions of boost::context is too brief. e) Implementation details description should be given. f) Better examples should be provided, I've attached few programs I used to test Boost.Context that implements yield like iterator and using context with Boost.Asio in thread like run and such examples should be given. If you want to use the code of the exapmples, consider them under BSL. g) The option context-impl is removed in alternative version and mistakenly was left in the docs. > What is your evaluation of the potential usefulness of the library? It is useful. I implemented a simple client server using Boost.Asio and Boost.Context that switch contexts on async requests and it was quite easy and straight-forward and brings very interesting paradigm to C++. I also had implemented a yielding iterator and it is was very nice, I like a fact that I have such concepts in C++. > Did you try to use the library? With what compiler? Did you have any > problems? I tested in on Linux x86_64 with gcc-4.4 I had problems that executable crashes using shared object libboost_concept.so and fcontext (when it is not compiled with -fPIC which is correct!) The author confirmed the bug and fixed it, no more problems seen. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I mostly tried to implement several tools like iterator and use it with Asio. I run some benchmarks and was quite impressed with fcontext performance. I spend about 6 hours on reviewing this library I implemented a simple client server using Asio and Context where in one case one side was reading and other writing and in other case it was echo server and client benchmark results were quite nice: Reader/Writeer Asio ------------------- Real-Threads, 2 CPU 0.95s Real-Threads, 1 CPU 1.53s ucontext 3.58s fcontext 2.90s Asio-Async 2.84s Echo Asio ---------- Real-Threads, 2 CPU 12.30s Real-Threads, 1 CPU 6.58s ucontext 7.24s fcontext 5.23s Asio-Async 5.24s So I think it is very good base to start from. > Are you knowledgeable about the problem domain? I hadn't used ucontext and fibers before, but I'm familiar with event driven programming and threading. I have large experience and asynchronous programming and implemented once threading support for MS DOS and for Z80. Additional Unrelated Note: -------------------------- Would you consider to create C version of Boost.Context or create C API. It is very useful to have fast setcontext/makecontext operations in C because it may be useful for too many systems where C API is must easier to integrate then C++. Best Regards, Artyom Beilis

2 3

Missing Documentation on Building and Installing Documentation.
by Stirling Westrup 23 Mar '11

23 Mar '11

I'm currently working with boost 1.46 which I downloaded from the main boost site and installed a few weeks ago, without a hitch. Just now I went to check in /usr/local/share/doc for the boost documentation, and discovered it wasn't installed when I asked bjam to install. So, how do I ask bjam to make the documentation, and to install it? I would like to have a local copy as I'm not always going to have internet access when working. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup

7 14

[random] Major update
by Steven Watanabe 23 Mar '11

23 Mar '11

AMDG I've nearly finished preparing Boost.Random for the next release. Here's a summary of the changes. I still have some minor clean-up, but it's mostly stable. I'd greatly appreciate it if anyone wants to take a look at it. If you have issues with any of this, speak up now, while it can still be changed relatively painlessly. * Synchronized with the new standard. - Many new distributions added: chi_squared_distribution, negative_binomial_distribution, fisher_f_distribution, student_t_distribution, weibull_distribution, extreme_value_distribution, discrete_distribution, piecewise_constant_distribution, piecewise_liear_distribution - Renamed uniform_int and uniform_real to uniform_int_distribution and uniform_real_distribution. - Added members to all distributions: param_type, param, stream operators, comparison operators, min and max. - Allow distributions to be used directly with generators without use of variate_generator. - Changed the meaning of the parameters of geometric_distribution and lognormal_distribution. - Added a second parameter to gamma_distribution. - Added seed_seq and added the corresponding constructors and seed overloads the generators. - Added generate_canonical. - Renamed the engine tempates. e.g. mersenne_twister becomes mersenne_twister_engine. - New engine adapter independent_bits_engine. - Added new predefined engine typedefs: mt19937_64, ranlux[24|48][_base], knuth_b. - Updated seeding algorithms. - Added discard - Use unsigned types instead of signed types in all the predefined engines. * Bug fixes: - linear_congruential_engine could assert because the modular arithmetic was not implemented in all cases. shuffle_output, now called shuffle_order_engine, could cause integer overflow. These cases were not triggered by any predefined engines. - uniform_small_int now actually behaves as documented. * New efficient algorithms for binomial_distribution and poisson_distribution. * Moved all features into namespace boost::random * Complete rewrite of the tests - Use Boot.Test's automatic registration and make better use of its test tools. - Statistical tests of the distributions - Separate tests for each engine and distribution Backwards compatibility issues: * The seeding algorithms have changed. This was unavoidable for compatibility with the standard. Not to mention that some of the existing algorithms were weird and inconsistent. - Seeding with an integer: The behaviour should be unchanged for most generators except lagged_fibonacci and subtract_with_carry (and thus ranlux). - Seeding a generator with another generator: This has been enabled by making all all generators models of SeedSeq. Therefore, if you seed a Boost.Random generator with a non Boost.Random generator, your code will no longer compile. The algorithm has changed, so code using this seeding method will yield different values. - Seeding a generator from a pair of iterators: This implicitly assumed that the elements were 32-bit integers in some places, but not everywhere. I've added this requirement everywhere and updated the algorithms accordingly. The behaviour of generators with a value_type no more than 32 bits should be unchanged, but I have not verified this. I've added tests to make sure that the algorithms can't be changed accidentally. * Renaming: - Whenever I renamed a class, I provided a wrapper with the old name. There are also using declarations in namespace boost for everything that I moved. - The names of a few accessors in the distributions changed. I left both the old and the new names in place. * geometric_distribution and lognormal_distribution: - The behaviour is different at runtime. boost::geometric_distribution and boost::lognormal_distribution provide the old behaviour, boost::random::geometric_distribution and boost::random::lognormal_distribution provide the new behaviour. * Streaming: gamma_distribution has a new parameter, thus text saved with the old version will not readable by the new version. I haven't tried to deal with this. do people consider this important? * variate_generator: variate_generator is now a simple pass through wrapper. Code that assumes that it will adjust the generator's result type to match the distribution will no longer work. This is not an issue with any of the distributions provided by Boost.Random. * Return types: The result_types of some generators have changed slightly. Hopefully no one is depending on it being int instead of unsigned... * has_fixed_range: - This is now always false, as it doesn't appear to be very useful and is excessively cumbersome. Anything that was accessing const_min and const_max without first checking has_fixed_range was incorrect to begin with. I think that covers the breaking changes. If there's anything else, it's probably a bug, and I'll try to fix it. A few thing I know about, but haven't changed: * lagged_fibonacci comparison is not technically correct. It's possible for operator== to return false in some cases where the generators will actually produce identical (infinite) sequences. The probability that this will ever actually happen is very small. (As in 2^{-20000} for lagged_fibonacci607) * Similarly the textual representation of lagged_fibonacci is inconsistent with that used by the mersenne_twister and subtract_with_carry. Changing this would make old records unreadable. In Christ, Steven Watanabe

5 10

[context review] Review - alternative version available
by Oliver Kowalke 23 Mar '11

23 Mar '11

Hi, I've uploaded an alternative version to boost vault (boost.context-alternative_version.zip : http://tinyurl.com/6fpnkro) The documentation is available at http://ok73.ok.funpic.de/alternative/boost/libs/context/doc/html/. changes: - fixed bug for x86_64/sysv/elf assembler file: missing assembler directive .type added - as suggested by Artyom and Vicente: - assembler implementation and native implementation of context switching functions compiled and applied as template arg to context<> -> context<> == context< protected_stack, asm_impl > on UNIX, context< protected_stack, native_impl > on Windows - for Windows assembler implementation is disabled Oliver

3 11

Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
by Oliver Kowalke 23 Mar '11

23 Mar '11

> I see that Boost.Fiber is on the review queue, but Boost.Tasklet and > Boost.Task are not yet? boost.tasklet will be renamed to boost.strand (see my git repo). because all of those lib require boost.context and hafe to be reqorked (except boost.fiber) the review wizards requested to remove boost.task from the review queue. If boost.context is accepted and in a final state I'll request a review for the other libs. > > Boost.Context allows to select the mechanism provided by the operating > system (ucontext on UNIX, Windows Fibers on Windows) or a faster > implementation provided by this library (fcontext using assembler). > > Note on the alternative implementation: I am not enthused about the > idea of embedding the fcontext decision in source code. I would rather > make that decision externally in the build machinery. I've pulished an alternative version of boost.context - the user can decide in its code which implemention should be used. > void (fn)(void*) and void* vp are very classic-C. While I'm sure there > are those who prefer to work at that level, I'd also want overloads > supporting a templatized nullary callable, like Fiber, plus the > args-for-implicit-bind variant. Hopefully Fiber and other high-level > abstractions implemented on Context could simply leverage Context's > support rather than reimplementing it. Since every library built on > top of Context will want to support those constructs, if that support > can be centralized in Context, it should be. Becuae most of the work is done ins assembler I'd like to keep the things simple as possible. Supporting templatized ctors + args-for-implicit-bind variant would make the assembler too much complicated and thus error prone (different C++ calling conventions on the platforms etc.). So I want to stuck with the C-style callback and track boost.context as a building block for other libs providing higher abstractions. > I'm not sure I understand the usefulness of a context object not > currently associated with a stack object, but I realize that > corresponds with a state designed into the underlying machinery, e.g. > ucontext.h. Oh: the initial current context doesn't manage an explicit > stack. Maybe a base class that represents a context with implicit > stack, and a subclass that represents a context with explicit stack? You have to differentiate between a context created to execute a new execution context (the ctor accepting funtion, stack etc.) which manages its own stack (passed as argument) and the context instance grapping the current execution context (default ctor) which collect the CPU state but does not manage the current stack because it its already managedd by the operating system (in the case of main()-function for instance) or by another context create by its ctor with protected_stack instance as argument. void main() { ... // ctx1 grapps the current CPU state // but does not manage a stack because the // current stack belongs to the operating system/process context ctx1; // ctx2 represent a new execution path executing my_fn() // it manages its own stack context ctx2( my_fn, 0, protected_stack( 65536) ); // now we jump from the curretn execution context ctx1 // to the new execution context ctx2 which will execute // function my_fn() ctx1.jump_to( ctx2); // we return from my_fn() == jumped out of execution context ctx2 // back to ctx1 ... } ctx1 pin-points (you could have mutliple) a specific point in the code/execution path. > (Is the static variable that underlies boost::context::current() > thread-local?) context has no static variables and no boost::context::current() (maybe you are using an old version?). > Fiber-local-storage on Windows: may I suggest a context-local<T> > abstraction for this library, implemented as Fiber-local for the > Windows Fibers implementation and thread-local elsewhere? hmm - this what I want to handle in libs with higher abstractions. So boost.context can be thin as possible. > Exceptions: "must not throw exceptions" may be too limiting. It's hard > for a typical coder to guarantee that no underlying code will throw. > Of course you could require that every fn passed to context's > constructor must have an explicit outermost try/catch(...) -- but > that's the sort of boilerplate that's easy to forget. context could > provide a wrapper containing that try/catch(...). In fact, you could > even use Boost.Exception to propagate any such exception to "somewhere > else" -- perhaps a context user's policy decision? Then one such > policy choice could be "I guarantee no underlying code will throw," > for those anxious to avoid the overhead. The function which is pased as first argument to the ctor of context must not throw. The reason is that it is passed to C-functions (== functions declared as extern "C") and throwing an exception through C-code results in undefined behaviour. > Exception management may feel like a topic best left for a > higher-level abstraction -- but I don't see how that could work. If > the higher-level abstraction is implemented in terms of Context, and > if Context flatly forbids exceptions, how could the higher layer > support them? Exception hamdling should be done by higher abstractions. For instance using packaged_task/future (as shown in boost.tasklet). > On the other hand, if it *is* reasonable for Context to defer > exception support to a higher level, then the documentation should be > revised to state the requirements for that support. I believe yes. > What's the use of a stack object representing not-a-stack? Wouldn't > the abstraction be simpler and more robust if every stack object is > guaranteed to represent a valid stack? That would seem to simplify > some of the semantics of Context as well. stack must support move-semantics -> a moved stack must be represented == not-a-stack. This is usefull for reducing memory allocation/deallocation for stacks. boost.tasklet reuses (== moves) stacks from a context which is finished and caches the stack. If a new context has to created in moves the recycled stack into the new context. That's trhre reason why stack must be move-able. > That said -- I'm a bit concerned that the documentation seems to imply > that stacks always grow downwards. Are we really never going to > encounter machines on which the opposite is true? Shouldn't the stack > concept include some support for directionality? On all platforms I've been working on the stack grows downwards. > The stack concept is fairly dense. Would it make any sense to define > an actual stack abstract base class? Because Context is > template-based, an implementation can (and protected_stack should) > avoid that base class -- but it could provide user stack > implementations with a starting point. because the stack is a template argument of context it represents an implicit interface - so no explicit interface like abstract_stack is required. The current solution doesn't require stakc to derive from a base class. > Thumbs up on providing protected_stack rather than a plain memory area. protected_stack appends a guard page at the end of the stack. This guard page issues sefault/access violation if you acces the address of that page. This is usefull if the size of the stack is too small. Ypou could use your own stack implementation without such a guard page. But if you excced the stack range you overwrite in the worst case the memory of your own application. > Again, the need to account for a context object that isn't currently > managing a stack feels like clutter. see above - pin-point of current execution path/context > The Boost.Coroutines documentation contains a discussion of the > possible unreliability of the GetCurrentFiber() == 0x1E00 trick, and > the value of calling IsThreadAFiber() on systems that support it. I > note some ambivalence in context_fiber.hpp about that. Why is the > IsThreadAFiber() implementation commented out? That is because of the fact that Windows XP + Sevice Pack 2/3 defines _WIN32_WINNT >= _WIN32_WINNT_VISTA but doesn't declare ::IsThreadAFiber(). I didn't found a way to detect XP + SP 2/3 beside of _WIN32_WINNT. > > - What is your evaluation of the documentation? > > At first I was confused about the usefulness of release_stack(). moves the stack out of the context instance for inspection or recycling > The Boost.Coroutines documentation notes that you can save the cost of > ConvertThreadToFiber() and ConvertFiberToThread() per round trip by > explicitly calling ConvertThreadToFiber() beforehand. > context_fiber.hpp is implemented the same way; presumably the same > note could be useful. Or are you assuming that all cycle-conscious > users will select the fcontext implementation instead of the Fiber > implementation? Holger Grund has some concerns regarding exception handling in the assembler implementation of fcontext on Windows. So I've dissabled it - maybe if I could fix it I'll make it available too. > There's a confusing phrase in the description of stack::address(): > "Function void* address() must return the address where the stack > begins to grow downwards (to lower addresses)" -- so far so good, with > a nod to the note above about stack direction -- "and the stack must > be moveable." see my comments above > This seems to say that the Context library might move the block of > memory in which the processor allocates stack frames. But that would > completely invalidate data residing in those stack frames! I *think* > the phrase is intended to mean that any class implementing the stack > concept (the object containing stack pointer and size) must be > moveable. Either way, the intent should be expressed more clearly. > What is that phrase doing attached to the description of > stack::address(), anyway? do refere to moving the stack out of a context? then this don for reusing that memory junk - otherwise the stack get deallocated. > I intend to try replacing that Boost.Coroutines Pth implementation > with a Context implementation. (Those who still care about OS X 10.4 > could then provide a Context implementation based on Pth. However, I > myself no longer care.) If Context is accepted into Boost, It strikes > me that a version of Boost.Coroutines based on Context would be a > useful evolutionary step in the Vault. I'm interessted in porting boost.context to MAC OS X (some first stepps in Jamfiles -> allow ucontext) - unforutnately I've no box running MAC OS X. I hope we can work together. best regards, Oliver -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

2 1

[GSoC11] Checks & Hashes
by Mateusz Nowak 23 Mar '11

23 Mar '11

Dear Paul A. Bristow, I'm 3rd year Informatics student at ETI, Gdańsk University of Technology and I'm highly interested in participating in GSoC 2011. I choose boost and "Checks & Hashes" project idea, because it meets with my coding abilities and "always try to make something useful" general rule. I have 7 years experience in programming and algorithms. I would rate my knowledge: c++ 4/5, svn 3-3.5/5. Some questions about the project. As CRC class seems to be only separate hashcodes library in boost, should the rest of algorithms libraries at least try to inherit crc methods naming and parameters convention or, if decision to use completely different convention, the crc library should be adapted or left as it is now? Actual naming idea is that function name should start with algorithm type - if it produces checksum or hash, than algorithm name (sha, crc, ...) and then variant (like in sha: sha1, sha256,...), so sha1 function name will look like h_sha_1, or for "Simple modulo 256 etc check values and digits." it will be c_simple_256. How many algorithms you expect to be found/implemented, documented, tested and got to work more or less? This would help me making work plan. Also i will have exams between 8-21 June, so my commitment to the project at that time will be low. I hope that this won't be a problem. Regards, Mateusz Nowak.

2 1

Boost related topics proposed by the CGAL Project at the Google Summer of Code 2011
by Andreas Fabri 23 Mar '11

23 Mar '11

Hello, The focus of the CGAL Project is computational geometry, and we use boost wherever it makes sense. We are mentoring organization at the GSoC 2011, and we are looking for students who master boost and who are interested in replacing home-grown solutions by boost solutions in the CGAL library. We propose two topics: Replacing some Basic Non-Geometric Tools in CGAL by Boost/TR1/C++0x Functionality http://www.cgal.org/project_ideas.html#boostification Switching from CGAL::HalfedgeGraph to boost::PlanarEmbedding http://www.cgal.org/project_ideas.html#embeddedGraph Best regards, Andreas Fabri

1 0