- Boost - lists.boost.org

[proto] Review
by Noah Stein 28 Mar '08

28 Mar '08

I wish I could have spent much more time with Eric’s library. I think it addresses a very important niche in the world of C++ libraries. This library could save me countless hours in the future. Even though I didn’t get as much time with the library as I’d hoped, I vote to accept it. - What is your evaluation of the design? The design is well thought out. I must admit that using it wasn’t as straightforward as I thought it would be. I believe that is not due to poor design. I believe it is fundamentally a result of Eric really trying to create a library that is ambitious and is really trying to provide an extensive set of features and functionality for library authors. - What is your evaluation of the implementation? I didn’t look too deeply into the guts of the implementation, only in so far as I was getting errors in my attempts to use the library. Unfortunately, the library is complex. There’s no way around it. I just didn’t have the time to dig too extensively under the hood. - What is your evaluation of the documentation? I don’t want to say that it was lacking, but for me this was the weakest aspect of a very strong library. The documentation is very good at what it covers. It does cover all the parts of the library. Each concept is covered in a good amount of detail. I hate to leave it at that, but I’ve been at this bullet point for 10 minutes now trying to figure out how to express what I want to say. Unfortunately, it’s 1:00 AM, and I need to be up in 4 hours. I’ll try to put something together this weekend or early next week to cover what I’m thinking. - What is your evaluation of the potential usefulness of the library? Extremely useful. - Did you try to use the library? With what compiler? Did you have any problems? I played around with implementing a class using proto. The environment was MSVC2005. I had zero problems compiling the examples or using the libraries. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read the documentation 3 or 4 times over the course of a few days. I spent 5 hours or so compiling the examples and working on implementing my own class with the library. - Are you knowledgeable about the problem domain? I think I’m sufficiently knowledgeable about the domain. I’ve implemented expression trees for a vector-matrix library in the past. Knowing how much effort it was to write that for a single domain without implementing expression transforms, I understand the tremendous effort that went into creating a generic system. I really think Eric has done a great job. He’s clearly put in a tremendous amount of thought into proto. Clearly, it’s been a lot of time. Having worked on Spirit in the past, I’m sure that it’s put proto through the fire already. If it can handle Spirit and the diversity of examples in the documentation, Eric’s done a fine job of making a solid DSEL library. -- Noah No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.1/1346 - Release Date: 3/27/2008 10:03 AM

1 0

[Review][proto] my review
by Maurizio Vitale 28 Mar '08

28 Mar '08

First let me apologize for the short review. It won't make justice to the huge contribution Eric made to the Boost Libraries. I definitely think Proto should be accepted and included into an official Boost release as soon as practical. - What is your evaluation of the design? Beautiful. - What is your evaluation of the implementation? Lot of attention has been put into making sure that compilation time stayed with reason, not an easy task with today's compilers. Also, to the extent it didn't conflict with the compilation speed goal, Eric made substantial restructuring of the code to prevent unwanted captures due to ADL and otherwise reduce surprises for users. I haven't really worked with the version submitted for review, but one of the issue I did have with v2 was that and_ and or_ didn't allow for 1 and 0 arguments, which is useful in a variety of folding situations. I remember Eric agreeing in the end that this could be indeed useful in some cases and the problem could be compilation time. I don't know if it has been solved one way or the other: a cursory look at the new documentation doesn't show any minimum arity (one thing that the docs should do, irrespective on whether the minimum is 0,1 or 2) Another issue I remember was related to BOOST_PROTO_MAX_ARITY. It is (was?) controlling both the maximum arity of boost expressions _and_ the arity of templates in grammars. Eric promised to decouple the two uses, but in my quick look at the docs I couldn't find out whether it has happened or not. I believe this change should really go in. The last design issue I had was about whether expressions should allow to store terminals by value. This might be different with the work on integrating fusion, I don't know. In my application (fixed-point arithmetic) I had cases where my object could have been stored by value and taking the space of an int (or less) and I would have liked to be able to do so. I admit mine was probably a very special case, where the quality of the assembler code generated was of upmost importance (must rival hand-written code). I don't remember the details of the conversation with Eric on this, but I think his conclusion was that allowing the user to specify the storage policy would have made compilation in the typical case slower. Still... - What is your evaluation of the documentation? Haven't had to much time to spend on it, but it seems to have improved substantially. Once proto gets in the hand of new users we'll know whether it does a good job in introducing complex concepts which are probably new to the average C++ programmer. - What is your evaluation of the potential usefulness of the library? Huge. - Did you try to use the library? With what compiler? Did you have any problems? I did use the previous version from April to October 2007 and have been a regular harrasser of Eric. Compilers: - GCC, many versions including SVN heads - Intel C++ compiler, few 9.x.y versions Problems: a few in the beginning, promptly fixed by Eric. I remember the Intel compiler exposed a number of issues. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? the review itself consisted of a quick glance to the new documentations. The work with the previous version of the library was 3-4 months (FTE) - Are you knowledgeable about the problem domain? I believe so.

