- Boost - lists.boost.org

[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