- Boost - lists.preview.boost.org

Phoenix: error: extra ‘;’ on boost/phoenix/core/environment.hpp
by Vicente BOTET 15 May '11

15 May '11

Hi, There is an error on In file included from ../../../boost/phoenix/core/call.hpp:12, from ../../../boost/conversion/fp/convert_to.hpp:15, from builtins.cpp:16: ../../../boost/phoenix/core/environment.hpp:446: error: extra ‘;’ It seems that the error: extra ‘;’ are on lines 433 and 444 at the end of two functions definitions. Could this be fixed? Thanks, Vicente

5 6

[countertree] New Version
by Francisco José Tapia 15 May '11

15 May '11

Hi this message is to announce the new version of the countertree library. You can find the zip file with the code and the documentation in < http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam…> or if you want a quick look , you can see in my web page < http://fjtapia.webs.com/works/countertree/index.html> Technically this library is an implementation of a binary red-black counter tree. Colloquially is a balanced tree with an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container. If the information stored is unordered, we have the class boost::vectortree. This class have the same interface than a std::vector. The std::vector is very fast O(k) inserting and deleting at end , but very slow O(N) if you must do in other positions . In the vectortree all the operations are O(logN). It is a bite slower than std:vector inserting and deleting at end, but much more faster for to insert and delete in any other position. If the information stored is ordered, you have the classes boost::set, boost::multiset boost::map and boost::multimap. These classes have identical interfaz than the std::set , std::multiset, std::map and std::multimap, and additionally, access by position with the function at(pos). The iterators are random access and have a function pos() which return their position in the container. You can mix safely access by iterators and access by position. The performance of these classes are similar to the classes of the STL. #include <boost/countertree/set.hpp> #include <iostream> int main ( void ) { //------------------------ begin -------------------- boost::set<int> A ; for ( int i = 0 ; i< 100 ; ++i) A.insert(i); for ( int i = 0 ; i < A.size() ; ++i) std::cout<<A.at(i); return 0 ; }; For to show the utility of this, imagine a large unordered file with the information about the employees of a big company. You have indexes implemented with multimaps, with pairs [value, position], and use the upper_bound and lower_bound functions . You need to select the employees in a range of age and weight. With the boost:multimap you can know the number of elements of the selection. In the weight query we found 100 elements and in the age query 10000 elements. To travel the elements of the weight query asking for the age, is faster than the opposite. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC (32 and 64) and Visual Studio 2008 (32) and Visual Studio 1010 (32 and 64). Please, if you find any problem, please mail me ( <fjtapia(a)gmail.com>) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. Francisco Tapia <fjtapia(a)gmail.com>

7 12

Phoenix: is there a Phoenix expression trait?
by Vicente BOTET 15 May '11

15 May '11

Hi, I'm adding a convert_to Phoenix like functor to Boost.Conversion. I would like to use the same name, i.e. convert_to, but the overloads conflict. I would like to use sfinae to choose the correct overloading between template inline typename expression::convert_to, U>::type const convert_to(U const& u); template Target convert_to(Source const& from, boost::dummy::base_tag const& p=boost::dummy::base_tag()) Is there a trait that can be used to detect if the parameter is a Phoenix expression? BTW, I have just based my implementation on the one for static_cast, that uses the detail boost::phoenix::detail::target Could someone explain me why this is needed? Could this detail be moved to the user interface? Best, Vicente

3 2

[context] new version (stack unwinding, ASIO example, ...)
by Oliver Kowalke 14 May '11

14 May '11

Hello, I've reworked on boost.context regarding to the suggestion of the last review (thanks to Vicente as review manager) - but not all requests could be fulfilled. The new lib supports stack unwinding, has examples like C# enumerator concept (yield_return(), yield_break()) and an adapted version of a echo server using stack-less coroutines written by Chr. Kohlhoff and Java continuations. The new version (boost.context-0.7.0.zip) is published on boost vault and the documentation can be read here : http://ok73.ok.funpic.de/boost/libs/context/doc/html/ . Best regards, Oliver

1 0

[BGL] container_gen (was Re: [tree] reviving the tree library)
by Cromwell Enage 14 May '11

14 May '11

--- On Fri, 5/6/11, Erik Erlandson wrote: > My storage models are effectively wrappers around the > underlying containers (the container is a member of > the node type). I originally thought it would be nice > to allow a user to somehow drop in any container they > wanted, but I was unable to find a way to make that > work properly. [snip] > Perhaps container_gen would allow it to be more fully > automated. The idea behind container_gen is indeed to allow users to drop in containers of their choosing by providing their own specializations and selectors. In turn, your node class template needs only to take in the selector type as an additional template parameter. One current limitation that may be important to you is the inability to supply custom allocators as well. I saw in the sandbox that the BGL authors were planning to provide selector templates parameterized by allocator type. I'm wondering how that work is progressing. At any rate, to the BGL authors: I find container_gen to be a useful utility metafunction outside its current home. Would anyone else like to see it become a first-class Boost citizen? Cromwell D. Enage

3 5

[signals2] trunk - vc++ 10 warning about assignment operator
by Edward Diener 13 May '11

13 May '11