2 3

[1.35.0] Web site fixes needed
by Beman Dawes 28 Mar '08

28 Mar '08

I've just added three web site items to the web site do list (http://svn.boost.org/trac/boost/wiki/MergeOneDotThreeFiveDotZero) * www.boost.org/libs should redirect to the current library docs page. * The "Documentation" sidebar entry links to an empty page. * The "Documentation" sidebar expansion does not list 1.35.0. --Beman

2 1

[python] DSW project fails to link
by Robert Dailey 28 Mar '08

28 Mar '08

Hi, When compiling Boost.Python using the *.dsw visual studio project file in the boost/libs/python/build directory, the project fails to link. Note that I've converted this project to a Visual Studio 9 project. Below are the linker errors: 1>Linking... 1> Creating library .\../bin-stage/boost_python_debug.lib and object .\../bin-stage/boost_python_debug.exp 1>function.obj : error LNK2001: unresolved external symbol "char * boost::python::objects::detail::cpp_signature_tag" (?cpp_signature_tag@ detail@objects@python@boost@@3PADA) 1>function.obj : error LNK2001: unresolved external symbol "char * boost::python::objects::detail::py_signature_tag" (?py_signature_tag@ detail@objects@python@boost@@3PADA) 1>function.obj : error LNK2019: unresolved external symbol "public: static class boost::python::list __cdecl boost::python::objects::function_doc_signature_generator::function_doc_signatures(struct boost::python::objects::function const *)" (?function_doc_signatures@ function_doc_signature_generator@objects@python@boost@@SA?AVlist@34@ PBUfunction@234@@Z) referenced in function _function_get_doc 1>../bin-stage/boost_python_debug.dll : fatal error LNK1120: 3 unresolved externals 1>Build Time 0:00 1>boost_python - 4 error(s), 0 warning(s)

2 5

Please update mailing list archives
by Jens Seidel 28 Mar '08

28 Mar '08

Hi, I'm sure I asked for this already but please remove the link to "The Mail Archive" from http://www.boost.org/more/mailing_lists.htm#archive (Archives for Boost developers list) as the last archived mail is from 2003. Jens

2 1

Re: [boost] Proposed patch for boost::counting_iterator
by David Abrahams 27 Mar '08

27 Mar '08

