RE: [Boost-Users] boost::date_time::posix_time and Intel Compiler 7.0?

Hi Andre,
this is not only behavior of VC, all compilers, as far as I know have some
include/lib paths preconfigured, to prevent you from specifying them always
on command lines. You have two options how to use stlport:
1) #include
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"
To: 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/
------------------------ Yahoo! Groups Sponsor ---------------------~--> Get A Free Psychic Reading! Your Online Answer To Life's Important Questions. http://us.click.yahoo.com/Lj3uPC/Me7FAA/uetFAA/EbFolB/TM ---------------------------------------------------------------------~-> 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/

Thanks for your detailed help.
I will definitely add the advice given by you and Tom Matelich regarding the
use of STLPort on Windows to our company's knowledge-base.
Greetings,
Andre.
----- Original Message -----
From: "Ferdinand Prantl"
Hi Andre,
this is not only behavior of VC, all compilers, as far as I know have some include/lib paths preconfigured, to prevent you from specifying them always on command lines. You have two options how to use stlport:
1) #include
+ STLport allows it and it does not clash with the VC STL and you can do also some benchmarks... ;-) - your code has hard-coded includes of STL headers and it is not easy to switch STL then 2) #include <string> + your includes look standard for any compiler/STL - your compiler must support replacing of its own ST with the alternative one (STLport)
The 2) option you can achieve with VC by two ways:
a) do not rely on the built-in header/lib paths and provide them always on the command line or environment (I'd recommend the latter...) - it is turned on by the switch /useenv (VC7) or /env (VC6) and then you have to provide your own paths e.g. in environment:
INCLUDE=D:\STLport-4.5.3;D:\STLport-4.5.3\stlport;D:\Program Files\Microsoft Visual Studio .NET\Vc7\ATLMFC\INCLUDE;D:\Program Files\Microsoft Visual Studio .NET\Vc7\INCLUDE;D:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\include;D:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\include;D:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\include\prerelease
LIB=D:\STLport-4.5.3\lib;D:\Program Files\Microsoft Visual Studio .NET\Vc7\LIB;D:\Program Files\Microsoft Visual Studio .NET\Vc7\ATLMFC\LIB;D:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\lib;D:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\lib;D:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\lib\prerelease
b) modify the paths in the VC's configuration - see the menu Tools/Options Projects/VC++ Directories and put the path(s) to STLport into the three of them: Include (for compiler), Library (for linker), Source (for debugger - necessary only in VC6, VC7 uses absolute paths n PDBs)
I personally prefer 2) a) because if I do not want to compile everything on my machine with STLport, it prevents me from still reconfiguring of VC system paths and I can set the variables simply in a build batch for devenv /build, and in a IDE-runing batch for tho work. Then I can easily test also more versions of STLport. You can choose your favorite way,
rgds,
Ferda
-----Original Message----- From: adutoit [mailto:adutoit@stonethree.com] Sent: Wednesday, May 21, 2003 16:41 To: Boost-Users@yahoogroups.com Subject: Re: [Boost-Users] boost::date_time::posix_time and Intel Compiler 7.0?
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
, _STL::allocator > << const _STL::basic_string return stream << input; ^ detected during: instantiation of "bool={bool} boost::detail::lexical_stream ::operator<<(const Source &) [with Target=unsigned short, Source=_STL::basic_string ]" at line 192 instantiation of "Target boost::lexical_cast (Source) [with Target=unsigned short, Source=_STL::basic_string ]" 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 (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"
To: 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"
To: 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/
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/
participants (2)
-
adutoit
-
Ferdinand Prantl