boost::date_time::posix_time and Intel Compiler 7.0?
Hi there. I get the following error when I try to compile code using boost::date_time::posix_time: c:\PROGRAM FILES\BOOST_1_30_0\boost/date_time/posix_time/time_formatters.hpp(43): error: more than one operator "<<" matches these operands: function "std::basic_ostream<_E, _Tr>::operator<<(std::_Bool={bool={bool}}) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(short) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(unsigned short) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(int) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(unsigned int) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(long) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(unsigned long) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(float) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(double) [with _E=char, _Tr=std::char_traits<char>]" function "std::basic_ostream<_E, _Tr>::operator<<(long double) [with _E=char, _Tr=std::char_traits<char>]" operand types are: std::basic_ostream<char, std::char_traits<char>> << boost::posix_time::time_duration::fractional_seconds_type << frac_sec; Looking at the offending file (time_formatters.hpp, line 43 and vicinity) gives: #if (defined(BOOST_MSVC) && (_MSC_VER <= 1200)) // 1200 == VC++ 6.0 boost::int64_t frac_sec = td.fractional_seconds(); // JDG [7/6/02 VC++ compatibility] char buff[32]; _i64toa(frac_sec, buff, 10); #else time_duration::fractional_seconds_type frac_sec = td.fractional_seconds(); #endif if (frac_sec != 0) { ss << "." << std::setw(time_duration::num_fractional_digits()) << std::setfill('0') // JDG [7/6/02 VC++ compatibility] #if (defined(BOOST_MSVC) && (_MSC_VER <= 1200)) // 1200 == VC++ 6.0 << buff; #else << frac_sec; //!!! Line 43 !!!// #endif It appears that there is not a streaming operator defined for the time_duration::fractional_seconds_type type. Looking deeper into this issue was a bit of nightmare; since the offending type consists of numerous nested typdefs etc. etc. If anyone has a short and sweet answer to my essay of a question, I would appreciate it. The obvious answer of "don't use the Intel compiler" will not suffice! Saying that, when I switched from the Intel compiler to bad old MSVC6 I had not problems. But our company's software requires the performance gain provided by the Intel compiler on Windows. Another issue, I saw that during installation of Boost, it is possible using STLPort and MSVC6 together, but (for the reasons mentioned above), why not STLPort with the Intel compiler? I did ask the same question some time before now, but no-one bothered to answer. I would really appreciate any help in this regard! Greetings, Andre.
It appears that there is not a streaming operator defined for the time_duration::fractional_seconds_type type.
This will normally be a 64 bit integer type (eg: __int64, long long or whatever Intel 7 calls it). I'm a bit suprised this is a problem since the Intel compiler passes the regression tests. http://boost.sourceforge.net/regression-logs/cs-win32.html What sort of settings do you have set on the compile? Is Intel the compiler the has an MSVC 6 compatibility mode that might be turned on? Jeff
Hi. What baffles me the most about this issue is that the Intel compiler should mostly be compatible with MSVC6 compiler, according to the Intel website. I.e. no special compiler switches for compatibility required? Anyway; I got around this issue with a temporary #define MSVC6 for the offending code section followed by a prompt #undef. Ugly, I know, but so is the code involved. I mean, the following lines (26-27) of <boost/posix_time/time_formatters.hpp> does not install any trust whatsoever on my part: //TODO the following is totally non-generic, yelling FIXME #if (defined(BOOST_MSVC) && (_MSC_VER <= 1200)) // 1200 == VC++ 6.0 Oh, the Intel compiler like most of the other compilers on the regression test page does not appear to pass the regression tests. In my book "pass" would be if the compiler fails none of the tests, but heck, I have never written a compiler so that means my opinion is null and void on this :). Thanks for the help! Greetings, Andre. Jeff Garland wrote:
It appears that there is not a streaming operator defined for the time_duration::fractional_seconds_type type.
This will normally be a 64 bit integer type (eg: __int64, long long or whatever Intel 7 calls it). I'm a bit suprised this is a problem since the Intel compiler passes the regression tests.
http://boost.sourceforge.net/regression-logs/cs-win32.html
What sort of settings do you have set on the compile? Is Intel the compiler the has an MSVC 6 compatibility mode that might be turned on?
Jeff
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
What baffles me the most about this issue is that the Intel compiler should mostly be compatible with MSVC6 compiler, according to the Intel website. I.e. no special compiler switches for compatibility required?
It baffles me that compatibility with MSVC6 would be desired at this point. But anyway, I'm not an expert on the Intel compiler, but I think your results will be better if you turn compatibility with MSVC6 off. I'm assuming that is at the root of this issue and the reason that the regression test work and your program doesn't.
Anyway; I got around this issue with a temporary #define MSVC6 for the offending code section followed by a prompt #undef. Ugly, I know, but so is the code involved. I mean, the following lines (26-27) of <boost/posix_time/time_formatters.hpp> does not install any trust whatsoever on my part:
//TODO the following is totally non-generic, yelling FIXME #if (defined(BOOST_MSVC) && (_MSC_VER <= 1200)) // 1200 == VC++ 6.0
Right. It shouldn't inspire confidence in MSVC6. This #ifdef is there because of a bug in MSVC6, period. The real code used for all other compilers is in the #else clause. Sorry if the comment is misleading, but there is no intent to ever fix this.
Oh, the Intel compiler like most of the other compilers on the regression test page does not appear to pass the regression tests. In my book "pass" would be if the compiler fails none of the tests, but heck, I have never written a compiler so that means my opinion is null and void on this :).
On the contrary, what I see is that it in fact passses the tests. Which means that the code you are writing should work. As for MSVC it passes the tests, but in a limited fashion. For MSVC stream-based I/O is turned off as explained in http://www.boost.org/libs/date_time/doc/BuildInfo.html Jeff
Thanks Jeff for taking the time to help me. In reading my own post again, I see the tone of my writing was somewhat unfriendly, sorry! Anyway; it just irks me that I should have issues with 'standard' stuff, like streaming operators. And the fact that the same code compiles with MSVC6 and NOT the Intel compiler. Especially if I know the same code compiles fine under Linux with GCC 3.2. Back on the #define which started my woes. The fact of the matter is, I get everything compiled when using MSVC6 and not the Intel compiler! I.e. the MSVC6-specific code works, the 'other' compiler code for the supposedly more Boost-compliant/friendly Intel compiler does not. Could it be because I am using STLPort in conjunction with the Intel compiler? Aargh. Just give me Linux and GCC... Greetings, Andre. ----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <Boost-Users@yahoogroups.com> Sent: Wednesday, May 21, 2003 3:00 PM Subject: RE: [Boost-Users] boost::date_time::posix_time and Intel Compiler 7.0?
What baffles me the most about this issue is that the Intel compiler should mostly be compatible with MSVC6 compiler, according to the Intel website. I.e. no special compiler switches for compatibility required?
It baffles me that compatibility with MSVC6 would be desired at this point. But anyway, I'm not an expert on the Intel compiler, but I think your results will be better if you turn compatibility with MSVC6 off. I'm assuming that is at the root of this issue and the reason that the regression test work and your program doesn't.
Anyway; I got around this issue with a temporary #define MSVC6 for the offending code section followed by a prompt #undef. Ugly, I know, but so is the code involved. I mean, the following lines (26-27) of <boost/posix_time/time_formatters.hpp> does not install any trust whatsoever on my part:
file://TODO the following is totally non-generic, yelling FIXME #if (defined(BOOST_MSVC) && (_MSC_VER <= 1200)) // 1200 == VC++ 6.0
Right. It shouldn't inspire confidence in MSVC6. This #ifdef is there because of a bug in MSVC6, period. The real code used for all other compilers is in the #else clause. Sorry if the comment is misleading, but there is no intent to ever fix this.
Oh, the Intel compiler like most of the other compilers on the regression test page does not appear to pass the regression tests. In my book "pass" would be if the compiler fails none of the tests, but heck, I have never written a compiler so that means my opinion is null and void on this :).
On the contrary, what I see is that it in fact passses the tests. Which means that the code you are writing should work. As for MSVC it passes the tests, but in a limited fashion. For MSVC stream-based I/O is turned off as explained in
http://www.boost.org/libs/date_time/doc/BuildInfo.html
Jeff
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Anyway; it just irks me that I should have issues with 'standard' stuff, like streaming operators. And the fact that the same code compiles with MSVC6 and NOT the Intel compiler.
Ok.
Back on the #define which started my woes. The fact of the matter is, I get everything compiled when using MSVC6 and not the Intel compiler! I.e. the MSVC6-specific code works, the 'other' compiler code for the supposedly more Boost-compliant/friendly Intel compiler does not.
I guess I was thinking that what was happening is that when compiling with Intel you were getting the MSVC defined and hence were taking the non-generic code. Perhaps not... Have you tried to run the tests in libs/date_time/test with your Intel/STLPort configuration? That might help diagnose the issue. Also, it might be instructive to post your compile command. Perhaps someone with experience on Intel can figure out why your configuration differs from the one that apparently passes the tests.
Could it be because I am using STLPort in conjunction with the Intel compiler?
Might be a factor. There have been some issues before with the library configuration assuming MSVC limitations which don't apply with STLPort in the mix.
Aargh. Just give me Linux and GCC...
Agreed :-) Jeff
Right; here are my compiler options, build configuration and the rest. Basically I am building a static library, which depends on some in-house software components, Qt and Boost. Our own library S3FC (), uses templates in such a manner as to make MSVC6 very unhappy. Therefore we use the Intel compiler under M$. Needless to say, our software compiles problemfree with GCC. For the aforementioned and other reasons we do not make use of Microsoft Foundation Classes when compiling under Windoze, but use the latest version of STLPort (which has been at the same version level for some time now). Anyway; our Windows development work takes place under Visual C++ but with the Intel compiler (version 7.0) selected instead of the MSVC6 compiler. OK; with this background then, here is the basic Visual C++ project settings for my build of the above-mentioned library. I have removed include paths etc. which point to in-house software: 1) "Not Using MFCC" selected for general project settings (as explained above). 2) Warning level => 3 Optimizations => Maximise Speed Debug info => None 3) Project Options => /nologo /ML /W3 /GR /GX /O2 /D "NDEBUG" /D "DEP_MS_WIN" /D "WIN32" /D "_WINDOWS" /U "QT_NO_STL" /Fp"Release/libs3_qt.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c The include and library paths for STLPort is set somewhere else, but these are basically the options. If anyone knows of any special project options, preprocessor directives I am perhaps missing for building Boost-related projects with the Intel compiler, please let me know! I suspect that we will soon be using Boost for other functionality besides that provided by date_time at the moment. Besides, I like the library and works in our main development environment, Linux with the GCC compiler. OK, I am forgetting about this problem for a day or two... Thanks to everyone who has provided me with help so far, especially Jeff Garland. Greetings, Andre. ----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <Boost-Users@yahoogroups.com> Sent: Wednesday, May 21, 2003 3:42 PM Subject: RE: [Boost-Users] boost::date_time::posix_time and Intel Compiler 7.0?
Anyway; it just irks me that I should have issues with 'standard' stuff, like streaming operators. And the fact that the same code compiles with MSVC6 and NOT the Intel compiler.
Ok.
Back on the #define which started my woes. The fact of the matter is, I
get
everything compiled when using MSVC6 and not the Intel compiler! I.e. the MSVC6-specific code works, the 'other' compiler code for the supposedly more Boost-compliant/friendly Intel compiler does not.
I guess I was thinking that what was happening is that when compiling with Intel you were getting the MSVC defined and hence were taking the non-generic code. Perhaps not...
Have you tried to run the tests in libs/date_time/test with your Intel/STLPort configuration? That might help diagnose the issue. Also, it might be instructive to post your compile command. Perhaps someone with experience on Intel can figure out why your configuration differs from the one that apparently passes the tests.
Could it be because I am using STLPort in conjunction with the Intel compiler?
Might be a factor. There have been some issues before with the library configuration assuming MSVC limitations which don't apply with STLPort in the mix.
Aargh. Just give me Linux and GCC...
Agreed :-)
Jeff
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
I know I said I will not return soon, but I finally realised that stupid Visual C++ is to blame for my original compilation error, not anyone from Boost or the Intel compiler writer team. For some reason, the order in which you specify include paths (for crying out loud!) matters in Visual C++!!! That means I must specify STLPort include path first, then stupid VC98 include path. Now I am down to one compilation error, using my much-reported compilation setup : Compiling... graph_qt.cpp C:\PROGRAM FILES\BOOST_1_30_0\boost/lexical_cast.hpp(147): error: no operator "<<" matches these operands operand types are: _STL::basic_stringstream<wchar_t, _STL::char_traits<wchar_t>, _STL::allocator<wchar_t>> << const _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>> return stream << input; ^ detected during: instantiation of "bool={bool} boost::detail::lexical_stream<Target, Source>::operator<<(const Source &) [with Target=unsigned short, Source=_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>]" at line 192 instantiation of "Target boost::lexical_cast<Target,Source>(Source) [with Target=unsigned short, Source=_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>]" at line 30 of "C:\PROGRAM FILES\BOOST_1_30_0\boost/date_ti me/time_parsing.hpp" instantiation of "time_duration boost::date_time::parse_delimited_time_duration<time_duration>(const _STL::string &) [with time_duration=boost::posix_time::time_duration]" compilation aborted for C:\home\adutoit\work\s3_qt\s3_qt\graph_qt.cpp (code 2) Error executing cl.exe. libs3_qt.lib - 1 error(s), 0 warning(s) Any ideas? (Except for checking my include path specs again :) ) Greetings, Andre ----- Original Message ----- From: "adutoit" <adutoit@stonethree.com> To: <Boost-Users@yahoogroups.com> Sent: Wednesday, May 21, 2003 4:16 PM Subject: Re: [Boost-Users] boost::date_time::posix_time and Intel Compiler 7.0?
Right; here are my compiler options, build configuration and the rest.
Basically I am building a static library, which depends on some in-house software components, Qt and Boost. Our own library S3FC (), uses templates in such a manner as to make MSVC6 very unhappy. Therefore we use the Intel compiler under M$. Needless to say, our software compiles problemfree with GCC. For the aforementioned and other reasons we do not make use of Microsoft Foundation Classes when compiling under Windoze, but use the latest version of STLPort (which has been at the same version level for some time now).
Anyway; our Windows development work takes place under Visual C++ but with the Intel compiler (version 7.0) selected instead of the MSVC6 compiler.
OK; with this background then, here is the basic Visual C++ project settings for my build of the above-mentioned library. I have removed include paths etc. which point to in-house software:
1) "Not Using MFCC" selected for general project settings (as explained above). 2) Warning level => 3 Optimizations => Maximise Speed Debug info => None 3) Project Options => /nologo /ML /W3 /GR /GX /O2 /D "NDEBUG" /D "DEP_MS_WIN" /D "WIN32" /D "_WINDOWS" /U "QT_NO_STL" /Fp"Release/libs3_qt.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c
The include and library paths for STLPort is set somewhere else, but these are basically the options.
If anyone knows of any special project options, preprocessor directives I am perhaps missing for building Boost-related projects with the Intel compiler, please let me know! I suspect that we will soon be using Boost for other functionality besides that provided by date_time at the moment. Besides, I like the library and works in our main development environment, Linux with the GCC compiler.
OK, I am forgetting about this problem for a day or two... Thanks to everyone who has provided me with help so far, especially Jeff Garland.
Greetings, Andre.
----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <Boost-Users@yahoogroups.com> Sent: Wednesday, May 21, 2003 3:42 PM Subject: RE: [Boost-Users] boost::date_time::posix_time and Intel Compiler 7.0?
Anyway; it just irks me that I should have issues with 'standard'
stuff,
like streaming operators. And the fact that the same code compiles with MSVC6 and NOT the Intel compiler.
Ok.
Back on the #define which started my woes. The fact of the matter is, I get everything compiled when using MSVC6 and not the Intel compiler! I.e. the MSVC6-specific code works, the 'other' compiler code for the supposedly more Boost-compliant/friendly Intel compiler does not.
I guess I was thinking that what was happening is that when compiling with Intel you were getting the MSVC defined and hence were taking the non-generic code. Perhaps not...
Have you tried to run the tests in libs/date_time/test with your Intel/STLPort configuration? That might help diagnose the issue. Also, it might be instructive to post your compile command. Perhaps someone with experience on Intel can figure out why your configuration differs from the one that apparently passes the tests.
Could it be because I am using STLPort in conjunction with the Intel compiler?
Might be a factor. There have been some issues before with the library configuration assuming MSVC limitations which don't apply with STLPort in the mix.
Aargh. Just give me Linux and GCC...
Agreed :-)
Jeff
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
adutoit wrote:
[ a lot of trouble using boost and Intel C++ ]
Since I had no time to "configure" Intel's compiler and since I was so fed up with getting it up and running, I did 2 things with Intel-7.0 on linux which work for me: I use -ansi and -DBOOST_NO_CONFIG. Though the latter might be a bad idea in general (since no special platform-dependent optimization can be used then) this solved a lot of trouble, especially since some parts of boost make (made?) assumptions about Intel's behaviour that no longer hold.
From my own experience, if it compiles with gcc-3.2 -ansi it should never fail with Intel's compiler except when the code is not completely compliant. At present I use gcc only for the much more intelligent error messages for templates.
If You could provide a small code snippet which shows this error I can try to compile it under Linux and see what is happening there. Markus -- Compile time analytic differentiation? Yes, at http://daixtrose.sourceforge.net/
I think I finally sorted out my previous compile errors when I changed the order in which my include directories are searched. But now I get errors relating to STLPort and Qt... So I'll probably continue this saga on the STLPort mailing list! Thanks anyway. A. ----- Original Message ----- From: "Markus Werle" <yg-boost-users@gmane.org> To: <boost-users@yahoogroups.com> Sent: Thursday, May 22, 2003 8:59 PM Subject: [Boost-Users] Re: boost::date_time::posix_time and Intel Compiler 7.0?
adutoit wrote:
[ a lot of trouble using boost and Intel C++ ]
Since I had no time to "configure" Intel's compiler and since I was so fed up with getting it up and running, I did 2 things with Intel-7.0 on linux which work for me:
I use -ansi and -DBOOST_NO_CONFIG. Though the latter might be a bad idea in general (since no special platform-dependent optimization can be used then) this solved a lot of trouble, especially since some parts of boost make (made?) assumptions about Intel's behaviour that no longer hold.
From my own experience, if it compiles with gcc-3.2 -ansi it should never fail with Intel's compiler except when the code is not completely compliant. At present I use gcc only for the much more intelligent error messages for templates.
If You could provide a small code snippet which shows this error I can try to compile it under Linux and see what is happening there.
Markus
--
Compile time analytic differentiation? Yes, at http://daixtrose.sourceforge.net/
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
participants (5)
-
adutoit -
Andre du Toit
-
Jeff Garland -
Markus Werle -
Paulius Galubickas