- Boost - lists.boost.org

Ok to add new folder?
by Antony Polukhin 22 Nov '11

22 Nov '11

There is already a folder trunk/libs/conversion where lies Boost.Lexical_cast tests. I`d love to split lexical_cast.hpp onto multiple files (old deprecated version, modern version, common headers for two versions...) and put those files into trunk/boost/conversion. Ok to add folder trunk/boost/conversion ? Best regards, Antony Polukhin

2 1

[functional] [variant] Hash patch for variant
by Antony Polukhin 22 Nov '11

22 Nov '11

Header and tests in attachments. Passes tests on GCC-4.4 and VC10. OK to commit to trunk and include header file from boost/functional/hash/extensions.hpp ? Best regards, Antony Polukhin

2 3

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 22 Nov '11

22 Nov '11

> boost::optional can be used for many purposes. One of these (and I had to > use optional like that) is to make classes that provide RAII-like interface > (noncopyable, nonmoveable) usable in contexts where I need to use two-phase > initialization or to release the resource before the end of the scope > (subject to some runtime condition) -- all that in order to have a resource > acquired for as short span of time as possible. > I would be forced to do that for std::lock_guard if the library did not > provide a second template std::unique_lock. But not every library provides > two interfaces for almost the same thing, and this is arguably an > unnecessary redundancy for an interface. optional<RAII> as described above > is a generic tool for transforming types that implement 'scoped ownership' > into types that implement 'unique ownership' of a resource. I think I went too far with this story. Although you can implement a two-phase initialization and cleanup, you cannot provide a full 'unique ownership' semantics with boost::optional for 'scoped' types, because there is no way to implement a move constructor for types that do not support either a move constructor or swap. Regards, &rzej

1 0

[local] Review
by Thomas Heller 22 Nov '11

22 Nov '11

Hi all, Following is my Review of the upcoming Boost.Local library. I will as others split my review into the three parts that make up this library: local functions, local blocks, scoped exit. Let me first start with some general comments. I personally find the decision to support two syntaxes not a good path to follow. While I understand the rationale behind it, and the desire to have the variadic macro version, having both might become a maintenance nightmare. Also, reading through the documentation, most of the time is spent on explaining, the difference between the two syntaxes. Why not just stick with one and concentrate on the functionality? Additionally, despite the introductory motivating statement ("Local functions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally, avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts.") I can not see that this library solves this appropriately. I personally think that exposing macros as the interface to program with the library does not lead to a nice and clean design of ones code. Boost.Local is very different from other heavily macro based libraries like Boost.Parameter. It is different, because I would consider Boost.Local not as a infrastructure library but as a library for end users. This being said, i would not like to see application code cluttered with overly verbose calls to macros. As boost is trying to not only push the boundaries of C++ it should also try to set examples of best C++ practice. I would not consider Macro calls to interface with a library not good practice. Local Functions: From the tutorial section on Local Functions: "Local functions are defined using the following macros (see the Reference section) from within a declarative context (this is a limitation with respect to C++11 lambda functions which can instead be declared within expressions):" Right, to have the lambdas in a "declarative context" use auto f = [...](...){...} The default parameter syntax is confusing, it looks like it is a completely new parameter, and not belonging to the previous argument. This gets confusing once you have more than one parameter with a default parameter. The WITH_DEFAULT macro should be the default, as it clearly states the relationship of the default value to the parameter. I would consider binding variables from the enclosing scope one of the major weak points of Boost.Local. The need to binding those variables is obvious. However, how it is done clutters the arguments list of the BOOST_LOCAL_FUNCTION_PARAMS to an extend that it is not immediately clear what the arity of the local function is. It would make things clearer to have something like: BOOST_LOCAL_FUNCTION_PARAMS(...) BOOST_LOCAL_FUNCTION_CAPTURE(...) Additionally as binding is probably the right term to use here, it might confuse people with the already existing solutions of the various bind implementations. WRT to your note in the documentation that C++11 can not bind const reference. I suggest the following workaround: int i = 0; auto f = [&](){ auto const & icr = i; ... }; I agree that this and _this should be used always, instead of having both _this and this. On other notes, Lorenzo already clarified the defect in the library that it can't really be used as a closure. This would have been my next point. All in all the documentation is very accurate and in good shape. Additionally i played around with this specific part of the library a little bit in order to see how i can break it. TBH, I didn't (and still don't) trust the macros to do the right thing always, my knowledge of the PP isn't good enough to judge that particular part of the implementation. However, by deliberately trying to break the breaks (putting typos in the variables, omitting commas etc.) the error messages are of course very arcane, and you have to know exactly where and what part of the macros involved failed and why. Of course, these error message can be deciphered very easily once you have enough experience with that library. But i would argue that this is the case for any other (TMP based) library. Which brings me to my next point. I think that Boost.Local does not fulfill its own purpose. While it is of course true that errors in the function bodies are written in "usual C++" the surrounding macros are, IMHO, just cluttering the code. The points Lorenzo makes in the motivational section are not met. I would argue that most of the times, namespaces and classes are good enough, and such a macro syntax should be avoided. For everything else, there already exist a couple of solutions (Boost.Bind, Boost.Lambda and Boost.Phoenix). I would like to see improvements in ease of use in these libraries instead of advertising a completely macro based solutions. Local Blocks: I can't see the value in that one. The example in the documentation doesn't help either, as those things are easily detected by any modern compiler, with the appropriate warning levels (ok, not in the assert case, but for other boolean contexts at least gcc does). Local Exit: Why do we need two libraries doing the exact same thing with neither of the adding any functionality. I suggest to improve ScopedExit instead. In the alternatives section, which version of Phoenix do you use? Now to the usual questions: > - What is your evaluation of the design? I think the design is not what can be considered Modern C++. However, in the context of what the author tried to achieve, he did a good job. > - What is your evaluation of the implementation? The implementation looks solid! > - What is your evaluation of the documentation? The documentation is very good! > - What is your evaluation of the potential usefulness of the library? The potential usefulness of the library is out of question, that is why C++11 now has lambdas, and libraries like Bind, Lambda and Phoenix exist. However, I do not believe that Local adds any value to the existing solution of the described problems. > - Did you try to use the library? With what compiler? Did you have > any problems? Yes. gcc 4.6.2. no problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? Reading of the documentation. Looking briefly at the implementation. > - Are you knowledgeable about the problem domain? Yes. I am the author of Phoenix V3. I vote to not include the library into boost. Regards, Thomas

8 42

Re: [boost] BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

> Hello, > > According to: > > http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… > > [Edge search] requires linear time in the number of edges outgoing from u. > > The purpose of the CSR format is to support highly efficient computation > with minimal memory requirements at the cost of mutability and additional > time in construction. Is there a reason, then, that the adjacencies are > stored unsorted within their vertex ranges? With minimal additional time > during construction, edge access could be reduced to logarithmic time in > the number of edges outgoing from u without sacrificing any functionality > elsewhere that I can determine. > > Can somebody explain this design decision to me? If there is no > explanation, does anybody have plans to adjust the representation? I would > probably be willing to contribute an adjusted representation if nobody else > has plans to do so. The edges from each vertex used to be sorted, but that was changed when linear-time graph construction was introduced. One problem is that the standard sorting routines cannot sort corresponding ranges of elements (such as edge targets and properties); also, sorting edges increases the time complexity of the graph construction algorithm. Note that the CSR constructors that do sorting, except for the in-place versions, apply stable sorts to the edges you input, so you could give it a sorted list of edges and then write a logarithmic-time search routine using out_edges(). -- Jeremiah Willcock Hi, Thanks for your response. I'm sorry to hear about the move away from sorted adjacencies. I'm not sure if this is open for discussion, but I'd like to offer my two cents. The construction cost (of sorting) is minimal, especially in sparse networks for which the compressed sparse row format is specifically targeted where it is essentially asymptotically constant-time unless the degree distribution is highly skewed. On the other hand, certain aspects of link prediction, subgraph counting, and any algorithm that requires neighbor set intersections will benefit greatly from the ordering. I actually rolled exactly the solution you suggested for my own needs. Thank you so much. Ryan Lichtenwalter

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Interesting. It looks like optional can be seen as a special container with > > the maximum size of 1, and then functions like clear() or empty() come as > > natural. On the other hand it can be seen as a pointer-like entity with > > value semantics, and then functions like reset() and literal nullptr come > > as natural. > > Ok, I have no strong preference between reset() or clear() for making the > optional empty. However, a explicit empty() member would be useful anyway. > class MyClass > { > optional< int > m_x; > public: > bool has_x() const { return !m_x.empty(); } > }; > With the current interface I should have written has_x() in a more obscure > way, like !!m_x or m_x.get_ptr() != NULL. > > I withdraw my suggestion to use nullptr. Function reset() would be a better > > choice. I also find reset() preferable to clear() because reset can be > > extended to accept parameters and the name does not become confusing; > > similarly to unique_ptr::reset(). > I think, providing the reset() member with construction semantic is not a good > idea because it would make imposible in-place default construction. There > should be another method that would handle construction. In another post I > suggested assign() but I'm happy if someone comes up with a better name. I managed to come up with the following interface for initializing and un-initializing. My goal was also to not introduce in-place factories. template< typename... Args > optional( tr2::in_place_t, Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) the first parameter is a /tag/, much like std::piecewise_construct for pairs. We use it like this: tr2::optional<W> { tr2::in_place, i, str, 1, &g }; The tag indicates that we request an 'in place' initialization of W with remaining arguments.Next functions are more natural: template< typename... Args > void initialize( Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) // for deferred initialization. void uninitialize() noexcept // so that it spells similar to 'initialize' bool is_initialized() const noexcept // as in boost Regards, &rzej

3 2

BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

Hello, According to: http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… [Edge search] requires linear time in the number of edges outgoing from u. The purpose of the CSR format is to support highly efficient computation with minimal memory requirements at the cost of mutability and additional time in construction. Is there a reason, then, that the adjacencies are stored unsorted within their vertex ranges? With minimal additional time during construction, edge access could be reduced to logarithmic time in the number of edges outgoing from u without sacrificing any functionality elsewhere that I can determine. Can somebody explain this design decision to me? If there is no explanation, does anybody have plans to adjust the representation? I would probably be willing to contribute an adjusted representation if nobody else has plans to do so. Thanks! Ryan Lichtenwalter

2 1

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Also, if someone likes the assignment-of-"none" syntax, in C++11 there will > > be a similar syntax available: > > std::tr2::optional<T> op = {}; > > op = {}; > Wouldn't that be confusing with creating a filled optional with the value > constructed with empty initialization list? If there is assignment-of-none > syntax, it should probably be more explicit, pretty much like the current > "none" keyword. I see your point. But note that this confusing syntax will still be available (and is available today on compilers that support the new initialization syntax) even if we have "none" keyword. This is just the new way of requesting value-initialization (default constructor). Personally, I have doubts about introducing entity "none". There would be too many ways of indicating the null-state for different types. You could look at nullptr as a special pointer with special value; but you could also think of it as a keyword for indicating null-state: a stet of not having any meaningful value. Pointers represent addresses: they can either represent a valid address or not-an-address. Now for optionals we will have none for not-a-value, even though it is almost the same concept. I was thinking also about null_value or nullval. But they appear even more confusing than an already familiar "none". I am not English speaker, so I cannot be positive about it, but does "none" fit logically into the context? Is "nothing" or "naught" more suitable, gramatically? Regards, &rzej

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > - What is your evaluation of the design? > The library is very well designed. The function declaration syntax looks a little foreign at first, but it is very easy to get used to. Furthermore, error messages are usually able to point you to what you did wrong. The fact that you can write the body of the function in plain C++ code is a major advantage of this library. Some have referred to Boost.Bind, Boost.Lambda and Boost.Phoenix as essentially being equivalent to this library, but in none of those libraries can you express the body of your function in plain C++; one advantage of this is that errors in your code result in normal C++ error messages rather than cryptic error messages. Lorenzo, given this comment by Greg, I do have one more suggestion for documentation (or did someone already say it?). Given the heated discussion of whether Boost.Bind, Boost.Lambda and Boost.Phoenix are sufficient to render Boost.Local unnecessary, perhaps it would be worth to provide a comparison of how my code (not too trivial, and not too complex) would look in either case. For instance: With C++11 lambdas: for_each( vec.begin(), vec.end(), []( std::string & n ){ if(n.empty()) n = "n/a";} ); With Boost.Lambda + Boost.Bind: for_each( vec.begin(), vec.end(), if_then(boost::bind(&std::string::empty, _1), _1 = "n/a") ); With Phoenix: using boost::phoenix::arg_names::arg1; using boost::phoenix::if_; using boost::phoenix::bind; // right? for_each( vec.begin(), vec.end(), if_(bind(&std::string::empty, arg1)) [ arg1 = "n/a" ] ); With Boost.Local (Boost.Closure): BOOST_CLOSURE_PARAMS( std::string & n ) { if( n.empty() ) n = "n/a"; }BOOST_CLOSURE_NAME(replace_empties); for_each( vec.begin(), vec.end(), replace_empties ); Ok, I am not sure if there are no better ways to write it in each variant, and I may be biased. I also didn't try to compile the examples. But it should give the potential users an overview of options they have. Regards, &rzej

4 4

Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 21 Nov '11

21 Nov '11

Hi, It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? No response to tickets from the past 3 years. What's the procedure in this case? https://svn.boost.org/trac/boost/ticket/2492 https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… Greetings, -- Olaf

1 3