An attempt to instantiate a signals2 signal of the form: template <class T> class notification_boost_signal2 { public: boost::signals2::signal<void (const i_some_interface<T> &,boost::optional<T>,T)> sig; }; for notification_boost_signal2<char>, gives the error message in vc++ of: "C:\Programming\VersionControl\boost\boost/signals2/detail/signal_template.hpp(367) : warning C4512: 'boost::signals2::detail::signal3_impl<R,T1,T2,T3,Combiner,Group,GroupCompare,SlotFunction,ExtendedSlotFunction,Mutex>::slot_invoker' : assignment operator could not be generated" There is a huge template trace leading up to this final warning, but before giving it I wonder if anyone knows what it is about ? Perhaps Frank Mori Hess or Douglas Gregor is out there and can tell me what is happening.

3 4

[Block Pointer] multithread help
by Phil Bouchard 13 May '11

13 May '11

Hi everybody, I was wondering if there is anybody familiar enough with Block Pointer that could give me a hand regarding multithread support. Once again the test file is at: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/th… The main class I am trying to protect with a mutex is block_header from: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp Thanks, -Phil

3 7

[multi_array] Is there interest for an [index_list] library?
by Pierre-Andre Noel 13 May '11

13 May '11

(This email has earlier been sent to the wrong list. Thanks to Steven Watanabe for pointing that out.) Dear all, I would like to gauge the interest of the community in a library that can serve 1) as a complement to Boost.MultiArray and 2) as an alternative to Boost.MultiArray. For the first type of use, an example of the candidate library's capabilities is that it makes available a special iterator "it" that allows to browse all the elements of a MultiArray "m". This special iterator has an it.indices() members that returns a "list" Collection of indices (i.e. an IndexList) such that "m(list)" and "*it" are the same elements. This can be useful for functions whose effect on an element of "m" depends on where this element is situated in "m". The second way to use the candidate library is as an alternative to Boost.MultiArray of dynamically chosen (execution time) dimensionality. Moreover, the elements do not necessarily need to be arranged in a multi-dimensional "box", as is the case in a MultiArray. For example, a "simplex" organization of the elements is already implemented. If you are interested to know more, I strongly suggest you to take a look at the example file in sandbox/index_list/libs/index_list/examples.cpp . The library itself is in sandbox/index_list/boost and a readme file (with some details concerning concepts and "priorities") is in sandbox/index_list/libs/README . An automatically generated (Doxygen) documentation is located in sandbox/index_list/libs/index_list/doc/index.html . Sadly, there is no "real" documentation for now. Many thanks for your time. Sincerely, Pierre-André Noël

5 11

boost lib must provide C interface?!
by Oliver Kowalke 13 May '11

13 May '11

Hi, can a boost C++ library be required/forced to provide a C API? Even if the library author doesn't like this idea - because he would be responsible for C stuff. <boost/config.hpp> include <cstddef> which will not be available for a C compiler - maybe this is an indication that boost libs are not required to implement a C-API. regards, Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

5 6

Testing Problems
by Christopher Jefferson 13 May '11

13 May '11

Apologises, the following message is going to be a fairly long list of complaints. However, I wanted to post them rather than just let them disappear. Some background: I previously worked on getting clang and libc++ working in boost, in both c++03 and c++0x mode, submitting a large number of patches to achieve that goal. I also ran regression testers for this libraries. I am broadly planning on giving that up, unless various things improve in various ways. That isn't a threat, just I don't have the man and CPU time to spare working around issues in boost. Problems: 1) Running the boost regression tests takes unacceptably long. I would like to run tests for clang with and without libc++, with and without c++0x mode. Running those 4 sets of tests takes a huge amount of time. Various tests (and I keep meaning to try to find which ones) take huge amounts of memory, meaning it isn't reasonable to run even a single-threaded boost regression test in the background on a 4GB machine. Running tests in parallel doesn't seem to speed them up particularly, while bringing the machine even more onto it's knees. 2) The boost regression testpage ( http://www.boost.org/development/tests/trunk/developer/summary.html ) is fairly useless, as it doesn't say when a particular test failed. This means I just have to try to memorise the current state of all the compilers I am interested in, and look for new fails by eyeball. Much more useful would be changing the 'fail' to the most recent svn version at which a new fail occurred? 3) I always find trac hard to use. I usually want to do 2 things: a) Find all open bugs attached to package X b) List all bugs which I filed, or have have submitted a message to. I find both of these easy to achieve with bugzilla, and not with trac. 4) Getting patches, in particular very simple ones (like warning suppression) can take multiple prods and can languish for a long time in trac. I'm not sure what the best solutions to all of these problems are. Obviously they could each be tackled but several of them would involve changes to many different boost libraries, which is something I find can be like pulling teeth (some maintainers are extremely good, I certainly don't want to tar everyone with one brush!) On practical note, is it time for boost to move to officially supported compilers for each release? These could easily be read off the testing page (no test = not offically supported), and the packages which do not pass testing could be briefly listed in the release notes. This might have the advantage of encouraging more people to run tests, if they want their compiler to be offically supported. Apologises for the lengthy rant, Chris Jefferson

2 1

