- Boost - lists.boost.org

[egg] Review (at last)
by Giovanni Piero Deretta 20 Apr '08

20 Apr '08

[ sorry for the delay, it was general election time here in Italy and I had to return home for voting ] - What is your evaluation of the design? Good. I think that the overall structure is pretty good (see the thread between me and the author). I did have reserves on some details, but the author tried to clarify most of my doubts. I still have some problems with some minor parts: * nestN: I still do not understand how this works. It certainly isn't more readable than bind expressions. It should dropped from egg, redesigned or simply relegated as an implementation detail. * Pipable functions: I think that the pipability details in egg are too convoluted. The Pipable and Ambi concepts are a little fuzzy, and the latter badly needs a better name. Personally I think that the '|' operator should perform functional composition (and treat non callable objects as if they were stubs), but I do not think that this view is popular. Most uses of the pipe operator for pipelines are similar to the usage in egg. * Most higher order functions and builders in egg can be used in pure type expressions using result_of without nee to provide the runtime counterpart. This is very useful if your functions are stateless, but I think that using the result_of syntax plus the static_ for this purpose is not very intuitive. I would prefer an approach with pure mpl meta-functions. Most of the quirks of egg (like the MajorFunctionObject concept, which is simply PolymorphicFunctionObject, except that it works with lambda), could be fixed with helps from other boost libraries: Lambda should be result_of compatible, both using result_of to deduce result types of user function objects and also using the result<> protocol for its own function objects. Also it would be great if both boost.bind and boost.lambda closures where default constructible (to a singular value maybe?) and, in the case of lambda, assignable (which would eliminate the need for the 'regular' wrapper. - What is your evaluation of the implementation? I didn't specifically take a look at it. I know that the author took great pains to make it work on as many compilers as possible (and workarounding more than one compiler bug) - What is your evaluation of the documentation? I think that the documentation is the only major problem of the library. IMHO one of the biggest (if not the biggest) selling point of Boost is the high quality of its documentation. Egg documentation is definitely not on par. In particular: * The quick start section reads simply as a showoff of some of the features of the library. It doesn't really explain anything. All the magic is still hidden. Also it covers only some part of the library and the examples are pretty arcane. It really need to show real life use cases and give a step by step explanation of all the features used. * The reference documentation is too formal. It is very hard to understand the formalism used, (and the lack of a true tutorial doesn't help of course). There is too much use of (obscure) examples and 'valid expressions', and often a clear explanation in English of what a function does is lacking. * It shows that the author is not an English speaker, but I think that many native speakers in the boost community can lend an hand here - What is your evaluation of the potential usefulness of the library? Very useful, at least if you take a functional approach to C++ and need polymorphic function object. I think that it would work very well when used with libraries like Fusion, Spirit, Proto and of course, Lambda that make great use of polymorphic function objects. - Did you try to use the library? Not as much as I wanted. I run the test suite and played around with the examples. - With what compiler? # g++ -v Target: i486-Linux-gnu Configured with: ../src/configure Linux gnu Thread model: posix gcc version 4.3.0 20070414 (experimental) - Did you have any problems? Most of the test suite compiled even if with many warnings (mostly due to "type qualifiers ignored on function return type"). Few tests ICEd the compiler. I think that the cause is that this compiler is very recent and egg hasn't been tested with it yet or maybe because it is an experimental snapshot of gcc. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study of the documentation. I didn't study the implementation directly, the author explain a good part of it to me. - Are you knowledgeable about the problem domain? Yes, I have written a library somewhat similar to egg. - Please always state in your review, whether you think the library should be accepted as a Boost library! Yes, but only after a mini review of the documentation only. I believe that the author will be able to come up with an excellent documentation. - Final comments Unfortunately I think that with so few reviews (just mine for now?), the library will have an hard time getting into Boost at this time. Probably the author didn't do a good job at selling it, even if many expressed interest in the past. If the library were to be rejected, I think that the author should resubmit a just a subset of it for inclusion, which would have a far greater chance to be appreciated and evaluated in a short time. This subset, IMHO, should concentrate on stateless function objects and should at least contain: * 'poly' which is a very convenient way to write polymorphic function * 'compose', 'curryN' and 'lazy' especially if, in addition to the higher order functions, the corresponding mpl metafunctions are provided to build polymorphic function objects types (without passing via result_of). * 'always', 'identity', and 'apply' are generally useful and simple enough that can go in the "basic package". Other advanced features, like pipability and infix notation (I like this one!) could then be evaluated once the basic functionality has been sold :). So should more hard-core functional capabilities like memoization and the fix point combinator. Support for static initialization of function objects could also come in a second time.

