I hope that if we deal with python problems, support for vc-8_0 toolset might be officialy endorsed. There will be documentation needed about these PITA warnings and "#pragma warning ..." workaround that Jeff proposed. User would be supposed to put these pragmas before and after including boost headers, but those who care do it anyway because those (and other warnings) are actually triggered by standard library headers shipped with vc8. Doug, what do you think? B.
On 11/2/05, Bronek Kozicki <brok@rubikon.pl> wrote:
I hope that if we deal with python problems, support for vc-8_0 toolset might be officialy endorsed. There will be documentation needed about these PITA warnings and "#pragma warning ..." workaround that Jeff proposed. User would be supposed to put these pragmas before and after including boost headers, but those who care do it anyway because those (and other warnings) are actually triggered by standard library headers shipped with vc8. Doug, what do you think?
I'm not Doug but I say on the trunk this would be well received. But it can't hold up or happen on the 1.33.1 branch. -- Caleb Epstein caleb dot epstein at gmail dot com
On 03/11/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
I'm not Doug but I say on the trunk this would be well received. But it can't hold up or happen on the 1.33.1 branch.
here is quick summary of issues that we have or recently had: - compilation error in named_slot_map - fixed - bind/mem_fn_eq test failing - I'm currently re-running test with debug symbols turned on. This should make the test pass. However, I still think that some documentation of the issue is needed, as mem_fn_eq is very fragile on vc8. Actually, seeing how fragile it is, I now agree with Peter that best way to deal with it is to add info to XML that the test is not expected to pass, and if it does - it's just an accident due to lack of specific optimization or presence of debug symbols. Peter, could you pls. do that? - boost_python_vc8.dll failing to build. This is wider issue, and although we now know culprit (#undef _DEBUG in wrap_python.hpp), obvious fix does not work due to linker error (python24_d.lib). Another fix (always define _CRT_NOFORCE_MANIFEST) might have undesirable side effects that we do not understand. I will continue discussion in the other thread. - "deprecated library feature" warnings - I would just document the issue and instruct users to use appropriate set of #pragma-s before and after including boost headers. I think that's all. Doug, what do you think? B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
Bronek Kozicki wrote:
- bind/mem_fn_eq test failing - I'm currently re-running test with debug symbols turned on. This should make the test pass. However, I still think that some documentation of the issue is needed, as mem_fn_eq is very fragile on vc8. Actually, seeing how fragile it is, I now agree with Peter that best way to deal with it is to add info to XML that the test is not expected to pass, and if it does - it's just an accident due to lack of specific optimization or presence of debug symbols. Peter, could you pls. do that?
When you say "add info to XML", do you mean on HEAD or on the 1.33 branch?
Peter Dimov <pdimov@mmltd.net> wrote:
Bronek Kozicki wrote:
- bind/mem_fn_eq test failing - I'm currently re-running test with debug symbols turned on. This should make the test pass. However, I still think that some documentation of the issue is needed, as mem_fn_eq is very fragile on vc8. Actually, seeing how fragile it is, I now agree with Peter that best way to deal with it is to add info to XML that the test is not expected to pass, and if it does - it's just an accident due to lack of specific optimization or presence of debug symbols. Peter, could you pls. do that?
When you say "add info to XML", do you mean on HEAD or on the 1.33 branch?
RC 1.33.1 B.
Bronek Kozicki wrote:
Peter Dimov <pdimov@mmltd.net> wrote:
Bronek Kozicki wrote:
- bind/mem_fn_eq test failing - I'm currently re-running test with debug symbols turned on. This should make the test pass. However, I still think that some documentation of the issue is needed, as mem_fn_eq is very fragile on vc8. Actually, seeing how fragile it is, I now agree with Peter that best way to deal with it is to add info to XML that the test is not expected to pass, and if it does - it's just an accident due to lack of specific optimization or presence of debug symbols. Peter, could you pls. do that?
When you say "add info to XML", do you mean on HEAD or on the 1.33 branch?
RC 1.33.1
Why do we suddenly need to add markup for 1.33.1? This problem has been present for years.
On 03/11/05, Peter Dimov <pdimov@mmltd.net> wrote:
Why do we suddenly need to add markup for 1.33.1? This problem has been present for years.
well, indeed vc71 is affected as well, but I did not know about it. Did you? Is it mentioned somewhere in boost documentation? B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
Bronek Kozicki wrote:
On 03/11/05, Peter Dimov <pdimov@mmltd.net> wrote:
Why do we suddenly need to add markup for 1.33.1? This problem has been present for years.
well, indeed vc71 is affected as well, but I did not know about it. Did you?
I knew about the linker folding feature, but didn't know that the test wasn't failing only because folding wasn't on.
Is it mentioned somewhere in boost documentation?
No. This issue has never been reported as a practical problem; whether this is due to the fact that different functions of the same type sharing representation is rare, or due to the fact that mem_fn comparisons are rarely used, I don't know. Probably a combination of the two. The problem is not limited to member pointers. Try this simple test: #include <iostream> void f() { } void g() { } int main() { std::cout << (f == g) << std::endl; } This potentially affects function<>::contains and bind equality, but we don't have test cases for it. Yet.
The problem is not limited to member pointers. Try this simple test:
Indeed. And it also affects msvc6. Well, in this case I would leave it as it is in 1.33.1 . I will try to run regression tests with debugger symbols on, this would make the test pass. B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
participants (4)
-
Bronek Kozicki -
Bronek Kozicki -
Caleb Epstein -
Peter Dimov