Sebastian Theophil wrote: > Hello Dave, > We really ought to be having this discussion in public, so let's please move to the Boost developers' list. > I took another look at the standard to make the argument clearer. > >> I don't follow. Let's try code. >> >> counting_iterator<int> i0(INT_MIN), i1(INT_MAX); >> std::iterator_traits<counting_iterator<int> >::difference_type d >> = i1-i0; >> >> Are you claiming that it's acceptable for d to be -1? > > Yes, that was what I tried to say. Because for all practical purposes > > i0 + d == i1 (Although the behavior is undefined it will work on most systems.) Here's where you get into the difference between theoretical and actual portability. > The other property I tried to express was that comparing two differences for their absolute values is meaningless if d is allowed to be -1 because of overflow. Ouch; your mailer doesn't wrap lines. What do you mean by "comparing two differences for their absolute value?" >>> My fundamental argument is that int is a modulo space which is exactly >>> why 1) works if B-A is still int. > >> No, int is not a modulo space. Overflows induce undefined behavior. >> Only unsigned integers are a modulo space in C++. > > OK, I believe you know the standard way better than I do, so I admit defeat in this point. OK. >>> This is also why (T* - T*) = ptrdiff_t >>> = int > >> No, ptrdiff_t is long on most platforms > >>> and not int64. > >> And it may be a 64-bit int (especially on 64-bit platforms) > > The last point is clear and I should have written that ptrdiff_t = word size or something like that. > But back to what the standard says about ptrdiff_t in section 5.7 on Additive Operators > > "When two pointers to elements of the same array object are subtracted, the result is the difference of the subscripts of > the two array elements. The type of the result is an implementation-defined signed integral type; this type shall be the > same type that is defined as std::ptrdiff_t in the <cstddef> header (18.1). As with any other arithmetic overflow, > if the result does not fit in the space provided, the behavior is undefined. In other words, if the expressions P and Q point > to, respectively, the i-th and j-th elements of an array object, the expression (P)-(Q) has the value i− j provided the > value fits in an object of type std::ptrdiff_t." > > Clearly, there's no strict requirement on ptrdiff_t except that it is a signed integral type. It clearly doesn’t have to be large enough to prevent overflows so it may have the same size as a processor word be that 4 bytes or 8. In practice that seems to be the preferred way although with a word length ptrdiff_t Generally it has nothing to do with the (data) word length. It is usually an integral type whose size corresponds to the size of a pointer. > char* c0=(char*)0; > char* c1=(char*)UIntToPtr(std::numeric_limits<size_t>::max()); > ptrdiff_t d=c1-c0; > char* c2=d+c0; > > d overflows and in practice is -1 as well. Thus c2==c1. Yes, but in practice no such array can exist, so it's not a problem. On the other hand, someone *can* reasonably make two counting_iterator<short>s and iterate from SHORT_MIN to SHORT_MAX. So in that case, representing the difference correctly could be important. > The same holds for > > int n0=INT_MIN; > int n1=INT_MAX; > int dn=n1-n0; > int n2=dn+n0; > > dn is -1 and n2==n1. Yes, that's because you specified int! The whole point of numeric_traits<int>::difference_type is to do better than that. > > Of course, the overflow behavior is implementation dependent and it doesn't have to work that nicely. However, my argument is that this fact didn't cause anybody on the standards committee to change the definition for ptrdiff_t. That's because it's up to QOI. In other words, an implementor interested in a high-quality implementation will ensure, if possible, that ptrdiff_t works for practical situations on his platform. That's exactly what we tried to do with counting_iterator. There's a difference between what the standard mandates and what an implementor should do. The standard also doesn't say that you have to support dynamic allocation of more than 10 bytes total. > I think counting_iterator<T> should behave exactly the same way when T is an integer than when it is an iterator. It does, whenever possible. An iterator's difference type is usually a type that can be used to represent the difference between any two such iterators that belong to the same sequence. That's exactly what we try to do with counting_iterator<int>. > In both cases it can return iterator_traits<T>::difference_type. std::iterator_traits<int>::difference_type is specialized to be int. I would be shocked if you could demonstrate that std::iterator_traits<int>::difference_type is specialized to be int in the standard, or indeed any implementation of C++. -- Dave Abrahams Boost Consulting http://boost-consulting.com

3 3

PCH compiler limit error
by Robert Dailey 27 Mar '08

27 Mar '08

Hi, I have a lot of boost files in a precompiled header, and compiling that precompiled header using boost 1.34.1 caused no errors. However, now that I've upgraded to 1.35, I'm getting the following error during PCH generation in MSVC9: 2>c:\it\tfs\crusades\sdks\boost\boost\filesystem\operations.hpp(827) : error C3859: virtual memory range for PCH exceeded; please recompile with a command line option of '-Zm112' or greater 2>c:\it\tfs\crusades\sdks\boost\boost\filesystem\operations.hpp(827) : fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limit The recommended fix in the error text resolves the problem, but I'm wondering why this is a problem in the first place. As I stated before, the earlier versions of boost never did this. Is this a bug?

2 1

Boost variant and memory allocations
by Emil Dotchevski 27 Mar '08

27 Mar '08

The never-empty requirement for Boost Variant requires memory allocation in general, in the implementation of operator=, as discussed here: http://www.boost.org/doc/html/variant/design.html#variant.design.never-empty The same page states that future implementations might use policy-based design to specify custom allocator. Assuming that it is desirable to allow for allocations to be customized, wouldn't it be better to use the same technique as in the custom allocator support in shared_ptr and in the version of boost::function that Doug just committed to the SVN trunk? In this case, the allocator wouldn't be provided as a policy to the variant template itself, but would appear as template parameter of its constructor and operator=. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

Boost.Test: "Test setup error: child has exited" error with RC2
by Jens Seidel 27 Mar '08