4 5

Egg Review ends today
by dan marsden 20 Apr '08

20 Apr '08

The review of the Egg library by Shunsuke Sogame ends today. If anybody is still considering doing a review, please do still submit it, even if it is a few days late. It will take a short while for me to summarise the discussion during the review period. The review result will be posted shortly. Thanks Dan Marsden Review Manager __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

1 0

[testing] summary of supported platforms?
by Neal Becker 20 Apr '08

20 Apr '08

Where can I find a test matrix showing which platforms are working with which boost versions?

1 0

[TR1] Test failures with VC9 + MS TR1
by Richard Webb 20 Apr '08

20 Apr '08

I've run a set of regression tests against Trunk with VC9 and the release MS TR1. Results are @ http://beta.boost.org/development/tests/trunk/developer/tr1.html, under the RW_WinXP_VC runner. A couple of observations: 1) The test_regex\std_test_regex tests are failing because basic_regex doesnt have an 'empty' member. However, the TR1 spec doesnt seem to say that it should? 2) The test file @ "libs/config/test/has_tr1_regex_fail.cpp" says: #ifndef BOOST_HAS_TR1_ARRAY #include "boost_has_tr1_regex.ipp" Shouldnt that be #ifndef BOOST_HAS_TR1_REGEX ? As far as the other failures go: some of them are 'by design' (e.g. is_base_of) due to MS following the current proposed spec rather than sticking to the TR1 draft, but others i'm not sure about (e.g. result_of). Anyone got any thoughts? Thanks, Richard Webb

2 8

[1.35][functional] gcc-4.2:dereferencing type-punned pointer will break strict-aliasing rules
by Mat Marcus 20 Apr '08

20 Apr '08

Hi, In boost 1.35.0 I'm getting many of the following warnings from gcc-4.2.0 under cygwin when using boost/functional/hash: ../boost_libraries/boost/functional/detail/hash_float.hpp: In function 'size_t boost::hash_detail::float_hash_impl(float)': ../boost_libraries/boost/functional/detail/hash_float.hpp:75: warning: dereferencing type-punned pointer will break strict-aliasing rules ../boost_libraries/boost/functional/detail/hash_float.hpp: In function 'size_t boost::hash_detail::float_hash_impl(double)': ../boost_libraries/boost/functional/detail/hash_float.hpp:82: warning: dereferencing type-punned pointer will break strict-aliasing rules ../boost_libraries/boost/functional/detail/hash_float.hpp: In function 'size_t boost::hash_detail::float_hash_impl(long double)': ../boost_libraries/boost/functional/detail/hash_float.hpp:90: warning: dereferencing type-punned pointer will break strict-aliasing rules Is this a boost bug, or a spurious warning? Is there a fix or a sound workaround? Thanks, Mat

7 15

[gil] new io extension
by Christian Henning 20 Apr '08

20 Apr '08

Hi there, there are new tiff image formats readable now. Basically, the new io lib supports up to 4 channels with 1, 2, 4, 6, 8, 10, 12, 14, 16, 24, 32, 64 bits depths. Right now a multi-channel image only supports the same channel depth for all channels. For instance for a rgb10_image_t all channels are 10 bits deep. I would really like to support multi-depths channels but unfortunately there would be too many template instantiations. I would like to ask the boost experts to have a look at my lib and to give some advise on how to deal with it. Also, is there someone that can compile my code on a Linux machine? I don't have access to it and would like to know if all is kosher. Thanks, Christian

1 0

[svn] wave instantiate_cpp_exprgrammer build failure
by Neal Becker 19 Apr '08

19 Apr '08

gcc.compile.c++ bin.v2/libs/wave/build/gcc-4.1.2/release/instantiate_cpp_exprgrammar.o ./boost/wave/util/macro_helpers.hpp: In function ‘boost::wave::token_id boost::wave::util::impl::skip_whitespace(IteratorT&, const IteratorT&)’: ./boost/wave/util/macro_helpers.hpp:262: error: ‘next_token’ was not declared in this scope ./boost/wave/util/macro_helpers.hpp:262: error: expected primary-expression before ‘>’ token ./boost/wave/util/macro_helpers.hpp:262: error: ‘::peek’ has not been declared ./boost/wave/util/macro_helpers.hpp:266: error: expected primary-expression before ‘>’ token ./boost/wave/util/macro_helpers.hpp:266: error: ‘::peek’ has not been declared ./boost/wave/util/macro_helpers.hpp: In function ‘boost::wave::token_id boost::wave::util::impl::skip_whitespace(IteratorT&, const IteratorT&, ContainerT&)’: ./boost/wave/util/macro_helpers.hpp:279: error: ‘next_token’ was not declared in this scope ./boost/wave/util/macro_helpers.hpp:279: error: expected primary-expression before ‘>’ token ./boost/wave/util/macro_helpers.hpp:279: error: ‘::peek’ has not been declared ./boost/wave/util/macro_helpers.hpp:283: error: expected primary-expression before ‘>’ token ./boost/wave/util/macro_helpers.hpp:283: error: ‘::peek’ has not been declared

