From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-05-25 03:50:02
>From: "Thomas Witt" <witt_at_[hidden]>
>> From: "Beman Dawes" <bdawes_at_[hidden]>
>> Exactly. This is something I've experienced before, too, that something
>> worked on the Linux version, but not on the Windows version. I guess it's
>> because there's no MSVC on Linux, so it doesn't run in default MSVC mode,
>IIUC they are trying to build "drop-in" compilers. One can argue whether
>is the right goal, but given this premise I think they are doing quite
Absolutely. I use it mostly because of the IDE, though. :) It lets me use
the MSVC IDE, which I think works quite well.
>> One thing you may try right away, and which looks very promising, is to
>> the option "-Qoption,cpp,--no_microsoft".
>This won't work. The problem is a 100% compliant compiler is almost
>not what you want. From my experience it wouldn't let you do any serious
>in the windows environment. As most headers and code are non-compliant in a
>way that they use ms extensions, think __declspec.
Yes. You'd need a 100% non-Microsoft extensions library, if using this
option, from what I found.
Anyway, like I said in the posting before that one, I haven't had a chance
to test out the options, to find out which combination of options is needed,
to compile things like the BLL. Therefore, I said that as a starting point,
one could try this option. I did not say that this necessarily works as is.
>> Therefore, I've found that it's probably best that I install the full
>> version of STLPort, including building it, so it uses its own streams. If
>> you do this, it may well compile. I'm going to try this, when I get a
>Even full STLport(4.5.3) will not work on intel in strict mode. See below.
> > Actually, the regular intel-win32 toolset in CVS already "works" in the
> > sense the compiles run, but a bunch of tests are failing, apparently
> > because the default is to emulate the Microsoft compiler, bugs and
> > That's what I was hoping someone has a workaround for.
>This leaves us with the question whether we should publish results for the
>default setting of a compiler or whether we allow tweaking. My opinion is
>that if we allow tweaking it should be consistent throughout boost.
In what way do you mean publish results?
When it comes to configuring Boost for a compiler (with config.hpp), I guess
it could assume a certain setting of the options, that work best across
Boost. In that case, these options could well be published, so that people
know how to configure their compiler for Boost.
>Here is what I am using on win32 with full STLport-4.5.3
Have you tried this setting with the BLL examples, as well?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk