March 2008 - Boost - lists.preview.boost.org

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

New boost::function allocator semantics?
by Emil Dotchevski 27 Mar '08

27 Mar '08

What is the procedure for updating the boost::function allocator semantics according to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2308.html? A working implementation is available here: http://www.revergestudios.com/boost-function/ I'm asking because it will break legacy code that uses the current allocator support in boost::function. Such legacy code would be very easy to fix (of course, legacy code that uses boost::function without supplying custom allocator will not break.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

Re: [boost] Reminder: review will end March 28th
by Cédric Venet 27 Mar '08

27 Mar '08

Hi, I am not sure to be qualified to make a review but I will give it a try. First, I think the library should be accepted. > - What is your evaluation of the design? Seems good. I must say I didnt read or try the transform part of proto. > - What is your evaluation of the implementation? Didnt read the code > - What is your evaluation of the documentation? I think there is some (more) work to do on it. I had some probleme with users_guide\expression_construction\construction_utils.html Because it was not clear to me how to put it in pratice. In fact after a fast read of the doc, I mostly used the exemple as reference of how to do something. So, I don't know exactly what can be done but some ideas may be: *Provide more basic exemple *Refer to the exemple in the documentation to show the practical use of what is described. *make a FAQ One difficulty I didn't had time to study is how to do polymorphic grammar or semantic checking. (perhaps I should not put this in the review). Mor clearly, I add two example: First I would like to have a grammar which can work on any terminal but can only have compatible terminal in a one expression (for example, you can't have vector and list in one expression but you can have one expression with lists and one with vector and they would follow the same grammar). My idea was to do a basic proto grammar which just check operator use and then to use a transform to fold the type of the terminals, checking they are all compatible. Second, I have a grammar where I can add terminals 'a+b' and index terminal 'a[b]'. you can have '(a+b)[c]'. some terminals may be indexable but other not. I could make a grammar for indexable terminal and another for not indexable but it would be duplicated. And if I add more properties to my terminals (for example Boolean, integer or float), the number of grammar explode. I was thinking to again use a transform to check the 'semantic' of the expression. Is it the way to go? I didn't see any reference to this in the documentation, but this seems a common pattern to me? The proto grammar would only check the 'parsing' and one transform would check the semantic. A yes, I would add two note which seem relevant for VS user: * the compiler flag -Zm (for example -Zm150) to change the maximum size of the precompiled header * the pragma inline_recursion and inline_depth (default off and 8) > - 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 used it with VS2005. I didnt had any problem (at least not one which wasnt my fault) > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I read the doc and started writing a small test. Didnt had the time to try transform. Regards, -- Cédric

1 0

[proto] I'm trying to write a vector class
by Noah Stein 27 Mar '08

27 Mar '08

Eric, I spent a few hours the other week trying to convert my last matrix-vector class library over to proto. It implemented expression trees, but I’d never gotten around to adding some features that proto should make much, much easier to implement such as expression optimization. I figured it would be a good way to experiment with the library to review. I eventually gave up on refactoring my class towards proto and instead tried refactoring your lazy_vector example towards my class. It's raised some questions/points. I'll illustrate with questions that are based on your lazy_vector example. 1) lazy_vector seemed like it could derive from lazy_vector_expr in CRTP fashion. I figured your use of std::vector<T> as the terminal type was just to make initialization easier; however, using CRTP fails to compile. Did I miss this in the documentation or is it not explicitly mentioned? 2) How can I handle scalar values transparently? My attempts to accept "v1=v2*5" have failed. I can't get the 5 to implicitly construct into a scalar_vector type I have defined. I had that working in my old one, but I can't seem to figure out the correct way of setting that up in proto. 3) My vector class' signature is very simple: template<typename T> class Vector : VectorExpr<terminal<T> > . The type T contains a number of traits defining the vector: the type of the elements, the dimension, how the data is stored. I can't figure out how to specify the terminals in my grammar. In your example, you use terminal<std::vector<_> > as your terminal. The std::vector part is unknown to me. That's my point of variation in my vector concept thus I can't know all the different types that could be used in the terminal. I tried deriving my storage classes from a common base class; however, that failed. Is there any way to encode some sort of restriction in the grammar for this situation? Right now, I'm using _, but that's clearly not a great solution. Proto looks very interesting. I was quite excited the first I saw it mentioned. There seems to be a lot of power there. I just need to figure out how to use it. You have a lot of documentation, but it seems to be attacking the problem from the opposite direction I'm approaching from, so it's been a little slow going. I hate asking questions about something I can investigate on my own, but I'd like to get far enough along that I can properly review it. Thanks, Noah No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.0/1342 - Release Date: 3/25/2008 10:26 AM

2 3

Status of thread safe signals?
by James Talbut 27 Mar '08

27 Mar '08

What is the status of the thread safe signals library in sandbox/thread_safe_signals? Will it go in the main boost library at some point? Thanks Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

4 4

[pending/relaxed_heap.hpp] assert problem
by Dawson, Paul (UK Filton) 27 Mar '08

27 Mar '08

Using relaxed_heap I'm getting a problem with the asserts in the top() and pop() functions: assert(smallest_value->value != 0); Where value is a ::boost::optional<T>, and T is the indexed type of the heap. The problem that I'm having is that when my T is an int, and the int in question is perfectly valid and has an initialised value of zero, it fails the assert test. Based on my limited understanding, we would actually want to be asserting either (smallest_value != 0) since smallest_value is a pointer, or (smallest_value->value.is_initialised()) since this is an optional. Apologies if I have misunderstood something, as I am a newcomer to boost. Many thanks, Paul. --------------------------- Paul Dawson BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************

2 1