- Boost - lists.boost.org

Re: [boost] [filesystem] problem with filename length (bug?)
by Allmen, Michael-P57512 20 Dec '05

20 Dec '05

Sorry, forgot that information. Solaris 9 Boost 1.33 -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Thursday, December 15, 2005 7:45 PM To: boost(a)lists.boost.org Subject: Re: [boost] [filesystem] problem with filename length (bug?) "Allmen, Michael-P57512" <Michael.Allmen(a)gdc4s.com> wrote in message news:C7FCC5C93630AB4E80049ED163FFD224B5ED0B@AZ25EXM04.gddsi.com... > Here is the code I am using (the problem also occurs with the > simple_ls.cpp sample)... > > #include <iostream> > #include "boost/filesystem/operations.hpp" > #include "boost/filesystem/path.hpp" > > namespace fs = boost::filesystem; > > int main( int argc, char* argv[] ) > { > fs::path dir( "somedir" ); > > fs::directory_iterator end; > for( fs::directory_iterator i( dir ); i != end; ++i ) { > std::cout << dir->leaf() << std::endl; } > > return 0; > } > > The problem is that once the program finds a file at least 22 > characters long, it will not print any filenames longer than first file correctly. What operating system are you using? What version of Boost? Thanks, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[bug] Visual Studio 2003 versus polymorphic_downcast
by Mat Marcus 20 Dec '05

20 Dec '05

