- Boost - lists.boost.org

bind behavior
by Dill, John 10 May '04

10 May '04

I ran into some possibly confusing behavior when trying out the documentation example from bind. When you have: struct F { int operator()(int a, int b) { return a - b; } bool operator()(long a, long b) { return a == b; } }; F f; int x = 104; bind<int>(f, _1, _1)(x); // f(x, x), i.e. zero What could be confusing is when you do this: long y = 104; bind<int>(f, _1, _1)(y) // Calls the operator<bool>, not operator<int> which is counter-intuitive as the documentation says your binding on the return type, but the return type is not actually what function call the type deduction gets. Does anyone else observe this behavior? I tried this on gcc 3.4. Thanks, John

1 0

number ranges and compile-time errors
by Reece Dunn 10 May '04

10 May '04

Is there a boost library that allows you to specify the range that a number can take, e.g. boost::range< int, 1, 12 > month; generating an error on an invalid range, e.g. month = 20; // [1] oops! Also, is it possible to distinguish between a number literal like the above and a variable assignment, like: month = m; // [2] The logic behind this is to provide compile-time checks where possible, so [1] would produce a compile-time error and [2] would be a run-time error. You could also do something like: inline char & string::operator[]( boost::range< int, 5, 10 > i ){ ... } // ... string s; s[ 1 ] = 'a'; // oops! and class date { boost::range< int, 1, 12 > month; public: inline date( boost::range< int, 1, 12 > m ): month( m ){} }; Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

3 3

Large files ( > 2GB) and boost::filesystem library
by David Judson 10 May '04

10 May '04

In a number of places in the filesystem library on Linux, the ::stat file system call is used. When this call is executed on a file whose size is larger than 2GB, it fails because the file size cannot fit into the default "stat" structure. This problem happens even when the size information in the stat structure is not used. For example the stat information is used in the directory iterator to look for sub directories. This can be corrected by setting the macro _FILE_OFFSET_BITS to 64. What is the best way to set this macro on Linux? I have looked at the jam rules and cannot locate the appropriate place to include the definition. Also, what process should be followed if I want to have this macro defined either by default or at least as an option in the boost source tree so that I don't have to modify the build rules each time I install boost?

6 8

[Graphs] another c.l.c++.m post
by David Abrahams 10 May '04

10 May '04

-- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

gmane
by Daniel Wallin 10 May '04

10 May '04

Did someone just import an archive to the boost gmane group? I've been getting old (1998+) postings and no new ones all day, also they are not in order which is kind of annoying.. -- Daniel Wallin

3 2

borland workaround still needed
by Gennadiy Rozental 10 May '04

10 May '04

Hi, I an trying to make protected member defined in base class public: template<class PropertyType> class class_property { protected: PropertyType value; }; template<class PropertyType> class readwrite_property : public class_property<PropertyType> { public: typedef class_property<PropertyType> base; #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) base::value; #else using base::value; #endif }; Borland fail to compile it, stating something about an attempt to grant access to protected member. Well that's the whole point!! Any suggestions? Gennadiy.

1 0

patch: boost/math/special_functions => compile error in asinh.hpp, acosh.hpp and atanh.hpp
by Huber, Carsten 10 May '04

10 May '04

Hello boost developers, this is my first mail to boost(a)lists.boost.org and it is already a bug that I found in the latest release 1.31.0 :-( I tried to compile boost::math::asinh, boost::math::acosh and boost::math::atanh recently and got a compile error "C2039 'abs' : is not a member of '_STL'" on my MSVC6 compiler. I have STLPort 4.5.3 installed and thought, this might be the problem, but then I found out that boost::math::sinc_pi and boost::math::sinhc_pi compile with no errors. To make it short: asinh, acosh and atanh are using ::std::abs, ::std::sqrt and ::std::log - which are not part of the STL. To fix this problem, I have created a patch - see attached files. Best regards, Carsten Huber ------------------------------------------------- Dipl.-Ing. Carsten Huber (Member of the VDE) Software Development Engineer Product Line Diagnostics (PDG) Vector Informatik GmbH Ingersheimer Str. 24 D-70499 Stuttgart Phone : +49 711 80670-0 Fax : +49 711 80670-299 Mailto : carsten.huber(a)vector-informatik.de Internet: http://www.vector-informatik.de -------------------------------------------------

2 1

[Boost-bugs] [ boost-Bugs-951106 ] bjam install does not copy .inc files
by SourceForge.net 10 May '04

10 May '04

Bugs item #951106, was opened at 2004-05-10 08:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=951106&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pere Mato (pmato) Assigned to: Nobody/Anonymous (nobody) Summary: bjam install does not copy .inc files Initial Comment: On trying to compile we got the follwing error: afs/cern.ch/cms/external/lcg/external/Boost/1.31.0/rh73_ gcc32/include/boost- 1_31/boost/pool/object_pool.hpp:83:51: boost/pool/detail/pool_construct.inc: No such file or directory The problem has been traced to the fact that the .inc files in boost/pool/detail were not copied to the installation area by "bjam install". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=951106&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Regression testing -- some new testing options?
by Jeff Garland 09 May '04

09 May '04

Robert Ramey & I have been having a discussion offline about the impact of new boost libraries on the time it takes to run the regression tests. Serialization has a particularly time consuming test -- the so called 'torture test' suite. The problem is, that once serialization is in the tree it will be important to run that full test from time to time (like right before release), but it would probably be overkill to run everyday. And from past dicussion it is clear that running the regression test is already becoming very time consuming. Of course this isn't a serialization specific issue. With more and more libraries added the time to do any sort of regression test is continuing to grow. In addition, there is now the 'dll' versus 'static' library dimension for those of us with compiled libraries. It might be nice to sometimes run one or the other to speed things up. Also, Robert would like to be able to run 'debug' versus 'release' tests from time to time. So here's a suggestion. Perhaps it be possible to create a standard way we could set up the regression test targets so that library authors could: 1) define a couple standard test levels - say 'basic' and 'torture' 2) DLL versus static tests would be an option on the regression suite -- so you could run only one or both. Of course this isn't an issue for header libraries. 3) debug versus release is an option 4) define specific compiler/platform exclusions I believe such a design could increase the regression test effectiveness by allowing some contributors and users to run only one set of options (eg: 'basic-dll-release') tests. This option would be much-much faster than 'torture-all-all' -- which for a compiled library needs to compile and excute 4 versions of the tests (dll-release, dll-debug, static-release, static-debug). The compiler/platform exclusions would save time by just skipping over stuff that is going to fail and will never be fixed. There may be some way of doing this now, but ideally we would have some way of specifying this in the bjam file for the tests. Thoughts? Jeff

1 0

Re: Request for small test in VC7.1
by Arkadiy Vertleyb 09 May '04

09 May '04

Hi Joaquin, Your example compiles with no problem in VC7.1 (.NET 2003) in both debug and release mode. Regards, Arkadiy

1 0