27 Mar '08

Hi, I tried to build the release branch on a Linux OpenSuse 10.2 with g++ (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux) and it worked well. I also called "make check" and the tests were successful. What I now miss is a config.log file which saved the arguments to ./configure (as used by autotools) since I already forgot how I started the build :-) I think I just tried ./configure --prefix=...; make; make install; make check I compiled my own program which uses Boost.Logging v1 and Boost.Test as well as boost::shared_ptr and got many compiler warnings in Boost.Test headers. Many of these (unused arguments) could easily be fixed but nothing happened since I reported some of these 5 months ago in http://svn.boost.org/trac/boost/ticket/1432 ... OK, but I also got a new error once I try to start my test: Test setup error: child has exited; pid: 1001; uid: 20576; exit value: 0 The problem seems to be related to a std::system() call, which I do not understand! Without it it works! Here is my test code: #include <cstdlib> #include <boost/test/included/unit_test_framework.hpp> using boost::unit_test::test_suite; void Vektor3Test1() { } test_suite* Vektor3_test_suite() { test_suite *test = BOOST_TEST_SUITE("Vektor3 test suite"); test->add(BOOST_TEST_CASE(&Vektor3Test1)); return test; } test_suite* init_unit_test_suite(int, char *[]) { std::system("true"); // leads to "Test setup error: child has exited; pid: 1001; uid: 30540; exit value: 0" test_suite *test = BOOST_TEST_SUITE("Master test suite"); test->add(Vektor3_test_suite()); return test; } Any idea? Jens

2 2

[Serialization] Build failures on the Boost trunk
by Douglas Gregor 27 Mar '08

27 Mar '08

I'm currently getting a bunch of errors from the serialization library on the Boost trunk on Mac OS X 10.4: darwin.compile.c++ ../../../bin.v2/libs/mpi/build/darwin-4.0.1/debug/ macosx-version-10.4/content_oarchive.o../../../boost/archive/impl/ archive_pointer_oserializer.ipp: In constructor 'boost::archive::detail::archive_pointer_oserializer<Archive>::archive_p ointer_oserializer(const boost::serialization::extended_type_info&)':../../../boost/archive/ impl/archive_pointer_oserializer.ipp:41: error: 'singleton' is not a member of 'boost::serialization'../../../boost/archive/impl/ archive_pointer_oserializer.ipp:43: error: expected primary- expression before '>' token../../../boost/archive/impl/ archive_pointer_oserializer.ipp:43: error: '::get_mutable_instance' has not been declared../../../boost/archive/impl/ archive_pointer_oserializer.ipp: In static member function 'static const boost::archive::detail::basic_pointer_oserializer* boost::archive::detail::archive_pointer_oserializer<Archive>::find (const boost::serialization::extended_type_info&)':../../../boost/ archive/impl/archive_pointer_oserializer.ipp:54: error: 'singleton' is not a member of 'boost::serialization'../../../boost/archive/impl/ archive_pointer_oserializer.ipp:56: error: expected primary- expression before '>' token../../../boost/archive/impl/ archive_pointer_oserializer.ipp:56: error: '::get_const_instance' has not been declared../../../boost/archive/impl/ archive_pointer_oserializer.ipp:57: error: 'singleton' is not a member of 'boost::serialization'../../../boost/archive/impl/ archive_pointer_oserializer.ipp:57: error: '::get_const_instance' has not been declared../../../boost/archive/impl/ archive_pointer_oserializer.ipp:57: error: expected primary- expression before 'void'../../../boost/archive/impl/ archive_pointer_oserializer.ipp:57: error: expected `)' before 'void'../../../boost/archive/impl/archive_pointer_oserializer.ipp:57: error: expected `)' before ';' token../../../boost/archive/impl/ archive_pointer_oserializer.ipp: In destructor 'virtual boost::archive::detail::archive_pointer_oserializer<Archive>::~archive_p ointer_oserializer()':../../../boost/archive/impl/ archive_pointer_oserializer.ipp:73: error: 'singleton' is not a member of 'boost::serialization'../../../boost/archive/impl/ archive_pointer_oserializer.ipp:75: error: expected primary- expression before '>' token../../../boost/archive/impl/ archive_pointer_oserializer.ipp:75: error: '::get_mutable_instance' has not been declared Any idea about what's happening? - Doug

1 0