[review] string convert
by Gordon Woodhull 12 May '11

12 May '11

Hi Vladimir, Ed, all, It is a curiosity of Boost reviews that a vote of conditional acceptance is actually more powerful than a No vote, because if you vote No, the author might try to convince you to change your vote but otherwise has no incentive to listen to you any further. Therefore I vote to accept this library with the strong condition that a simpler syntax be adopted, doing away with the odd static ::from() function, and completely getting rid of the confusing, error-prone lazy functions. I am aware that the author thinks the present syntax is necessary, but I will argue against it in each case. (As another meta-review comment, I've noticed a few authors saying they won't consider any changes unless their library is accepted. This sets up a deadlock situation: the reviewer will not accept the library without the changes, and the author won't make the changes without acceptance. Everyone digs in their heels and nothing gets done. I think any author who really wants their library to be in Boost should be willing to submit it for a second review. And I think reviewers should tend toward conditions on acceptance rather than no votes. My two cents.) > - What is your evaluation of the design? That's the focus of my review, specifically, the design of the interface. Supplying a default value, a don't-throw option, and applying manipulators/locale, are the major features missing from lexical_cast. So I think there is no doubt that a library like this is needed, if lexical_cast can't be upgraded. And according to its author, lexical_cast can't be upgraded because it must look like a cast and all these features require more parameters (template or actual). So, fine, let's have a replacement that's not .*_cast. It is incredibly clear what lexical_cast does because it uses the standard meaning of the operators, function calls, and return values. There is a lot of value in that. I don't think it's always a bad idea to have lazily evaluated objects or creative uses of operators, but IMHO if it is possible to do something more clearly with the standard order of evaluation and standard use of operators and function calls, then that should be preferred. The interface of the proposed Convert library is not simple enough. To start out with the most annoying thing, I don't like "::from" at all. The replacement should look as close to lexical_cast as possible. So, why the extra '::from'? Even though I disagree with the lazy evaluation (see below), even that doesn't seem to require this weird static member syntax. Is '::from' just so that '::result' will not feel lonely? For the rest of this review, I'm going to refer to convert<T>::from(s), but please keep in mind that I really think it should be something like string_convert<T>(s). So, next '::result'. It's some form of optional return. So why not just return optional? It is not much less to type convert<int>::result maybe = convert<int>::from("not an int"); versus optional<int> maybe = convert_cast<int, use_opt>("not an int"); (Where use_opt might also be spelled dont_throw, opt_out, .. I don't really care. Yes there may be problems because of the necessary deduced template argument for the source type. But isn't there a way around that with Boost.Parameter?) Why should the LHS modify the behavior of the proxy object returned by ::from? It's far too much to think about for such a simple operation. I'd rather the function clearly did or didn't throw on its own, not be influenced by its context. Lazy evaluation in expression templates is typically used to offer some kind of declarative syntax. So let's ask ourselves if that is needed here. The main innovation here is a lazily evaluated object which can then - throw or not throw based on its context convert<int>::result i = convert<int>::from("not a string"); - take iostream manipulators, which are applied before the conversion takes place. - take additional options through a second application of function call operator (!) All of these uses defy the way we ordinarily read function evaluation. What, the conversion is now feeding some data into std::hex? And then where does it go after that? It gets returned? Weird. The right shift operator was chosen in the standard because it depicts an arrow; otherwise there is nothing that says I/O about it. Thus the only way this syntax would make sense to me is if it were int i = std::hex >> convert<int>::from("deadbeef"); and then unfortunately it would be impossible to have more than one manipulator without some horrible parentheses, because of the left associativity. I don't like the look of streaming operators that lead nowhere. No, why not just int i = convert<int>::from(s, std::hex); ? Or from(s, _manip = std::hex) Or, at worst (and I don't see why this is necessary) from(s)(_manip = std__hex); If you want the operator syntax, just do int i; stringstream(s) >> std::hex >> i; If it's really got to be one line, a syntax like int i = stringstream_(s) >> std::hex >> ret_; would at least make sense and I'm sure that there's a way to do that almost as succinctly using Phoenix. On a similar nice-feature-but-weird-syntax note, let's look at the Using Boost.Convert with Standard Algorithms section, which offers a few ways that you can use convert<T>::from() to create a functor: std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<int>::from(string(), -1) >> std::hex); std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<int>::from<string>()(fallback_ = -1) >> std::hex); Apparently if you pass an empty string or omit the parameter to from(), it creates a function object which takes a string as a parameter. Is this correct? This seems like it would have unwanted consequences, since we now have a function object that can take either extra options or the string input. Again, I'm not against clever syntax, but this seems promiscuous and confusing. I think it would be much more appropriate to provide a Phoenix function object for the purpose, something like std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert_<int>(_1, -1, std::hex)); Sigh of relief. I see what that means immediately, and it doesn't make me worry about what convert's going to do if I forget a parameter. I agree with Jeroen's request for a default-constructed version. I don't see why no syntactic sugar could be doled out for this, a _defcon (template or real) parameter or whatever. I also want to mention type-to-type conversion, which Vicente Botet has thought out much more thoroughly in his Conversion library. This library offers type-to-type conversion seemingly as an afterthought, just because the syntax allows it. I definitely see the value of a conversion mechanism that first looks for a direct type-to-type conversion and then defaults to using type-to-string-to-type. I just don't think conversion should always do that, and I don't think such a mechanism should be called plain convert. It does make any more sense to call such a thing plain convert than it does to start optimizing lexical_cast with special cases that don't use strings (sorry!). It would be called best_conversion or something that conveys that it's doing the best it can based on what converters have been "installed" at compile time. Again my objection is not to the functionality but to an obfuscating interface where you're not sure what behavior you're going to get. I feel the same about the string-to-string conversion: it seems to be in there just because the syntax supports it, not because it actually makes sense here. I guess this is because library is called Convert instead of String Convert or Via Stream Convert, which is its main focus (and rightly so). Apologies for repeating this: I still don't get why the extra options go into a second function call operator. I found some earlier messages where you simply added those to the first function call. Simplify, simplify, simplify the interface. Please. To summarize, I don't get why we can't just have this simple clear syntax: optional<int> i = string_convert<int, dont_throw>(s); // or string_convert<int>(s, _throw=false) if that's impossible int i = string_convert<int>(s, manip_ = std::hex); It's (plain) functional. There's no question when things get evaluated or thrown. I don't care about any of the particular names used, just the syntax. > - What is your evaluation of the implementation? I read the code enough to answer my own questions about what the library actually does. As noted, I disagree with many design choices, but the implementation seems fine. The only thing that caught my eye as a little strange is that there's the string_sfinae namespace and header which in fact contains a bunch of metafunctions which are sometimes used in sfinae and sometimes just used as metafunctions. Obviously not a big deal, just some metonymy or historical artifact there. To return to convert<>::result On Apr 27, 2011, at 7:07 PM, Vladimir Batov wrote: > They, indeed, seem to provide *similar* functionality. In fact, convert::result *uses* boost::optional. If you have a look at convert::result (it's quite small), then everything else in addition to boost::optional is what convert::result adds. In words, IMHO convert::result is better than boost::optional tailored for its domain (conversions). So you made me look. I conclude that the only functionality it adds is the ability to delay throwing on error until the result::value() is called, am I wrong? I don't understand why you'd want this, because I thought the whole point of using ::result was when you didn't want to throw. But maybe I'm missing something. Again I think this could all be SO much simpler. > - What is your evaluation of the documentation? It's well written and explains the subject well. It seems a bit flippant in places ("I've included this and that because why not?" kinds of statements) and IMO that's because the focus of this library is a little too fuzzy. Stick to string/stream conversion, fix the problems with lexical cast. Don't try to build a general conversion framework unless you're really willing to think that through. I looked for a Rationale section that would explain why this functionality could not be included in lexical_cast, and could not find it. Vladimir, I know you said On Apr 26, 2011, at 6:47 PM, Vladimir Batov wrote: > I again urge you to please dig the archives to see why that "extra > functionality should be added to boost::lexical_cast" view is not exactly original and most importantly why it was decided *not* to proceed as you insist. But I don't think that's a substitute for explaining to new users why they can't get what they want with modest improvements on the lexical_cast interface. Why is it that they really want some fancy lazy function object / "declarative" interface? Likewise with this non-argument: On Apr 26, 2011, at 6:47 PM, Vladimir Batov wrote: > I've come to a firm conclusion that that additional > functionality/configurability is *not* implementable within the boundaries of the lexical_cast interface. In particular, the TypeIn and TypeOut types must be discriminated, i.e. one type has to be specialized first. Without going into details I'll just say that otherwise is just does not work. So, it has to be convert<TypeOut>::from<TypeIn>. You can take my word for it or you could walk that road yourself. Sorry, but I find this response either lazy or rude. You wrote the library: you explain to us why the way it is! I'd really like to know why you think it's necessary to do convert<T>::from(s) rather than the much more familiar and easy-to-grasp string_convert<T>(s). I don't want to try to write it myself to find out why it does or doesn't need to be that way. You entered a fairly contentious arena with a majorly different interface. Write a rationale and don't just tell us to search the list. > - What is your evaluation of the potential usefulness of the > library? Very, very useful. I use lexical_cast and am frustrated by the limitations. > - Did you try to use the library? With what compiler? Did you > have any problems? No, I did not - I see how it works and trust that it does. I was not tempted to start looking for ways to make the library produce surprising results because it was immediately clear to me from the interface design that those misbehaviors would exist. I'm not always a Keep It Simple person, but in this case, please do. Otherwise you're destroying one of the best features of lexical_cast. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I spent about 5 hours reading the documentation and code, and 5 hours reading/rereading the current reviews and writing mine. I wish I'd had time to go back to the earlier discussions, although I searched a little bit; again I think everything that could be learned there should have been in the Rationale. > - Are you knowledgeable about the problem domain? Moderately. I like to know how every construct I'm using works, and I gulp at the inefficiency of lexical_cast every time I use it, even though I never use it where efficiency matters. To further prove my point that conditional acceptance is stronger than voting no, note that I've basically made my yes vote conditional on fixing most of the things Thomas Heller complained about, notably On Apr 26, 2011, at 2:58 PM, Thomas Heller wrote: > Moreover, I don't get how the design really is superior to boost::lexical_cast, and why it couldn't been implemented as an extension to that library. (It can't take a .*_cast name, but it can use the simple syntax.) > The use of this converter function object looks like a nice concept at first sight but, as mentioned above, in the end, probably adds more confusion and problems than anything else. (It confused me and didn't look nice.) > I don't think that having everything hidden behind this static from function is wise and should be rethought. Different functions, for different purposes would be better suited. On Apr 27, 2011, at 5:14 AM, Thomas Heller wrote: > Even though you tried to be minimal and > simplistic, the function is overloaded with too different (in concept) > behavior that its really confusing to get what the function is really > doing. So my end result is that its not really minimal and > minimalistic, but bloated ... sometimes, more is less. (I think more template or function parameters could also do the trick.) I realize that my conditions mean some serious redesign, but this is an 834-line library and it would probably be even shorter without all the unnecessary lazy functions and weird out-of-place operators. I want to contrast this with my No vote in the XInt review, where I also had issues with the design. I would have voted for conditional acceptance of XInt if it were possible, but the changes there seemed like they would need additional review. String Convert is much simpler and I think that a compromise could be reached to (IMO) simplify the interface and answer most of the objections that Thomas, Jeroen, and I have made. I apologize to Ed for making a complicated vote. I'd be glad to clarify my position if needed. Cheers to Vladimir - you've identified an important problem! Now just give it a clear interface and we'll have something good. Gordon

13 163

[local] Help for the Alternatives section
by Lorenzo Caminiti 12 May '11

12 May '11

Hello all, I am updating Boost.Local docs and I could use a some help in getting the Alternatives section right http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… . How can I program the following code (its local function and `factor` constant binding) using Boost.Phoenix, Boost.Lambda, and C++0x lambda functions? If you know, can you please reply with the actual code? #include <boost/local/function.hpp> #include <iostream> #include <vector> #include <algorithm> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, // Variable `factor` bound as constant. bind& sum, const bind& factor) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) std::vector<double> v(3); v[0] = 1.0; v[1] = 2.0; v[2] = 3.0; // Local function `add` passed as template parameter. std::for_each(v.begin(), v.end(), add); return 0; } Thank you very much! -- Lorenzo

14 82

Delimiting protocol messages (was [asio] read_some() splits data)
by Marsh Ray 12 May '11

12 May '11

On 05/11/2011 09:36 AM, Andrew Holden wrote: > On Wednesday, May 11, 2011 9:57 AM, Slav wrote: >> Then messages of length not multiple of 128 (BUFFER_SIZE) >> will not be read - tested it, anyway, after >> last socket::read_some() (with readBytes> 0&& < >> BUFFER_SIZE) next socket::read_some() never ends. > > It would probably help to understand that TCP has no concept of a > "message". Anything you write to a socket is appended to a stream of > *bytes*. Alternatively, we could say that TCP, in fact, does have a well-defined concept of messages: they are all exactly one byte long. > Several subsystems on both the sending and receiving computers ... and sometimes boxes in the middle ... > will have the option of splitting and combining adjacent buffers with no > consideration to how big each individual write was. I've done a little protocol stuff with ASIO now and I must say it's a lot of fun and I can't go back to doing it any other way. > On further thought, I think I see the problem (and I apologize for the > bad recommendation in my last email). Your sender somehow needs to > communicate the message size or flag the end of the message. A partial > list of options includes: The pattern I encounter over and over again (often at multiple levels in a protocol) is: class protocol_layer_context { vector<uint8> buffer; void on_received_data(vector<uint8> & rx_bytes) { buffer.append(rx_bytes); // perhaps a virtual override. size_t msg_len = this->parse_len_from_start_of_buffer(); if (buffer.size() <= msg_len) { vector<uint8> msg_buf = consume_data_from_front_of_buffer(buffer, msg_len); // perhaps a virtual override this->process_complete_message(msg_buf); } // post another ASIO read request this->request_more_data(); } ... But there are some important issues with this naive pseudocode: 1. It can result in recopying the data a bunch of times for every protocol layer, killing performance. 2. It's susceptible to a denial-of-service (DoS). Bad guy can send trick you into allocating all your memory. 3. Sometimes the length of a message is stated at the beginning of the message, sometimes it isn't known until the end. 4. No processing happens on the message until it's completely read, but some protocols really need the receiving endpoint to process it incrementally. 5. Error handling 6. Optimal threading 7. Etc. We find bugs in exactly this logic all the darn time. Often the data being received is untrusted and possibly malicious. Real-world protocol implementations will commonly crash under fragmentation fuzzing, sometimes resulting in exploitable security holes. In a sense, this is the general refactoring problem of 'incrementalizing' a parsing function by moving all its state from stack variables into a longer-lived context object. We've seen it done successfully with coroutines, but that's not a commonly accepted solution because, frankly, the native C/C++ runtimes have not yet given coroutines the love (i.e., portability and performance guarantees) they really deserved. If someone figured out how to leverage generic techniques to handle just the unidirectional message delimiting problem in a bulletproof way I think it would make a really great boost library. - Marsh

1 0

Free BoostCon Registration
by Dave Abrahams 12 May '11

12 May '11

Unfortunately, two of our registrants had to cancel after the refund deadline. Fortunately, they have offered their registrations to anyone who might have not registered because of the cost. If you would like to claim these available registrations, please send email to our registrar, Marshall Clow (mclow AT gmail.com) Thanks, and see you in Aspen! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 1

[spirit][qi] Dynamically combine Boost.Spirit.Qi rules at runtime
by Daniel F. 11 May '11

11 May '11

Hi, I recently tried to combine an arbitrary number of rules as alternatives in Boost.Spirit.Qi. Since rules are implemented as objects it seemed feasible to me. My motivation was to make certain parts of my grammar easily extensible. Unfortunately, I ran into some problems, so I wrote a simple program (see attachment for the complete code) demonstrating the unexpected behavior. Here's the key part: // "Dynamic" version - Does not compile! :( /* std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); rule_t grammar; grammar = (*i)(qi::_r1); //[no_op] for(++i; i!=last; ++i) { grammar = grammar.copy() | (*i)(qi::_r1); //[no_op] } */ // "Dynamic" version - Kind of works! :-/ std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); qi::rule<iterator_t, int()> temp; temp = (*i)(qi::_val); //[no_op] for(++i; i!=last; ++i) { temp = temp.copy() | (*i)(qi::_val); //[no_op] } rule_t grammar; grammar = temp[qi::_r1 = qi::_1]; Now, I suppose that the first version (commented out) doesn't compile, because I'm not passing the inherited attribute down to grammar.copy(). I would love to know if there's a better way of doing this than the workaround that is the second version. The second version actually compiles and it seems to do the right thing. However, once I attach a simple semantic action as indicated in the code using comments (see "[no_op]"), the behavior becomes really weird. Rather than printing 0,1,2 as before, the program prints 0,0,2. So I'm wondering, is what I'm trying to accomplish resulting in undefined behavior? Is this a bug? Or, quite possibly, am I just using something (e.g. semantic actions?) the wrong way? Thanks for reading, Daniel

4 7

[convert] no-throw and fallback feature
by Vicente BOTET 11 May '11

11 May '11

Hi, I was thinking on the fallback feature a little bit more and I've the impression that we can get it for free. If we accept that we need a no-throw function such as try_convert_to that returns an optional Target we can have the fallback using the optional::get_value_or function auto r = try_convert_to(*int*)(s); int i = r.get_value_or(fallback); or just int i = try_convert_to(*int*)(s).get_value_or(fallback); or int i = get_value_or(try_convert_to(*int*)(s), fallback); I don't know if it is worth adding a function that does all in one int i = convert_to_or(*int*)(s, fallback); Best, Vicente

5 25

[autoindex] Review
by Edward Diener 11 May '11

11 May '11

This is my review of autoindex. - What is your evaluation of the design? Very clean and easy to understand. - What is your evaluation of the implementation? Did not look at the internals. - What is your evaluation of the documentation? Generally good. Here is a list of mostly grammatical errors: 1) Overview: "the HTML indexes look a lot less good" -> "the HTML indexes look a lot worse" Step 1: Build the AutoIndex tool: "Finally note that tools/auto_index/auto-index.jam gets copied into the same directory as the rest of the Boost.Build tools." -> I am not sure if this means that building AutoIndex does this automatically or the end-user must do it but the sentence grammar suggests the former, which does not happen for me. If the end-user should do it, the line should read "Finally note that tools/auto_index/auto-index.jam should be copied into the same directory as the rest of the Boost.Build tools." 2) Step 2: Configure Boost.Build jamfile to use AutoIndex "Always send the output to a log file. It will contain of lot of stuff, but is invaluable to check if all has gone right, and else diagnose what has gone wrong. -> ..."and also diagnose what has gone wrong." ..."or else diagnose what has gone wrong." 3) Available Indexing Options: For Document Type 'library', Available Index Types says 'See Chapter'. I am guessing this means it is the same as Document Type 'chapter' but it should be made clearer in the remark. 4) Step 7: Iterate - to refine your index: "You can restrict which sections are indexed for a particular term. So assuming that the docbook document has the usual hierarchical names for section ID's hierarchical names for section IDs(as Quickbook generates, for example), you can easily place a constraint on which sections are examined for a particular term. " ' -> remove the second repeated "hierarchical names for section IDs". "This would avoid an index entry every time ° kelvin is found, something the user is unlikely to find helpful. " -> "This would avoid an index entry every time 'Kelvin' is found, something the user is unlikely to find helpful. " 5) Script File (.idx) Reference: "Blank lines consisting of only whitespace are ignored, so are lines that start with a #. (But, of course, you can't append # comments onto the end of a line!). " -> I am guessing this should be: "...(But, of course, you can append # comments onto the end of a line!)." "recurse An optional boolean value - either "true" or "false" - that indicates whether to recurse into subdirectories. This defaults to "false" -> Needs a period at the end. "type The type to which items found using this rule will assigned, index terms created from the source file and then found in the XML, will have the type attribute set to this value, and may then appear in a specialized index with the same type attribute " -> Needs a period at the end. The only other issue in the documentation is that while there is very good documentation about what type of XML container wraps an internally generated index, I am not sure what this actually means to a Quickbook author. No doubt somewhere there is probably a discussion in Docbook of what these XML containers mean and do but, aside from experimentation, the user of AutoIndex is not likely to understand what it means to put the Index in a specific XML container and how this affects the final layout of the documentation. Perhaps some further explanation of what this actually means for an AutoIndex user, especially for a Quickbook document, would be appropriate. - What is your evaluation of the potential usefulness of AutoIndex? Immense. Searching through documentation of even mildly complex libraries which have little or no index is very frustrating. - Did you try to use it? With what compiler? Did you have any problems? I have used it for the documentation of my VMD and TTI libraries with both gcc and vc++ under Windows. Any problems were of my own making and the author of AutoIndex answered my questions when I was stuck. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A pretty deep study, although I have not tried to add anything to the index file other than 'scan' statements. - Are you knowledgeable about the problem domain? Yes. I vote for the library to be accepted into Boost. Edward Diener