2 1

[shared_Ptr][tr1] and those dreaded circular dependencies again.
by John Maddock 19 Apr '08

19 Apr '08

A recent change in SVN head (whether directly to shared_ptr or something else I'm not sure) has broken some of the TR1 tests: http://beta.boost.org/development/tests/trunk/developer/output/daw-msvc71-b… The two patches below would fix this, but as ever I'm open to other/better suggestions. Cheers, John. Index: C:/data/boost/boost/trunk/boost/detail/shared_count.hpp =================================================================== --- C:/data/boost/boost/trunk/boost/detail/shared_count.hpp (revision 44538) +++ C:/data/boost/boost/trunk/boost/detail/shared_count.hpp (working copy) @@ -29,7 +29,7 @@ #include <boost/detail/sp_counted_base.hpp> #include <boost/detail/sp_counted_impl.hpp> -#include <memory> // std::auto_ptr +#include <boost/config/no_tr1/memory.hpp> // std::auto_ptr #include <functional> // std::less #include <new> // std::bad_alloc Index: C:/data/boost/boost/trunk/boost/shared_ptr.hpp =================================================================== --- C:/data/boost/boost/trunk/boost/shared_ptr.hpp (revision 44538) +++ C:/data/boost/boost/trunk/boost/shared_ptr.hpp (working copy) @@ -20,7 +20,7 @@ #include <boost/detail/shared_ptr_nmt.hpp> #else -#include <memory> // for std::auto_ptr +#include <boost/config/no_tr1/memory.hpp> // for std::auto_ptr #include <boost/assert.hpp> #include <boost/checked_delete.hpp>

2 2

Some notes on Egg
by John Phillips 19 Apr '08

19 Apr '08

Sorry this is not a full review. I had a half an hour to dedicate to this, and that just isn't enough time for the library. First, I want to say that I find some of the possibilities of this library intriuging, and whatever the outcome of this review I hope to see some form of it in boost in the future. However, I find the documentation difficult to read. Some of this is because of grammatical considerations. For this part of the documentation, I suggest the author works with any of the various people on this list who have offered to assist with ddocumentation in the past. I think there are still some offers with contact information that can be found on the wiki. The other problem I have with the documentation is that the author seems to know what he is talking about well enough that he doesn't realize that it is not complete enough for many potential readers. For this I have two suggestions. The first is to include more examples in the flow of the documentation. Some of them should betrivial, while others show more complete use cases. Every time a new concept or use is introduced, consider how an example could improve the discussion. This has become a hazard in the Boost community because we are all far more steeped in functional programming concepts and practices than the general run of C++ programmers and this leads to a communications disconnect for what we think is clear documentation compared to what the mainstream community needs for clear documentation. My second suggestion is to think a lot about how to reorganize the documentation with a new user of the library in mind. If someone comes to the library without knowing what you are doing, how can you show them each of the advantages of the library, preferably one at a time? How can you build the ddocs to draw them through that process and to make it obvious what parts of the library will help solve what problems for the user? An example is the "How to Read the Docs" section at the bottom of the Quick Start page. The reader is two pages into the docs, and a new reader who doesn't understand will have already given up before getting to this section. Separate it and make it clear where to find it in the ToC, instead of hiding it in another page. I haven't looked at the implementation enough to have a usable opinion, so I can really only talk about the documentation. In my opinion, the docs need substantial improvement before the library should be accepted, and I strongly encourage the author to make those improvements whatever the outcome of the review. John Phillips

2 1

[real_concept] Problem with round() family of functions
by Hartmut Kaiser 19 Apr '08

19 Apr '08

Hi John, while moving the new Spirit to the Boost SVN I came across the new functions introduced to allow rounding and truncation to an integer. Cool, thanks for adding these. But now I have the problem, that these functions are in a different namespace as the original real_concept class, which makes it impossible for the compiler to find these through ADL. Is there any reason why you didn't put the round() and truncate() functions for the real_concept class in the 'namespace concepts' instead? Do I miss something? Regards Hartmut

1 0