Errors in date_time module
Hello!
I tried to build the date_date libraries of Boost 1.31.0 with a gcc
2.95.2 compiler on a SuSE 7.0 Linux system. I discovered several problems:
1. Several header and source files try to include the sstream header
file. This header is not available for gcc 2.95.2. I solved this problem
by using #if defined(BOOST_NO_STRINGSTREAM) ... #else ... #endif
constructions to include the correct header file and use the correct class.
2. In order to trigger the correct header file from error no. 1 the flag
BOOST_NO_STRINGSTREAM must be set. This should be done by the config
system (e.g. in boost/config/compiler/gcc.hpp).
3. I tried to include the date_time header files into a source file that
also uses the Xerces library. This resulted in an error in file
boost/date_time/gregorian_calendar.ipp, function
gregorian_calendar_base
At Friday 2005-02-18 04:13, you wrote:
Hello!
I tried to build the date_date libraries of Boost 1.31.0 with a gcc 2.95.2 compiler on a SuSE 7.0 Linux system. I discovered several problems:
problem 1: you're using an ancient compiler. problem 2: you're using an out of date version of boost. I recommend to boost that we not accept patches for the compiler. IMO we cannot afford the effort.
1. Several header and source files try to include the sstream header file. This header is not available for gcc 2.95.2. I solved this problem by using #if defined(BOOST_NO_STRINGSTREAM) ... #else ... #endif constructions to include the correct header file and use the correct class.
2. In order to trigger the correct header file from error no. 1 the flag BOOST_NO_STRINGSTREAM must be set. This should be done by the config system (e.g. in boost/config/compiler/gcc.hpp).
3. I tried to include the date_time header files into a source file that also uses the Xerces library. This resulted in an error in file boost/date_time/gregorian_calendar.ipp, function gregorian_calendar_base
::day_number(const ymd_type& ymd) because of two + operators the compiler can use ( the buildin operator+(int, int) and second one from Xerces ). This error can be solved by doing a static cast to unsigned int for the three classes boost::gregorian::greg_year, greg_month and greg_day. The unsigned int operator is defined for all three classes. I have created two patch files for boost versions 1.31.0 and 1.32.0: http://home.arcor-online.de/markus.petermann/boost_1_31_0.patch http://home.arcor-online.de/markus.petermann/boost_1_32_0.patch
Maybe these corrections can be considered for future releases.
Best regards,
Markus Petermann
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At Friday 2005-02-18 04:13, you wrote:
Hello!
I tried to build the date_date libraries of Boost 1.31.0 with a gcc 2.95.2 compiler on a SuSE 7.0 Linux system. I discovered several problems:
problem 1: you're using an ancient compiler. problem 2: you're using an out of date version of boost.
He also supplied a patch for Boost 1.32.0.
I recommend to boost that we not accept patches for the compiler. IMO we cannot afford the effort.
I think that should be up to the maintainers of the individual libraries. Markus Petermann wrote:
2. In order to trigger the correct header file from error no. 1 the flag BOOST_NO_STRINGSTREAM must be set. This should be done by the config system (e.g. in boost/config/compiler/gcc.hpp).
That's the wrong place to do it, it should be done in the library configuration file, not the compiler configuration file. GCC 2.95 appears to use the SGI standard library by default, and if you look in boost/config/stdlib/sgi.hpp, you'll find this: // // No std::stringstream with gcc < 3 // #if defined(__GNUC__) && (__GNUC__ < 3) && \ ((__GNUC_MINOR__ < 95) || (__GNUC_MINOR__ == 96)) && \ !defined(__STL_USE_NEW_IOSTREAMS) || \ defined(__APPLE_CC__) // Note that we only set this for GNU C++ prior to 2.95 since the // latest patches for that release do contain a minimal <sstream> // If you are running a 2.95 release prior to 2.95.3 then this will need // setting, but there is no way to detect that automatically (other // than by running the configure script). // Also, the unofficial GNU C++ 2.96 included in RedHat 7.1 doesn't // have <sstream>. # define BOOST_NO_STRINGSTREAM #endif I think the comment says it all. Daniel
On Sun, 20 Feb 2005 11:24:28 +0000, Daniel James wrote
Victor A. Wagner Jr. wrote:
At Friday 2005-02-18 04:13, you wrote:
Hello!
I tried to build the date_date libraries of Boost 1.31.0 with a gcc 2.95.2 compiler on a SuSE 7.0 Linux system. I discovered several problems:
problem 1: you're using an ancient compiler.
And in general we don't make it a point to support these old compilers -- however, if a user goes to the work of creating patches I feel obligated to at least evaluate including them. That said, I do recommend upgrading your compiler because future I/O features in date-time will not be backward compatible to compilers like 2.95.x that don't provide wchar_t support.
problem 2: you're using an out of date version of boost.
He also supplied a patch for Boost 1.32.0.
Yep, the 1.31 patch won't go anywhere since there is no plan for a 1.31.1
I recommend to boost that we not accept patches for the compiler. IMO we cannot afford the effort.
I think that should be up to the maintainers of the individual libraries.
And, I will look at them. These are complex enough and impactive enough on the codebase that I won't guarantee that they will be applied, but I'll evaluate and let you know. Jeff
At Sunday 2005-02-20 04:24, you wrote:
Victor A. Wagner Jr. wrote:
At Friday 2005-02-18 04:13, you wrote:
Hello!
I tried to build the date_date libraries of Boost 1.31.0 with a gcc 2.95.2 compiler on a SuSE 7.0 Linux system. I discovered several problems:
problem 1: you're using an ancient compiler. problem 2: you're using an out of date version of boost.
He also supplied a patch for Boost 1.32.0.
I recommend to boost that we not accept patches for the compiler. IMO we cannot afford the effort.
I think that should be up to the maintainers of the individual libraries.
perhaps, but it screws up the regression testing also. I say it's not worth the effort, period.
Markus Petermann wrote:
2. In order to trigger the correct header file from error no. 1 the flag BOOST_NO_STRINGSTREAM must be set. This should be done by the config system (e.g. in boost/config/compiler/gcc.hpp).
That's the wrong place to do it, it should be done in the library configuration file, not the compiler configuration file. GCC 2.95 appears to use the SGI standard library by default, and if you look in boost/config/stdlib/sgi.hpp, you'll find this:
// // No std::stringstream with gcc < 3 // #if defined(__GNUC__) && (__GNUC__ < 3) && \ ((__GNUC_MINOR__ < 95) || (__GNUC_MINOR__ == 96)) && \ !defined(__STL_USE_NEW_IOSTREAMS) || \ defined(__APPLE_CC__) // Note that we only set this for GNU C++ prior to 2.95 since the // latest patches for that release do contain a minimal <sstream> // If you are running a 2.95 release prior to 2.95.3 then this will need // setting, but there is no way to detect that automatically (other // than by running the configure script). // Also, the unofficial GNU C++ 2.96 included in RedHat 7.1 doesn't // have <sstream>. # define BOOST_NO_STRINGSTREAM #endif
I think the comment says it all.
Daniel
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Sun, 20 Feb 2005 14:28:01 -0700, Victor A. Wagner Jr. wrote
At Sunday 2005-02-20 04:24, you wrote:
Victor A. Wagner Jr. wrote:
He also supplied a patch for Boost 1.32.0.
I recommend to boost that we not accept patches for the compiler. IMO we cannot afford the effort.
I think that should be up to the maintainers of the individual libraries.
perhaps, but it screws up the regression testing also. I say it's not worth the effort, period.
Well, I wouldn't let that happen :) The bottom line here is that if these changes get put in, there will be no regression tester that validates their correctness since we don't test with this old compiler. And before I check in I'll be doing the usual work to try and make sure more modern compilers are not impacted. All this said, the changes are substantial and they aren't my highest priority so it will be some time before anything happens. Jeff
participants (4)
-
Daniel James
-
Jeff Garland
-
Markus Petermann
-
Victor A. Wagner Jr.