From:
Tired of MSVC deficiencies, and hoping to get certain performance increase I got evaluation version of Intel C++ compiler.
Sounds familiar. I did the same. :) A nice thing about it, besides the conformance and optimisation, is that it works as a drop-in replacement for MSVC, as you said, so you can use the same IDE.
I've heard lots of good things about this compiler, and was under impression that transition from MSVC to ICL should be very smooth. Huh, I had all kinds of troubles.
If you run it in "Microsoft mode" (the default), then the transition should be smooth, as you say. However, that also means it emulates MSVC's bugs, so that doesn't buy you that much. Only when setting the options to turn this emulation off, does it show its true EDG nature, but then, as you say, the transition may not be very smooth, as some things, such as the MSVC standard library, are made for MSVC with its bugs, so using it with Intel C++ running in strict mode gives a lot of errors for the library. I also switched to STLPort, which I'm using for both MSVC and Intel C++.
First of all boost 1.29 gave up saying that it is an unknown compiler. Looking into config I figured that last known ICL was 6.0, so I just hacked it badly by redefining ICL as 600 prior to including any boost headers.
This is fixed in the CVS, so it will be fixed in the next release, at least.
I understand that it is not a good way, but hey, I am just evaluating it.
Ok now everything compiled, but code using regex failed to link. No wonder, I have not build regex library with new compiler. It turns out that there is no makefile for any intel compiler, so I tried to do it with bjam, but seems that bjam did not set CC variable; it invoked compilation with just line of flags. At this point I gave up and decided to focus on parts of my project which do not depend on regex.
It should be possible to build it using the MSVC makefile, since it's command-line compatible with it.
Next surprise was when I tried to run tests, in debug mode everything was fine, but release mode failed miserably. It appears that date_time library does not work at all with optimization. Even setting /O1 did not help, only /Od worked.
Strange. If you manage to distil it down to a relatively simple test case, you might submit it as a problem report to Intel. They have excellent customer support.
I searched through Boost Users and Dev mailing lists, found few posts discussing turning on strict ansi checks on intel, and also that in this case it is better to use STLport, since STL coming with MSVC could not be compiled in ansi mode.
Yes.
I tried to do that but can't compile STLport in strict mode either. Using STLport in regular mode did not have any effect on problems I am having.
I think I had to make some changes to STLPort to make it work, as well, but it works now, running in strict mode. Feel free to mail me off-list (as it's not Boost specific) about the problems and errors you get, and I may be able to help.
Now, my question is: are these problems well known? If they are, is there any plans to fix them in next release?
It seems some of this is not related to Boost. Since the Date/Time library works in debug mode, but fails in release mode, it appears to be compiler-related, instead. Unless there are some bugs in the library. You may want to check the same code on another compiler, for example MSVC, or g++. That should show if it's the compiler or library.
And while we at it, when should we expect new release? I know there were some discussions about mid-February, is there any update?
The schedule that has been posted, and recently confirmed, is:
The tentative release schedule for 1.30.0 looks like:
January 31 - Finish commits of major new components. February 14 - Branch for release. By end of February - Final release.
By the way, the options I use for Intel C++ is: -Qoption,cpp,--strict,--arg_dep_lookup,--no_microsoft_bugs,--no_guiding_decl s,--dep_name You'll find a description of these in the EDG manual at the EDG site. The first three should be obvious. no_guiding_decls is a pre-standard thing, and "guiding declarations" is on by default, for MSVC emulation, but it breaks code with overloaded function templates. dep_name turns on two-phase lookup, which is also off by default, for the same reason. There's also the option: /Zc:wchar_t which makes wchar_t an intrinsic character, rather than an alias for unsigned short, as in MSVC 6. Regards, Terje