2 1

inquiry about proposing a new Boost library for a tree template container class
by Erik Erlandson 11 May '11

11 May '11

Hello, I recently completed an STL-compliant template container class for storing data in an arbitrary tree structure. It seemed like it might be a useful component of Boost, and I wanted to ask about how new projects are submitted for consideration. The current incarnation of the project is called 'st_tree', and resides here: https://github.com/erikerlandson/st_tree/wiki Regards, Erik Erlandson

7 27

[type_factory] new utility/class proposal
by Vlad Lazarenko 11 May '11

11 May '11

Dear Boost developers, How many times in your experience you needed to associate a type with some identifier known at run-time only? It’s like having an associative container with numeric key and type as a value. Not object, but type. This is a concept similar to object factory pattern but with no objects, only their types. I call it a type factory. There might be a solution for this in Boost already but I haven’t seen it. Please forgive me if I am just being blind. Just to give you a little taste of what I mean – imagine that you have a stream of bytes where objects of different types and sizes are stored (serialized), and one byte identifying a type is preceding every such serialized object, and you need to parse it. One approach is to have a switch statement, for example, where all type identifiers are cased, and parse data depending on a type. But then, as list of types grows and/or shrinks, maintenance of this switch becomes unpleasant. And if this logic is in some base library, where user specifies list of types, it becomes even worse. There might be another way, I thought, and came up with sort of hybrid between compile-time types and run-time identifiers – a type factory. I am wondering if anyone else will find it useful. Perhaps we can have it as part of boost utility classes. Here is a very simple example of usage: https://github.com/Yocto/type_factory/blob/master/test/simple_example.cpp It gets a number from “argc”, and then, depending on its value, invokes “speak” method of either “cow”, “dog” or “alligator” classes. More functionality is covered in unit test. Basically, the type factory, given a list of types as “MPL vector“ is enumerating them from 0 to N. Later, for any given instantiation of “create” method, it generates a dispatch table for invoking of one of template methods (with no arguments) on a supplied “visitor” class. The source code of the class is here - https://github.com/Yocto/type_factory/blob/master/include/yocto/type_factor…. There are a lot of details, but the main class exposed to the user-land API is “type_factory”. Please let me know if you are interested in such a concept. Thank you, Vlad