Visual studio 2003 seems to be buggy in a way that can break boost::polymorphic_downcast. Unless I am missing something, it's a rather scary silent failure: ### # include <cassert> class left {}; class right {}; class derived : public left, public right {}; int _tmain(int argc, _TCHAR* argv[]) { derived x; const derived *xp=&x; right *yp=&x; // assert(const_cast<derived*>(xp)==yp); no bug assert(xp==yp); //bug: this fires return 0; } ### This bug causes the assert in polymorphic_downcast to fire when it shouldn't. Here is one possible patched version: template <class Target, class Source> inline Target polymorphic_downcast(Source* x BOOST_EXPLICIT_DEFAULT_TARGET) { #if BOOST_WORKAROUND(BOOST_MSVC, <= 1310) assert( static_cast<const Source*>(dynamic_cast<Target>(x)) == x ); // detect logic error #else assert( dynamic_cast<Target>(x) == x ); // detect logic error #endif return static_cast<Target>(x); } ### The problem is not present in VS 2005. Thoughts? Mat

1 0

More Math Functions for Statistics (and TR2)
by Paul A Bristow 19 Dec '05

19 Dec '05

More Mathematical Functions especially for Statistics +++++++++++++++++++++++++++++++++++++++++++++++++++++ Aficionados of mathematical functions may remember that I proposed some additional functions http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1668.pdf to the choice of Walter Brown which have been added to the C++ TR1 (latest draft) http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1905.pdf The rationale for my proposed functions is that previously standardized functions do not include many functions which have very much wider utility in statistical problems, even the most elementary, like Student's t, Fisher and Chi-sqr tests. To recap, a long list of basic and essential functions were added with the C99 for which rationale is given in http://www2.open-std.org/JTC1/SC22/WG14/www/C99RationaleV5.10.pdf Briefly the total list of functions consists of 1 Original math.h functions, log, exp, pow, sin, cos... 1 So-called IEEE recommended functions, signbit, isnan, isfinite ... 2 Some simplish math functions like lgamma, tgamma, cbrt, acosh. 3 TR1 Bessel functions, Reimann, hypergeometric... 4 TR2 proposed additions, incomplete beta, Fisher, Student, Chisqr probability quantile distributions... I have now produced a first demo of a few of these functions to carry out some very simple, but almost universally applicable, statistical tests - Student's t and Fisher's F-ratio. The example is from analytical chemistry, but could equally well be of school exams, economic comparisons, measurement of lengths, brightness of stars - the list is endless. The demo shows computation of the probability that two methods of extracting tin from foodstuffs give a different result and the probability that one method is more precise than the other. It does NOT require the use of published tables. All the hard and expert work has been done by Stephen Moshier, author of a respected book on mathematical functions, and a long supported (since 1984) and extensive library of mathematical functions in C called Cephes. Moshier has kindly offered to change the library license terms to the Boost terms to support this project. I have merely packaged a few examples of the C functions as C++ functions and placed them in namespaces std::tr2 to show what they would look like in final form. The C versions are required to remain in global namespace to follow the example of the C99 functions which can be used by both C and C++ programs. I am advised that this is a requirement to get the proposal accepted by C WG14 and C++ WG21 Standard groups. I have compiled all the Cephes modules (with a few name changes using macros in the mconf.h configuration header file) and built a library from them. In unitTestfunc1.cpp, I show declarations and definitions of a few sample functions float cbrt(float x) { // Loss of speed over C float version cbrtf? // But not less accurate. // return float(::cbrt(x)); return ::cbrtf(x); // C99 implementation from Cephes, // 32-bit IEEE 754 single precision. } //float cbrt(float x) Some of the 'issues' are: 1 Floating-point format. I have assumed IEEE formats, but try to check and warn if not. All built-in types can vary in precision, especially double and long double: I have shown an example of selecting long double having 53, 80 or 128 significand bits (all IEEE formats). 2 I have only used MSVC 8.0 (but I expect older versions to work too) where long double == 64-bit double. 3 Cephes can be configured to deal with 'wrong' endianness using a macro definition in the configuration header. This might be derived from a Boost header? 4 User Defined Types I have also used Victor Shoup's NTL 128-bit and arbitrary precision library to show that the function definitions can be successfully extended to include User Defined Types such as these. There are a small but significant group of users who want a higher precision than the native long double provides, especially Microsoft compiler users where long double is identical to double and only 64-bit (about 15 decimal digit). (I'm sorry that this makes the sample code rather messy, but you can skip over the NTL part). 5 I have shown some sample tests using the Boost Unit Test framework. These are only a few spot values, calculated using Cephes DOSbox qcalc.exe 100 decimal digit calculator (output to 40 decimal digits) or NTL. These are intended merely to test a few obvious, random, or exact values, a few corner cases, and around some points at which the algorithms are know to change. They aim to check for general algorithm 'sanity' rather than attempt to evaluate accuracy in detail over the whole range. The Cephes functions have already been tested rather fully and their accuracy and tests are reported in the package. 6 In the test example, for simplicity I have concatenated all the declarations and definitions in the same file. These will of course be in separate header and/or source files. 7 I have not concerned myself with efficiency or speed and assumed that the compiler will inline and otherwise optimise away inefficiencies from wrapping. In some cases, the float versions may simply do the calculation in double and return a conversion to float: it may be the best speed and/or accuracy anyway. 8 Implementations will always have to make some compromises between size, speed and accuracy. 9 Cephes deals with errors (for example, from wrong parameter values) by the then conventional method of calling matherr & setting a global math error no, and printing a message, rather than throwing exceptions. But I note that the system-wide error numbers (XENIX) in the Microsoft error.h include files are undocumented, and conflict with the Cephes codes. And C99 (and thus TR1?) no longer REQUIRE a math error to set errno. The simplest solution would be to change the existing matherr function to set errno and NOT print any message: users would always be free to change this module to suit their other requirements. I would NOT wish to implement the C99 exception handling, nor C++ floating_point exceptions. __Detailed__ recommendations about if and how this error handling should be made more 'standard', perhaps using error.h would be welcomed. 10 Cephes could provide test and values for NaNs and infinity etc, but only for some floating- point layouts. These C99 functions are _essential_, but outside the scope of my work at present. 11 I have assumed that compilation and link option choices will deal with floating point instruction set variations, including 'intrinsic' functions like log, exp, sin, cos. This will complicate building the math library and provide potential for confusion at link time. 12 The Cephes code produces a lot of warnings when compiled in 'strict' mode. I have ignored these, although they suggest that the C code does not meet todays 'picky' standards. However a full revision would be a big undertaking with risks of introducing errors: my impression is that most of the warnings look spurious. 13 Cephes implements complex but I have not yet even thought about it ;-) 14 Finally may I reiterate that the objective of this implementation is to persuade the C and C++ Standards groups to standardize the signatures of these functions: it will be possible for better implementations to be produced in the future by both open source and commercial organisations like Dinkumware. Before I undertake the tedious task of wrapping all the proposed TR2 functions (and as many of the C99 and TR1 functions as possible), and presenting the collection for Boost review, I would like feedback from Boosters ever-critical eyes. Bear in mind that (without dealing with complex) there are nearly ***500*** function signatures! I would especially like to avoid a lot of bright new ideas emerging at the review stage, as seems to happen all too often. Speak now or forever hold thy peace, please! Thank you. Paul For those want to see code, a simple demo is at: http://www.hetp.u-net.com/public/mathFuncDemo1.cpp http://www.hetp.u-net.com/public/math2.cpp http://www.hetp.u-net.com/public/math2.hpp and two samples, simple and with UDTs of unit testing: http://www.hetp.u-net.com/public/unitTestFunc1.cpp http://www.hetp.u-net.com/public/unitTestFunc2.cpp -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

3 5

como test problem
by Arkadiy Vertleyb 19 Dec '05

19 Dec '05

Hi all, The following test result: http://tinyurl.com/7e2f7 contradicts to itself by stating that test was "unexpectedly passed" and failed at the same time. Any thoughts on this? Regards, Arkadiy

1 0

[test] Missing implementation for boost::itest::manager
by Markus Schöpflin 19 Dec '05

19 Dec '05

When linking against the test execution monitor lib, the implementation for boost::itest::manager is missing from the library. The header file for the class gets picked up like this: logged_expectations.cpp => logged_expectations.ipp => interaction_based.hpp. It looks like interaction_based is missing from the list of sources (TEST_EXEC_MON_SOURCES) in the libs/test/build/Jamfile Markus

2 1

Re: [boost] [filesystem] problem with filename length (bug?)
by Allmen, Michael-P57512 19 Dec '05

19 Dec '05

1_33_0 -----Original Message----- From: Allmen, Michael-P57512 Sent: Monday, December 19, 2005 7:06 AM To: 'boost(a)lists.boost.org' Subject: RE: [boost] [filesystem] problem with filename length (bug?) Sorry, forgot that information. Solaris 9 Boost 1.33 -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Thursday, December 15, 2005 7:45 PM To: boost(a)lists.boost.org Subject: Re: [boost] [filesystem] problem with filename length (bug?) "Allmen, Michael-P57512" <Michael.Allmen(a)gdc4s.com> wrote in message news:C7FCC5C93630AB4E80049ED163FFD224B5ED0B@AZ25EXM04.gddsi.com... > Here is the code I am using (the problem also occurs with the > simple_ls.cpp sample)... > > #include <iostream> > #include "boost/filesystem/operations.hpp" > #include "boost/filesystem/path.hpp" > > namespace fs = boost::filesystem; > > int main( int argc, char* argv[] ) > { > fs::path dir( "somedir" ); > > fs::directory_iterator end; > for( fs::directory_iterator i( dir ); i != end; ++i ) { > std::cout << dir->leaf() << std::endl; } > > return 0; > } > > The problem is that once the program finds a file at least 22 > characters long, it will not print any filenames longer than first file correctly. What operating system are you using? What version of Boost? Thanks, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[filesystem] BOOST_FILESYSTEM_STATUS_CACHE configuration on SunOS
by Caleb Epstein 19 Dec '05

19 Dec '05

***See: http://tinyurl.com/7pp9r *These test results appear to pre-date line 69 below: 62 // BOOST_FILESYSTEM_STATUS_CACHE enables status_flags cache in 63 // dir_itr_increment. The config tests are placed here because some of the 64 // macros being tested come from dirent.h. 65 // 66 // TODO: "|| defined(__APPLE__)" compiles, but at runtime d_type is alwasy 0. Why? 67 // TODO: find out what macros enable dirent::d_type on various operating systems. 68 # if !defined(__CYGWIN__) && !defined(__osf__) \ 69 && !(defined(__sun) && defined(__GLIBCXX__)) \ 70 && (defined(BOOST_WINDOWS_API) \ 71 || defined(__USE_BSD) || defined(_DIRENT_HAVE_D_TYPE) \ 72 ) 73 # define BOOST_FILESYSTEM_STATUS_CACHE 74 # endif So I expect Filesystem will compile properly on my Monday test run. However I think the macro test should just be for defined(__sun), and not both __sun && __GLIBCXX__. The lack of d_type in dirent is a C library issue, not a C++ library issue and as would affect any compiler on Solaris (e.g. SunPRO CC would hit this too). -- Caleb Epstein caleb dot epstein at gmail dot com

2 2

Review Request: pimpl
by Asger Mangaard 19 Dec '05

19 Dec '05

I would like to submit the pimpl library for a formal review. The suggested library can be found in the sandbox's root. Regards, Asger Mangaard

5 9

[random] Intel failures again
by Stefan Slapeta 19 Dec '05

19 Dec '05

Some time ago, John Maddock investigated the problem with too large arrays on the stack in the random library: http://lists.boost.org/Archives/boost/2005/07/90547.php Does anybody care to solve this in 1.34? Stefan

1 0

[serialization][limitation]
by Oleg Abrosimov 19 Dec '05

19 Dec '05

Hello again I've discovered one more problem. Commented code bellow doesn't compile, because of private inheritance. I don't think that it is a bug, but just limitation of the current implementation. But it limits use of C++, so, if I want to use boost::serialization library I don't allowed to use private inheritance. I don't think that it is very good :) Anyway, if it can not be fixed easily, this limitation should be explicitly stated in docs, or in library's code, that compiler error points to. Best, Oleg Abrosimov #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/utility.hpp> #include <boost/serialization/list.hpp> #include <list> //class my_list1 : // private std::list<int> //{ // friend class boost::serialization::access; // template<class Archive> // void serialize(Archive &ar, const unsigned int version) // { // save/load base class information // ar & boost::serialization::base_object< std::list<int> >(*this); // } //}; // //void save(my_list1 const& lst, const char* const filename) //{ // std::ofstream ofs(filename); // boost::archive::text_oarchive oa(ofs); // oa << lst; //} class my_list2 : public std::list<int> { friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { // save/load base class information ar & boost::serialization::base_object< std::list<int> >(*this); } }; void save(my_list2 const& lst, const char* const filename) { std::ofstream ofs(filename); boost::archive::text_oarchive oa(ofs); oa << lst; } class my_list3 { std::list<int> m_lst; friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & m_lst; } }; void save(my_list3 const& lst, const char* const filename) { std::ofstream ofs(filename); boost::archive::text_oarchive oa(ofs); oa << lst; }

1 0