2 1

Review manager needed for TTI library
by Edward Diener 10 May '11

10 May '11

I am looking for a review manager for my TTI library in the review queue. 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. Since I have acted as a review manager for another library, and have expressed my willingness to do so for some other libraries, I would appreciate it if someone, who understands Boost MPL well and the compile-time introspection problems my library solves, would be a review manager for my own library.

3 6

Re: [boost] [trolling] Alexander's crusade (was: [provocative] Whom did the SFC pay to list boostdevelopers as a whole in "Current Member Projects"?)
by Matt Chambers 10 May '11

10 May '11

> ... pointless quoted legal jargon... What's your point? -Matt

10 17

[container_bptree] first version of submitted library
by Vadim Stadnik 09 May '11

09 May '11

Hi all, The first version of submitted library container_bptree http://www.boostpro.com/vault/index.php?action=downloadfile&filename=contai… offers a number of STL variants of containers based on B+ trees. These powerful data structures enable the implementation of various useful extensions of STL containers and iterators. One of the most interesting improvements is the efficient algorithm accumulate(), which has computational cost *O(log N)* in the worst case. This algorithm can increase performance of solutions in numerous application areas, including traveling salesman problem. Please read the documentation and try the included test code. The current implementation has been developed for Visual Studio compilers (2008 and 2010). Portability of this library has not yet been tested. I would really appreciate if someone could compile and run the test code using other compilers and let me know if there are any technical issues. Any suggestions concerning improvements of the current version of this library will be carefully analyzed and implemented if possible. The potential of B+ trees has not yet been used to its full capacity. There are a number of options for further extensions of this library. The community interest and feedback will have an effect on the priority of the development of new features and efficient algorithms in future versions of this library. Thank you, Vadim Stadnik

2 2

[phoenix] not playing nice with other libs
by Eric Niebler 09 May '11

09 May '11

The following trivial program fails to compile: #include <boost/phoenix/core/limits.hpp> #include <boost/numeric/conversion/converter.hpp> It generates the following: In file included from ../../../../branches/release/boost/numeric/conversion/detail/is_subranged.hpp:17, from ../../../../branches/release/boost/numeric/conversion/detail/conversion_traits.hpp:21, from ../../../../branches/release/boost/numeric/conversion/conversion_traits.hpp:13, from ../../../../branches/release/boost/numeric/conversion/converter.hpp:13, from main.cpp:2: ../../../../branches/release/boost/mpl/multiplies.hpp:38: error: wrong number of template arguments (12, should be 5) ../../../../branches/release/boost/mpl/aux_/preprocessed/gcc/times.hpp:68: error: provided for ‘temp late<class N1, class N2, class N3, class N4, class N5> struct boost::mpl::times’ Phoenix is changing the following fundamental constants: BOOST_PROTO_MAX_ARITY BOOST_MPL_LIMIT_METAFUNCTION_ARITY BOOST_PROTO_MAX_LOGICAL_ARITY BOOST_RESULT_OF_NUM_ARGS IMO, Phoenix shouldn't be touching these. It should work as best it can with the default values. Users who are so inclined can change them. -- Eric Niebler BoostPro Consulting www.boostpro.com

13 40

Re: [boost] [tree] Reviving the tree library
by Cromwell Enage 09 May '11

09 May '11

--- On Fri, 5/6/11, Rene Rivera wrote: > On 5/6/2011 4:22 PM, Cromwell Enage wrote: > > What are your thoughts on a generalized depth-first > > iterator that also indicates whether it's currently > > in pre-order traversal mode, post-order traversal mode, > > or neither? I've found it useful for implementing > > scene graphs, for example. > > The goal was to make it possible to have any kind of > iteration. The ones in the TR are the simple common > ones. So yes, other iterations would be good to add. > I'm all for generalization. Are you thinking of the > static kind, as in traits, etc.? Or are you thinking > of something run-time? I was originally thinking of run-time generalization, i.e. the depth-first iterator being a functional superset of pre-order, post-order, and in-order iteration. But now that I look at the implementation, it might not necessarily be so. For a simple illustration, consider this ASCII rendition of the following tree: ___B +--+--+ A_____C If this were stored in a sorted binary tree, one might expect binary_tree::iterator to output the elements in this order: A B C However, if we expect an unsorted nary_tree::iterator to behave the same way (in-order, in this case), then what is the correct output for the following tree? _________I +-----+--+--+-----+ A_____E_____O_____U My current depth-first iterator would output the following: I pre_order A pre_order A post_order E pre_order E post_order O pre_order O post_order U pre_order U post_order I post_order One could filter by pre_order or post_order to obtain the corresponding output, so in that respect my depth-first iterator would be a functional superset. However, it traverses every node exactly twice, and definitely not in the same way as a sorted binary_tree::iterator. Therefore, while I agree that my depth-first iterator could make a fine addition, it may not necessarily serve well as an nary_tree::iterator. Thoughts? Cromwell D. Enage

1 0

[lexical-cast] New maintainer
by Antony Polukhin 09 May '11

09 May '11

Alexander Nasonov and Kevlin Henney gave me their permissions to become a new maintainer of Boost.LexicalCast library. Plans for the nearest future: 1) fix inspection program warnings (missing licenses, copyrights, non ascii chars ...) 2) contact with bug reporters, and fix bugs if they still exist 3) add unit tests and performance optimizations If somebody has some advices, comments or wishes, I would be glad to hear them. 2011/5/9 Kevlin Henney <kevlin(a)curbralan.com>: > Antony Polukhin <antoshkka(a)gmail.com: >> There are some bug fixes in trunk and performance optimizations, that >> can not make their way to release. And there is no accepted >> Boost.Convert library, that can do better than lexical_cast. >> >> Alexander Nasonov, the current maintainer of lexical_cast, wrote that >> he has no time for maintaining lexical_cast and that he has no >> objections against new maintainer.( That was in thread '[boost] >> [lexical-cast] version of lexical_cast in 1.46.1 is quite older than >> in trunk'). >> >> If you don`t mind, I`d like to become a new maintainer of >> lexical_cast. I`ve already talked with Alexander, he gave me a short >> introduction of how to maintain and what changes can be accepted into >> the library. He also advised to talk to you. > > Yes, I would be happy for you to do this, if you want to run initial changes > by me and/or Alexander. > > Antony Polukhin <antoshkka(a)gmail.com: >> Would you be so kind to give me some advises and tell more, about the >> official procedure of becoming a maintainer? > > I don't think there is an official process for becoming maintainer, other > than the original author and/or the current maintainer saying "You are now > the maintainer!" :-) > > And please feel free to ask me any questions about the requirements or > design intent. > > Antony Polukhin <antoshkka(a)gmail.com: >> Is there some requirements, not described in N1973 that the library >> must follow to? > > No, we had no plans for any additional features, only fixes to bugs and > improvements in performance. The functionality is at a point where it is > stable. > > So, congratulations: You are now the maintainer! > > Regards, > > Kevlin

1 0